Journey Into Incident Response

Today I gave a presentation titled Malware Root Cause Analysis Don't Be a Bone Head at the New York State Cyber Security Conference. This presentation was a follow-up to the presentation I gave last year titled Finding Malware Like Iron Man. Last year I laid out a triage process to find malware and this year I went into more depth discussing how the malware got there in the first place. This post contains the following for my talk: CFP, slide deck, and video I showed.

CFP

Computer users are confronted with a reoccurring issue every day. This happens regardless if the user is an employee doing work for their company or a person doing online shopping trying to catch the summer sales. The user is using their computer and the next thing you know it is infected with malware. Even Hollywood is not immune to this issue as illustrated in the TV show Bones.  The most common action to address a malware infection is to reimage, rebuild, and redeploy the system back into production.  Analysis of the system to understand where the malware came from is not a priority or goal.

Root case analysis needs to be performed on systems impacted by malware to improve decision making. The most crucial question to answer is how did this happen since it will determine if we were targeted and more importantly what can be done to mitigate this from re-occurring. Last year, in my presentation Finding Malware Like Iron Man I explored the first step in root cause analysis, which is locating the malware. The next step in root cause analysis is to identify the malware's source.

In this technical presentation Corey will discuss the root cause analysis process to determine how malware infected a computer running the Windows operating system. The topics will include: why perform root cause analysis, how not to perform root cause analysis,  compromise root cause analysis model, attack vector artifacts, and scenarios.

Slide Deck

Malware Root Cause Analysis Don't Be a Bone Head slides viewable online

Malware Root Cause Analysis Don't Be a Bone Head slides PDF file

Video

I chopped up the Bones TV episode The Crack in the Code (Season 7 episode 6) I purchased through iTunes. However, others have posted the segment I used in my presentation. For your viewing pleasure here is "Malware on Bone".
 

I recently had the opportunity to attend the Volatility Windows Malware and Memory Forensics Training. Prior to the training, I used memory forensics (and thus Volatility) in different capacities but it wasn't a technique I leveraged when responding to security events and incidents during incident response activities. This was an area I wanted to improve upon going into the training. As the training went on and more material and labs were covered I kept thinking to myself how I intended to incorporate memory forensics into my response process. To use the technique when triaging live systems remotely over the network. The labs in the training provided numerous scenarios about using memory forensics on compromised systems but I wanted to further explore it with a simulated a security event. This post explores Volatility usage against an infected system's memory image by first determining: is the system infected and if so, how did it become infected in the first place.

Short Thought About the Training

Before diving into the memory image I first wanted to provide a short thought about the training. The training is not just about a single memory forensics tool named Volatility. The training goes in-depth in numerous topics including Windows internals, malware reversing, Windows data structures, how those structures are parsed, and bypassing encryption. I was looking for an in-depth course and I found it with Volatility. It walks you through exploring the Windows internals, the structures, how they can be parsed, and then actually doing it in labs. This layout results in knowing not just how to use tools for memory forensics but understanding what they are doing and what they are suppose to be doing. To top it off, the content is put into context as it relates to Digital Forensics and Incident Response (DFIR). All in all, it was a great training and  I highly recommend it to anyone looking to get more memory forensics knowledge and skills. For a more detailed review refer to TekDefense's Review - Malware and Memory Forensics with Volatility (just keep in mind the content has been updated since his review.)

Is the System Infected?

To set up the simulation I configured an extremely vulnerable virtual machine and then browsed to potentially malicious websites. I suspended the VM to grab the vmem file (memory) once I saw the first indication the system may be compromised. This is where the simulation starts to determine if this system is infected.

I first scanned the memory image for any previous networking activity that may be tied to malware by executing the command below:

python vol.py -f Win7.vmem --profile=Win7SP0x86 netscan

The picture below shows the partial output from netscan. A few different items jump out. The first is the process 0320.dll PID 3812 listening on the TCP ports 61779 and 8681. These ports are not typically open on Windows systems which made this a good lead. The other item to note is that Internet Explorer was active at one point in time.


