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.

HowTo: Detecting Persistence Mechanisms

This post is about actually detecting persistence mechanisms...not querying them, but detecting them.  There's a difference between querying known persistence mechanisms, and detecting previously unknown persistence mechanisms used by malware; the former we can do with tools such as AutoRuns and RegRipper, but the latter requires a bit more work.

Detecting the persistence mechanism used by malware can be a critical component of an investigation; for one, it helps us determine the window of compromise, or how long it's been since the system was infected (or compromised).  For PCI exams in particular, this is important because many organizations know approximately how many credit card transactions they process on a daily or weekly basis, and combining this information with the window of compromise can help them estimate their exposure.  If malware infects a system in a user context but does not escalate it's privileges, then it will mostly likely start back up after a reboot only after that user logs back into the system.  If the system is rebooted and another user logs in (or in the case of a server, no user logs in...), then the malware will remain dormant.

Detecting Persistence Mechanisms
Most often, we can determine a malware persistence mechanism by querying the system with tools such as those mentioned previously in this post.  However, neither of these tools is comprehensive enough to cover other possible persistence mechanisms, and as such, we need to seek other processes or methods of analysis and detection.

One process that I've found to be very useful is timeline analysis.  Timelines provide us with context and an increased relative confidence in our data, and depending upon which data we include in our timeline, an unparalleled level of granularity.

Several years ago, I determined the existence of a variant of W32/Crimea on a system (used in online banking fraud) by creating a timeline of system activity.  I had started by reviewing the AV logs from the installed application, and then moved on to scanning the image (mounted as a volume) with several licensed commercial AV scanners, none of which located any malware.  I finally used an AV scanner called "a-squared" (now apparently owned by Emsisoft), and it found a malicious DLL.  Using that DLL name as a pivot point within my timeline, I saw that relatively close to the creation date of the malicious DLL, the file C:\Windows\system32\imm32.dll was modified; parsing the file with a PE analysis tool, I could see that the PE Import Table had been modified to point to the malicious DLL.  The persistence mechanism employed by the malware was to 'attach' to a DLL that is loaded by user processes that interact with the keyboard, in particular web browsers.  It appeared to be a keystroke logger that was only interested in information entered into form fields in web pages for online banking sites.

Interestingly enough, this particular malware was very well designed, in that it did not write the information it collected to a file on the system.  Instead, it immediately sent the information off of the system to a waiting server, and the only artifacts that we could find of that communication were web server responses embedded in the pagefile.

Something else to consider is the DLL Search Order "issue", often referred to as hijacking. This has been discussed at length, and likely still remains an issue because it's not so much a specific vulnerability that can be patched or fixed, but more a matter of functionality provided by the architecture of the operating system.

In the case of ntshrui.dll (discussed here by Nick Harbour, while he was still with Mandiant), this is how it worked...ntshrui.dll is listed in the Windows Registry as an approved shell extension for Windows Explorer.  In the Registry, many of the approved shell extensions have explicit paths listed...that is, the value is C:\Windows\system32\some_dll.dll, and Windows knows to go load that file.  Other shell extensions, however, are listed with implicit paths; that is, only the name of the DLL is provided, and when the executable (explorer.exe) loads, it has to go search for that DLL.  In the case of ntshrui.dll, the legitimate copy of the DLL is located in the system32 folder, but another file of the same name had been created in the C:\Windows folder, right next to the explorer.exe file.  As explorer.exe starts searching for the DLL in it's own directory, it happily loaded the malicious DLL without any sort of checking, and therefore, no errors were thrown.

Around the time that Nick was writing up his blog post, I'd run across a Windows 2003 system that had been compromised, and fortunately for me, the sysadmins had a policy for a bit more extensive logging enabled on systems.  As I was examining the timeline, starting from the most recent events to occur, I marveled at how the additional logging really added a great deal of granularity to thing such as a user logging in; I could see where the system assigned a token to the user, and then transferred the security context of the login to that user.  I then saw a number of DLLs being accessed (that is, their last accessed times were modified) from the system32 folder...and then I saw one (ntshrui.dll) from the C:\Windows folder.  This stood out to me as strange, particularly when I ran a search across the timeline for that file name, and found another file of the same name in the system32 folder.  I began researching the issue, and was able to determine that the persistence mechanism of the malware was indeed the use of the DLL search order "vulnerability".

Creating Timelines
Several years ago, I was asked to write a Perl script that would list all Registry keys within a hive file, along with their LastWrite times, in bodyfile format.  Seeing the utility of this information, I also wrote a version that would output to TLN format, for inclusion in the timelines I create and use for analysis.  This allows for significant information that I might not otherwise see to be included in the timeline; once suspicious activity has been found, or a pivot point located, finding unusual Registry keys (such as those beneath the CLSID subkey) can lead to identification of a persistence mechanism.

Additional levels of granularity can be achieved in timelines through the incorporation of intelligence into the tools used to create timelines, something that I started adding to RegRipper with the release of version 2.8. One of the drawbacks to timelines is that they will show the creation, last accessed, and last modification times of files, but not incorporate any sort of information regarding the contents of that file into the timeline.  For example, a timeline will show a file with a ".tmp" extension in the user's Temp folder, but little beyond that; incorporating additional functionality for accessing such files would allow us to include intelligence from previous analyses into our parsing routines, and hence, into our timelines.  As such, we may want to generate an alert for that ".tmp" file, specifically if the binary contents indicate that it is an executable file, or a PDF, or some other form of document.

Another example of how this functionality can be incorporated into timelines and assist us in detecting persistence mechanisms might be to add grep() statements to RegRipper plugins that parse file paths from values.  For example, your timeline would include the LastWrite time for a user's Run key as an event, but because the values for this key are not maintained in any MRU order, there's really nothing else to add.  However, if your experience were to show that file paths that include "AppData", "Application Data", or "Temp" might be suspicious, why not add checks for these to the RegRipper plugin, and generate an alert if one is found?  Would you normally expect to see a program being automatically launched from the user's "Temporary Internet Files" folder, or is that something that you'd like to be alerted on.  The same sort of thing applies to values listed in the InProcServer keys beneath the CLSID key in the Software hive.

Adding this alerting functionality to tools that parse data into timeline formats can significantly increase the level of granularity in our timelines, and help us to detect previously unknown persistence mechanisms.

Resources
Mandiant: Malware Persistence without the Windows Registry
Mandiant: What the fxsst?
jIIR: Finding Malware like Iron Man
jIIR: Tracking down persistence mechanisms

HowTo: Malware Detection, pt I

Many times we'll come across a case where we need to determine the presence of malware on a system.  As many of us are aware, AV products don't always work the way we hope they would...they don't provide us with 100% coverage and detect everything that could possibly affect our systems.

This post is NOT about malware analysis.  This post addresses malware detection during dead box analysis.  Malware detection is pretty expansive, so to really address the topic, I'm going to spread this one out across several blog posts.

Malware Detection
Malware detection during dead box analysis can be really easy, or it can be very hard.  I say this because we can mount an image as a read-only volume and run several (or more) AV scanners against the volume, and keep track of all the malware found.  Or, we can run several AV scanners against the volume, and they will all find nothing - but does that mean that there isn't any malware on the system?

This post is the first of several that will write, in an attempt to fully address this issue.

Characteristics
Before we start digging into the guts of detecting malware during dead box analysis, it is important to understand the four characteristics of malware, specifically the initial infection vector, the propagation mechanism, the persistence mechanism, and artifacts of the malware.  I originally developed these characteristics as a way of helping new analysts develop a confident, professional demeanor when engaging with customers; rather than reacting like a deer in the headlights, my hope was to help these new analysts understand malware itself to the point where they could respond to a customer request in a professional and confident manner.  Understanding and applying these characteristics enables analysts to understand, detect, locate, and mitigate malware within an infrastructure.

