PDF exploits targeted through Blackhole exploit kits.

PDF exploits have been targeted by Blackhole exploit kits for some time now. The Blackhole exploit kit will deliver various malicious PDF files to a user if the victim is running a potentially vulnerable version of Adobe Reader. When these PDFs are opened through Adobe Reader, a known vulnerability is exploited which will then compromise the user’s machine.

Let’s look at the de-obfuscated portion of the Blackhole exploit kit. The exploit kit for this sample was delivered from “flightpub.net/l/src.php?case=46677c190b37f2d6”.

The de-obfuscated code above shows how an iFrame of 1x1 pixels is created to load a malicious PDF file residing at “./content/ap1.php?f=97d19::182b5” or “./content/ap1.php?f=97d19::182b5”, depending upon the version of Adobe reader installed. These two files are hosted on same the domain - “flightpub.net”.

The absolute paths of the malicious files are,

hxxp://flightpub.net/l/content/ap1.php?f=97d19::182b5 and
hxxp://flightpub.net/l/content/ap2.php?f=97d19::182b5

For analysis purposes, we can manually downloaded the aforementioned PDF files. The PDF files contain a JavaScript object, which contains obfuscated JavaScript, as shown below:

The JavaScript code loops through array ‘ar’ and converts each element of the array with logic included in function ‘test2()’. The de-obfuscated code targets a three year old vulnerability in Adobe Acrobat reader.

Let’s take a look at the some of the de-obfuscated code,

A stack based buffer overflow vulnerability exists in the ‘getIcon()’ method, which is detailed in CVE-2009-0927.

This vulnerability is widely targeted by various versions of the Blackhole exploit kit. I have seen different variants of the payload URL used to host these PDF exploits. The URL pattern changes with different variants of the exploit kit. The different URL path patterns seen so far are:

/content/ap1.php?f=97d19::182b5
/content/ap2.php?f=97d19::182b5
/content/fdp1.php?f=63
/content/fdp2.php?f=63
/content/adfp2.php?f=193
/content/adfp1.php?f=193

The common pattern in the above URL paths are ‘/content/’ and ‘.php?f=’. By identifying these common patterns one can write a network signature on URL strings to catch these malicious URLs.

Let’s take a look at couple of snort signatures for detecting these malicious URL’s.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS Blackhole Acrobat 1-7 PDF exploit download request 3"; flow:established,to_server; content:"/fdp1.php?f="; http_uri; reference:md5,8a33d1d36d097ca13136832aa10ae5ca; reference:cve,CVE-2011-0611; classtype:trojan-activity; sid:2014052; rev:2;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS DRIVEBY Blackhole PDF Exploit Request /fdp2.php"; flow:established,to_server; content:"/fdp2.php?f="; http_uri; reference:md5,8a33d1d36d097ca13136832aa10ae5ca; reference:cve,CVE-2011-0611; classtype:trojan-activity; sid:2014035; rev:2;)

Most of the vulnerabilities targeted by various exploit kits are public. Making sure all of your applications are updated regularly with the latest security updates will go a long way in helping to keep your computer secure.

Pradeep

Analysis of a Blackhole Exploit page

The Blackhole Exploit kit is still a very popular attack on the web. They are many variants of the threat. Here is a detailed analysis of one Exploit kit page and the obfuscation technique leveraged by the attack.

In this example, the exploit is heavily obfuscated. The exploit has been encoded and stored as HTML and JavaScript is used to decode the payload and run it.

Blackhole Exploit encoded ans stored in HTML

JavaScript decoding loop

To decode the exploit, I used Malzilla, a popular JavaScript deobfuscation tool. Malzilla cannot manipulate the DOM like a real web browser, so I needed to copy and past the HTML-encoded data into a JavaScript variable. I then changed the JavaScript loop slightly, to extract the data from the variable instead of the HTML. Instead of doing an eval() of the code, I replaced the last line with document.write(c) to output the result.