The netscan plug-in provided some information but additional information is needed for PID 3812 0320.dll. I first wnated to know the command used to launch the program and I did this with pstree plug-in with the -v switch

python vol.py -f Win7.vmem --profile=Win7SP0x86 pstree -v

The program's location in the temp folder made it even more suspicious as being malicious.


To get a better understanding about how PID 3812 started  I ran the pstree plug-in again without the -v switch to make it easier to see.

python vol.py -f Win7.vmem --profile=Win7SP0x86 pstree

The Internet Explorer process PID 572 spawned the PID 3812 0320.dll.


The netscan plug-in showed that this Internet Explorer was reaching out to the IP address 176.9.176.166. A search with the Malware Analysis search provided a few different hits including one to VirusTotal. The passive DNS showed this IP associated with domains flagged as malicious as well as a malicious file being downloaded from there.


To get a better idea about any processes that may had started and exited around the time PID 3812 0320.dll executed I ran the psscan plug-in.

python vol.py -f Win7.vmem --profile=Win7SP0x86 psscan

I highlighted the other processes that started around the same time but it didn't provide any more substantial leads.

0x000000007dd8f510 iexplore.exe       3600   2504 0x7d7a75c0 2014-05-11 01:38:00 UTC+0000
0x000000007e4d1030 0320.dll           3812    572 0x7d7a7540 2014-05-11 01:46:02 UTC+0000
0x000000007dad3d40 msiexec.exe        4036    492 0x7d7a7700 2014-05-11 01:46:38 UTC+0000
0x000000007e243030 dllhost.exe        2292    612 0x7d7a71e0 2014-05-11 01:46:55 UTC+0000   2014-05-11 01:47:00 UTC+0000

To see what access the PID 3812 process had on the system the getsids plug-in was used.

python vol.py -f Win7.vmem --profile=Win7SP0x86 getsids -p 3812

The lines below show 0320.dll was running in the context of the lab user account and had administrative rights to the system.

0320.dll (3812): S-1-5-21-2793522790-2301028668-542554750-1000 (lab)
0320.dll (3812): S-1-5-32-544 (Administrators)

I continued my focus on PID 3812 0320.dll to get more information about it by seeing what other items it is interacting with. To see it's handles I used the following:

python vol.py -f Win7.vmem --profile=Win7SP0x86 handles -p 3812

The only item of note in the handles output was the process's mutant; maybe it could help in researching in the malware.

0x8583b278   3812       0xd0   0x1f0001 Mutant           Y7X-TYAA-X7A

The next item I explored was the process's loaded DLLs.

python vol.py -f Win7.vmem --profile=Win7SP0x86 dlllist -p 3812

Listed among the DLLs was one item located in the lab user profile; C:\Users\lab\AppData\Local\sattech.dll.


The last item I wanted to explore was to see if the process leveraged code injection with the command.

python vol.py -f Win7.vmem --profile=Win7SP0x86 malfind

The output showed the following processes had injected code into them: explorer.exe (PID 300), wmpnetwk.exe (PID 2116), iexplore.exe (PID 2504), iexplore.exe (PID 2504), iexplore.exe (PID 572), iexplore.exe (PID 3600), and msiexec.exe (PID 4036).

Exploring 0320.dll and sattech.dll

Volatility enabled me to quickly identify two suspicious files indicating the system is infected. The next step was to explore these files to actually confirm the infection. Both files were dumped from memory with the following commands (first one dumps 0320.dll while second dumps sattech.dll.)

python vol.py -f Win7.vmem --profile=Win7SP0x86 procdump -p 3812 -D .

python vol.py -f Win7.vmem --profile=Win7SP0x86 dlldump -p 3812 -b 0x10000000 -D .

For brevity I'm not posting everything I did to examine these dumped files. The one item I wanted to note was that the strings in 0320.dll referenced the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Run which may be its persistence.  Knowing this was a simulated environment I ran both files through VirusTotal on 5/11/14 (the detections were low: 1/52 for 3020.dll and 10/52 for sattech.dll). I rescanned them while writing this post and the detections increased as can be seen in the 0320.dll VT report and sattech.dll VT report.

How Did the System Become Infected?

