HowTo: Data Exfiltration

One of the questions I see time and again, in forums as well as from customers, is "what data was taken from the system?"  Sometimes, an organization will find out what data was taken when they get a call from an outside third party (just review any of the annual reports from Verizon, Mandiant, or TrustWave); if this is the case, they may have a pretty good idea of what data was taken.

This post is not intended to be totally comprehensive; rather, the idea here is to present artifacts that you can look for/at that you may not have seen before, and provide other opportunities for finding indications of data exfiltration.  Many of these artifacts are very simple to check for and analyze, and provide for a more thorough and complete examination, even if nothing is found.  After all, simply illustrating to the customer that you checked all of these possibilities provides value, regardless of whether any useful evidence was turned up.

It's also very important to point out that these artifacts may provide an indication of data exfiltration of some kind; the only way to determine if data was exfiltrated at a particular time, and what that data might have been, in a definitive manner is to have a full packet capture from the time of exfiltration.  That way, you can see exactly what was exfiltrated.

Attachments
Attachments are an easy means for getting files off of a system.  Attachments can be made to email, web mail, as well as to chat/IM programs.  Files can be uploaded via the web to sites like Twitter, Yahoo Groups, Google Docs, etc.  The use of social media should be examined closely.

Program Execution
One of the things you'll want to look for is artifacts of program execution...many times, exfiltrating data requires that a program of some type be executed; whether it's launching a standalone application or uploading something via a browser, a program must be running for data exfil to occur.

Programs you might want to look for include the Windows native ftp.exe command line utility, third-party FTP utilities, etc.  Also, you might consider looking for the use of archiving utilities, such as rar.exe, particularly in cases where files may have been archived prior to transmittal.  As stated in the previous blog post, you'll want to look for artifacts such as application Prefetch files, etc.  You might also want to look to user-specific Registry values, such as:

User's UserAssist (GUI) or MUICache (CLI) - RegRipper userassist.pl or muicache.pl plugins, respectively

Tracing key - RegRipper tracing.pl plugin; this key contains subkeys that I have found refer to applications with networking capabilities.  I say this in part due to observation, but also because during one investigation where an intruder had installed and run an vulnerability exploitation tool (specifically, Havij), I found references to this tool beneath this key.

BlueTooth
The first time I ran across the use of the Windows native fsquirt.exe utility, I found an entry for the utility in the user's MUICache data. The path pointed to the file in the system32 folder, which, after an initial investigation, appeared to be correct. I then found a Prefetch file for the utility, as well.  The utility is actually a wizard with a GUI, and as such, uses common dialogs to allow the user to select files to send to device; analysis of values in the ComDlg32\OpenSavePidlMRU key provided indications of files that might have been copied to the device.

Shellbags
You're probably thinking, "Really?" Well, you can find indications of possible data exfiltration (or infiltration) within the shellbags artifacts.

Shellbag artifacts can provide indications of access to network resources (such as shares), not only within the network infrastructure, but also beyond the borders of the infrastructure.

Shellbags can show indications of access to resources for data exfiltration through different types of shell items.  When I first started working with my publisher, I was provided with instructions for accessing their FTP site via Windows Explorer, which would allow me to drag-and-drop files between folders.  This method for accessing an FTP server does not leave what one would expect to be the "normal" artifacts...there is no Prefetch file (or other artifact) created for the use of the native ftp.exe utility, nor are there any UserAssist artifacts created.  However, as this method of exchanging files requires interaction with Windows Explorer, shellbag artifacts are created, and as a result, artifacts are also created beneath the Software\Microsoft\FTP\Accounts key within the user's NTUSER.DAT hive.

As mentioned previously, shellbags artifacts can also provide indications of access not only to traditional USB storage devices (i.e., thumb drives), but also to other devices (smartphones, MP3 players, and digital cameras) that can be connected to the system via a USB cable.  This is important to understand, as a number of the available tools for parsing shellbag artifacts do not parse the shell items for these devices; as such, access to these devices will not be apparent when some of the popular tools are used to parse and display these artifacts.