The code below was delivered by Malzilla following the aforementioned adjustments (I've cut out the encoding data):

Modified code to run in Malzilla

I can now execute the script. The obfuscation requires many passes to fully decode the data andit takes quite a while to complete.

Script executed by Malzilla

Now, let's examine the output from Malzilla. The first part addresses a "Please wait page is loading..." message, very typical of the Blackhole Exploit kit so that the victim remains patient while the exploit code executes.

Then, the JavaScript figures out which browser is visiting the page, what plugins are installed and with which version. This is subsequently to decide which exploit payloads to deliver.

Browser fingerprinting

Depending on what browser information was obtained, different exploits can be delivered. It could for example be a malicious Java applet:

Launch a malicious Java applet

... or a remote code execution targeting a known Internet Explorer vulnerability:

MDAC exploit for Internet Explorer

.. or a malicious PDF file:

Malicious external PDF file

... or a malicious Flash file:

Malicious Flash file

Separating the exploit into an encoded payload and a decoding loop made it easier for the exploit kit creators to create an infinite array of different pages in order to evade detection. The Exploit kit is also more sophisticated than many other exploits as it is able to use the right exploit for each visitor.

Incognito exploit kit

Exploit kits are becoming an increasingly popular means of spreading attacks. Umesh recently blogged about seeing a spike in the usage of the Blackhole exploit kit. This exploit kit targets multiple known vulnerabilities present in a victim's browser, increasing the probability of a successful compromise. Various exploit kits differ in the way they are packaged, designed and implemented. The most distinguishing factor among different exploit kits is how exploits are obfuscated, in order to bypass various security controls.

Recently, I have noticed a significant increase in the usage of the Incognito exploit kit. Similar to the Blackhole exploit kit, Incognito also targets vulnerabilities in Java and Adobe products. Another item that stands out to differentiate among these exploit kits is the URL patterns used. Most of the time, the URL pattern remains same within a given exploit kit. A quick look at malwaredomainlist shows the usage of common patterns used in URLs associated with Incognito.

Common URL patterns for Incognito:

Code obfuscation (Formatted for good view),

De-obfuscation of the aforementioned JavaScript, shows the exploit kit carrying out different attack vectors. Let’s analyze different pieces of the de-obfuscated code.

Object Initializations and other functions,

Iframe Injection:

Google safe browsing reports this URL to be malicious. Visiting the above link redirects you to fake search portal delivering ads hxxp://searchportal.information.com/?o_id=164060&domainname=register-domain-names.info.

Step 0: This is the entry point of the malicious code. It completes required initializations of objects for vulnerable ActiveX controls. Upon the successful creation of objects, it launches the first attack vector by calling function 'gr', which injects a malicious file. The code then moves on to Step 1.

Vulnerability Details:
CVE : CVE-2006-4704
Name : Microsoft Visual Studio 2005 WMI Object Broker Remote Code Execution Vulnerability

My previous blog post describes a different version of obfuscated JavaScript targeting this vulnerability.

Step 1 : This code targets the “Java Deployment Toolkit”.

Vulnerability Details:
CVE : CVE-2010-1423
Name : Java Deployment Toolkit insufficient argument validation

Step 2 : This creates Iframe tags for malicious PDFs.

This example illustrates how the multi-level attacks targeted by exploit kits are becoming a favored choice of attackers these days. More importantly, the creation of automated tools to deliver these exploits, provides attackers with the opportunity to launch campaigns on a frequent basis, with limited technical knowledge.

Pradeep

Increase in use of PDFs for spam

In recently weeks, I have noticed an increase in the use of PDF files for spam. Instead of uploading an HTML page using a compromised account, as seen shown in a previous post "Hundreds of College and Government websites still redirecting to fake stores", spammers are instead uploading PDF files. My guess for their motivation, is that PDF files are less likely to be checked for spam than plain HTML pages.

Most of the spam PDF files contain text only.

Example of spam PDF

The goal of the spammer is to redirect users to a malicious website. This is done using a piece of JavaScript embedded into the PDF file.

JavaScript snippet from the PDF file

In this example, the user is redirected to hxxp://searchglobalsite.com/in.cgi?23 (the URL is obfuscated in the PDF file) which then redirects to hxxp://www.results-today.com/.

hxxp://www.results-today.com/

The list of websites hosting spam PDF files is very similar to what I have reported earlier. It includes college web sites, governmental sites, and wiki pages, such as the following:

• hxxp://forum.wiki.usfca.edu/file/view/file10.pdf
• hxxp://www.lapspecs.com/wiki/_media/http:cr43.pdf 
• hxxp://www.dublincore.biz/accessibilitywiki/ImplementersNews?action=AttachFile&do=get&target=dub14.pdf
• hxxp://wikiglobe.org/en/images/c/c9/Texas-veterans-home-loan.pdf
• hxxp://wiki.solusvm.com/images/c/c6/Uk-cash-loans.pdf
• hxxp://nspcommunity.net/wiki/images/e/e8/Small-loan-business.pdf
• hxxp://wiki.fossasia.org/images/6/67/Ship-loans.pdf
• hxxp://vuas.net/~dpmccann/mw/images/Real-estate-mortgage-loans.pdf

A Google search for "cialis viagra canadian pharmacy filetype:pdf site:.edu" for example, provides plenty of other examples.

-- Julien

Analyzing PDF exploits for finding payloads used

We have written a couple of previous blogs which focus on an in-depth analysis of PDF exploits as this is yet another techniques used by attackers to package malicious code and avoid antivirus detection. We have also written in the past about different decoding filters used to hide the malicious code inside PDF files. In this blog, we will examine yet another in the wild PDF exploit which has hidden it’s malicious code under different objects. We will also identify the final payload used to carry out the attack. The malicious PDF sample was retrieved from “hxxp://sj1s.co.cc/games/pdf.php?f=21”. Here is the PDF source code:

The above PDF file is small in size and contains clear text JavaScript. Let’s look at object 1, which contains malicious JavaScript code. This code is very simple to read and understand. The JavaScript accesses some property values declared elsewhere such as “this.producer”, “this.subject” etc. Now, where are those declared values coming from? If you look at the object 3, you will notice that all other variables are accessed from these object properties. The strings used like “eval” and “StringfromCharCode”, suggest this JavaScript is used for malicious purposes. Now, we have 3 different strings from object 3, which will be used in the malicious JavaScript code.

1) Property Producer contains a long array of values
2) Property Subject contains string “eval”
3) Property Title contains string “StringfromCharCode”