Memory forensics so far was able to confirm the infection, locate malware, provide clues about the malware's purpose, and extract the malware for further analysis. The next question I needed memory forensics to help me answer was how did the infection occur in the first place. An effective technique to address this question is timeline analysis and the Volatility training really opened my eyes to the additional capabilities memory provides to this technique. To fully explore Volatility timelines I'm performing timeline analysis in three separate stages. First only using the $MFT, then the timeliner plug-in (numerous time related objects), and finally the NTFS change journal ($USNJrnl).

Exploring the memory image to confirm the infection provided a few leads I leveraged in timeline analysis. There were the two files of interest: C:\Users\lab\AppData\Local\Temp\0320.dll and C:\Users\lab\AppData\Local\sattech.dll. Plus, the timeframe of interest was 2014-05-11 01:46:02 UTC+0000 since this was when the 0320.dll process started. I searched on these indicators and looked at the system activity that proceeded it and occurred after it. However, for clarity I'm presenting my timeline analysis in sequential order.

$MFT Timeline

The commands below generates a timeline in bodyfile format with the $MFT records found in memory. Then the timeline is converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns.

python vol.py -f Win7.vmem --profile=Win7SP0x86 mftparser --output=body --output-file=mft-body

mactime -b mft-body -d -z UTC > mft_timeline.csv

cat mft-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > mft-timeline_05-11-14.csv

The image below shows the MFT timeline starting at 05/11/14 01:45:59 UTC.


The first few lines show Internet activity with files being created in Internet Explorer's temporary files cache. The last three lines shows activity for the C:\Windows\SoftwareDistribution folder (which is associated with Windows update) and file creation inside the Silverlight application folder (C:\Users\lab\AppData\LocalLow\Microsoft\Silverlight). The timeline continues as shown in the image below.


The activity for involving the SoftwareDistribution and Silverlight folders continues before the 0320.dll file is created on the system at 05/11/14 01:46:02. Solely, based on this activity it provides a clue to how the system became infected. There was Internet activity followed by Silverlight activity then malware appearing on the system. This activity points to a drive-by that targeted a vulnerability in the Silverlight application. This shows again the significance of exploring attack vector artifacts and it's an area I've been looking in to for some time (it applies to all types of attacks). I just opted to stop blogging about it and only recently posted the CVE 2013-0074 & 3896 Silverlight Exploit Artifacts documenting Silverlight exploits to provide context to the activity in this timeline. The image below continues with the $MFT timeline.


It shows that the sattech.dll file was created on the system one second after 3020.dll. The last portion of the timeline I'm discussing is shown below.


The Silverlight application activity surrounds the malware further confirming the attack vector used against the system. In addition, at 01:46:10 artifacts associated with program execution started appearing on the system. There are prefetch files showing both Silverlight application and malware executed.

Volatility Timeliner and $MFT Timeline

The $MFT timeline created from the memory image enabled me to answer the "how" question. However, adding addition timeline data will make the events surrounding the infection more clear. The commands below generates the timeliner timeline in bodyfile format and combines it with the $MFT bodyfile. Then the timeline is converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns. Side note: one item I'm hoping Volalitity incorporates into the timeliner plug-in is the ability to specify what timeline artifacts to parse instead of parsing everything (this change should make timeline creation faster and more focused.)

python vol.py -f Win7.vmem --profile=Win7SP0x86 timeliner --output=body --output-file=timeline-body

cat mft-body timeline-body > timeliner-mft-body

mactime -b timeliner-mft-body -d -z UTC > timeliner-mft-timeline.csv

cat timeliner-mft-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > mft-timeliner_05-11-14.csv

The image below shows the timeliner and $MFT timeline starting at 05/11/14 01:45:59 UTC.


Right off the bat the other timeline data pulled from the memory image provided more context about what happened. Various Internet explorer processes were connecting to the freshdekor[dot]com domain. Remember the Volatility netscan plug-in output showed Internet Explorer connecting to two different IP addresses and one of them was 74.125.226.218. One of the Google searches on this IP address lead to a VirusTotal report containing passive DNS information. One of the passive domains listed for the IP address was freshdekor[dot]com. It's nice stuff how everything ties together more clearly. The image below continues with the timeline.


