STE WILLIAMS

We’ve written about the PlugX malware before on Naked Security, thanks to a pair of technical reports from SophosLabs Principal Researcher Gabor Szappanos (Szappi).

Szappi presented an inside look at this intriguing malware family in his analysis of PlugX Version 6, published back in May, and of its close cousin Smoaler, published in July.

Interesting tactics used in these malware samples include:

• They were distributed in believable-sounding emails.
• The emails included booby-trapped attachments.
• The attachments exploited a vulnerability in Micrsoft Word’s handling of RTF files.
• The attachments had a Tibetan political theme.
• The malware unpacked itself in several stages.
• The malware loaded and launched its own payload executable, bypassing the operating system program loader.
• The malware carried with it a digitally signed legimitate application, used to initiate infection.
• This legitimate application was tricked into loading a malicious DLL.
• The final payload opened a backdoor allowing the crooks to feed the malware instructions remotely.

PlugX revisited

Now, Szappi, and fellow researcher Xinran Wu of SophosLabs in Sydney, have been looking into what seems like another example of the PlugX family.

They have come across a curious mixture of similarities and differences.

This particular threat isn’t yet very widespread: we have had only one report directly from the wild, together with the email in which it was delivered, plus a handful of samples from other sources.

What we therefore don’t yet know is whether the PlugX malware writers are practising on new targets, experimenting with new malware, or (let us hope!) finding it increasingly difficult to get an infection foothold these days.

The primary differences in this attack are obvious:

• The malware is aimed at Japan.
• The Tibetan theme is replaced with a managerial one.
• The malware exploits a vulnerability in popular Japanese word processor Ichitaro, not Word.

There are numerous similarities, too:

• The malware loads and launches its own compressed payload executable, bypassing the operating system program loader.
• The malware carries with it a digitally signed legimitate application.
• This legitimate application is tricked into loading a malicious DLL.
• The final payload opens a backdoor allowing the crooks to feed the malware instructions remotely.

How the malware arrives

The malware arrived in a booby-trapped attachment to an email.

The email looked like this:

Subject: Personnel info for 26 Nov and 30 Nov

Attachment: PersonnelInfoFor26NovAnd30Nov.jtd

Many of you may have it already, but I have received personnel information as of 22 August and 27 August from XXXX.

I am sending this to you in an attachment.

Please check it. Thanks.

The .JTD extension is used by Ichitaro document files.

We can’t give you precise details about how the exploit works or how to mitigate it (we haven’t been able to configure an Ichitaro environment in which it triggers), but we recommend that all Ichitaro users look at the latest security bulletin from the product’s vendor, Justsystems.

The bulletin details a recent patch to protect you from files booby-trapped with exploits against the vulnerability CVE-2013-5990:

[JS13003] Risks of executing malware exploiting a vulnerability in Ichitaro. Published 2013-11-12.

Summary: Some of our products have been found to contain vulnerabilities. If exploited, this could allow arbitrary code execution. We have listed the affected products, with patches and mitigations, below.

Vulnerability: If a document crafted to exploit this vulnerability is opened, it will try to execute malicious code.

By simulating the execution of the exploit so that the shellcode in the document extracts the next stage of the malware, we can see what is supposed to happen next.

How the malware loads

A WinRAR self-extracting archive, containing three files, is written to disk and run:

The self-extractor turns control over to starter.exe, which is a 2011-vintage digitally signed application from anti-virus vendor Kaspersky:

The Kaspersky component is designed to load a DLL called splash_screen.dll, but doesn’t force that DLL to be loaded from a specific directory on the disk.

So, if there happens to be an imposter DLL with that name somewhere in the Windows PATH (which includes the current directory) the imposter will be run instead of the genuine DLL.

→ This is known as an insecure library loading vulnerability, and can be exploited against any program that denotes the DLLs it neeeds merely by name, e.g. MY.DLL, rather than by using unambiguous path-and-file names, e.g. C:SPECIFICMY.DLL. Warning to programmers: always specify DLL filenames unambiguously when calling LoadLibrary().

The imposter DLL reads, decompresses and loads the payload file, splash_screen.dll.sp1.

Here is the code in the imposter DLL that calls the Windows function RtlDecompressBuffer() in the system library NTDLL:

As a very mild anti-analysis trick, the decompressed data is nearly, but not quite, a proper Windows DLL file.

The two instances of XV in the diagram below are supposed to be MZ and PE respectively, where MZ denotes that a file is a Microsoft-format executable program, and PE denotes that it is a Portable Executable, or Windows program:

The absence of MZ and PE is irrelevant to the imposter DLL, which doesn’t rely on Windows to load the decompressed program.

Instead, the imposter DLL includes its own program loader, patching the splash_screen.dll.sp1 payload program correctly into memory itself, and then jumping to it.

While patching the decompressed payload, the imposter DLL uses the header information (amongst other load-time data) shown above, but once the loader is ready to jump into the payload program, the header information is redundant.

So the imposter DLL overwrites the payload header with zeros before transferring control to the payload itself.

That prevents malware analysts from easily dumping the running payload program out of memory onto disk in a form that would immediately make sense to Microsoft’s official Windows debugging tools.

Once again, this acts as a mild anti-analysis trick.

→ In practice, you can bypass this sort of anti-analysis by using a debugger to halt the imposter DLL immediately after the abovementioned call to RtlDecompressBuffer(), and dumping the relevant header data before it gets wiped out.

How the malware works

One the payload program has been loaded into memory and prepared for use, the imposter DLL jumps to it.

The payload connects to a server at www DOT mofamails DOT com for instructions on what to do next.

Like many bots or backdoors, this gives the infiltrators very general control over the infected computer, including functionality to:

• Collect running process and module information.
• Load and reconfigure system services.
• Start and stop processes.
• Create and delete files.
• Manipulate the registry.
• Acquire detailed system information.
• Log keystrokes.
• Take screenshots.
• Monitor network resources and connections.

What we can learn

The obvious questions raised by this attack are: why Japan, and why Ichitaro?

One answer is, “We don’t know.”

Another, sadly, is, “Why not?”

As far as we can tell, the PlugX creators acquired an Ichitaro exploit, giving them a way to attack victims they couldn’t reach before, so they decided to try it out.

What this reminds us is that we are all potentially at risk due to vulnerabilities and exploits, not just those of us who use the dominant operating systems and products in the market. (Apple OS X users take note!)

In short:

• Avoid opening attachments you weren’t expecting, no matter how believable they might sound.
• Keep up to date with patches against known vulnerabilities in all the software you use.
• Use an on-access (real-time) virus scanner, and ensure it is up to date.

Follow @duckblog

Note. Sophos products detect and block this malware as follows:

• Booby-trapped documents: Troj/DocDrop-AZ

• The malware dropped: Troj/Plugx-W

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/SMrO6rcNkRw/