Journey Into Incident Response

Finally

As I’m writing the first paragraph of a paper for my Masters of Science program the only thought that keeps running through my mind is finally. I finally reached not only the last week of class but the last week of my master’s program. In a few days I will finally complete the MSIA program when I submit my paper and my experience -not the knowledge- will gradually become a distant memory.

The second thought to run through my mind was everything on my to do list. My list has been piling up over the months and one of the more recent items on the list is the lack of my blog posts over the past few weeks. This will hopefully change once I’m done with school and a few of the future posts will cover some of the things I’m looking at including Java vulnerability exploit artifacts, my introduction to log analysis, and possibly a new crime scene camera that people are putting into their homes.

In the meantime here are a few links about timelines.

Timeline Analysis Links

Kristinn has an excellent post about analyzing timelines which can be found here. I previously blogged about reviewing timelines with Excel (post is here) and Calc (post is here). I created the timelines using mactime and redirected the output to a csv file which I then imported into Excel. Kristinn approaches analyzing timelines with Excel a different way. Kristinn mentioned that filtering is not optimal with mactime and Excel so he uses the CSV output module in log2timeline to create the timeline. One of the limitations I found with Excel was the limit on the number of variables you can filter on using basic filters (Calc had a higher limit but it was still only eight variables). This was one of the reasons I looked into using advanced filters, Kristinn's approach is really interesting since the CSV module breaks up the description field which makes it easier to filter on using basic filters. His write-up is very informative and educational. Trying out this approach has been added to my to do list. Kristinn, thanks again for the write-up and sharing this information.

One of the downsides to being state public sector employee – especially for New York state- is the lack of funds to attend trainings and conferences. This is the main reason why I like when speakers share their conference presentation slides since it lets people who couldn’t attend the conference (aka me) to see some of the presented material. Mandiant posted their DoD Cyber Crime 2011 presentations and one of them was Rob Lee’s Super Timeline Analysis presentation. My biggest take away from Rob's slides was his research on the Windows time rules (I was already familiar with the other content in the slides since I read Rob's post on the SANs forensic blog about supertimelines and volume shadow copy timelines). The Windows time rules (slides 15 and 16) outline how the timestamps in the Standard Information Attribute and Filename Attribute are changed by actions taken against a file. For example, you can see the difference between the changes to a file's timestamps when it is moved locally as compared being moved to another volume. The charts are a great reference and thank you Rob for sharing this information.

I was working on a computer a few weeks ago (non-work related issue) when my antivirus scanner flagged two files. The names of the two files were 2371d6c6-2a6da032.idx and 2371d6c6-2a6da032; both files were located in the Sun Java cache folder. The first time I came across this type of artifact I mentioned it in the jIIr post Anatomy of Drive-by Part II. This time around things were different because I didn’t have to identify the files since the antivirus software marked them as containing the CVE-2010-0094 exploit. I thought this known Java exploit was a good candidate for a sample to practice on. Not only could the sample be used to learn how to analyze Java exploits with REMnux but it could also be used to try out a few recipes from the Malware Analyst’s Cookbook. This post is the examination of the 2371d6c6-2a6da032.idx and 2371d6c6-2a6da032 files which consists of the following:

        * Understand the Java Cache folder
        * Examine the IDX File
        * Examine the JAR File
        * Extract Java Source from the JAR File
        * Examine Java Source

Understand the Java Cache folder

The 2371d6c6-2a6da032.idx and 2371d6c6-2a6da032 files were located in the following folder: Users\\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\6\. This folder is the default location where Java stores temporary files on the computer so the files can be executed faster in the future. The picture below highlights where the temporary file location can be changed from its default value in the Java Control Panel. Note: the picture was taken from a Windows XP system but the samples came from a Windows 7 system which is why the path shown below is different than the one I mentioned.

Examine the IDX File

The storage location of the 2371d6c6-2a6da032.idx and 2371d6c6-2a6da032 indicate they are temporary files. The files in the cache folder with an extension of IDX are Java applet cache index. The index tracks information about the temporary files in the cache folder such as: the file’s name, URL the file came from, IP address of the computer the file came from, the last modified date of the file, and what appears to be the date of when the file was downloaded. The picture below shows this information stored in an index file I grabbed from my Java cache folder. Note: Skillport is a legitimate website so the information below is not malicious.

The temporary files’ indexes can be viewed using the View button in the Java Control Panel (the button is to the right of the Settings button in the picture of the Java Control Panel above). I verified this by comparing the contents of an IDX file on my computer with the information in the Java Control Panel viewer. The picture below highlights the relationship between the values in the IDX file and the viewer.

As can be seen in the picture above, the Java Cache Viewer doesn’t provide all of the information that’s available in the index file. For example, the last modified date only shows the date while the index file also contains the time. Another example is the Java Cache Viewer not showing the IP address of the computer where the file came from even though the address is present in the index.

The 2371d6c6-2a6da032.idx file is the index for the 2371d6c6-2a6da032 file and this index provides valuable information about where the file came from. The picture below shows the information in the 2371d6c6-2a6da032 file’s index (the file was viewed using the vi text editor in REMnux).

The index file contains some valuable information about the JAR file and some of that information is listed below.

        * Filename: 7909df6ac8d.jar
        * URL where file came from: hxxp://partersl(dot)com/new/2fcf33c783
        *File size: 23996
        * File's last modified date: Wed Oct 27, 2010 14:44:55 GMT
        * IP address of the computer where file came from: 91.213.217.35
        * Web software involved: Apache
        * Deploy request content type: application/ java archive
        * Date when file was downloaded: Sun Oct 31, 2010 21:49:25 GMT