The activity is for the files in Internet Explorer's temporary files cache but now I know these came from the freshdekor[dot]com domain. The image below is the next portion of the timeline.


The first line shows something very cool. The Internet Explorer PID 572 is loading the coreclr.dll dll at 01:46:00. Running grep across the dlllist plug-in showed the full path to the dll which was c:\Program Files\Microsoft Silverlight\5.0.61118.0\coreclr.dll. A Google search for the dll indicated it is a Silverlight plug-in. This line is showing iexplore.exe loading the Silverlight plug-in within a second after visiting the freshdekor[dot]com domain. The third line from the top is cut off in the screenshot but it shows Internet Explorer PID 572 accessing the registry key SOFTWARE\APPDATALOW\SOFTWARE\MICROSOFT\SILVERLIGHT\PERMISSIONS for the lab user account. The rest of this timeline portion is more IE history artifacts for the domain in question. Continuing on with the timeline in the image below.


This activity is from the $MFT and was shown previously. However, now it's clear Internet Explorer loaded the Silverlight plug-in for a Silverlight application on a website. The Silverlight activity in this timeline portion was the result of a Silverlight application which was the exploit. The image below continues with the timeline.


Besides the threads it is the same activity shown previously involving Silverlight and the SoftwareDistribution folder. Continuing on with the timeline below.


This brings us to 01:46:02 which is when the 0320.dll process started. The activity shows the dlls being loaded (minus the sattech.dll dll), process created, and first thread started for 0320.dll PID 3812. This confirmed that the 0320.dll executed as soon as it was dropped onto the system. The image below shows what happened next.


The sattech.dll was created on the system and loaded by 0320.dll PID 3812 one second after the process started. The last section I'm highlighting in the timeliner/$MFT timeline is below.


The activity is from $MFT records and is the program execution artifacts mentioned previously.

NTFS Change Journal, Volatility Timeliner and $MFT Timeline

The timeliner combined with the mftparser plug-in provided a wealth of information about how the system became infected. It even provide additional information about the attack that would never be found on the host. There is still yet another source of timeline data that can be added to the timeline. During the week I was taking the Volatility training, the instructors gave us the heads up that Tom Spencer released the USNParser plug-in to parse the NTFS change journal. The $USNJrnl is an excellent source to reference as I illustrated in my post Re-Introducing $UsnJrnl. To further explore memory timelines, I downloaded the plug-in and ran the commands below. It first generates the $USNJrnl in bodyfile format and then combines it with the timeliner/MFT bodyfile. The timeline is then converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns.

python vol.py -f Win7.vmem --profile=Win7SP0x86 usnparser --output=body --output-file=usn-body

cat usn-body timeliner-mft-body > timeline-all-body

mactime -b timeline-all-body -d -z UTC > timeline-all-timeline.csv

cat timeline-all-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > timeline-all_05-11-14.csv

The image below shows the $USNJrnl, $MFT, and timeliner timeline starting at 05/11/14 01:45:59 UTC.


The $USNJrnl didn't provide much useful in this portion of the timeline since it only shows the edb.log inside the SoftwareDistribution\DataStore\Logs folder. The timeline continues in the image below.


The first $USNJrnl activity shows the mssl.lck being referenced. This file was referenced in my CVE 2013-0074 & 3896 Silverlight Exploit Artifacts post. Even if I wasn't aware about these exploit artifacts, mssl.lck can still be tied to Silverlight by grepping for the file in the filescan plug-in output. This shows mssl.lck located in the C:\Users\lab\AppData\LocalLow\Microsoft\Silverlight folder. The image below is the next part of the timeline.


The additional information shown in this activity highlights an item that was present in the previous timelines. Prior to Internet Explorer PID 572 loading the Silverlight plug-in (coreclr.dll), the webpage stored in the temporary Internet files cache was named 8fdhe54wg1[1].htm was visited. This highlights another file to examine closer on the host to determine if it was responsible for serving up the malicious Silverlight application. The image below is the next part of the timeline.


