Journey Into Incident Response

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.

Artifact Name

Exploit Artifacts for CVE 2013-0074/3896 (Silverlight) Vulnerabilities

Attack Vector Category

Exploit

Description

Two vulnerabilities present in Microsoft Silverlight 5 that in combination enable an attacker to execute arbitary code.

CVE 2013-3896 affects Microsoft Silverlight 5 before 5.1.20913.0. The vulnerability is due to not properly validating pointers during access to Silverlight elements, which allows remote attackers to obtain sensitive information via a crafted Silverlight application. The significance of this vulnerability as explained in TrendMicro's  A Look At A Silverlight Exploit article:

"The exploit uses this vulnerability to leak a pointer address in memory, and then uses this leaked address to compute the base address of mscorlib.ni.dll, bypassing ASLR. Later, this base address is used to compute the ROP gadgets in order to bypass DEP."  

CVE 2013-0074 affects Microsoft Silverlight 5 before 5.1.20125.0. The vulnerability is due to not properly validating pointers during HTML object rendering, which allows remote attackers to execute arbitrary code via a crafted Silverlight application. The TrendMicro article stated this vulnerability "is used to control the execution flow to jump to the ROP gadget."

Attack Description

The significance of these Silverlight vulnerabilities is their usage in mass attacks through exploit kits. Furthermore, Packetstorm security posted the exploit code for these vulnerabilities making them public and thus available to anyone to use them including exploit kits' authors.

This description was obtained from the very detailed Malware don't need Coffee blog post CVE-2013-0074/3896 (Silverlight) integrates Exploit Kits. To truly understand this attack I highly recommend reading this blog post.

     1. User visits a malicious website.

     2. The website serves up a malicious Silverlight application to compromise the system.

Exploits Tested

Metasploit exploit/windows/browser/ms13_022_silverlight_script_object

Target System Information

Windows 7 SP0 x86 Virtual Machine with Silverlight v 5.0.60818.0 (no Silverlight applications were executed on the system prior to test)

Different Artifacts based on Administrator Rights

Not tested

Different Artifacts based on Tested Software Versions

Not tested

Potential Artifacts

The potential artifacts include the 2013-0074/3896 exploit and the changes the exploit causes in the operating system environment. The artifacts can be grouped under the following three areas:

     * Temporary File Creation
     * Indications of the Vulnerable Application Executing
     * Internet Activity

Note: the documenting of the potential artifacts attempted to identify the overall artifacts associated with the vulnerability being exploited as opposed to the specific artifacts unique to the Metasploit. As a result, the actual artifact storage locations and filenames are inside of brackets in order to distinguish what may be unique to the testing environment.

     Temporary File Creation

- Webpage created in a temporary Internet files storage location on the system within the timeframe of interest. [C:\ Users\lab\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\I87XK24W\nXKoGc[1].htm] The webpage contains the code to load the Silverlight application exploit. The code includes: the data/type variables indicating " application/x-silverlight-2" and the InitParams indicating what to load. The image below shows the webpage code (please note: the InitParams in Metasploit contains the code to execute while on other systems it may point to an actual file)



     Indications of the Vulnerable Application Executing

- Folder activity involving the Silverlight application. [C:\Users\lab\AppData\LocalLow\Microsoft\Silverlight]

- File creation inside the Silverlight application folder. [C:\ Users\lab\AppData\LocalLow\Microsoft\Silverlight\BIT65AC.tmp and C: \Users\lab\AppData\LocalLow\Microsoft\Silverlight\mssl.lck]

- Registry modification involving Silverlight in the user profile's NTUSER.DAT hive the exploit executed under. [HKU\Software\AppDataLow\Software\Microsoft\Silverlight and HKU\ Software\AppDataLow\Software\Microsoft\Silverlight\Permissions] (note: this artifact may be due to Silverlight executing for the first time)

- Entries for Silverlight programs that executed for the first time on the system inside the RecentFileCache.bcf file (Windows 7 artifact) [c:\program files\microsoft silverlight\5.0.61118.0\agcp.exe]