Initial Infection Vector
The initial infection vector (or IIV) refers to how the malware originally made it's way on to the system.  Worms like SQL Slammer took advantage of poor configuration of systems; other malware gets on to systems as a result of exploiting vulnerabilities in browsers.

Understanding malware IIV mechanisms not only provides us with a starting point for beginning our investigation, but also allows analysts to go from "I think it got on the system..." or "..if I had written the malware...", to actually being able to demonstrate, through empirical data, how the malware ended up on the system.  Too many times, the IIV is assumed, and that assumption is passed on the customer, who uses that information to make critical business decisions, possibly even validating (or, invalidating) compliance.

Also, keep in mind that many of the more recent malware samples appear on systems as a result of a multi-stage delivery mechanism.  For example, a user may open an email attachment, and the document will contain embedded malicious code that will exploit a vulnerability in the target application, which may reach to a server with additional instructions, and then the second stage will reach out to another server and download the actual malware.  As such, the malware does not simply appear on the system, and the IIV is actually much more complex than one might expect.

Determining the IIV can be an important factor in a number of exams.  For example, PCI exams require that the analyst determine the window of compromise, which is essentially the time from when the system was first compromised or infected, to when the incident was discovered and taken offline.  While this is done for fairly obvious reasons, other non-PCI cases ultimately have similar requirements.  Being able to accurately determine when the system was first infected or compromised can be a critical part of an exam, and as such should not be left to speculation and guesswork, particularly when this can be determined through the use well-though-out processes.

Propagation Mechanism
This characteristic refers to how the malware moves between systems, if it does.  Some malware doesn't move between systems on it's own...instead, it infects one system and doesn't move on to other systems.  For example, RAM scrapers found during PCI cases don't infect one system and then propagate to another...rather, the malware is usually placed on specific systems by an intruder who has unrestricted access to the entire infrastructure.

Some malware will specifically infect removable devices as a means of propagation.  Worms are known primarily for their ability to propagate via the network.  Other malware is known to infect network shares, in the hopes that by infecting files on network shares, the malware will spread through the infrastructure as users access the infected files.

It's important to note that the malware propagation mechanism may be the same as the IIV, but analysts should not assume that this is the case.  Some malware may get onto a system within an infrastructure as a result of a spear-phishing campaign, and once on the internal infrastructure, propagate via network or removable drives.

Artifacts
According to Jesse Kornblum's Rootkit Paradox, rootkits want to remain hidden, and they want to run.  The paradox exists in the fact that by running, there will be ways to detect rootkits, even though they want to remain hidden.  The same is true with malware, in general, although malware authors are not as interested in remaining hidden as rootkit authors.  However, the fact is that as malware interacts with it's environment, it will leave artifacts.

Self-Inflicted Artifacts
As malware interacts with it's environment, artifacts will be created. These artifacts may be extremely transient, while others, being created by the environment itself, may be much more persistent.

One of the issues I've seen over the years when AV vendors have produced technical reports regarding malware is that there are a number of self-inflicted artifacts; that is, artifacts are created as a result of how the malware is launched in the testing environment. One of the best examples of this occurs when the IIV of a malware sample is a multi-stage delivery mechanism, and the analyst only has a copy of the executable delivered in the final stage. When this occurs, the malware report will contain artifacts of the analyst launching the malware, which will not show up on a system that was infected in the wild.

Looking for malware artifacts is a lot like using those "expert eyes" that Chris Pogue talks about in his Sniper Forensics presentations.  When malware executes, it interacts with it's environment, and the great thing about the Windows environment is that it records a lot of stuff.  In that way, it's a lot like using 'expert eyes' to look for deer on the Manassas Battlefield park...as deer move through the park, they leave signs or 'artifacts' of their presence.  They're grass eaters, and they leave scat that is different from fox, dogs, and bears (as well as from other grass eaters, like our horses).  They leave tracks, whether it's in the mud, sand, soft dirt or snow.  When they move through tall grass, they leave trails that are easily visible from horseback.  When they lay down for the night, they leave matted grass.  Sometimes the bucks will leave velvet from their horns, or if a couple of bucks are sparing, you may actually find a horn or two (we have a couple hanging in the barn).  My point is that I don't have to actually see a deer standing in a field or along a stream to know that there are deer in the area, as I can see their "artifacts".  The same thing is true for a lot of the malware out there...we just need to know what artifacts to look for, and how to look for them.  This is how we're able to detect malware during dead box analysis, particularly when that malware is not detected by AV scanners.

Some of the more popular locations where I've found artifacts include AV logs, and on Windows XP systems in particular, within the Windows firewall configuration.  I've seen a number of instances where malware has been detected by AV, but according to the logs, the AV was configured to take no action.  As such, as strange as it may seem, the malware infection is clearly visible in the AV logs.  In another instance, I was reviewing the on-demand scan AV logs and found an instance of malware being detected.  A closer examination of the system indicated that malware had originally been created on the system less than two days prior to the log entries, and I was able to verify that the malware had indeed been quarantined and then deleted.  About six weeks later, a new variant of the malware, with the same name, was deposited on the system, and throughout the course of the timeline, none of the subsequent scans detected this new variant.  Previously-detected malware can provide valuable clues of an intruder attempting to get their malware on to a system.

In other instances, the malware infection process creates a rule in the Windows firewall configuration to allow itself out onto the network.  Finding a reference to a suspicious executable in the firewall configuration can point directly to the malware.

In another instance, the "malware" we found consisted of three components...a Windows service, the "compiled" Perl script, and a utility that would shuttle the collected track data off of the system to a waiting server.  The first time that the malware components were installed on the system, within two days, an on-demand AV scan detected one of the components and removed it from the system (as indicated by the AV logs and subsequent lack of Perl2Exe temp folders).  Several weeks later, the intruder installed a new set of components, which ran happily...the installed AV no longer detected the first component.  This can happen a lot, and even when the system has been acquired, AV scans do not detect the malware within the mounted image.  As such, we very often have to rely on other artifacts...unusual entries in autostart locations, indirect artifacts,

The use of artifacts to detect the presence of malware is similar to the use of rods and cones in the human eye to detect objects at night or in low light.  Essentially, the way our vision works, we do not see an object clearly at night by looking directly at it...rather, we have to look to the side of the object.  AV scanners tend to "look directly at" malware, and may not detect new variants (or in some cases, older variants)

Persistence Mechanism
The persistence mechanism refers to the means that malware utilizes to survive reboots.  Some persistence mechanisms may allow the malware to launch as soon as the system is booted, while others will start the malware until a user logs in, or until a user launches a specific application.  Persistence mechanisms can be found in Registry locations...during the 2012 SANS Forensic Summit, Beth (a Google engineer) described writing a web scraper to run across an AV vendor's web site, and around 50% of the Registry keys she found pointed to the ubiquitous Run key.  Persistence can also be achieved through a variety of other means...locations within the file system, DLL Search Order parsing, etc.  Determining the persistence mechanism can be a very valuable part of gaining intelligence from your examination, and detecting new persistence mechanisms (to be covered in a future post) can been equally important.

Mis-Identified Persistence
Sometimes when reading a malware write-up from a vendor, particularly Microsoft, I will see that the persistence mechanism is listed as being in the HKCU\..\Run key, and the write-up goes on to say, "...so that the malware will start at system boot. This is incorrect, and can be critical to your examination; for example, if a user context on a system is infected, but when the system is rebooted another user logs in, the malware is not active.

As you may already see, the persistence mechanism of malware is also an artifact of that malware; persistence is a subset of the artifact set.  In many ways, this can help us to a great extent when it comes to detecting malware, particular malware missed by AV scanners.

