Malware Analysis [Part 1]


Lately I’ve been hunting for some interesting malware to reverse engineer. That opportunity presented its self in the form of a drive-by exploit being hosted on the popular website around November 10, 2013. The team at Barracuda Labs provided a brief yet very informative article on how a vulnerable machine would have been exploited via the hostile javascript being hosted at the compromised site. In their analysis of the drive-by exploit they also provided a full PCAP of their vulnerable machine being exploited and the  payload being delivered.  The provided PCAP is a goldmine of malicious javascript,  java/PDFs and the malware used post-exploitation, which I’ll be relying on for the majority of my analysis (Thanks Barracuda Lab!).

  • Part 1 of this series I’ll be focusing on the initial exploitation and delivery of the malware. Starting with the script used to download the exploits and malware, then exploring methods on how to carve out the malicious files out of the Barracuda Lab’s PCAP,  from there I’ll deobfuscate the Javacsript used to exploit a vulnerable host.
  • Part 2 will cover static analysis of the shellcode and the malware used post-exploitation via tools such as Ida and Dependency Walker.
  • Part 3 will be done through dynamic analyis via tools such as Windbg and Process Monitor.

A word to the wise: This article was written with the assumption that the audience is made up of either aspiring network security enthusiasts or network security professionals.  Some of the URLs provided in this article may still be live and contain malicious scripts and exploits. Please exercise caution if you decide to interact with some of the provided URLs.


Analysis of the malicious Javacsript used to download the exploits 

When was still compromised a user would have been greeted with the following script located in index.html of

After substituting the variables to the appropriate string, the script now looks like this:

When a script like this is implemented into the <body> tag of a webpage, it will try and contact the remote host, in this case being i .crackedcdm .com and run the script held in i.php. As you can see in this wireshark dump.
After the GET request was fulfilled the victims browser would now attempt to execute the following script found in i.php:

Which would create a hidden iframe and cause the browser to call out to (Warning: Malicious URL):
hxxp:// p68ei5 .degreeexplore .biz:53331 /51fd0e1afd1243f00bd4f6473a0bfc41.html

Once the browser reaches this point, a series of exploits would be downloaded and executed into the victims browser.  By using the wireshark filter http contains p68e15 .degreeexplore .biz a complete listing of all the malicious files used to exploit a vulnerable system can be seen here:


Carving out malicious files from the Barracuda Lab Packet Capture

Since my goal now is to analyze the files used to exploit and maintain access to a compromised host, I need to carve out files of interest from the provided PCAP so they can be used for later analysis.  Opening the provided Barracuda Lab’s PCAP,  I’ll use Wireshark to carve out anything malicious.  As  mentioned earlier, I’ll rely on the Wireshark filter http contains p68ei5 .degreeexplore .biz, to provide a summary of all the exploits and malware used to compromise the victims system.


As you can see, this filter provides a summarized view of all the malicious items.  There are a couple ways to carve out the necessary malicious files via Wireshark, you can either do it manually and select which file you would like to specifically export, or you can have Wireshark export everything it can carve out of the PCAP all at once.  I’ll start by doing a specific extraction of the 1384112580.jar file.

While  using the filter http contains p68ei5 .degreeexplore .biz, I select Packet No. 2565, then in the dissector frame expand Transmission Control Protocol and look for where it displays Stream index, in this case the Wireshark Stream Index has a value of 74, meaning it’s the 74th TCP stream to be found in the Wireshark trace.


By using the Stream Index I can now set a filter to follow that particular TCP Stream, by using the filter eq 74. Now the entire interaction for downloading the 1384112580.jar between the malicious host and the local host is filtered in the Wireshark window. To extract that specific jar file, I look for a HTTP 200/1.1 OK (application/java) response.  (the HTTP 200 response indicates that the server was able to retrieve the requested entity from the GET request.)



I then right click on the HTTP/1.1 200 OK packet and in the dissector frame expand Media Type and right click on Media Type: application/java (13034) where I then select Export Selected Packet Bytes and save the file as 1384112580.jar.


Excellent, now that I have the malicious .jar file I can do a quick analysis on it via in an attempt to discover what kind of vulnerability it is attempting to trigger in a vulnerable Java application. As of now, the malicious .jar file is detected by 5 out of the 47 AV scanners available at (Results). Avast and Microsoft both report it using Exploit:Java/CVE-2012-1723, which states that the following versions of Java are vulnerable:

  • JDK and JRE 7 Update 4 and earlier Java SE
  • JDK and JRE 6 Update 32 and earlier Java SE
  • JDK and JRE 5.0 Update 35 and earlier Java SE
  • SDK and JRE 1.4.2_37 and earlier Java SE

Great, now that I have this information I’ll make sure my version of Java on my vulnerable VM is susceptible to this particular exploit. I ended up downloading Java 6 Update 32 from onto my vulnerable VM.

Carving out all the files via Wireshark

This method is incredibly simple, and you’ll probably be wondering why I didn’t do this in the first place. To extract all possible HTTP objects from a PCAP via Wireshark, goto:
File –> Export Objects –> HTTP.
The following screen will then pop-up:


Another window will pop-up asking for the name of the folder you’d like to use, choose a name then click OK and most of the HTTP objects from the pcap will be carved and dumped into the specified folder. Wonderfully simple. Another option if for some reason the mass export was not successful in dumping all of the files, is to use Network Miner which can be found here.


Deobfuscating the malicious Javascript

The file 51fd0e1afd1243f00bd4f6473a0bfc41.html contains all of the malicious scripts used to download and execute the exploits. The html page is obfuscated, but when rendered in a browser the obfuscated scripts creates an applet that refers to the malicious .jar files that were hosted at p68ei5 .degreeexplore .biz.

On first glance of the source code, it appears as a garbled mess with an odd combination of element tags and a moderately sized section of Javascript that use seemingly random variable names and no formatting.  Before I started deobfuscating the Javascript manually, I used to format the Javascript to make it have an easy to read structure.

Since I had assumed the obfuscated Javascript would have to decode its self into an executable script,  I was able to take advantage of this assumption by using the obfuscated Javascript to translate its self so I could have much more readable code. This was done by simply using the Javascript function console.log(variable) which would output the contents of the variable into the browsers console window, effectively translating the garbled mess into the familiar functions of Javascript by the same methods the obfuscated Javascript used to translate the content on html page into an executable script.

(I apologize about the use of screenshots, I was concerned that I could get flagged for a compromised website by hosting the actual scripts used in the exploits.)

(Chrome render of the obfuscated html page, you wouldn’t see this on a compromised website I’m just displaying it for reference)

51fd0e1afd1243f00bd4f6473a0bfc41.html (Obfuscated Source Code 1/2)

51fd0e1afd1243f00bd4f6473a0bfc41.html (Obfuscated Source Code 2/2)

51fd0e1afd1243f00bd4f6473a0bfc41.html (Deobfuscated) Comments were made by me.514d0e1_javascript_decoded

On line 100 of the deobfuscated Javascript, the Exploit_Code variable is executed. When I did a console.log(Exploit_Code) I was able to capture the translated malicious Javscript.

Deobfuscated Exploit Code

Looking at lines 2106 – 2109 shows where the exploit code refers to depending on the detected version of Java in the victims browser.

As you can see, it points to the host discussed earlier, where it then downloads the Java .jar file, if this applet is executed in a version of Java that is vulnerable to this specific exploit the applet then downloads the malware used for maintaining access to the compromised host.

Another point of interest, here the deobfuscated javacsript downloads an obfuscated .tpl file and  a malicious .pdf depending on the detected version. exploit_code_deobfuscated_3

Now time for the 1384112580.tpl file. I didn’t end up deobfuscating all of the decoding mechanisms in the .tpl file like I had in the .html file. Since I knew by this point all I needed to do was find where in the .tpl file the code executed the decoded version of the contents found within the .tpl.

1384112580.tpl The variable JQsj seen on line 271 contains the deobfuscated exploit (Circled in red)

1384112580.tpl  On line 272 I added console.log(JQsj) to display the contents of that variable. 1384112580_tpl_2

I renamed the 1384112580.tpl to 1384112580.tpl.html so I could run the Javascript in chrome. After running the file, Chrome’s console presents the deobfuscated script used to exploit a vulnerable system. But this time the deobfuscated .tpl file proved to be a bit more interesting then the .html file because the shellcode* used to deliver the malware seems to be present in the Javascript.

*(I am assuming it is shellcode, Part 2 of this series will provide some static analysis of the alleged shellcode.)

This is can be seen on line 467 of the deobfuscated tpl, where the hex is stored into the variable jo.

1384112580.tpl Deobfuscated

Unlike the previous .html and .jar which was used to trigger an old vulnerability in Java and/or Adobe (via the .pdf), the exploit code used in the .tpl file seems to be targeted at Internet Explorer. And even more interesting, the vulnerability that it was attempting to trigger in IE looks like the exploit used at Pwn2Own in 2013 by VUPEN (CVE-2013-2551). Which is now available in Metasploit, so it’s safe to assume that it’s widely available and commonly used.


Here’s a quick summary of the carved out malicious files and their associated Virustotal reports:

  • 1384112580.jar &  1384112640.jar
    • Virustotal
    • Java (CVE-2012-1723)
    • Affected versions of Java:
      • JDK and JRE 7 Update 4 and earlier Java SE
      • JDK and JRE 6 Update 32 and earlier Java SE
      • JDK and JRE 5.0 Update 35 and earlier Java SE
      • SDK and JRE 1.4.2_37 and earlier Java SE
  • 1384112580.tpl & 1384112640.tpl
  • 1384112580.pdf & 1384112640.pdf
  • 5.exe & 2.exe

After doing a google search of the deobfuscated Javascript, I found a result that had been done on 11-08-2013 for  It contains all of the deobfuscated Javascript that I had manually translated, and has detected the malicious scripts used as part of the Nuclear Exploit Kit.

2 thoughts on “ Malware Analysis [Part 1]

  1. eirik says:

    Very nicely explained, good job

  2. Jay says:

    Excellent Post!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <term prompt="" escaped=""> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Current day month ye@r *