- References to Silverlight programs in the CONHOST.EXE's prefetch file handles [\DEVICE\HARDDISKVOLUME1\PROGRAM FILES\MICROSOFT SILVERLIGHT\5.0.61118.0\COREGEN.EXE]

     Internet Activity

- Web browser history of user accessing websites within the timeframe of interest. [lab user account accessed the computer running Metasploit]

- Files located in the Temporary Internet Files folder. [Users\lab\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5]

Timeline View of Potential Artifacts

The images below shows the above artifacts in a timeline of the file system from the test Windows 7 SP0 system. The timeline only includes the file system metadata. The purpose of the timeline is to help illustrate what the artifacts look like on a compromised system.

A few tidbits about items listed in the timeline that are not discussed above. First, in numerous tests when Silverlight executes it initiates activity in the C:\Windows\SoftwareDistribution\DataStore. This folder is associated with Windows updates and at times it referenced Silverlight activity.  Secondly, in numerous tests when Silverlight executes there is activity in the C:\Windows\System32\wdi folder. The files didn't specifically reference Silverlight but the activity was consistent. In both cases, I opted to not include these artifacts until it can be determined that this activity is directly associated with Silverlight being exploited.

     * MFT Timeline




     * Change Journal Timeline
 

When you look at papers outlining how to build an enterprise-scale incident response process it shows the text book picture about what it should look like. It's not until you start building out the incident response (IR) process and/or responding to security events/incidents when you can truly see what the critical pieces are in the process. In most of the "text book style" IR documentation I've read (for my Masters, enjoyment, and research) they tend to gloss over the triage. Triage is only mentioned as necessary to confirm an indicator and determine if a security event is an incident. Whether if you are building out an IR process or doing internal IR work, triage is not an activity that should be glossed over. In my opinion, it is one of the most important steps. Not only does it need confirm an indicator and determine if a security event is an incident but it also needs to provide guidance to staff for security events that are not incidents. In addition, a good percentage of one's work will be triaging indicators/events to determine what needs to be done - if anything. Seeing how important triage is I dedicated a lot of time to improving and refining techniques to triage security indicators and events. In this post I'm explaining a single technique, which is how the Recentfilecache.bcf file can be used to quickly identify an infected system.

It's All About Triage

I'm not going to disclose my exact triage process nor any other specifics about activities conducted during triaging. However, I will explain the logic behind it to show my thought process and how it was structured. My goal for triage was to find a balance between the amount of resources and time one spends on triaging indicators and alerts. Too much time results in less items being looked at and resources being wasted on trivial things. Not enough time results in items potentially slipping through the cracks. The balance needs to be just enough time spent on triaging an indicator to perform a sufficient analysis so as many indicators/events as possible can be triaged. Lastly, the triage process has to be understandable since I'm teaching others how to do it.

To satisfy these goals I went with a tiered approach to triage. There are different levels in the triage process that does different activities. The lower levels are used to initially look into an indicator. Based on what is learned will determine the next step. Either stop work on the indicator (and update monitoring as needed) or do a more in-depth triage. At the next level the process repeats. Continuing triaging to determine the next steps and take action as necessary. There are four layers in the triage process with the top one being the most in-depth.

Each layer leverages various data and examines that data using various techniques. This way multiple techniques and various data sources are used to provide a more accurate picture. If attempts are made to bypass one technique one of the others will catch it. One technique in one of the layers is the one I'm discussing in this post. Collecting and examining the Recentfilecache.bcf file from a system suspected of being impacted with malicious code to confirm if it is infected and where malware may be located.

Revisiting the RecentFileCache.bcf File

It's probably important to first revisit what the RecentFilecache.bcf file is and why it is important. In my post Revealing the RecentFileCache.bcf File I explained the significance of this file as it relates to digital forensics and incident response. The file records executables that executed on a Windows 7 system and the relevance of the listed executables mean the following:

        1.  The program is probably new to the system.
        2.  The program executed on the system.
        3.  The program executed on the system some time after the ProgramDataUpdater task was last ran.