The activity is involving the same files and domains already discussed. The timeline continues below.


Just prior to the activity for the BITFC11.tmp file in the Silverlight folder there is more activity involving the C:\Windows\SoftwareDistribution\DataStore\Logs folder. This time around it is for the tmp.edb file. The image below is the next portion of the timeline.


There is no additional items to note so the timeline continues in the image below.


Again, there isn't any additional activity of interest but I'm still posting these images for others to see the timeline in its entirely. The image below shows the next part of the timeline.


The $USNJrnl shows activity for the Silverlight application and the timeline continues below.


This portion was shown in the timeliner/$MFT timeline where the 0320.dll PID 3812 process started. The image below shows what happens next.


After the 0320.dll PID 3812 process started then there is a lot of activity for a tmp file in the Windows\Temp folder as shown below.


The $USNJrnl also reflects the sattech.dll file being created on the system. The last image of the timeline shows more information about the Silverlight application and program execution artifacts I mentioned previously.

Memory Forensics for the Win

As I went into the Volatility Windows Malware and Memory Forensics Training I wanted to leverage memory forensics more when responding to security events and incidents during incident response. The way I intend to use this technique is for analysis of live systems remotely over the network. As a method to investigate a security alert such as a system reaching out to a known malicious domain. Memory forensics could provide a wealth of information for this type of alert. Tying the specific network activity to a process and then determining where the process came from in the first place. Very similar to the simulation I did for this post. I may had started out wanting to leverage memory forensics more but I ended up with more knowledge and an improved skillset to help me hold the last line of defense for my organization.

Mass injection attacks that compromise thousands of websites are now a common occurrence on the Internet. One of the more recent attacks was DarkLeech. Darkleech compromised thousands of servers running Apache which resulted in iframes being injected into the websites to redirect their visitors to malicious sites. Both the Sucuri Blog and Unmask Parasites Blog do an outstanding job talking about the artifacts left on the compromised servers. The one perspective that doesn’t get discussed often is from the visitors’ computers who happen to browse to these compromised websites. This post demonstrates how to perform a root cause analysis on an infected computer to determine if the initial infection vector was the result of an injected iframe.

The Malware Indicator

Every malware incident starts with an indicator. In this instance it was obvious the computer was infected with malware as can be seen in the screenshots below.




A program named “S.M.A.R.T. Repair” started running on the computer spitting up errors about the computer’s hard drive failing. The malware went so far as trying to hide folders and files to make it appear even more authenticate.

The Response

The purpose of this post is not to illustrate my examination process. For that you can refer to my other posts such as Finding Malware Like Iron Man, Malware Root Cause Analysis, or Finding the Initial Infection Vector. Instead my focus is on showing how the artifacts I found on the system lead me to the injected hidden iframe.

Every story has a beginning so I have to at least fill in the blanks about how I found the malware on this box. I initially grabbed the volatile data with modified version of the tr3secure volatile data collection script before taking the box offline. Looking at the running processes I quickly flagged a few suspicious items.


These stood out since they are randomly named programs; a great indicator by the way to identify malware. The process to executable mapping revealed where these files were located.


Armed with the knowledge about two suspicious files (C:\ProgramData\WqPb9DQGxuSfxt.exe and C:\ProgramData\VHuvoNRQPlUqRK.exe) I was able to quickly perform the root cause analysis. This analysis is what lead me to the injected iframe on a cached webpage.

My intention wasn’t even to discuss this examination; I completed it over a year ago. I saw an email come across a listserv about finding computers impacted by an injected iframe. After I read the email exchanges I wondered how many people actually know how to determine if an infected system was the result of an injected iframe or something else. I wanted to shed light on the topic by illustrating how to do it.

               **** Important *****

To protect the identity of all parties I have changed any identifiable information. I altered user names, URLs, domain names, certain values in URLs, dates, search terms, etc... Basically, everything you are reading related to the infection has been altered except for the malicious items. XMEN had nothing to do with the actual infection; I’m just a huge fan of the XMEN. Also, for brevity I’m only showing some of the final timeline I put together about the infection.

               **** Important *****

