Malware Root Cause Analysis

The purpose to performing root cause analysis is to find the cause of a problem. Knowing a problem’s origin makes it easier to take steps to either resolve the problem or lessen the impact the next time the problem happens again. Root cause analysis can be conducted on a number of issues; one happens to be malware infections. Finding the cause of an infection will reveal what security controls broke down that let the malware infect the computer in the first place. In this post I’m expanding on my Compromise Root Cause Analysis Model by showing how a malware infection can be modeled using it.

Compromise Root Cause Analysis Revisited

The Compromise Root Cause Analysis Model is a way to organize information and artifacts to make it easier to answer questions about a compromise. The attack artifacts left on a network and/or computer fall into one of these categories: source, delivery mechanism, exploit, payload, and indicators. The relationship between the categories is shown in the image below.

I’m only providing a brief summary about the model but for more detailed information see the post Compromise Root Cause Analysis Model. At the model’s core is the source of the attack; this is where the attack came from. The delivery mechanisms are for the artifacts associated with the exploit and payload being sent to the target. Lastly, the indicators category is for the post compromise activity artifacts. The only thing that needs to be done to use the model during an examination is to organize any relevant artifacts into these categories. I typically categorized every artifact I discover as an indicator until additional information makes me move them to a different category.

Another Day Another Java Exploit

I completed this examination earlier in the year but I thought it made a great case to demonstrate how to determine a malware infection’s origin by using the Root Cause Analysis Model. The examination was kicked off when someone saw visual indicators on their screen that their computer was infected. My antivirus scan against the powered down computer confirmed there was an infection as shown below.

The antivirus scan flagged four files as being malicious. Two binaries (fuo.exe and 329991.exe) were identified as the threat: Win32:MalOb-GR[Cryp]. One cached webpage (srun[1].htm) was flagged as JS:Agent-PK[Trj] while the ad_track[1].htm file was identified as HTML:RedirME-inf[Trj]. A VirusTotal search on the fuo.exe file’s MD5 hash provided more information about the malware.

I mentally categorized the four files as indicators of the infection until it’s proven otherwise. The next examination step that identified additional artifacts was timeline analysis because it revealed what activity was occurring on the system around the time when malware appeared. A search for the files fuo.exe and 329991.exe brought me to the portion of the timeline shown below.

The timeline showed the fuo.exe file was created on the computer after the 329991.exe file. There were also indications that Java executed; the hsperfdata_username file was modified which is one artifact I highlighted in my Java exploit artifact research. I was looking at the activity on the system before the fuo.exe file appeared which is shown below.

The timeline confirmed Java did in fact execute as can be seen by the modification made to its prefetch file. The file 329991.exe was created on the system at 1/15/2012 16:06:22 which was one second after a jar file appeared in the anon user profile’s temporary folder. This activity resembles exactly how an infection looks when a Java exploit is used to download malware onto a system. However, additional legwork was needed to confirm my theory. Taking one look at the jar_cache8544679787799132517.tmp file in JD-GUI was all that I needed. The picture below highlights three separate areas in the jar file.

The first area labeled as 1 shows a string being built where the temp folder (str1) is added to 329991.exe. The second area labeled as 2 first shows the InputStream function sets the URL to read from while the FileOutputStream function writes the data to a file which happens to be str3. Remember that str3 contains the string 329991.exe located inside the temp folder. The last highlighted area is labeled as 3 which is where the Runtime function starts to run the newly created 329991.exe file. The analysis on the jar file confirmed it was responsible for downloading the first piece of malware onto the system. VirusTotal showed that only 8 out of 43 scanners identified the file as a CVE-2010-0840 Java exploit. (for another write-up about how to examine a Java exploit refer to the post Finding the Initial Infection Vector). At this point I mentally categorized all of the artifacts associated with Java executing and the Java exploit under the exploit category. The new information made me move 329991.exe from the indicator to the payload category since it was the payload of the attack.

I continued working the timeline by looking at the activity on the system before the Java exploit (jar_cache8544679787799132517.tmp) appeared on the system. I noticed there was a PrivacIE entry for a URL ending in ad_track.php. PrivacIE entries are for 3rd party content on websites and this particular URL was interesting because Avast flagged the cached webpage ad_track[1].htm. I started tracking the URLs in an attempt to identify the website that served up the 3rd party content. I didn’t need to identify the website per say since I already reached my examination goal but it was something I personally wanted to know. I gave up looking after spending about 10 minutes working my way through a ton of Internet Explorer entries and temporary Internet files for advertisements.

I answered the “how” question but I wanted to make sure the attack only downloaded the two pieces of malware I already identified. I went back in the timeline to when the fuo.exe file was created on the system. I started looking to see if any other files were created on the system but the only activity I really saw involved the antivirus software installed on the system.

Modeling Artifacts

The examination identified numerous artifacts and information about how the system was compromised. The diagram below shows how the artifacts are organized under the Compromise Root Cause Analysis Model.

As can be seen in the picture above the examination did not confirm all of the information about the attack. However, categorizing the artifacts helped make it possible to answer the question how did the system become infected. It was a patching issue that resulted in an extremely vulnerable Java version running on the system. In the end not only did another person get their computer cleaned but they also learned about the importance of installing updates on their computer.


Usual Disclaimer: I received permission from the person I assisted to discuss this case publicly.