A good percentage of the time when a machine is compromised with malicious code  an executable is initially created on the system and executed. This is how both downloaders and droppers typically work and why both of these tools end up listed in the RecentFileCache.bcf file. So when you are looking into an malicious code indicator checking this artifact is a fast way to determine if a new executable was created and executed on the system. I've been using this technique for some time and it is very effective in confirming a system infected with malware that occurred fairly recently (within last 24 hours or since the ProgramDataUpdater task last ran).

Still Digesting Harlan Carvey's Latest Work

If you haven't noticed Harlan Carvey has released some new things for the community. There is the new RegRipper package which includes a bunch of new plug-ins. His new book Windows Forensic Analysis Toolkit: Advanced Analysis Techniques for Windows 8 was published and he released the book materials online. Needless to say I'm still digesting all of this. However, I wanted to take a look at what is new. After reading the RegRipper update file to see the new plug-ins I went through his book archive. That's when I saw one of the tools in the Chapter 4 folder named rfc.exe. To see what the tool does you can read the Perl source code (wfa4e\ch4\source rfc.pl) but I'll say what the tool does. It parses the RecentFileCache.bcf file.

Until now, there are not many (if any) tools that parse this file. You can read the programs listed in this artifact with a hex editor but doing so takes time. Using a parser is faster since all you need to do is execute one command to see the listed programs. For example, running the rfc.exe tool against a Recentfilecache.bcf file from a machine recently infected shows the following:

rfc.exe G:\Windows\AppCompat\Programs\RecentFilecache.bcf

c:\windows\system32\schtasks.exe
c:\program files\common files\java\java update\jusched.exe
c:\users\lab\appdata\local\microsoft\windows\temporary internet files\content.ie5\i87xk24w\n6up2014[1].com
c:\program files\common files\java\java update\jucheck.exe


I highlighted the one suspicious file; the com file that executed from a user profile's temporary internet files folder. As you can see, rfc.exe makes a quick way to locate malware even quicker.

Triaging with RecentFileCache.bcf File and rfc.exe

As I demonstrated, combining the RecentFileCache.bcf file with Harlan's rfc.exe (or rfc.pl) tool is a quick way to locate malware. This technique is excellent for use in triage to determine if a system is infected. All that needs to be done is to access or collect the RecentFileCache.bcf file then parse it to see what is listed in it.

Another useful thing to know about the RecentFileCache.bcf file is it is not a locked file. This means the file can be accessed, collected, and parsed without another tool to unlock it. If you are triaging an indicator on a live system all you need to do is run the following command:

E:\DFIR-Tools\rfc.exe C:\Windows\AppCompat\Programs\RecentFileCache.bcf

The command will work but who wants to interact with the live system through its keyboard. This requires finding the system, walking to the system, explaining things to a person, and then triaging the system. It's not a fast method. The better approach is to do your triage remotely against the system. It works regardless if the system is on a different floor or in a different city. This is made even easier if the environment you are in has Windows administrative shares. These shares "are hidden network shares created by Windows NT family of operating systems that allow system administrators to have remote access to every disk volume on a network-connected system." You can access them by typing in the full UNC path in Windows Explorer or the Run dialog box. This will bring up the remote system's volume in Windows Explorer which is a GUI and not a fast method. The faster method is to access the remote system's volume by creating a mapped network drive to it. After the drive is mapped you can either parse the RecentFileCache.bcf file directly or copy the file to your analysis machine for offline parsing. Let's walk through how to do this.

The command below maps the remote C volume to the drive letter R and the mapped drive is not persistent.

net use R: \\192.168.1.1\c$ /PERSISTENT:NO


The command below parses the RecentFileCache.bcf file remotely.

C:\DFIR-Tools\rfc.exe R:\Windows\AppCompat\Programs\RecentFileCache.bcf


The command below is to collect the file for offline parsing (the asterisk tells xcopy the object is a file and the /h switch is to copy system and hidden files)