Programming and DFIR

I was browsing through an online list recently and I came across an older post that I'd written, that had to do with tools.  In it, I'd made the statement, "Tweaked my browser history parser to add other available data to the events, giving me additional context."  This brought to mind just how valuable even the smallest modicum of programming skill can be to an analyst.

This statement takes understanding data structures a step further because we're not simply recognizing that, say, a particular data structure contains a time stamp.  In this case, we're modifying code to meet the needs of a specific task.  However, simply understanding basic programming principles can be a very valuable skill for DFIR work, in general, as the foundational concepts behind programming teach us a lot about scoping, and programming in practice allows us to move into task automation and eventually code customization.

Note
David Cowen has been doing very well on his own blog-a-day-for-a-year challenge, and recently posted a blog regarding some DFIR analyst milestones that he outlined. In this post, David mentions that milestone 11 includes "basic programming".  This could include batch file programming, which is still alive and well, and extremely valuable...just ask Corey Harrell.  Corey's done some great things, such as automating exploiting VSCs, through batch files.

Scoping
My programming background goes back to the early '80s, programming BASIC on the Timex-Sinclair 1000 and Apple IIe.  In high school, I learned some basic Pascal on the TRS-80, and then in college, moved on to BASIC on the same platform.  Then in graduate school, I picked up some C (one course), some M68K

assembly, and a LOT of Java and MatLab, to the point that I used both in my thesis.  This may seem like a lot, but none of it was really very extensive.  For example, when I was programming BASIC in college, my programs included one that displayed the Punisher skull on the screen and played the "Peter Gunn theme" in the background, and another one interfaced with a temperature sensor to display fluctuations on the screen.  In graduate school, the C programming course required as part of the MSEE curriculum really didn't have us to much more than open, write to or read from, and then close a file.  Some of the MatLab stuff was a bit more extensive, as we used it in linear algebra, digital signal processing and neural network courses.  But we weren't doing DFIR work, nor anything close to it.

The result of this is not that I became an expert programmer...rather, take a look that something David had said in a recent blog post, specifically that an understanding of programming helps you put your goals into perspective and reduce the scope of the problem you are trying to solve.  This is the single most valuable aspect of programming experience...being able to look at the goals of a case, and break them down into compartmentalized, achievable tasks.  Far too many times, I have seen analysts simply overwhelmed by goals such as, "Find all bad stuff", and even when going back to the customer to get clarification as to what the goals of the case should be, they still are unable to compartmentalize the tasks necessary to complete the examination.

Task Automation
There's a lot that we do that is repetitive...not just in a single case, but if you really sit down and think about the things you do during a typical exam, I'm sure that you'll come across tasks that you perform over and over again.  One of the questions I've heard at conferences, as well as while conducting training courses, is, "How do I fully exploit VSCs?"  My response to that is usually, "what do you want to do?"  If your goal is to run all the tools that you ran against the base portion of the image against the available VSCs, then you should consider taking a look at what Corey did early in 2012...as far as I can see, and from my experience, batch scripting such as this is still one of the most effective means of automating tasks such as this, and there is a LOT of information and sample code freely available on the Interwebs for automating an almost infinite number of tasks.

If batch scripting doesn't provide the necessary flexibility, there are scripting languages (Python, Perl) that might be more suitable, and there are a number of folks in the DFIR community with varying levels of experience using these languages...so don't be afraid to reach out for assistance.

Code Customization
There's a good deal of open source code out there that allows us to do the things we do.  In other cases, a tool that we use may not be open source, but we do have open source code that allows us to manipulate the output of the tool into a format that is more useful, and more easily incorporated into our analysis process.  Going back to the intro paragraph to this post, sometimes we may need to tweak some code, even if it's to simply change one small portion of the output from a decimal to hex when displaying a number.  Understanding some basic coding lets us not only be able to see what a tool is doing, but it also allows us to adjust that code when necessary.

Being able to customize code as needed also means that we can complete our analysis tasks in a much more thorough and timely manner.  After all, for "heavy lifting", or highly repetitive tasks, why not let the computer do most of the work?  Computers are really good at doing the same thing, over and over again, really fast...so why not take advantage of that?

Summary
While there is no requirement within the DFIR community (at large) to be able to write code, programming principles can go a long way toward developing our individual skills, as well as developing each of us into better analysts.  My advice to you is:

Don't be overwhelmed when you see code...try opening the code in a text viewer and just reading it.  Sure, you may not understand Perl or C or Python, but most times, you don't need to understand the actual code to figure out what it's doing.

Don't be afraid to reach out for help and ask a question.  Have a question about some code?  Reach out to the author.  Many times, folks crowdsource their questions, reaching to the "community" as a whole, and that may work for some.  However, I've had much better success by reaching directly to the coder...I can usually find their contact info in the headers of the code they wrote.  Who better to answer a question about some code than the person who wrote it?

Don't be afraid to ask for assistance in writing or modifying code.  From the very beginning (circa 2008), I've had a standing offer to modify RegRipper plugins or create custom plugins...all you gotta do is ask (provide a concise description of what's needed, and perhaps some sample data...).  That's it.  I've found that in most cases, getting an update/modification is as simple as asking.

Make the effort to learn some basic coding, even if it's batch scripting.  Program flow control structures are pretty consistent...a for loop is a for loop.  Just understanding programming can be so much more valuable than simply allowing you to write a program.

HowTo: Track Lateral Movement

A reader recently commented and asked that the topic of scoping an incident and tracking lateral movement be addressed.  I've performed incident response for some time and been involved in a wide variety of cases, so I thought I'd present something about the types of lateral movement I've encountered and how these types of cases were scoped. Some types of lateral movement are easier to scope than others, so YMMV.

When there's been lateral movement there are usually two systems involved; system A (the source) and system B (the destination).  Throughout this post, I'll try to point out which system the artifacts would appear on, as this can be a very important distinction.

SQL Injection
SQL injection (SQLi) is an interesting beast, as this exploit, if successful, allows an unprivileged user to access a system on your network, often with System-level privileges.  Not all SQLi cases necessarily involve lateral movement, specifically if the web and database servers are on the same system.  However, I have been involved in cases in which the web server was in the DMZ, but the database server was situated on the internal infrastructure.

After gaining access to a system via this type of exploit, the next thing we tended to see was that a reverse shell tool was downloaded and launched on the system, providing shell-based access to the attacker.  Very often, this can be achieved through the use of a modified version of VNC, of which there are several variants (OpenVNC, TightVNC, RealVNC, etc.). It was usually at this point that the intruder was able to orient themselves, perform recon, and then 'hop' to other systems, as necessary.

Tools: Editor, coding skillz

Note
I remember in one case, an intruder had installed a reverse shell on a system (we found this later during our investigation) and had gone undetected until they found that they were on the system at the same time as one of the admins...at which point, they opened up Notepad and typed a message to the admin. It was only after this event that we were called. ;-)

Terminal Services
I was once engaged in a case where an employee's home system had been compromised, and a keystroke logger installed.  The intruder found that the user used their home system to access their employer's infrastructure via Terminal Services, and took advantage of this to use the stolen credentials to access the infrastructure themselves.  The access was via RDP, and after initial access to the infrastructure, the intruder continued to use RDP to access other systems.  Further, all of the systems that the intruder logged into had never been accessed with those credentials.  As such, it was a simple matter to examine a few artifacts on the each of the "compromised" systems in turn, and then to verify other systems on which the user profile was found.

