Triaging with the RecentFileCache.bcf File

Monday, April 21, 2014 Posted by Corey Harrell
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.



Post a Comment