(Almost) Cooked Up Some Java
Monday, February 7, 2011
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.
* 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\
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 \
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.
Labels:
attack vectors,
exploits,
java
Posts
Excellent post and way to be persistent! Thank you for sharing this.
Corey,
I tried to leave a comment on your About page and couldn't get the comment page to pop-up. I tried Firefox and IE with no luck. You might want to check it
I liked all your explanations and pics on your blog. Keep up the good work. And I like the name of your blog: Journey into Incident Response. To me it says that there’s always more to learn, and reminds me of Journey to the Center of the Earth, which is kind of what forensics is, in a sense, no?
I added your blog in my blog's LINKS page under the Computer Forensics link.
When I saw your comment for a second I thought I should delete it. ;)
I only wanted the About page to provide background information so I disabled the comments on that page. The comment box still appears probably because of my blog's template.
When I was trying to come up with a name for the blog I settled on jIIr because investigating security incidents was new to me. I'm sharing the information since the information might be helpful to others and the feedback I receive helps me learn more. I'm only at the beginning of a journey that has no end (unless I switch career fields). As you said, there is always something to learn so the name jIIr will always be relevant whether if I'm just starting out or have 20 years of experience under my belt. I never saw the movie or read the book Journey into the Center of the Earth so I can't make the comparison.
Thanks for checking out the blog and adding it to the links section of your blog.
Hi, I stumbled on your blog when I'm going through the same research as you did. But from my experience this code or any java code that the author don't want to de-compile use obfuscators. The main idea of using these obfuscators is to add additional layers of randomness not to divulge. But I know people who can read code from binaries. i.e, They open these .class files in Hex editors and try to understand the source code. I don't want to get to that level. But want I want to know is the intention of this malware.