The systems that we dealt with were a mix of Windows XP, and Windows 2000 and 2003 for servers.  As such, the artifacts we were interested in were found in the user profile's NTUSER.DAT hive file.  If the workstation systems had been Windows 7 systems, we would have included Jump Lists (specifically, those with the AppID specific to Terminal Services) in our examination.

The system A artifacts would include Registry values, and for Windows 7 systems, Jump Lists.  Depending upon the actions the user took (i.e., double-clicking a file), there may also be shortcuts/LNK files that point to the remote system.

System B artifacts would include logins found in the Security Event Log...on Win2003 systems, look for event ID 528 type 10 logins.  On Win2008 R2, look for event ID 4624 events, as well as TerminalServices-LocalSessionManager events with ID 21.

Tools: RegRipper tsclient.pl plugin, Jump List parser (system A), Logparser (system B)

Mapping Shares
While the interaction with shares is somewhat limited, it can still be seen as a form of "lateral movement".  Shares mapped via the Map Network Drive wizard appear within the user's Registry hive, in the Map Network Drive MRU key, on system A.

On system B, the connection would appear as a login, accessing resources in the Event Log.

As Event Logs tend to rotate, the artifacts on system A may persist for much longer than those on system B.

Note
It is important to make the distinction between GUI and CLI artifacts. Many of the artifacts that we see in the user's hive that are associated with accessing other systems are the result of the user interacting via the Windows Explorer shell, which is why the path where they can be found is Windows\CurrentVersion\Explorer.  Access via CLI tools such as mapping/accessing a remote share via net.exe does not produce a similar set of artifacts.

Tools: RegRipper mndmru.pl plugin (system A); Logparser (system B)

Shellbags
It's funny that when I sit down to outline some of these HowTo blog posts, I start by typing in subheaders )like this one, which I then italicize) for topics to include in the overall subject of the post.  It's interesting that the shellbags artifacts tend to appear in so many of these posts!  Similar to mapping shares, these artifacts can provide indications of access to other systems.  There are specific top-level shell items that indicate network-based resources, and will illustrate (on system A) a user accessing those remote resources.

Tools: RegRipper shellbags.pl plugin (system A)

Scheduled Tasks
Scheduled Tasks can easily be created through the use of one of two CLI tools on systems:  schtasks.exe and at.exe.  Both tools utilize switches for creating scheduled tasks on remote systems.  On system A, you may find indications of the use of these CLI applications in the Prefetch files or other artifacts of program execution.  On system B, you may find indications of a service being started in the System Event Log (event ID 7035/7036), and on WinXP and 2003 systems, you may find indications of the task being run in the SchedLgU.txt file (although this file, like the Event Logs, tends to roll-over...).  On Windows 2008 R2, you should look to the Microsoft-Windows-TaskScheduler/Operational Event Log...event ID 102 indicates a completed task, and event ID 129 indicates that a task process was created.