Following the Cookies Crumbs to an iframe

Searching for the malware I located in the volatile data brought me to the point of interest in my timeline.


The Tracing registry key showed a program named WqPb9DQGxuSfxt executed after the file was created on the system. To find out what happened on the system I had to look at the activity preceding the creation of the WqPb9DQGxuSfxt.exe file. The picture below shows some of that activity.


The jusched.log file revealed that the Java application ran around the time of this infection. Continuing on I found more interesting artifacts.


The Shim cache showed the presence of some other executables that were on the computer around the time of interest. The browser history showed the system accessing the URL hxxp://leynurivid.com. The web browsing activity continued on as shown below.


Remember my disclaimer above? Fake data alert!! The user visited a XMEN WordPress blog and the products page on the blog. Immediately preceding this activity brought me closer to the initial infection vector as shown in the picture below.


The 0.11512169499856473h7i.exe file’s name closely resembles the pattern I’ve seen numerous times for downloaders dropped onto systems after successful exploits. Not only was this the first reference to other file I found in volatile data (C:\ProgramData\VHuvoNRQPlUqRK.exe) but there was another artifact for Java execution. Can you guess what should appear next?


Immediately preceding the downloader and a modification to the Java prefetch file were Java exploits. At the time I parsed these Java index files manually since there were no tools available. However, at the time of writing this post there are now a few tools including: Brian Baskin's Java Cache IDX Parser (I used this parser for this post), Harlan’s idx parser, or Mark Woan’s JavaIDX parser. The 36158da7-67c256c0 file was a Java exploit and its index file (36158da7-67c256c0.idx) contained the following:

IDX file: 36158da7-67c256c0.idx (IDX File Version 6.03)

[*] Section 2 (Download History) found:
URL: hxxp://marcelleoonard.aa.am/gipoto/yzjnbweofzjngtc9.jar
IP: 173.236.50.237
: HTTP/1.1 200 OK
content-length: 18799
last-modified: Tue, 17 Apr 2012 04:45:22 GMT
content-type: application/x-java-archive
date: Fri, 20 Apr 2012 12:39:55 GMT
server: Apache/2.2.3 (CentOS)
deploy-request-content-type: application/x-java-archive

The 10874ac5-7334b734 file was another Java exploit and its index file (10874ac5-7334b734.idx) contained the following:

IDX file: 10874ac5-7334b734.idx (IDX File Version 6.03)

[*] Section 2 (Download History) found:
URL: hxxp://marcelleoonard.aa.am/gipoto/xuxvgpcwawdrdt.jar
IP: 173.236.50.237
: HTTP/1.1 200 OK
content-length: 9722
last-modified: Tue, 17 Apr 2012 04:45:22 GMT
content-type: application/x-java-archive
date: Fri, 20 Apr 2012 12:39:55 GMT
server: Apache/2.2.3 (CentOS)
deploy-request-content-type: application/x-java-archive

Both Java exploits were served up from the URL hxxp://marcelleoonard.aa.am. Java wasn’t the only application that was targeted.


An Adobe Reader exploit was served up as well but the system didn’t have this vulnerability. Notice the lack of Adobe Reader activity on the system? In the midst of all this activity involving the marcelleoonard.aa.am domain there was a cached webpage (xmen-steel_claws-for-sale[1].htm) from the XMEN website.


The activity before the exploits appearing on the system showed more Java execution artifacts and the XMEN webpage being accessed as shown above. At this point in the analysis I identified the malware and then traced the malware infection back to Java exploits. What was left was to identify what served up the exploits which the preceding activity revealed as shown below.


The activity that occurred before the exploits was web browsing activity involving that hxxp://marcelleoonard.aa.am URL again. One item was the cached webpage dabstepinattack[1].htm. Looking at the webpage code was confirmation about its purpose.


The dabstepinattack[1].htm file served up the Java exploits (xuxvgpcwawdrdt.jar and yzjnbweofzjngtc9.jar) and Adobe Reader exploit (grfoinbnktbq.pdf). The last piece to the puzzle was to figure out what caused the dabstepinattack.php page to appear. The preceding activity answered that question for me as shown below.