Cloud Services
I purposely haven't addressed cloud services in this post, as this topic should likely be addressed on it's own.  I have provided some resources (below) that may be of value.  As there are a number of different types of cloud services available, I would like to get input from the DFIR community regarding this topic, specifically. Many of these cloud services can be accessed via the web, or by specific applications installed on the system, and as such, artifacts may vary depending upon how the user accessed those services.

I've provided links to some interesting resources on this topic below.

Resources
Jad Saliba's presentation
Mary Hughes' capstone project blog; this site hasn't been updated since Feb, 2013, but it does have a number of very useful links
Derek Newtons Forensic Artifacts: Dropbox blog post
Some Carbonite artifacts - lists some Registry keys and files, not much explanation or detail

Other Means
Not all means of exfiltrating data out of an infrastructure are really very sophisticated.  I once worked for a company that was going out of business, and was involved with providing physical security when offices were being shut down.  At one point, we were contacted by HR, as they suspected that the office closure schedule had been obtained after someone "hacked" one of their computers.  A short investigation determined that someone had printed the schedule, and left it on the printer, where someone else had found the schedule and faxed it to all of the involved offices.  I've also seen where information has been pasted into an AIM chat window.

Examples
A number of years ago, I had a couple of data exfil/exposure incidents while I was filling an FTE position at a now-defunct telecom company.  In 2001, the official story was that the company was going to go through bankruptcy, and morale was very low.  The security team was contacted by a member of senior management, as apparently company memos regarding the proceedings of meetings and the direction of the company were being posted to a site called "doomedcompany.com" (this site had a sister site, whose name was a bit more vulgar).  In many cases, these memos were being posted before offices outside of the corporate headquarters received the memos via email.  We knew that a number of employees in the company were visiting the site, and that most were doing so in order to read the memos and commentary.  We had to create an account on the site, and then upload a file in order to be able to differentiate between an employee reading the memo, and someone uploading a file.  By identifying those artifacts, we were able to incorporate that information into searches.

In another case, the security team was contacted by members of HR, with the complaint that their computers were 'hacked'.  The issue centered around the impending shutdown of a call center office in Arizona, and the fact that the list of the employees being laid off was made available to that entire office.  We sat down with the HR associate who had put the list together, and asked questions, such as "...did you email this list to anyone?" and "...did you place this list on a file server?"  Ultimately, we found out that she'd sent the list to the printer, and then stepped out for a meeting.  Apparently, another employee had collected their printed document from the printer, found the list, and then faxed the list to the Arizona office.

The point is that sometimes, data exfiltration is as simple as picking up something off of the printer.

Summary
Data can be exfiltrated from a system in a number of ways, but those methods generally come down to using the network (moving data to a file share, attaching files to web-based emails, etc.), or copying files to an "attached" device (attached physically via USB, or via Bluetooth).  If data exfiltration is suspected, then the steps that you might want to take include:

1. Attempt to determine with a greater level of certainty or clarity why data exfil is suspected; what details are available?  Is this based on third-party notification, or the result of monitoring?
2. Determine where the data that was thought to have been exfil'd originally or usually could be found; was the data on a file or database server, or did it reside on a user's system?
3. Did the user have access to that data?  Are there indications that the user interacted with or accessed that data?  
4. Determine indications of programs that could be used for data exfil being executed.

One final thought...Windows systems do NOT maintain artifacts of copy operations.  You will not find any logs or Registry values that indicate files that were copied to a removable device, for example, particularly if all you have available for analysis is an image of the system.  If the user were to copy a file to an external resource, such as a thumb drive or remote file share, and then open the file from there, then a Windows shortcut/LNK file would be created on the user's system.  However, by itself, all that LNK file shows is that the user opened a file...it does not provide an indication that the user explicitly copied the file to the external resource.  In the absence of some sort of monitoring agent, additional analysis, particularly of file system time stamps on both resources, would be required in order to more closely determine if the user copied the file.