PSExec
PSExec and other similar services (I've seen rcmd and xcmd used) can be used to execute processes on remote services.  The artifacts you would look for would be similar to those for Scheduled Tasks, with the exception of the specific event records on system B.

Artifacts on system A might include Prefetch files and other artifacts of program execution.

Artifacts on system B might include System Event Log entries, specifically those with event source Service Control Manager and event IDs of 7035 (service sent a start command) and 7036 (service entered a running state).

Tools: LogParser, TZWorks evtwalk or evtx_view (system B)

Testing, and Artifacts
In order to see for yourself what these artifacts "look like", try running these tools on your own.  You can do so fairly easily by setting up a virtual system and using any of these methods to access the "remote" system.

HowTo: Determine User Access To Files

Sometimes during an examination, it is important for the analyst to determine files that the user may have accessed, or at least had knowledge of.  There are a number of artifacts that can be used to determine which files a user accessed.  As of Vista, the Windows operating systems, by default, do not update the last accessed times on files when normal system activity occurs, so some other method of determining the user (or process) that accessed files, and when, needs to be developed.  Fortunately, Windows systems maintain a good deal of information regarding files users have accessed, and some artifacts may be of value, particularly in the face of the use of anti- or counter-forensics techniques.

Files on the Desktop
By default, Windows does not normally place files on a user's desktop.  Most often, installation programs provide an option for putting a shortcut to the application on the desktop, but files themselves usually end up on the desktop as a result of direct and explicit actions taken by the user.  The presence of the files themselves on the desktop can be correlated with other artifacts in order to determine when the user may have accessed those files.

Recycle Bin
Clearly, if a user deleted files, they had knowledge of them, and accessed them to the point that they deleted those files.  However, keep in mind that this is not definitive...for example, if the user uses the Shift+Del key combination, or the NukeOnDelete value has been set, the files will bypass the Recycle Bin.  As such, an empty Recycle Bin should not lead to the assumption that the user took the explicit action to empty it.  It's trivial to check artifacts that can significantly impact your findings, so do so.

Tools: Various, including custom Perl script (recbin.pl)

LNK Files/Jump Lists
Most analysts are familiar with Windows shortcut/LNK files, particularly as a means of demonstrating user knowledge of and access to files.  LNK files within the user's Windows\Recent and Office\Recent folders are created automatically when the user double-clicks the files (and the application to view the file is launched), and will contain information about the location of the file, etc.

AutomaticDestinations Jump Lists are similarly created automatically by the operating system, as a result of user actions.  These files consist of a compound binary format, containing two types of streams...LNK streams, and a DestList stream, both of which are documented and easily parsed.  The DestList stream serves the purpose of an MRU list.

Browser History
Browser history, in general, illustrates access to pages found on the Internet, but can also provide information about other files that a user has accessed.  Browser history, particularly for IE, can contain file:/// entries, indicating access to local, rather than web-based, resources.

Tip
If you find that the LocalService, NetworkService, or Default User accounts have an IE browser history (i.e., the index.dat is populated...), this may be an indication of a process running with System level privileges that is accessing the Internet via the WinInet API.

When it comes to browser history, you will also want to look at file downloads.  Beginning with Windows XP SP2, files downloaded via IE or as OutLook attachments had a Zone Identifier NTFS alternate data stream attached to them by the operating system.  I have seen this, as well, on Windows 7 systems, but irrespective of the browser used.

To illustrate this, open a command prompt (should open to your user profile directory) and type the following command:

dir /s /r * | find "$data" /i | more

This can be very revealing.  Of course, it doesn't illustrate where the files are located, as you're applying a filter to the output of 'dir' and only showing specific lines, but it can provide a good indication of files that you've downloaded.  Also, I'd be very wary of any Zone Identifier ADSs that are more than 26 or 28 bytes in size.

Prefetch Files
It's common knowledge amongst analysts that application prefetch files provide information regarding when an application was run, and how many times that application was run.  These files also contain module paths, which are essentially embedded strings that point to various files, usually DLLs.  Many times, however, the module strings may point to other files.  For example, an application prefetch file for IE will include strings pointing to the index.dat files within the user profile (for the user who launched it).  The application prefetch file for sms.exe in Lance Mueller's first practical contains a path to "del10.bat", as well as a path to the sms.exe file itself, both of which are very telling.  I've seen application prefetch files for keystroke loggers that have contained the path to the file where the keystrokes are recorded, which just goes to show how useful these files can sometimes be, and that there's a great deal of information that can be pulled from these files.  Application prefetch files can be tied to applications launched by a particular user (i.e., correlate the last run time embedded within the file to program execution information for the user), which can then provide information regarding how the files were accessed.

Tools: Custom Perl script (pref.pl)

Registry
The Registry is well-known for being a veritable treasure trove of information, particularly when combined with other analysis techniques (timeline analysis, parsing VSCs, etc.).  While not everything can be found in the Registry (for example, Windows does not maintain records of files copied...), there is a great deal that can be found within the Registry.

RecentDocs
Most of us are familiar with the RecentDocs key within the user hive.  This is one of the classic MRU keys, as the key itself and all of it's subkeys contain values, and on Windows 7 systems, one of the values is named MRUListEx, and contains the MRU order of the other keys. The other values beneath each key are numbered, and the data is a binary format that contains the name of the file accessed, as well as the name of an associated shortcut/LNK file.

Each of the subkeys beneath this key are named for various file extensions, and as such, not only provide information about which files the user may accessed, but also which applications the user may have had installed.

A means for determining the possible use of counter-forensics techniques is to compare the list of value names against the contents of the MRUListEx value; numbers in this value that do not have corresponding value names may indicate attempts to delete individual values.

Tools: RegRipper recentdocs.pl plugin

ComDlg32
The user's ComDlg32 key contains information related to common dialogs used within Windows, and can provide specific indications regarding how the user interacted with the files in question.

Some of the subkeys beneath the ComDlg32 key are...

CIDSizeMRU
As described in a previous post, this key provides indications of program execution.

LastVisitedPidlMRU and LastVisitedPidlMRULegacy
These keys contain MRUListEx values, as well as numbered values.  The numbered values contain the name of the executable from which the common dialog was launched, followed by a shell item ID list of the path that was accessed.

OpenSavePidlMRU
This key is found on Vista+ systems, and corresponds to the OpenSaveMRU key found on XP systems.  The subkeys beneath this key correspond to the extensions of opened or saved files.  Each of the numbered values beneath the subkeys consist of shell item ID lists, and there's an MRUListEx value that provides the MRU functionality for each key.

On Windows XP, value data beneath the ComDlg32 subkeys consist of ASCII strings, whereas on Vista and Windows 7, the value data consists of shell items.  This means that in some cases, those data structures will contain time stamps.  However, to be of use during an examination, the analyst needs to understand how those time stamps are created, and maintained.

Tools: RegRipper comdlg32.pl plugin

MS Office File/Place MRU Values
Each of the applications within MS Office 2010 maintains an MRU list of not only files accessed, but places from which files have been accessed (in separate keys).  In addition to the paths to the files or folders, respectively, the value string data contain entries that look like, "[T01CD76253F25ECD0]", which is a string representation of a 64-bit FILETIME time stamp.  As such, these keys aren't MRU keys in the more traditional sense of having an MRUList or MRUListEx value.

Tools: RegRipper office2010.pl plugin

TrustRecords
A while back, Andrew Case pointed out this interesting artifact.  When an MS Office document is downloaded or accessed from the network, there's a yellow bar that appears at the top of the application window, just below the menu bar.  Most often, this bar contains a button, which the user must click in order to enable editing of the document.  Within the TrustRecords key, the value names are the paths and names of the files accessed, and the first 8 bytes of the binary data appears to correlate to the time when the user clicked the "Enable Editing" button.

Tools: RegRipper trustrecords.pl plugin

Application-specific MRUs
A number of file viewers (Adobe Reader, MS Paint, etc.) maintain their own MRU lists.  Most often when interacting with the application, if you click on File in the menu bar of the app, the drop-down menu will contain (usually toward the bottom) a list of recently accessed files.  Many times, that information can be found in the Registry.

Tools:  RegRipper applets.pl and adoberdr.pl plugins

On Windows 8, the Photos key in the user's USRCLASS.DAT hive is used to track photos opened via the Photos app on the Windows 8 desktop (many thanks to Jason Hale for sharing his research on this topic).

Tools: RegRipper photos.pl plugin

ShellBags
Ah, there they are again!  Shellbags...can shellbags artifacts be used to help determine files that a user may have accessed?  Yes, they can.  On Windows XP, correlating the shellbags artifacts includes mapping the NodeSlot value in the BagMRU key to the Bags keys, where in some cases you may find what amounts to a directory listing of files; this does not appear to be the case on Windows 7.  However, the shellbags artifacts can illustrate directories that the user accessed, both locally and on network resources, and can therefore provide some information regarding files that the user may have accessed.

In addition to folders on local and removable drives, shellbags artifacts can also illustrate access to mapped network drives, Internet resources (i.e., accessing FTP sites via Windows Explorer), as well as to zipped archives.  Most of us don't usually think twice when we click on a zipped archive and it opens up just like a regular folder, in an Explorer window...however, it is important to note that this does appear as a shellbag artifact.

Tools: RegRipper shellbags.pl plugin

TypedPaths
Similar to the shellbags artifacts, the TypedPaths key in the user's NTUSER.DAT hive maintains a list of folders that the user accessed; however, for this artifact, the paths were typed into the Windows Explorer Address Bar.

Users can also disable this feature, so if you find no values in the TypedPaths key, check for the AutoSuggest value.

Tools: RegRipper typedpaths.pl plugin

Searches
With Windows XP, user search terms were maintained in the ACMru key; on Windows 7, they're found in the WordWheelQuery key.  These values can provide information regarding what the user was looking for, and provide some indications of files they may have accessed (often determined through timeline analysis).

Tools: RegRipper acrmu.pl and wordwheelquery.pl plugins

A good deal of the information that provides indications of a user's access to files has time stamps associated with it, and as such, can be included in a timeline.  This timeline can provide context and granularity to your analysis, particularly when correlated with other artifacts.

HowTo: Determine Program Execution

Sometimes during an examination, it can be important to determine what programs have been executed on a

system, and more specifically, when and by which user. Some of the artifacts on a system will provide us with indications of programs that have been executed, while others will provide information about which user launched the program, and when.  As such, some of this information can be included in a timeline.

Hopefully, something that will become evident throughout this post, as well as other HowTo posts, is that rather than focusing on individual artifacts, we're going to start putting various artifacts into "buckets" or categories.  The purpose for doing this is so that analysts don't get lost in a sea of artifacts, and are instead able to tailor their initial approach to an examination, possibly using an analysis matrix.

Okay, let's get started...

AutoStart Locations
Before we begin to look at the different artifacts that can be directly tied to a user (or not), I wanted to briefly discuss autostart locations.  These are locations within the system...file system, Registry...where references to programs can reside that allow  programs to be executed automatically, without any interaction from the user beyond booting the system or logging in.  There are a number of such locations and techniques that can be used...Registry autostart locations, including the ubiquitous Run key, Windows services, the StartUp folder on the user's Program Menu, and even the use of the DLL Search Order functionality/vulnerability.  Each of these can be (and have been) discussed in multiple blog posts, so for now, I'm simply going to present them here, under this "umbrella" heading, for completeness.

Scheduled Tasks can be, and are, used as an autostart location.  Many of us may have QuickTime or iTunes installed on our system; during installation, a Scheduled Task to check for software updates is created, and we see the results of this task now and again.  Further, on Windows 7 systems, a Scheduled Task creates backups of the Software, System, Security, and SAM hive files into the C:\Windows\system32\config\RegBack folder every 10 days.  When considering autostart locations, be sure to check the Scheduled Tasks folder.

Tip
On a live system, you need to use both the schtasks.exe and at.exe commands to get a complete listing of all of the available Scheduled Tasks.

Tools: RegRipper plugins, MS/SysInternals AutoRuns; for XP/2003 Scheduled Task *.job files, jobparse.pl; on Vista+ systems, the files are XML

User
There are a number of artifacts within the user context that can indicate program execution.  This can be very useful, as it allows analysts to correlate program execution to the user context in which the program was executed.

UserAssist
The contents of value data within a user's UserAssist subkeys can provide an excellent view into what programs the user has launched via the Explorer shell...by double-clicking icons or shortcuts, as well as by navigating via the Program Menu.  Most analysts are aware that the value names are Rot-13 encoded (and hence, easily decoded), and folks like Didier Stevens have gone to great lengths to document the changes in what information is maintained within the value data, as versions of the operating systems have progressed from Windows 2000 to Windows 8.

Tools: RegRipper userassist.pl and userassist_tln.pl plugins

RunMRU
When  a user clicks on the Start button on their Windows XP desktop, and then types a command into the Run box that appears, that command is added to the RunMRU key.

Interestingly, I have not found this key to be populated on Windows 7 systems, even though the key does exist.  For example, I continually use the Run box to launch tools such as RegEdit and the calculator, but when I dump the hive file and run the runmru.pl RegRipper plugin against it, I don't see any entries.  I have found the same to be true for other hives retrieved from Windows 7 systems.

Tools: RegRipper runmru.pl plugin

ComDlg32\CIDSizeMRU Values
The binary values located beneath this key appear to contain names of applications that the user recently launched.  From my experience, the majority of the content of these values, following the name of the executable file, is largely zeros, with some remnant data (possibly window position/size settings?) at the end of the file.  As one of the values is named MRUListEx, we can not only see (via a timeline) when the most recent application was launched, but we can also see when other applications were launched by examining available VSCs.

AppCompatFlags
According to MS, the Program Compatibility Assistant is used to determine if a program needs to be run in XP Compatibility Mode.  Further, "PCA stores a list of programs for which it came up...even if no compatibility modes were applied", under the Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted key in the user's NTUSER.DAT hive.  As such, we can query these values and retrieve a list of programs run by the user.

Tools: RegRipper appcompatflags.pl plugin (I updated the plugin, originally written by Brendan Cole, to include retrieving the values beneath the Persisted key, on 6 July 2013; as such, the plugin will be included in the next rollout)

MUICache
The contents of this key within the user hives (NTUSER.DAT for XP/2003, USRCLASS.DAT for Win7) often contains references to applications that were launched within the user context.  Often times, these application will include command line interface (CLI) utilities.

Windows shortcuts/LNK files and Jump Lists
You're probably thinking..."huh?"  Most analysts are familiar with how shortcuts/LNK files (and Jump Lists) can be used to demonstrate access to files or external storage devices, but they can also be used to demonstrate program execution within the context of a user.

Most of us are familiar with the LNK files found in the ..\Windows\Recent and ..\Office\Recent folders within the user profile...so, think about how those shortcuts are created.  What usually happens is that the user double-clicks a file, the OS will read the file extension from the file, and then query the Registry to determine which application to launch in order to open the file.  Windows will then launch the application...and this is where we have program execution.

Many times when a user installs an application on their system, a desktop shortcut may be created so that the user can easily launch the application.  The presence of an icon on the desktop may indicate that the user launched an installer application.

Tools: custom Perl script, tools to parse LNK files

Java Deployment Cache Index (*.idx) Files
The beginning of 2013 saw a lot of discussion about vulnerabilities to Java, as well as reports of 0-days, and as a result, there was a small number of folks within the community looking into the use of Java deployment cache index (*.idx) files during analysis.  The use of these files as artifacts during an investigation goes back to well before then, thanks to Corey Harrell.  These files provide indications of downloads to the system via Java, and in some cases, those downloads might be malicious in nature.  These artifacts are related specifically to Java being executed, and may lead to indications of additional programs being executed.  Further, given that the path to the files is within the user profile folder, we can associate the launch of Java with a specific user context.

Tools: idxparse.pl parser

Browser History
A user's browser history not only indicates that they were browsing the web (i.e., executing the browser program), but the history can also be correlated to the *.idx files discussed above in order to determine which site they were visiting that caused Java to be launched.

System
There are a number of artifacts on the system that can provide indications of program execution

Prefetch File Analysis
Most analysts are aware of some of the metadata found within Prefetch files.  Application prefetch files include metadata indicating when the application was last launched, as well as how many times it has been launched.  This can provide some excellent information

Tools: pref.pl, or any other tools/scripts that parse the embedded module strings.  Recent versions of scripts I've written and use incorporate an alerting mechanism to identify items within the strings and string paths found to be "suspicious" or "unusual".

AppCompatCache
This value within the System hive in the Registry was first discussed publicly by Mandiant, and has proven to be a treasure trove of information, particularly when it comes to malware detection and determining program execution, in general.

Tools: Mandiant's shim cache parser, RegRipper appcompatcache.pl plugin (appcompatcache_tln.pl plugin outputs in TLN format, for inclusion in timelines).

Legacy_* Keys
Within the System hive, most of use are familiar with the Windows services keys.  What you may not realize is that there is another set of keys that can be very valuable when it comes to understanding when Windows services were run...the Enum\Root\Legacy_* keys.  Beneath the ControlSet00n\Enum\Root key in the System hive, there are a number of subkeys whose names being with LEGACY_, and include the names of services.

There are a number of variants of malware (Win32/Alman.NAD, for example) that install as a service, or driver, and when launched, the operating system will create the Enum\Root\Legacy_* key for the service/driver.  Also, these keys persist after the service or driver is no longer used, or even removed from the system.  Malware writeups by AV vendors will indicate that the keys are created when the malware is run (in a sandbox), but it is more correct to say that the OS creates the key(s) automatically as a result of the execution of the malware.  This can be an important distinction, which is better addressed in another blog post.

Tools: RegRipper legacy.pl plugin

Direct* and Tracing Keys
These keys within the Software hive can provide information regarding program execution.

The "Direct*" keys are found beneath the Microsoft key, and are keys whose names start with "Direct", such as Direct3D, DirectDraw, etc.  Beneath each of these keys, you may find a MostRecentApplication key, which contains a value named Name, the data of which indicates an application that used the particular graphics functionality.  Many times during an exam, I'll see "iexplore.exe" listed in the data, but during one particular exam, I found "DVDMaker.exe" listed beneath the DirectDraw key.  In another case, I found "mmc.exe" listed beneath the same key.

I've found during exams that the Microsoft\Tracing key contains references to some applications that appear to have networking capabilities.  I do not have any references to provide information as to which applications are subject to tracing and appear beneath this key, but I have found references to interesting applications that were installed on systems, such as Juniper and Kiwi Syslog tools (during incident response engagements, this can be very helpful and allow you collect Event Logs from the system that have since been overwritten, and included in a timeline...).  Unfortunately, these artifacts have nothing more than the EXE name (no path or other information is included or available), but adding the information to a timeline can provide a bit of context and granularity for analysis.

Tip
When examining these and other keys, do not forget to check the corresponding key beneath the Wow6432Node key within the Software hive.  The RegRipper plugins address this automatically.

Tools: RegRipper direct.pl and tracing.pl plugins

Event Logs
Service Control Manager events within the System Event Log, particularly those with event IDs 7035 and 7036, provide indications of services that were successfully sent controls, for either starting or stopping the service.  Most often within the System Event Log, you'll see these types of events clustered around a system start or shutdown.  During DFIR analysis, you're likely going to be interested in either oddly named services, services that only appear recently, or services that are started well after a boot or system startup.  Also, you may want to pay close attention to services such as "PSExeSvc", "XCmdSvc", "RCmdSvc", and "AtSvc", as they may indicate lateral movement within the infrastructure.

On Windows 2008 R2 systems, I've found indications of program execution in the Application Experience Event Logs; specifically, I was examining a system that had been compromised via an easily-guessed Terminal Services password, and one of the intruders had installed Havij (and other tools) on the system.  The Application-Experience/Program-Inventory Event Log contained a number of events associated with program installation (event IDs 903 and 904), application updates (event ID 905), and application removal (event IDs 907 and 908).  While this doesn't provide a direct indication of a program executing, it does illustrate that the program was installed, and that an installer of some kind was run.

On my own Windows 7 system, I can open the Event Viewer, navigate to the Event Log, and view the records that illustrate when I have installed various programs knowingly (FTK Imager) and unknowningly (Google+ Chat).  There are even a number of application updates to things like my ActiveState Perl and Python installations.

Tools: LogParser, evtxparse.pl

Other Indirect Artifacts
Many times, we may be able to determine program execution through the use of indirect artifacts, particularly those that persist well after the application has finished executing, or even been deleted.  Many of the artifacts that we've discussed are, in fact, indirect artifacts, but there may still be others available, depending upon the program that was executed.

A number of years ago, I was...and I don't like to admit this...certified to perform PCI forensic audits.  On one case, I ran into my first instance of a RAM scraper...this was a bit of malware that was installed on a point-of-sale (POS) back office server (running Windows) as a Windows service.  After the system was booted, this instance of the malware would read the contents of a register, do some math, and use that value as a seed to wait a random amount of time before waking up and dumping the virtual memory from one of eight named (the names were listed in the executable file) processes.  The next step was to parse the memory dump for track data, and this was accomplished via the use of Perl script that was "compiled" via Perl2Exe.  I'm somewhat familiar with such executables, and one of the artifacts we found to validate our findings with respect to the actual execution of the malicious code was temporary directories created by "compiled" script.  When executables "compiled" with Perl2Exe are run, any of the Perl modules (including the runtime) packed into the executable are extracted as DLLs into a temporary directory, at which time they are "available" to the running code.  As the code was launched by a Windows service, the "temp" directories were found in the C:\Windows\Temp folder.  The interesting thing that we found was that the temp directories used to hold the modules/DLLs are not deleted after the code completes, and they persist even if the program itself is removed from the system.  In short, we had a pretty good timeline for each time the parsing code was launched.

On my own Windows 7 system, because I run a number of Perl scripts that were "compiled" with Perl2Exe within the context of my user account, the temp directories are found in the path, C:\Users\harlan\AppData\Local\Temp...the subdirectories themselves are named "p2xtmp-", and are followed by an integer, and themselves contain subdirectories that represent the Perl runtime namespace.  The time stamps (creation dates) for these subdirectories provide indications of when I executed scripts  that had been compiled via Perl2Exe.

Memory Dumps
During dead box analysis, memory dumps can be an excellent source of information.  When an application crashes, a memory dump is created, and a log file containing information including a process list also created.  When another application crash occurs, the memory dump is overwritten, but the log file is appended to, meaning that you can have a number of crash events available for analysis.  I have found this historical information to be very useful during examinations because, while the information is somewhat limited, it can illustrate whether or not a program was running at some point in the past.

We're not going to discuss hibernation files here, as once you access a hibernation file and begin analysis, there really is very little difference between analyzing the hibernation file and analyzing a memory dump for a live system.  Many of the techniques that you'd use, and the artifacts that you would look for, are pretty much the same.

Tools: text viewer

Malware Detection
Another use of this artifact category is that it can be extremely valuable in detecting the presence of malware on a system.  However, malware detection is a topic that is best addressed in another post, as there is simply too much information to limit the topic to just a portion of a blog post.

Resources
This idea of determining program execution has been discussed before:
Timeline Analysis, and Program Execution
There Are Four Lights: Program Execution

HowTo: Correlate Files To An Application

Not long ago, I ran across a question on the ForensicFocus forum, in which the original poster (OP) said that

there were a number of files were found in a user profile during an examination, and they wanted to know which application was "responsible for" these files.  There wasn't much of a description of the files (extension, content), so it wasn't as if someone could say, "oh, yeah...I know what those files are from."

There are number of analysis techniques that you can use in an effort to determine the origin of a file.  My hope in sharing this information is to perhaps provide something you may not have seen or thought of before.  Also, I'm hoping that others will share their thoughts and experiences, as well.

What's in a name?
Some applications have a naming convention for their files.  For example, when you open MS Word and work on a document, there are temp files saved along the way while you edit the document that have a particular naming convention; using this naming convention, MS has advice for recovering lost MS Word documents.

Another example that I find to be useful is the naming convention used by digital cameras.  We see this many times when our friends post pictures to social media without changing the names of the files, and we'll recognize the naming convention of the files (i.e., file name starts with "IMG" or "DSC", or something similar) and know that the files were uploaded directly from a digital camera or smartphone.  This may also be true if the files were copied directly from the storage medium of the device to the computer system that you're examining.

Location
Some applications will save various files in specific locations, which are not usually changed by the user.  However, in other instances, applications simply use the user or system %Temp% folder as a temporary storage location.  MS Office, as mentioned above, uses the current working directory to store it's temp files, which are created at (by default) regular intervals while the application is open.  If you have an MS Word document open on your desktop, and you're editing it, you can see these files being created.

Content
Try opening the file in question in a viewer or editor of some kind.  Sometimes, a viewer like Notepad might be enough to see the contents of the file, and the file may contain contents that provide insight as to it's origin.

Tip
I remember working on a case a long time ago, assisting another analyst. They'd sent me a file that contained several lines, including an IP address, and what looked like a user name and password.  I asked for the location of where the file was located on the system, but that wasn't much help to either of us.  As we dug into the examination, it turned out that the system had been subject to a SQL injection attack, and what we were looking at was an FTP batch script; we found the commands used to create the script embedded within the web server logs, and we found the file downloaded to the system, as well.

One aspect of file contents is the file signature.  File signature analysis is still in use, and most seasoned analysts are aware of the uses and limitations of this analysis technique.  However, it may be a good place to start by opening the file in a hex editor, and viewing the first 20 or so bytes of the file, comparing that to the file extension.

Another aspect of content is metadata.  Many file types...PDF, DOCX/PPTX, JPG, etc...have the capacity to store metadata within the file.  Metadata stays with the file, regardless of where the file goes, or what the file name is changed to...as long as the format isn't modified (.jpg file opened in MS Paint, and saved in .gif format), or the file isn't somehow manipulated, then the metadata will remain.

Here's an excellent post that can provide some insight into where certain, specific files may have come from. This is a great example of how a file may be created as a result of a simple command line, rather than a full-blown GUI application.

While not specific to the contents of the file itself, look to see if the file has an associated alternate data stream.  When XP SP2 was rolled out, any file downloaded via IE or OutLook had a specific ADS associated with it, which was referred to as the file's "zoneID".  In many instances, I've see the same sort of thing on Windows 7 systems, even though the browser was Firefox or Chrome.  If a file has an associated ADS, document the name and contents of the ADS, as it may provide a very good indication of the origin of the file, regardless of location.  Also, keep in mind that it is trivial to fake these ADSs.

Timelines
Timeline analysis is a fantastic analytic tool for determining where files "came from".  Timelines provide both context and granularity, and as such, can provide significant insight into what was happening on the system when the files were created (or modified).

Consider this...with just a file that you're curious about, you don't have much.  Sure, you can open the file in an editor, but what if the contents are simply a binary mess that makes no sense to you?  Okay, you check the creation date of the file, and then compare that to information you were able to pull together regarding the users logged on to the system, and you see the "cdavis" was logged on at the time in question.  What does that tell you?  I know...not a lot.  However, if you were to create a timeline of system and user activity, you would see who was logged into the system, what they were doing and possibly even additional details about what may have occurred "near" the file being created.  For example, you might have information about a user logging in and then sometime later, their UserAssist data shows that they launched an application, and this is followed by a Prefetch file being modified, which is followed by other activity, and then the file in question was created on the system.

If you're performing timeline analysis and suspect that the time stamps on the file in question may have been modified (this happens quite often, simply because it's so easy to do...), open the MFT and compare the creation date from the $FILE_NAME attribute to that of the $STANDARD_INFORMATION attribute; it may behoove you to include the $FILE_NAME attribute information in your timeline, as well.

