Targeted malware attack piggybacks on Nvidia digital signature

When it comes to targeted attacks, Tibetan-themed campaigns seem to be a popular choice for attackers. They don’t lose momentum and just keep coming back day after day.

Recently I saw one of these attacks which had an interesting chain of events. It used multiple layers, including one that abused a legitimate, signed Nvidia application. Although we were already protecting users, I decided to dig a little deeper and find out what was happening.

The path from malicious document to installed backdoor was not as simple as you might imagine.

What I found was a multi-stage installation process involving a security vulnerability, two stages of shellcode, an archive, and an innocent application abused by the attackers. In this article we will explore how the attack worked, including technical details along the way.

Initial phase: threat delivery

At the end of January we saw reports from our Live Protection service of a campaign being blocked by our Exp/20120158-A detection. The carrier was an RTF document that exploited the CVE-2012-0158 vulnerability – the most popular choice in targeted attacks nowadays.

It was carrying a variant of the PlugX backdoor which is known to be used in conjunction with Tibetan themes.

The document file contained an embedded, specially crafted OLE document that exploited a known vulnerability in the Listview control.

The basic infiltration process follows a simple scheme: the RTF document exploits a vulnerability that triggers some shellcode, which then extracts and executes the embedded Win32 binary component.

Embedded shellcode

In this case, however, there are interesting twists in this simple scheme.

To begin with, there is not one shellcode in the RTF, but two, which are executed in two stages. Aside from making it more difficult to analyze, this is also done in order to evade anti-malware scan engines.

Opening the document in Microsoft Word will trigger the shellcode and start the infiltration process. The OLE2 document contains the first stage shellcode that only redirects to the second stage. The second stage code is cleverly hidden in the document.

Analysis of the first stage shellcode reveals the location where we should be looking for the second stage:

According to this code fragment, the data for the second stage is at file offset 0x1770D. The content there is converted from ASCII hexadecimal representation to binary code, which is then executed.

This is how the raw data of the second stage looks within the RTF:

At first glance it looks like the document contains another embedded object, a ZIP file. The highlighted section appears to be the ‘magic word’ that appears at the beginning of all ZIP files, 504b0304.

However, on closer inspection the data immediately following this magic word does not look like a ZIP file at all. The next few bytes should describe the structure of the ZIP file and the version number but they are just garbage.

It is possible that this technique might even cause some anti-malware scanners to conclude that the entire RTF file is corrupted when trying to interpret the data as a ZIP archive.

But the first stage shellcode has a slightly distorted point of view. When initiating the decode process, it positions midway into the ZIP header just a little bit misaligned – not on the byte boundary, but rather with a half byte shift.

This way the 09 09 05 53 bytes will suddenly become 90 90 55 3, which are decoded to the NOP and PUSH assembly instructions. This code is the beginning of the second stage shellcode.

Performing this half-byte shift makes the binary blob suddenly look better and some information, including portions of the file names used by the malware, is immediately revealed.

The second stage shellcode does the actual decrypting of the malware executable which is encoded with bin2hex and encrypted with a simple XOR and a fixed encryption key value of 0xBF.

The decoy

While this is happening the shellcode also extracts a document file stored at the end of the container RTF, using the temporary name ~WINWORD into the %TEMP% directory, and then opens it.

This document serves as a decoy to distract the attention from the background activities of the malware, and to assure the victim that everything is normal. As far as they can see, an RTF document was opened and a document is displayed so they can assume that everything is normal.

While the victim is reading about the Tibetan Youth Congress the malware is busy installing itself.

Machine compromise: malware installation

The binary extracted from the RTF is a WinRAR self-extracting archive. It drops three more files, Nv.exe, NvSmartMax.dll and NvSmartMax.dll.url, and then automatically runs Nv.exe.

In almost all other attacks Nv.exe would be the main malware executable. But not this time. In fact, it is not even malicious. It is a clean application, the Nvidia Smart Maximise Helper Tools. Moreover, it is digitally signed with a valid signature by Nvidia!

So far the attacker has gone to a lot of trouble just to deliver a legitimate, genuinely signed piece of software. So, what is really going on?