We will use Malzilla for decoding this malicious JavaScript. For that, we need to substitute the respective values into the variables. We will re-create the JavaScript code for Malzilla using those values to as it with the decoding process. We will need to look at the code carefully, because the array contains some substitution and arithmetic operations. Here is what we need to substitute:

Let’s take the first value from the Producer property array, which is “t9.5*w”. The malicious JavaScript contains one variable “w”, declared with a value of 4 and then there is another function (axp = axp.replace\(/t/g,'2'\);), which will replace character “t” with value 2. So the first integer of the array will become (29.5*4) = 118. When we substitute the whole array with values of “t” and “w” we can create the final simple JavaScript code:

We will now decode the above simplified code using Malzilla. The decoded content is shown below:

The decoded content contains malicious heap spray code, shellcode and code for attacking different Adobe vulnerabilities. However, we have to yet identify what this malicious code does once it exploits the vulnerability? What payloads does it use for the exploit? For this we need to identify the shellcode used. Here is what the shellcode looks like:

The shellcode used, is in %u Unicode-encoded format. We will convert this code into byte code or executable code for further reversing using IDA pro or OllyDbg. For this, we will use favorite online tool Shellcode 2 EXE. We will copy and paste the shellcode bytes from the variable, which will generate a sample “.exe” file to analyze. Here is the screenshot:

Now, we have executable file to analyze. So let’s open in IDA pro first to look at the strings used inside the payload. Here are the strings found,

The string shows that this payload is going to download additional files on the system. Now let’s open this file in OllyDbg for obtaining the malicious URL used inside the payload.

The shellcode starts with NOP instructions followed by another loop which will decode the malicious code. Look at the instructions above, inside the highlighted box. Those are the instructions which are used to decode everything. By stepping through the code, we come to know that there is an instruction that will compare the value with E9 to exit and another, which is XORing byte with a value of 31. We will put breakpoint at the RETN instruction. The code will successfully run and we will be presented with the decoded content, which contains more interesting strings.

Look at the highlighted string above in the dump area. This URL will be used to download another binary from the server. Now, we have identified this malicious payload and the URL used. For reference, here is the result from ThreatExpert for the same shellcode.

That’s it for now.

Umesh