HowTo: Determine Users on the System

Now and again, I see questions in various forums that are related to (or flat out asking) about how to go about determining users on a Windows system.  In several instances, I've seen the question posted to the EnCase User Forum, asking why the results of the "Initialize Case" EnScript are different from what is retrieved by other tools.  There are several locations within the Windows system that can contain information about accounts on the system.

SAM hive - The SAM hive maintains information about user accounts local to that system.  In a corporate environment, many times you won't find the user account for the active user listed in the SAM hive, as the user account was set up in Active Directory and managed from a domain controller.  In home environments, you're likely to see multiple user accounts listed in the SAM hive.

Tool: RegRipper samparse.pl plugin; the samparse_tln.pl plugin will parse the SAM hive and output various items (account creation date, last login date, etc.) in TLN format for inclusion in a timeline.

Software hive - Within the Software hive is a key named "ProfileList" that maintains a list of...you guessed it...user profiles on the system.  This information can then be correlated against what you find within the file system (see below).

Tool: RegRipper profilelist.pl and winlogon.pl plugins.  The winlogon.pl plugin checks for "Special Accounts", which are accounts that do not appear on the Welcome screen.  This technique used by intruders in order to "hide" accounts from administrators.

File system - User information is maintained and "recorded" in the user's profile within the file system...on Vista+ systems, in the C:\Users folder.  There should be a correlation between what's in the ProfileList key, and what can be observed within the file system.

