dfm covers

Wake up and Smell the COFEE

Wake up and Smell the COFEE

Bill Dean separates fact from fiction as he evaluates what COFEE means for forensics professionals.

  As everyone in the digital forensics community is well aware, Microsoft recently developed and released a forensic data collection tool named COFEE (Computer Online Forensic Evidence Extractor), intended for the law enforcement community only. But what seemed to be only minutes later, the tool was leaked to various Internet websites and torrent feeds. Very soon, many digital forensics specialists searched for, found, and then anxiously performed their first test of this revolutionary toolset. Disappointment quickly set in. COFEE doesn’t disclose secret backdoors into the system? COFEE doesn’t automatically bypass all passwords or provide the decryption keys? It doesn’t install the “show all evidence” button? No it doesn’t. I want to make one very important point: COFEE does not perform digital forensics. Its primary function is to perform data collection, to be analyzed at a later time. In my opinion, COFEE has a core design flaw; it is comprised of only Microsoft tools. Since many of us do not legally have access to COFEE, let us instead learn to build our own kit and add key functionality not available from Microsoft tools.

Don’t pull the plug

COFEE is a collection of various data collection tools to be executed from a portable USB drive. The tool is specifically designed to allow law enforcement to collect digital evidence from a running computer while at the crime scene. It gathers volatile data such as machine information, running processes, network connections, and so on. Overall, I applaud the efforts of Microsoft to help the law enforcement community. With law enforcement finally evolving from the “pull the plug” approach, to gathering volatile information from a running computer, this will greatly aid in their ability to be more successful in their investigations. Microsoft is enabling them to do so without extensive training. As stated on their website “An officer with even minimal computer experience can be tutored—in less than 10 minutes—to use a pre-configured COFEE device.” What many of the press releases failed to mention is that the most recent release of COFEE is actually the second version of this toolset. The initial version was released in early 2008. What is notable is that the very experienced Microsoft legal team is now in full force to have COFEE removed from the websites that were hosting it. In addition, there is rumour of altered binaries floating around. I would wager that these alterations are not legitimate enhancements. Microsoft has built this kit with only Microsoft tools; I am convinced that the COFEE would not even exist without the previous acquisition of Mark Russinovich’s and Bryce Cogswell’s Sysinternals tool suite. Because Microsoft only uses their native tools for the kit, they cannot take advantage of the great Open Source and free utilities available to you and I. As a word of caution, please do not use this tool in your investigations if you are not authorized to have it. Instead, let’s build a better toolset. COFEE uses Microsoft’s native and freely available tools to collect volatile information from a running computer. In my experience in using many of the Microsoft tools in both incident response and forensic investigations, below is a list of useful volatile artefacts that Microsoft’s COFEE gathers and the associated tool to do so.

  • <!--[if !supportLists]-->       Machine specific information (msconfig,exe, hostname.exe, psuptime.exe, and psinfo.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Local and remote file shares (net.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Groups and user information (net.exe, showgrps.exe, psloggedon.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Current user info (whoami.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Services list and their state (sclist.exe, sc.exe, and psservice.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Running Processes (pslist.exe, tasklist.exe, pslist.exe, and pstat.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Scheduled Jobs (at.exe and schtasks.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Open Files (handles.exe and psfile.exe)<!--[endif]-->
  • <!--[if !supportLists]-->       Network information (ipconfig.exe, route.exe, netstat.exe, nbtstat.exe, arp.exe, getmac.exe)<!--[endif]-->
  •  Registry information (reg.exe, autorunsc.exe)
<!--[if !supportLists]-->
Volatile data collection methodology

Contrary to some whitepapers and standards within certain sectors of our field, pulling the plug on a running machine is no longer a viable solution for preserving information when the machine is running. In fact, pulling the plug destroys electronic evidence. Depending on the situation, the most valuable information sought may be located in transient locations that will likely not be available after the machine is shut down. While volatile information has always been key in incident response, successful digital forensic investigations now benefit from this sensitive information. When a machine is running, there is an opportunity that volatile data will provide value to your investigation and it should be collected. A paradigm with many investigators with this approach is the staple of not altering the evidence in any way. This is an understandable concept and one that should be observed, until the artifacts you need are to be destroyed unless some changes are made to the evidence. The concept to keep in mind when having to alter evidence is Locard’s exchange principle. Locard’s exchange states, “with contact between two items, there will be an exchange”. For a very good application of this principle to electronic evidence, pick up your copy of Harlan Carvey’s Windows Forensics Analysis and read chapter 1. If you do not have either of the Windows Forensic Analysis books, I strongly suggest getting them. With this principal in place, we must accept that we will alter the electronic evidence to gather the needed volatile information. As a matter if fact, standing in front of the running machine making the decision on whether or not to collect volatile data is passively altering the digital evidence. Now that we have accepted that we must alter the evidence to gather volatile information, we do have the option of either being surgical with each command executed or leveraging an automated collection tool to harvest as much information as possible. This decision will depend on the specific situation and the sensitivity of the incident. When responding to an incident that is currently in progress, the option to be surgical with the commands issued may be most applicable. However, since we are discussing COFEE and building our own kit, we will be focusing on gathering as much information as possible in an automated fashion. When choosing to gather information from various volatile sources in an automated fashion, we must still be very strategic in the order in which we issue commands. The goal is to start with gathering the information most sensitive to change and work our way to the least sensitive. While working in this fashion, we must also be cautious not to perform steps that will alter evidence that we will need to draw specific conclusions or move that action to the end. Whether you are building a kit specific to incident response or a kit geared for forensic investigations, you will find that you seek much of the same information. Because of this, let’s build a core kit that meets both of these objectives. We will first outline the type of volatile information that we desire, determine our priorities from most volatile to least volatile, find the utilities to collection the information, and then script the automation of the collection. During the order of operations, we must be very cautious not to alter evidence that we will actually need to draw conclusions both while analyzing the volatile information and during a further forensic analysis. For example if we hash all files in the windows\system32 directory, we will alter the last access time for each of these files. If we are later trying to perform a timeline analysis of a malware infection in this directory, our volatile data collection efforts may prevent us from having all of the information needed during the full forensic analysis. We will be altering evidence, but we must understand what level of alteration we are performing and understand the consequences of these actions during the analysis. We should always make best effort to perform our volatile data collection using trusted binaries. It is well documented and demonstrated that machines infected with rootkits may alter the utilities that we are using to gather data to mask themselves, and information specific to their activities. The best method to reach this objective is to place all binaries, and scripts used to automated their tasks, on read only media such as a CD-ROM. However, there may be instances in which this may not be feasible.  The reality is that you may not be present when the kit is needed. Maybe it is an end customer or armed law enforcement officer executing a search warrant in a dangerous situation. When there are instances in which the end user of the kit may have “minimal computer experience”, you need the ability to hand someone a USB drive and instruct “insert this, run the executable, send the USB drive back to me”. It is advisable that you have the kit with static binaries, but is also a good idea to provide a kit that it as easy as possible to use. With all of this said, let’s built our kit with these methodologies in mind.


The full article appears in Issue 2 of Digital Forensics Magazine, published 1st February 2010. You must log in with a valid subscription to read on...


Please make cache directory writable.

Submit an Article

Call for Articles

We are keen to publish new articles from all aspects of digital forensics. Click to contact us with your completed article or article ideas.

Featured Book

Learning iOS Forensics

A practical hands-on guide to acquire and analyse iOS devices with the latest forensic techniques and tools.

Meet the Authors

Andrew Harbison

Andrew Harbison is a Director and IT Forensics Lead at Grant Thornton


Coming up in the Next issue of Digital Forensics Magazine

Coming up in Issue 31 on sale from May 2017:

DDOS Attacks on Mobile Devices

Denial of service attacks (DoS), distributed denial of service attacks (DDoS) and reflector attacks (DRDoS) are well known and documented. More recently however we have seen that these attacks have been directed at mobile communication devices.  Read More »

Advancements in Windows Hibernation File Forensics

Brian Gerdon looks at how the windows hibernation files can be a valuable source of information for digital forensic investigators. Read More »

Subscribe today

Testing Damage Sustainability on SD Cards

A growing number of companies and agencies are now specializing in repair and recovery of data and not on the forensic examination of the data. Read More »

Every Issue
Plus the usual Competition, Book Reviews, 360, IRQ, Legal

Click here to read more about the next issue