Wednesday, December 19, 2012

EXPLOIT-KIT Java User-Agent downloading Portable Executable - Possible Exploit Kit

In our most recent rule pack, amongst the 39 new rules were two very important rules that may require a bit of analyst work when you see them alert.

The two rules I am referring to are:
* 1:25041 <-> ENABLED <-> EXPLOIT-KIT Java User-Agent flowbit set (exploit-kit.rules) 
* 1:25042 <-> ENABLED <-> EXPLOIT-KIT Java User-Agent downloading Portable Executable - Possible Exploit Kit (exploit-kit.rules)
25041 looks for a Java User-Agent outbound from your network in the User-Agent string of the http header.  While it's not totally unusual for Java itself to form http requests on the network, this will happen from time to time, that's not what we are focusing on.

25042 looks for an executable being downloaded onto the system, first checking to see if the flowbit from 25041 is set.  Meaning, that it's not a browser downloading an executable, it's actually Java.

From my continuing work on the "exploit-kit" category of rules, I've noticed that almost every single time a Java exploit is used to bring download an executable onto a compromised box, (which is almost every exploit kit I've seen so far) it's malicious.  In fact, we've had these rules in our test systems for about a month and we've seen zero false positives.

Now we know that every network is unique and while we didn't experience any false positives in the test systems that we have, I am sure they will occur in real life, so let me give you a hint of what to look for.

#1 -- Look at the URL that was the referrer for the download.

In the Sourcefire interface, we show you the hostname and URL that prompted the initial download of the file.  In this case, it's not so obvious to tell if this one is malicious, but if we look at the http header of the file being actually downloaded:

#2 -- Look at the header:

You can see the file is plainly named "calc.exe".  So a couple things indicate that this is bad.  "calc.exe" is the name of the built in calculator program that is installed on every Windows machine in the world.  There's no way that this file needs to be downloaded from the internet.  Second thing is, the name of the file being downloaded is different from the name of the file being requested.  Third, this is an indicator of the Blackholev2 Exploit Kit.

Let's look at another example.

While not obvious to the common observer, this is also an indicator of the Blackholev2 Exploit Kit downloading its payload.  If you'll noticed, it almost looks like there is a "mac address" in the url.  (It looks like a mac address, even though it's clearly not, we detect this as well with another rule shipped recently: 25043).  If you look at the header on this one:

You can see "readme.exe" right there under filename.

While it may be an extra layer of protection to write rules that look for these known bad files in the blackholev2 exploit kit, the way I wrote 25041 and 25042 will catch much more.

Here's an example of another exploit kit that was simply caught by these rules:

...and the header:

Now, even if you don't have a Sourcefire device you can still dump out the "extra data" fields from your unified2 logs and see exactly which url's prompted these downloads like I show above.  More information about how to use these fields can be found here:

Happy hunting!

Tuesday, December 11, 2012

Triggering Miniflame's C&C Communication to Create a Pcap

There are times when a malware's payload doesn't trigger because of a condition or an environment that the malware requires in order for it to execute its payload. Such is the behavior of the miniflame malware that we encountered recently.

To create a Snort signature, the network behavior of the malware needs to be triggered. The miniflame report from Securelist doesn't exactly specify the best setup to trigger the behavior. If this is an incident response, which is usually the case for a sophisticated malware like miniflame, and you need a signature, you have limited time to analyze the malware deeply.

According to the report the C&C communication is triggered by the .ocx files. The only samples that we had available are the 4.XX versions of the miniflame's .ocx components, which were named differently from the files mentioned in the report - so we have to sift out which files are which and then rename the file(s) appropriately before analysis. The files are all dll/ocx files.

We tried Regsvr32 /s [filename].ocx to trigger the communication but we didn't see any C&C activity in wireshark. Instead, after inserting the registry key below re-running the malware or rebooting the PC, the network behavior is triggered. This registry key has been also used as a prerequisite for other malware to talk to the network, like Conficker.


The CurrentControlSet\Services subkeys under HKLM/SYSTEM contain entries for standard and optional Windows services, such as device drivers, file system drivers, and Win32 service drivers. The Network Location Awareness (NLA) service provider enables Windows Sockets 2 applications to identify the logical network to which a Windows computer is attached.

According to the report, “If the file “icsvnt32.ocx” is installed without errors, the module then changes the target registry key’s default value to “%windir%\system32\icsvnt32.ocx” - so instead of reverse engineering the code further, we just need to modify the value of ServiceDll and point it to our ocx file.

The network packets below were captured and as we can see from the POST request (highlighted in orange) the malware communicated with the C&C server:

As we can see the malware connected to, which is one of the C&C servers listed in the report:

With live traffic now successfully captured, detection was easy - a combination of the URL from the packet above and any of the hosts the malware is known to connect to. It’s been released as Snort SID 24406.

Thursday, December 6, 2012

Quarian: Reversing the C&C Protocol

Win.Trojan.Quarian was reportedly first found in a leaked email from the Syrian Ministry of Foreign Affairs. It arrives on the victim's machine via a PDF document. The PDF contains an exploit for CVE-2010-0188 which, if successful, passes execution to embedded shellcode. The shellcode then extracts 0x8A218 bytes at offset 0xD98 in the PDF decrypting this with a XOR cipher and saving it as "%TEMP%\explorer.exe", which is the main malware executable. An embedded PDF document "%TEMP%\964.PDF" is similarly dumped and a new Adobe Reader process is launched to display it. The user is presented with this PDF with the malware running in the background.

The malware's CNC traffic will depend on the proxy settings of the infected machine. If a proxy is configured then the malware will attempt to connect to it with the following:

User-Agent: Mozilla/4.0
Content_length: 0
Proxy-Connetion: Keep-Alive
Pragma: no-cache

The malware's CNC host "" is hardcoded. Also notice the misspelled "Proxy-Connetion" and the underscore and lowercase 'l' in the header "Content_length". These anomalies in the proxy connection are easy to spot in the main malware executable and on the wire. However, the direct CNC traffic is not. Every time the malware loads it sends 8 bytes to "". Since the CNC server was not online at the time we began our research we couldn't make any observations on the response to these 8 bytes. We decided to reverse the CNC protocol and see if we could send the malware commands:

Starting with the hypothesis that the first 8 bytes sent to the CNC server were some kind of key, we attached the malware process in a debugger and began to observe the malware's behavior when bytes were sent as a response to the malware's initial 8 byte message.

We noticed that when sending 8 NULLs in a response some of the comparisons made by the malware code would result in the 8 byte key that was sent. From this observation we knew the malware was expecting an XOR key from the CNC server in order to process commands. After some trial and error, we had a local CNC server up and running:

The CNC protocol uses a XOR key on both sides to communicate commands and responses. If a direct connection exists (or after starting a proxy connection) the malware will send CNC an 8 byte XOR key. CNC will then respond with its own 8 byte XOR key XOR'd with the malware key. When CNC sends a command, it XORs each byte of the command with the cnc_key, and when the malware sends a response it XORs each byte of the response with the mal_key:

   Malware            Command and Control
-------------         -------------------
      mal_key  ---->
               <----   mal_key ^ cnc_key
               <----       cmd ^ cnc_key
res ^ mal_key  ---->

Commands are implemented in a switch statment where 0x01 dumps various system info and 0x06 starts a shell. If a command has an argument, it immediately follows the command byte. See the IDA dump below:

As always, the VRT has coverage for this threat with SIDs 24858 & 24859 on the Snort side and Sig Win.Trojan.Quarian for Clamav.