xcopy R:\Windows\AppCompat\Programs\RecentFileCache.bcf C:\Collection\RecentFileCache.bcf* /h


After the RecentFileCache.bcf is either parsed or copied then the drive letter to the remote C volume can be deleted with the following command:

net use R: /delete /y


If you have access to Encase Enterprise (or Encase Forensic with F-response) and prefer to stay within Encase then use Lance's RecentFileCache.bcf enscript.

Wrapping Things Up

What I illustrated is the basic technique for leveraging the Recentfilecache.bcf file to quickly confirm if a system is infected and where malware may be located. The technique is even faster by automating it in a script. As you might have guessed, I use this technique remotely across the enterprise when triaging indicators. It can be a standalone technique but I don't use it as such. It's just one technique out of many I incorporated into my layered triage process. Hopefully, people find this useful and it provides a little more context to my tweet last week.

You end up having to talk to a range of people when building out an internal incident response process. It's a natural consequence because the way people did things in the past is changing and these changes will impact the way they do things going forward. The people you need to communicate with is dependent upon the organization and what the changes actually are. In my case, I ended up discussing incident response with a cross section from the information technology department including: helpdesk, server groups, security units, and management. At some point during the discussions the "why" incident response is needed has to be addressed in order to get buy-in to implement the changes. Thinking about the "why" and the various audiences who need to hear it makes it more clear how concise your explanation needs to be. The message has to be clear and convey the reality we find ourselves in with the threats we face without adding any additional FUD (fear, uncertainty, and doubt) in attempts to influence people's decisions.

Prevention Will Eventually Fail

Despite our best efforts and everything we try to do to secure organizations the end result will be the same. The preventative controls we put in place to protect organizations from the threats we face will fail. The gravity of the situation is illustrated in a three year old FireEye quote:

"today’s cyber criminals are nearly 100% effective at breaking through traditional security defenses in every organization and industry, from the security savvy to security laggards"

The defense in-depth strategies of applying layers of security controls to protect data is incapable of preventing compromises and data breaches. The continuous stream of news about breached organizations from retail stores to universities to public sector organizations is our constant reminder that prevention will not prevent threats from accomplishing what they are trying to do.

Incident Response - The Last Line of Defense

Anton Chuvakin framed the conundrum we find ourselves in with his paper Security Incident Response in the Age of APT (behind a pay wall):

"First, prevention and preventative security controls will fail. Prevention fails on a daily basis at many organizations; it will suffice to look at antivirus tools and contrast their 99%-plus deployment rates with widespread ongoing malware infection rates."

"Second, detection also fails on a frequent basis. A copy of Verizon Data Breach Investigations Report reveals plentiful evidence of that."

"What remains of the entire realm of information security. Only incident response."

"Thus, IR simply has to be there because this is where the security of an organization will fall after all else fails - and it will."

In essence, after every other security control fails an organization's last line of defense is incident response. A line that needs to: investigate, contain, remediate, detect further compromises across the enterprise, and reduce future compromises. This last line of defense is solely dependent on having the right people (incident responders) to carry it out. As incident responders, our job is to hold this line against the threats our organizations face on a daily basis despite everything else failing around us.

To be a catalyst for change this is the message we must convey:

Prevention will fail and when it does, the last line of defense to thwart the threats we are up against is the incident response process and its staff.

The Application Experience and Compatibility feature ensures compatibility of existing software between different versions of the Windows operating system. The implementation of this feature results in some interesting program execution artifacts that are relevant to Digital Forensic and Incident Response (DFIR). I spent a lot of time talking about these artifacts in my posts: Revealing the RecentFileCache.bcf File, Revealing Program Compatibility Assistant HKCU AppCompatFlags Registry Keys, and Exploring Windows Error Reporting. In this short post I'm discussing another source containing program execution information, which is the Application-Experience Program Inventory Event Log.

Where Is the Program Inventory Event Log

Similar to the other event logs on a Windows system, the program inventory event log (Microsoft-Windows-Application-Experience%4Program-Inventory.evtx) is located in the C:\Windows\System32\winevt\Logs folder as shown below.