Tool: Any file viewer, or mount the image as a volume and use the dir command

Note
The LocalService or NetworkService accounts having a populated IE index.dat (web history) may be an indication of a malware infection.  I've examined systems infected with malware that is used for click-fraud and found an enormous index.dat file for one of these accounts.

Now, most analysts are aware that you can have an account listed in the SAM hive, but not have a user profile folder within the file system.  What this can indicate is that the user account was set up, but has not been used to access the system yet.  User profiles are not created until the user logs into the system using the account credentials.

Changing Settings
In order to determine if someone was accessing user settings (changing user account information, or modifying account information), there are two places you can look.  First, examine the Windows Security Event Log for indications of events that pertain to user account management (see MS KB 977519 for a list of pertinent event IDs).

Tools: LogParser, evtxparse.pl

Second, look to the shellbags.  What?  That's right...look to the shellbag artifacts.  Event Logs can roll over, and sometimes quickly, depending upon activity and Event Log settings (events being audited, Event Log size, etc.).  If you suspect that a user has been creating user accounts, or if you just want to determine if that has been the case, check the shellbags artifacts, and you might see something similar to the following in the artifact listing:

Desktop\Control Panel\User Accounts
Desktop\Control Panel\User Accounts\Create Your Password
Desktop\Control Panel\User Accounts\Change Your Picture