All of the activity involving malware, Java exploits, Adobe exploits, and the marcelleoonard.aa.am domain just stopped. There was only web browsing activity of the user searching for wolverine steel claws which lead them to the xmen-steel_claws-for-sale page on the XMEN website. Something on that webpage resulted in the redirect to the exploits so I took a closer look at it. In the cached xmen-steel_claws-for-sale webpage’s code showed there was an injected iframe pointing to the dabstepinattack.php page on marcelleoonard.aa.am domain.

In Closing

Systems will visit the thousands of websites compromised in mass injection attacks. If these systems have client-side vulnerabilities then mostly likely some of them will cross our paths due to them getting infected. To tie the initial infection vector back to a mass injection campaign all you need to do is locate the injected iframe at the top or bottom of the cached webpage.

Knowing what programs ran on a system can answer numerous questions about what occurred. What was being used to communicate, what browsers are available to surf the web, what programs can create documents, were any data spoliation programs ran, or is the system infected. These are only a few of the questions that can be answered by looking at program execution. There are different artifacts showing program execution; one of which is the application compatibility cache. Mandiant’s whitepaper Leveraging the Application Compatibility Cache in Forensic Investigations (blog post is here and paper is here) explains what the cache is in detail and why it’s important to digital forensics. One important aspect about the cache is it stores information about files such as names, size, and last modified times; all of which may be useful during a digital forensic examination. The application compatibility cache has provided additional information I wouldn’t have known about without it. As such I’m taking some time to write about this important new artifact.

I wanted to highlight the significance of the cache but I didn’t want to just regurgitate what Mandiant has already said. Instead I’m doing the DFIR equivalent of man versus the machine. I’m no John Henry but like him we are witnessing the impact modernization has on the way people do their jobs. One such instance is the way people try to determine if a system is infected with malware. A typical approach is to scan a system with antivirus software to determine if it is infected. There is a dependency on the technology (antivirus software) to do the work and in essence the person is taken out of the process. Seems very similar to what John Henry witnessed with the steam powered hammer replacing the human steel drivers. John Henry decided to demonstrate man’s might by taking the steam powered hammer head on in a race. I opted to do the same, to take on one of my most reliable antivirus scanners (Avast) in a head on match to see who can first locate and confirm the presence of malware on a system. I didn’t swing a hammer either. My tools of choice were RegRipper with the new appcompatcache plugin to parse the application compatibility cache along with the Sleuthkit and Log2timeline to generate a timeline containing filesystem metadata. Maybe, just maybe in some distant future in IT and security shops across the land people will be singing songs about the race of the century. When Man took on the Antivirus Scanner.

The Challenge

The challenge was to find malware that an organization somewhere in the land is currently facing. Before worrying about what malware to use I first configured the test system. The system was a Windows XP fresh install with Service Pack 3. I only installed Adobe Reader version 9.3 and Java version 6 update 27. These applications were chosen to make it easier to infect the system through a drive-by. I wanted to use unknown malware as a way to level the playing field; I didn’t need nor want any advantages over the antivirus scanner. To find the malware I looked at the recently listed URLs on the Malware Domain List to find any capable of doing a drive-by. I found two potential URLs as shown below.


The first URL pointed to a Blackhole exploit pack. I entered the URL into Internet Explorer and after waiting for a little bit the landing page appeared as captured below.


I gave Blackhole some more time to infect the computer before I entered the second URL. That was when I saw the first indication the system was successfully infected with an unknown malware.


The race was now officially on. Whoever finds the malware and any other information about the malware first wins.

On Your Mark, Get Set

I mounted the system to my workstation using FTK Imager in order for tools to run against it. I downloaded and installed the latest Avast version followed by updating to the latest virus signature definitions. I configured Avast to scan the mounted image and all that was left was to click “Scan”. With my challenger all set I made sure I had the latest RegRipper Appcompatcache plugin. Next I fired up the command prompt and entered the following command:

rip.pl –p appcompatcache –r F:\Windows\System32\config\system > C:\appcompt.txt