In the Windows event viewer the log can be found at: Applications and Services Logs\Microsoft\Application-Experience\Program-Inventory as shown below.

Program Inventory Event Log Relevance to DFIR

The DFIR relevance of the events recorded in this log has been mentioned by others. The Cylance Blog briefly mentions it in their post Uncommon Event Log Analysis for Incident Response and Forensic Investigations. The NSA document Spotting the Adversary with Windows Event Log Monitoring references the log in the Recommended Events to Collect section (pg 27). The document outlined the following event IDs: 800 (summary of software activities), 903 & 904 (new application installation), 905 & 906 (updated application), and 907 & 908 (removed application). Harlan provides more context on how the events in this log can be useful in his post HowTo: Determine Program Execution. He shared how he used this log to determine an intruder installed a tool on a compromised system.  Now let's take a closer look at these event IDs to see what information they contain.

Event ID 800 (summary of software activities)


Event IDs 900 & 901 (new Internet Explorer add-on)



Event IDs 903 & 904 (new application installation)



Event ID 905  (updated application)


Event IDS 907 & 908 (removed application).


 

"Look, if you had one shot, or one opportunity,
To seize everything you ever wanted. One moment
Would you capture it or just let it slip?"

~ Eminem


Everybody has a story. Everybody has a reason about why they ended up in the Digital Forensic and Incident Response (DFIR) field. Sharing these experiences is beneficial to those looking to follow in your footsteps; students fresh out of college, career changers, or people looking to do something different in DFIR. In this post I'm sharing my story, my story about how I became an incident responder. A path that has been very challenging while rewarding at the same time. A path that started with the mindset seen in the "Lose Yourself" lyrics below.

"You better lose yourself in the music, the moment
You own it, you better never let it go
You only get one shot, do not miss your chance to blow
The opportunity comes once in a lifetime"

Formulate Your Plot

At the time I was working in a security unit doing network penetration testing and digital forensics support for investigations. How I ended up in this unit in the first place was due to the same mindset I'm about to describe. I enjoyed the offensive side of the house but I knew it wasn't my passion. Digital forensics was at one point challenging but it became very repetitive mostly working fraud investigations. I wanted something more. I wanted something where you are constantly challenged; I wanted to do incident response. I set my sights on incident response being the end goal and knew everything I would do was to help me reach that goal. I didn't know where this path would lead but I thought about my preferences which were in this order: incident responder in my own organization, incident responder with a specific organization in the NYS public sector, or joining an established rock solid IR team.

Focus on the Process

In DFIR and information security in general, people have a tendency to focus on the tools one should use. The better approach and the one I take is to initially focus on the process one uses to leverage tools to accomplish something. Within incident response there are numerous processes that are dictated by an incident's classification. To make it more manageable as I started my journey into incident response I focused on one specific incident type (malicious code incidents). I set out to learn everything about what examination steps one uses to investigate a machine compromised with malicious code, what artifacts to parse, and the tools one uses.

My plan wasn't to only be skilled at malicious code incidents since my focus was on the larger incident response field. In addition to learning the technical skills and knowledge, I spent considerable time better understanding the larger incident response process. How the process should work, how to design the process, how to build and manage a CSIRT, and how to manage incidents. I even focused on incident response while I was going for my Masters of Science in Information Assurance. I took the incident response management track as well as made this my focus on assignments where we had flexibility with choosing our own topics.

Focus on the Skill Set

Learning the processes is only the first step; my next step was to develop my skill set carrying out those processes. I spent considerable time practicing the malicious code  investigation process by compromising test systems followed by examining them. In a future post I'll share how I did this so others can follow suit. I did this for months. In the beginning it was to learn the process then it was to be more efficient then it was to be faster.

