Journey Into Incident Response

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.