The command is using RegRipper’s command-line version and says to run the appcompatcache plugin against the system registry hive in the mounted image’s config folder. To make it easier to review the output I redirected it to a text file.

My challenger is all set waiting at the starting line. I’m all set just waiting for one little word.

Go!

The Avast antivirus scan was started as I pressed enter to run the RegRipper’s appcompatcache plugin against the system registry hive.

0 minutes 45 seconds

I opened the text file containing the parsed application compatibility cache. One cool thing about the plugin is that Harlan highlights any executables in a temporary folder. In the past I quickly found malware by looking at any executables present in temp folders so I went immediately to the end of the output. I found the following suspicious files which I inspected closer.

Temp paths found:

C:\Documents and Settings\Administrator\Local Settings\Temp\gtbcheck.exe
C:\Documents and Settings\Administrator\Local Settings\Temp\install_flash_player_ax.exe
C:\Documents and Settings\Administrator\Local Settings\Temp\install_flashplayer11x32ax_gtbd_chrd_dn_aih[1].exe
C:\Documents and Settings\Administrator\Local Settings\Temp\gccheck.exe
C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\4967GLU3\install_flashplayer11x32ax_gtbd_chrd_dn_aih[1].exe
C:\Documents and Settings\Administrator\Local Settings\Temp\install_flashplayer11x32ax_gtbd_chrd_dn_aih[1].bat

3 minutes 4 seconds

My hopes of a quick win came crashing down when I found out the executables in the temporary folders were no longer present on the system. I went back to the beginning of the application compatibility cache’s output and started working my way through each entry one at a time. Avast was scanning the system at a fast pace because the image was so small.

5 minutes 10 seconds

Avast was still scanning the system but it still didn’t find the malware. That was good news for me because I found another suspicious entry in the application compatibility cache.

C:\Documents and Settings\Administrator\Local Settings\Application Data\armfukk.exe
ModTime: Tue Aug 21 20:34:04 2012 Z
UpdTime: Tue Aug 21 20:38:03 2012 Z
Size : 495616 bytes

The file path drew my attention to the program and a check on the system showed it was still there. I quickly uploaded armfukk.exe to VirusTotal as stared at the Avast scan waiting to see if it would flag it before the VirusTotal scan completed.


VirusTotal delivered the verdict: 9 out of 42 antivirus scanners detected the armfukk.exe file as malware. Going head to head against Avast I located a piece of malware in about 5 minutes while Avast was still scanning. As you probably expected Avast still didn’t flag any files as being malicious.

Avast was still running the race as it kept scanning the system. I continued my examination by turning to my next tool of choice; a timeline. A timeline would provide a wealth of information by showing the activity around the time the armfukk.exe file was created on the system. I ran the following Sleuthkit command to create a bodyfile containing the filesystem metadata:

fls.exe -m C: -r \\.\F: > C:\bodyfile

9 minutes 30 seconds

Avast was still chugging along scanning but it still didn’t flag any files. The bodyfile was finally created but I needed to convert it into a more readable format. I wanted the timeline in log2timeline’s csv format so I next ran the command:

log2timeline.pl -z local -f mactime -w timeline.csv C:\bodyfile

11 minutes 22 seconds

I imported the timeline into Excel and sorted the output. Just as I was getting ready to search on the “armfukk.exe” keyword Avast finally completed its scan with zero detections.

Shortly There After

The race was over but I wasn’t basting in the glory of winning. I wanted to know how the malware actually infected the computer since I was so close to getting the answer. I searched on the armfukk.exe filename and found the entry showing when the file was created on the system.


There was activity showing Java was running and five seconds before the armfukk.exe file was created I came across an interesting file in the Java cache. VirusTotal gave me all the confirmation I needed.

Moral of the Story

As I said before, maybe, just maybe in some distant future in IT and security shops across the land people will be singing songs about the race of the century. Remembering the day when man demonstrated they were needed in the process to locate malware on a system. Putting antivirus technology into perspective as a tool; a great tool to have available in the fight against malware. Remembering the day when man stood up and said "antivirus technology is not a replacement for having a process to respond to malware incidents nor is it a replacement for the people who implement that process".