The above listing is an extract that was pulled out of the shellbags artifacts from my own system, but I should note that while investigating a system that had been compromised via Terminal Services, I parsed the shellbags artifacts for the compromised user account, and found similar entries related to those above, with the exception that they indicated that a user account had been created.   The intruder had then attempted to "hide" the account from the Welcome screen by making the new account a "Special Account", but they had misspelled one of the keys in the path, so the functionality was not enabled for the account.

Tool: RegRipper shellbags.pl plugin

Note
If you have thoughts as to how to expand these "HowTo" posts, or questions regarding how to take the analysis further, please let me know. Also, if there's anything specific that you'd like to see addressed, please comment here or contact me at keydet89 at yahoo dot com.

HowTo: Correlate an Attached Device to a User

Not long after my previous post on correlating LNK files to an external device, I received a question regarding correlating a device to a particular user.  Some may look at this and think, well, that's easy...the LNK files in question are located in the user profile, so correlating the user to the device is actually pretty easy.

Okay, but what happens if there are no LNK files that point to the device?  After all, for a LNK file to be available, the user must either create it manually, or perform some action where the operating system will create it automatically, right?  Usually, this means that the user has opened a folder on the external device and double-clicked a non-executable file of some kind, such as a .txt file or a Word or PowerPoint document.  The resulting action is that the appropriate application is launched based on the file extension, and the file is opened in that application, and an LNK file is created.

So, if you're examining a system and you suspect (or can show) that a USB device had been connected to the system, then how would you go about associating the device with a particular user, in the absence of LNK files?

MountPoints2 Key
As part of your USB device discovery process, one of the places that you're going to look is in the MountedDevices key within the System hive, in order to map the devices you've found in the USBStor subkeys to the volume globablly-unique identifier (GUID).  Beneath the MountedDevices key, some of the value names will be the volume GUIDs, and their binary data will contain the device information, in Unicode format.  Parsing the data and mapping back to the value name will provide you with the volume GUID.  You can then use this information to search the subkeys beneath the MountPoints2 key in the NTUSER.DAT hive files for the volume GUID

The path to the MountPoints2 key is:
\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Volume GUID key LastWrite time
It's commonly accepted that the LastWrite time for the volume GUID subkey beneath the MountPoints2 key indicates when that device was last connected to the system.

Shellbags Artifacts
Another artifact that allows us to correlate an attached device to a user is the shellbags artifacts, which on Windows 7 systems are found in the USRCLASS.DAT hive file within the user profile.  This is how we can tie a device to a particular user.

The shellbags artifacts are simply paths to resources composed of shell items, the same types of data structures that can be found in LNK file shell item ID lists, Jump Lists, as well as other locations within the Registry.  On Vista and Windows 7 systems, the first time that the user opens an Explorer window to a folder on an attached USB device (external hard drive or thumb drive), one of the shell items in the path will represent the drive letter to which the device was mapped, followed by the folder paths.  The drive letter can be correlated to a particular USB device by mapping to the contents of the MountedDevices key values (or, for a device previously connected to the system, you may want to dig a bit into the MountedDevices key contents available in VSCs), or to the "Windows Portable Devices\Devices" subkeys in the Software hive (again, be sure to check VSCs, as well).

Historical Registry Information
If you're looking for historical information from within the Registry, be sure to check the contents of the C:\Windows\system32\config\RegBack folder for backed-up copies of the System and Software hives.

However...and this is very important...the shellbags artifacts may contain information about attached devices that are not immediately obvious via other means of analysis.  For example, USB external drives and thumb drives are usually represented on the system as a volume (i.e., F:\, G:\) or drive letter, whereas smartphones, digital cameras, and MP3 players, while storage devices, usually appear beneath in the shellbags artifacts as a different type (type == 0x2e) of shell item.  Not all of the tools available for parsing shellbags will parse these types of shell items; in fact, those that don't seem to simply skip parsing the entire path, so shellbags with type 0x2e shell items at their root are not displayed.

Further, depending upon the version of Windows and the type of device, the shell items the comprise the path the resource might be type 0x00, or a variable type.  As the name implies, the routine for parsing these types of shell items varies, and in many instances, a great deal of information can be retrieved via knowledgeable manual analysis.

Devices connected via Bluetooth
Devices can be connected to a Windows system in other ways, including via Bluetooth. What's interesting about this type of connection is that smartphones are pretty ubiquitous at this point, and once the initial connection has been made, reconnecting to the device is trivial, and the device doesn't even have to be in view. The device can be reconnected as long as it is in range, and can be on a belt, or in a backpack or purse.

In my research, I found that a lot of users will connect to their smartphone via Bluetooth and use that connection to play music via their computer.  I also found out that MS provides a file called fsquirt.exe, which is loaded on a system during installation if the system is found to have a Bluetooth radio.

Use the bthport.pl RegRipper plugin to get some information about devices connected to a Windows system via Bluetooth.