Side note: I conducted a few tests on the download date. I'm not sure if any actions alter this date but during my testing the date didn’t change the same file was accessed on a server at a later time.

Examine the JAR File

The 2371d6c6-2a6da032.idx file provided some interesting information about the 2371d6c6-2a6da032 file. Further research could be done on some of this information such as the IP address or domain names; the Malware Analyst Cookbook has a few recipes for this type of research. The index file indicated that the 2371d6c6-2a6da032 file was an application/java archive but there wasn't any other information about what was the file's purpose. A closer examination was needed to find out the file’s purpose.

JAR files are package with the ZIP file format; this means JAR files can be used for ZIP tasks such as archiving files. This means the 2371d6c6-2a6da032 JAR file is an archival. I wanted to become more familiar with the JD-GUI program so I downloaded it to REMnux in order to view the contents of the JAR file. The picture below shows the contents of the 2371d6c6-2a6da032 file (I added the .jar extension when I had an issue with JD-GUI not seeing the file).

A JAR contains a manifest which “is a special file that can contain information about the files packaged in a JAR file”. The information contained in the manifest enables the JAR file to be used for multiple purposes. This also means the manifest can help determine what the purpose of an unknown JAR is. The picture below shows 2371d6c6-2a6da032 file’s manifest.

The 2371d6c6-2a6da032.idx file indicated this JAR was an application and if an application is bundled in a JAR file then there needs to be a way to indicate which class file within the JAR is the application’s entry point. The entry point is identified using the Main-Class header and the picture above shows the main class is the starting point for the bundled application. This information established the starting point of the examination of the Java in the eight class files.

Extract Java Source from the JAR File

The SANs Internet Storm Center posted an entry -Java Exploits- and this post discussed how Java exploits can be analyzed. To examine the class files a Java decomplier is required in order to extract the Java source from the files. I wanted to become familiar with the jad decomplier in REMnux so I attempted to extract the source code using the method outlined in the post Java Exploits.

The class files were unzip from the JAR.

Jad was used to extract the source code when the following error was encountered.

I looked into the error and came across a forum that stated jad has issues handling Java 5.0. To get around the issue I used JD-GUI to extract the source code.

Examine Java Source Code

This post is called (Almost) Cooked Up Some Java because I wasn't successful in examining the Java source code. I wanted to complete the 6-2 recipe in the Malware Analyst Cookbook to see if the exploit could be identified in the Java code. This would have completed the examination of the 2371d6c6-2a6da032.idx and 2371d6c6-2a6da032 files. However, the exploit wasn't identified because of an error running the source code. I received the error when running the code through jsunpack-n and spidermonkey (REMxun has both programs). The screenshots of the errors are shown below.


The error referenced a missing semicolon but the review of the code showed there wasn't a semicolon missing. I even ran the Java source code through Wepawet to see if the result would be different but the site doesn't show if an error occurred similar to jsunpack-n. I reached out for help on this issue and someone helped identified the lines in the code causing the errors. The lines had string variables with values containing numbers. When the numbers were removed then the error would disappear. However, removing the numbers wasn’t a solution to the error so this meant I couldn’t examine the Java source code.

               ******** Update ********

A reader responded and pointed out the errors were due to the programs I was using. Spidermonkey and jsunpack-n are used to analyze Javascript instead of Java code. Thank you again to the reader who took the time to contact me.

I was hoping someone would see what I was doing wrong because I still wanted to know how to examine the Java code in order to locate the exploit and its payload. If there are any more updates to this post in the future, I'll put them at the end of the post after the summary.


               ******** Update ********

At this point I thought the next step could be to conduct a few searches using keywords from the JAR file. I performed a few quick searches using different combinations of the names of the class files in the JAR file. I wasn’t able to find the same 2371d6c6-2a6da032 file but I found other files that had similar class file names. A few of the search hits are listed below.

        * Oct 7, 2010: JAR file was run through ThreatExpert and there were no detections
        * Oct 29, 2010: JAR file was run through ThreatExpert and there were no detections
        * Oct 31, 2010: 2371d6c6-2a6da032 file being examined was downloaded
        * Dec 06, 2010: JAR file was run through ThreatExpert and there was one detection
        * Dec 23, 2010: Microsoft Malware Protection write-up on TrojanDownloader:Java/Rexec.C
        * Feb 03, 2010: 2371d6c6-2a6da032 file being examined was run through ThreatExpert and there were numerous detections

Summary

The Java cache folder is one location on a system where there could be artifacts of a Java exploit. The folder’s location can be changed but the default location for Windows 7 is \\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\6\ while Windows XP is \\Application Data\Sun\Java\Deployment\cache\6.0.

For each temporary file downloaded into the Java Cache folder will result in two files being present. One file will be the actual temporary file while the second file will be the Java applet cache index for the temporary file. The index tracks information about the temporary file such as: the file’s name, URL the file came from, and the file’s last modified date. The temp file and its index can provide valuable information about the file’s purpose and where it came from.

Now back to my examination. I was unable to analyze the Java code in the JAR file and the few quick Google searches I performed didn’t provide a good hit (around the time of 10/31/2010) to confirm my suspicions about the file. However, I was able to quickly confirm my suspicions using the information from the index file. A quick Google search of the IP address 91.213.217.35 resulted in a hit for the Malc0de database. The Malc0de database entry is shown below.

Notice the first entry was on 11/01/2010 which was one day after the JAR file was downloaded to the system. The database entry contained the IP address and domain that was tracked in the 2371d6c6-2a6da032.idx file.

For anyone interested here is the VirusTotal report about the 2371d6c6-2a6da032 file. The report analyzed the file three months after the file was downloaded to the system I was looking at.