In fact, the malicious component being installed is the NvSmartMax.dll file that is bundled within the same archive, and dropped into the same directory as Nv.exe. The malware author is abusing the default DLL search order used by Windows. When an executable has an import from a dynamic link library (DLL), Windows searches a predefined set of folders for the necessary DLL. One of those folders is the location of the running program itself.

Therefore, if a DLL with a matching filename is present in the directory of the running application, it will be loaded not the legitimate DLL from elsewhere (system folder or the appropriate Program Files folder). This way a trusted application can be made to load a malicious DLL. Abusing the load order is not a new technique, and we’ve mentioned it on NakedSecurity before.

So, after all of these steps, we have finally reached the malicious component – NvSmartMax.dll. Happily this is detected by Sophos as Troj/Plugx-G.

The story does not stop here however!

NvSmartMax.dll is only a boot loader for the main component of the attack, which is the NvSmartMax.dll.url file (in earlier versions of the attack this file was called boot.ldr). This file is actually an encrypted block of code that is inserted directly into memory by NvSmartMax.dll.

When this code is executed, it copies the malware files to the following locations:

%ALLUSERPROFILES%\SxS\Nv.exe
%ALLUSERPROFILES%\SxS\NvSmartMax.dll
%ALLUSERPROFILES%\SxS\NvSmartMax.dll.url

Nv.exe is registered as a service under HKLM\SYSTEM\CurrentControlSet\Services\SxS. This way it will be loaded automatically on system startup, each time triggering the abuse of the DLL load order.

Remote access functionality

The attack is designed to compromise the target computer and provide the attacker with remote access. The backdoor functionality is organized into a set of functions, which are listed below.

Disk            Get drive information (type, free space)
                Enumerate files
                Create Directory
                Create/Modify file
                Copy/Delete/Move/Rename files
                Execute files
KeyLog          Log keystrokes to file 
                %ALLUSERSPROFILE%\SxS\NvSmart.hlp
Nethood         Enumerate shared network resources
Netstat         Set TCP connection state
                Enumerate UDP and TCP connections
Option          Lock workstation
                Logoff/Reboot/Shutdown workstation
                Display messagebox
PortMap         Perform port map
Process         Terminate process
                Enumerate processes and modules
                Get process and module information
RegEdit         Enumerate/Create/Delete registry entries
Screen          Capture screenshot
Service         Get service information
                Change service configuration
                Start service
                Control service
                Delete service
Shell           Create remote shell
SQL             List SQL drivers
                List SQL data sources
                Execute SQL command
Telnet          Create telnet connection

Command and Control

The backdoor also collects system information, and sends it to the Command and Control (C&C) server. This information includes:

• Computer name
• Username
• CPU
• User token
• User group
• Total/Free memory
• OS Version
• System time

When connecting to a C&C server, four possible IP addresses are used, all of which are hardcoded in the malware. The current sample uses the same value for all four, pointing to a server residing in Thailand.

The relevant information returned by the server is placed between markers. The start marker is DZKS and the end marker is DZJS (this behavior is also reported in some Baidu variants seen by the folks at Norman).

Why? Doing this enables the backdoor to hide its C&C communication as a small block within a much larger data flow, that will look innocent. Detailed and thorough analysis is required in order to spot the malicious communication embedded somewhere in the middle.

Miscellaneous observations

In addition to all the usual backdoor features listed above, the code has two other features more commonly found in commercial software – a demonstration mode and an error log.

The backdoor demo mode is activated by an internal flag – a reminder message is displayed by two parts of the code. Apart from the display of these two messages, there are no other restrictions in the demo mode. The sample that we investigated did not have the demo switch turned on.

When an exception is generated during execution, information is saved (to %ALLUSERSPROFILE%\SxS\bug.log), which can be retrieved later by the malware author and used to improve the quality of his creation.

And what is the moral of this story?

The first lesson to learn here is, of course, the benefits of good patch discipline. Step one of this attack uses CVE-2012-0158, a vulnerability that was patched by Microsoft in April of 2012. The fact that attackers are still using it in targeted attacks some 9 months later is a clear indication that too many of us are still not taking the first basic steps towards security.

The second lesson is mainly for application developers. Even if you are not developing security applications, you must consider the risks that your software introduces to your customers’ networks. Microsoft have published advice on reducing the impact of DLL load order abuse for both users and developers.

In this attack, Nvidia’s software was abused but it could just as easily have been any of a thousand other developers.