As I was working towards my goal I kept my eyes open for the opportunities that come once in a lifetime. I knew I wasn't ready to approach my organization about doing IR work since I had to own it when I did. However, other opportunities presented themselves when family members and friends reached out to me as their "IT support guy" because their systems were infected. This opportunity allowed me to continue building my skill set while helping others. In addition to practicing on test systems, I began making it known to family and friends that I will fix their infected computers for free.

Search for the Opportunity

Opportunities have a tendency to just appear but sometimes you have to seek them out. At the time I was well prepared with my knowledge and skill set in incident response so I was confident I could own certain opportunities if I found them. I started to pursue my first preference for doing IR work, which was for my current organization. I didn't ask them to send me to training or to let me help them with their incident response process. Instead I wanted them to see the value in what IR can do for an organization besides putting out fires but I had to do it in a way to compliment my skills.

I got the word out to the other security units that I could assist them with any infected systems. I made two things clear. First, I would tell them what the root cause was so they can start to mitigate infections by strengthen their controls. I knew root cause analysis wasn't consistently being done and for the security units to have access to this new skill set was instant value for them. My second point was a calculated risk but I made it clear I would be faster than their current process as well as the IT shops who re-image infected systems. If I was going to be doing the work it had to be faster than their current processes. If it wasn't then why should they even bother with me. I knew being faster would add value to the organization by freeing up FTEs (full time employees) to do other work.

I occasionally kept putting out reminders to the security units about my offer as well as getting my supervisor to remain on board for me to do this work. I can't remember how long this selling went on for (maybe a month or two) but my opportunity finally presented itself. There was an infected machine and they wanted to know the root cause. This was my shot and I knew there were two outcomes. If I came back with nothing or if my response was I can't do this work without training then they probably wouldn't had come back to me for help again. If I nailed it and showed them the value in root cause analysis for minor malicious code events then maybe I would do this work more frequently. Needless to say, the preparation I did on my own enabled me to nail the examination and I came through on the two points I sold to them to get their buy-in. Nailing the first examination wasn't enough because I had to own this and lose myself in the DFIR music.

Own the Opportunity

I and my organization had a taste of using the IR skill set for security events that were not considered to be incidents. Now I had to own this opportunity. I continued working to improve my skill set through compromising test systems and helping anyone who asked. I continued buying and reading DFIR books as well as blogs, papers, articles, etc.. I continued to hone my process to make it faster. I sacrificed my free personal time to live and breathe DFIR. The request for malicious code assistances kept coming in and each time I was better than the last. I kept getting faster and I kept showing my organization more value in what IR can do.

As I said, opportunities have a tendency to present themselves. After some time building up this working relationship there was a priority security incident. A highly visible website was potentially compromised and a determination about what happened had to be done as soon as possible. The case was mine if I wanted it and I knew I was prepared due to the months I lost myself in the DFIR music. This opportunity was different and had more at stake. My organization leveraged a third party IR service for priority incidents. In this incident, my organization used this service in addition to my assistance. To make the stakes even higher, initially we (myself and the third party) were not allowed to communicate with each other. This was an opportunity for me to not only reassure myself my place in the IR field but for me to own my place in my organization's incident response process. I worked the case with my co-worker (who was a network penetration tester with zero DFIR experience) and we were able to come back with answers before the third party service. In the end, the server wasn't compromised and everyone can stand down.

I continued losing myself in the DFIR music and owned each new opportunity that presented itself. This journey has lead to where I am today. I'm building out my organization's enterprise-wide incident response capability, developing our CSIRT, and improving our response capability by making it faster. I'm improving our detection capability by architecturing and managing our SIEM deployment as well as combining our detection and response capabilities.

Lose Yourself in the DFIR Music

The path that lead me to become an incident responder has been very challenging but rewarding. It required sacrifices and a lot of work to be prepared for the opportunities that God put in my path. It requires constant motivation so I will be better tomorrow than I am today. It requires me to approach my career as if each opportunity may be the last. It requires me to have the mindset seen in the "Lose Yourself" lyrics.

"You better lose yourself in the music, the moment
You own it, you better never let it go
You only get one shot, do not miss your chance to blow
The opportunity comes once in a lifetime"