Copying Files

Every now and again, I see the question of "where does Windows keep logs of files copied to a thumb drive, or CD/DVD?" Recently, I saw that question posted to several lists, as well as emailed directly to my inbox. ;-) As such, I thought it would be a good idea to address that issue here, and maybe get comments back from others with respect to how they might address this kind of situation.

In general, Windows does not maintain a record or log of files that are copied. Whether you use the command line "copy", or use drag-n-drop, there simply isn't a record on Windows systems that show, "on this date, user X copied this file from here to here". Using something like WMI, someone could surely write a file system monitor that looked for and correlated file accesses to file creations...but that might be complicated, as you would need to also alert on removable storage devices being attached to the system and then include those within your monitoring scheme. However, this model wouldn't take into account instances in which a user opened a file in, say, MS Word, and then chose "Save As..." from the File menu and saved the file to another location.

If you have images of both pieces of media that you're interested in (ie, the hard drive, and the external storage media), you can use information from this MS KB article to gain some insight into the copy direction...if a copy operation did, in fact, occur. However, you may find a Windows shortcut/.lnk file in the acquired image of the hard drive, and a reference in the Registry to the thumb drive having been attached to the system in question. But what does this tell you? It may indicate that the user had accessed the document on the removable storage device, but it doesn't necessarily provide an indication of a copy operation.

Okay, so what if you find files...say, Word documents...with the same name on both pieces of media? Again, refer back to the previous MS KB article with respect to analyzing the MAC times of the file found in both images. I would also highly recommend hashing the files within each image (MD5, as well as perhaps also using ssdeep), as well as recording their sizes. If the files are the type that are known to contain metadata (Office or PDF docs, image files, etc.), extract and record that, as well.

The Future of IR

Many readers like to hear what others think is "the future" of something...what changes are coming down the road, how a certain segment of society or "community" will/should react to those changes, etc. Based on some of my own experiences, I thought I'd focus not so much on where I think things are going in the world of incident response (IR) and computer forensic (CF) analysis, but more on where IMHO I think things should be going.

For the most part, many of the changes that affect what we do as incident/first responders and forensic analysts are driven by outside forces. For example, storage media continues to increase in capacity, as well as complexity. Not only is the storage media itself (hard drives, thumb drives, etc.) increasing in capacity, but so is the complexity of how these are used (ie, multi-terabyte NASs and SANs, boot-from-SAN servers, etc.). Add to that increased sources (iPods, cell phones...let's not even discuss cell phones and PDAs...) of data (I'm refraining from the use of the term "evidence", but in many cases, it's synonymous with 'data'), as well as changes in operating systems and applications themselves, and the level of complexity is quickly surging out of control.

Our world is changing...so what do we do about it? Well, for one, we can adapt and change how we do things in order to keep up, with the goal being to try to get one step ahead of the "bad guys". Rather than looking only at an acquired image of the physical drive, start conducting more live response and going into memory for data. Folks like ManTech and Volatility Systems make this sort of thing possible.

As incident responders, our needs are changing...sometimes even when we're not aware that they are. Folks like Matt Shannon have recognized this, and as a result have produced tools such as F-Response. Matt has separated the presentation and collection phase of IR/CF from the analysis phase, making even collection of data vendor-agnostic. What this means is that using F-Response, you end up with a drive icon on your forensic platform that you can then acquire, read-only, regardless of what you've got on the other end (RAID, SCSI, SAS, etc.). You can then use any tool to acquire your image, and any forensic analysis application to perform your analysis.

The thing is, Matt comes from the managed forensic services world...which is something that itself should be growing as corporate IT goes green. With the corporate IT perimeter continuing to disappear and cybercrime increasing, there is a growing need for quicker response times - that is, less time between discovery of an incident (or breach) and someone actually taking action to address it. Many organizations do not seem to be interested in training their own staff to perform first response and containment, so there needs to be a way to get data collected and analyzed and initiate response activities in a timely, efficient, and correct manner. Managed security monitoring services aid greatly in the detection (and prevention) of incidents, and managed forensic/IR services using tools such as F-Response (Enterprise Edition) would greatly decrease response time. However, managed forensic services require a great deal of trust between the customer and vendor, and that trust takes time to develop.

IMHO, innovations such as F-Response and the Volatility Systems tools are not taking us to the cutting edge of IR capabilities...rather, the people behind these innovations are creating the absolute bleeding edge of incident response.

We need to take a look at what we do and how we do it, examining and adapting our procedures and processes, based on what makes sense to us...not what makes sense to an application vendor.

Imaging Devices in the Registry

I ran across an interesting blog this morning that had to do with Windows image acquisition devices, and where files are stored. These devices aren't write-blockers (what most forensic analysts may think when they hear "image acquisition") but instead digital cameras, like the MS LifeCam. The post mentions a GUID that is part of the directory path, and a search at the MS site reveals the following:

Identifier:	GUID_DEVINTERFACE_IMAGE
Class GUID:	{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}

As a corporate consultant, I don't do a great deal of work with illicit images...however, this post does show what kind of information about image capture/acquisition devices (aka, cameras) is resident within a system image, and in particular within the Registry. The question then becomes, what other information is available?

While this specific post may apply more appropriately to law enforcement (i.e., illicit images), I can see how our team might get a call from a corporate customer regarding issues like someone taking pictures of other employees without their consent, etc. So this is great information to keep in mind.

Note that this does not apply to digital cameras that someone hooks up to their system via a USB cable and copies pictures from the camera memory device. Such devices are treated by Windows as removable storage...what we're talking about here is devices controlled via WIA in order to capture images/pictures, such as web cams.

Addendum: Apparently, some still image devices will be added to the Registry, even if they are only connected via USB and images copied off of them.

And yes, Virginia...there is a plugin! Rip.exe output looks like:

C:\Perl\forensics\rr>rip -r d:\cases\system -p imagedev
Launching imagedev v.20080730
imagedev
ControlSet001\Control\Class\{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}

Still Image Capture Devices
hp photosmart 320

Resources:
How the Windows Image Acquisition Service Stores Images from a USB Camera in Preview
Registry Entries for Still Image Devices

BRAP Forensics

Sometimes I have to marvel at the little pearls (as opposed to Perl!!) I find through sites like eEvidence...Christina's diligence in ensuring that there is always new information added to the site really makes it worthwhile to stop by at least once a month and see what's new.

One of the items I really enjoyed was Hal Berghel's article on BRAP Forensics. In this article, Hal talks about some of the nice little bits of debris or (in his words) "guano" left behind by browsers and applications, as well as OLE file (MS Word) metadata and Recycle Bin/INFO2 file analysis. Hal also mentions Registry analysis, particularly of the NTUSER.DAT file. For the most part, Hal refers to these tidbits in negative terms but for forensic analysts working on an examination, these tidbits can be priceless. I've used many of these techniques...sometimes in combination...to extract some extremely useful information from an examination.

Resources
Mandiant's WebHistorian

Challenges

As I sit here behind my keyboard, looking at my desktop, I have a couple of items on my plate...things to do...some short-term, some long-term.

One short-term item I keep in mind is, how can I do what I do better? What were some of the challenges I had to overcome on a recent (or several recent) engagement? How could I prepare myself better in the future? This usually results in an update to my own personal IR toolkit, either through a tool (something I've downloaded, or something I've written), or a methodology/process.

One long-term item is preparing to update Windows Forensic Analysis for its second edition. Lots of opportunity there...with tools like RegRipper, a lot of the smaller scripts just go away, and their functionality gets incorporated into a plugin of some kind.

When thinking about these things and actually beginning work on any/all of them, I find myself thinking, what challenges do others face? I'm a consultant by day, and a forensics nerd by...well, all the time. I do primarily corporate work, but I know that folks who hold FTE (full-time employment) positions within organizations doing what I do have a different set of challenges that they face. Throw LE into the mix, and you can see that based on the direction from which you approach IR/CF, and how you're involved in either (or both), you're going to have a different perspective, and a different set of challenges.

What are your challenges? Are they technical? Political?

RegRipper Plugin

Jason has written the first RegRipper plugin (pagingfile.pl) that I'm aware of to be written by someone other than me! The plugin returns the location of the pagefile for Windows systems.

Great job, Jason! If you want to post the plugin for public consumption or include it in the distro, let me know. And thanks for taking that first step!

ShutdownCount

I was tooling around the Internet last night and ran across the "Forensics from the sausage factory" blog...and to be honest, my first thought was, "Oh, snap!"...it sounded like another one of those blogs that starts out being technical and interesting and then pretty soon the author starts posting personal or political stuff...

Anyway, I did find some pretty interesting posts, like this one. Like a fish, I'm easily distracted by shiny objects...in this case, anything that has to do with forensic analysis and the Registry. This post mentioned the following value:

HKLM\System\CurrentControlSet\Control\Watchdog\Display\ShutdownCount

Interesting. According to the post, this maintains a count of how many times the system was shut down. Most of the information regarding this value that I've been able to find via Google has to do with CastleCops and spyware scans...not sure why. I did find some info at MS on this, but it has to do with a Watchdog timer for video display drivers.

Any thoughts?

Any other keys/values of interest? If so, it's usually helpful to state why the key/value is of interest to forensic examiners (or incident responders).

Yes, I created a plugin for this value. ;-)

Deleted Keys in the Registry

Have you ever thought, what happens when keys are deleted from the Registry? Yeah, me, too. Where do they go? Well, as it turns out, they appear to hang around, in Registry hive file "unallocated space".

A bit ago, Jolanta Thomassen asked me to help with ideas (and be her sponsor) for her master's thesis, and I threw out Registry "slack" or unallocated space recovery...which she picked up and started running with right away. So far, she's done a great job of locating "deleted" Registry cells, the most interesting (to forensic examiners) of which are cells representing Registry keys, as keys have pointers to their parent keys (so that you can reassemble the full path of the key), timestamps (aka, LastWrite time), as well as pointers to their values. All of these maybe useful to a forensic examiner.

Not only that, but she's writing her code in Perl! This makes it easy for me to understand, add print() statements to (ie, "poor man's debugger"), and modify. For example, I've borrowed her search code, and added in my own code for parsing the key cells, etc., so that I can better see and understand what's going on. In some ways, it's not too different from looking for processes in a memory dump using a brute force approach...you read in values, and make decisions about the type of cell you've found based on those values.

Okay, so I've focused on Registry keys, as I tend to think that they are the most useful to a forensic analyst, for the reasons stated above. By themselves, Registry values found in hive file "unallocated" space may not be entirely useful...without any time-based information, or anything else to reference to (ie, like a key), they're about as useful as finding some text in the pagefile or file slack.

Addendum: Got some code working (finally!) to track backwards through the hive file once a "deleted" key has been found, and attempts to reassemble the full path name of the key. Jolanta already has this working, but I wanted to give it a shot. Below is an excerpt from my code outupt (still with debug info showing):

0x0008e474 456
Software\Microsoft\Windows\CurrentVersion\Explorer
\MountPoints2\{2490fb13-f08b-11d8-958e-806d6172696f}\
Shell
LastWrite = Mon Sep 26 23:37:22 2005
Subkeys = 0
Values = 1
Ofs_LF = 0xffffffff

0x0008e4e4 344
Software\Microsoft\Windows\CurrentVersion\Explorer\
MountPoints2\{2490fb13-f08b-11d8-958e-806d6172696f}\
Shell\AutoRun
LastWrite = Mon Sep 26 23:37:22 2005
Subkeys = 0
Values = 1
Ofs_LF = 0xffffffff

0x0008e32c 784
Software\Microsoft\Windows\CurrentVersion\Explorer\
CD Burning\Current Media
LastWrite = Mon Sep 26 23:34:10 2005
Subkeys = 0
Values = 6
Ofs_LF = 0xffffffff

Notice with the first two keys above, the second is a subkey of the first, yet actual data from the first key's structure states that there are no subkeys available. Interestingly, names, LastWrite times and links to values are retained when a key is deleted, but links to subkeys are not.

Another interesting artifact retained in deleted Registry keys can be seen in the output of one of the code samples Jolanta sent me:

$$$PROTO.HIV\Software\Microsoft\Windows\CurrentVersion\
Explorer\CD Burning\Current Media
Last modified: Mon Sep 26 23:34:10 2005
-->REG_BINARY; TotalBytes; 00 88 10 00 00 00 00 00;
-->REG_BINARY; FreeBytes; 00 00 00 00 00 00 00 00;
-->REG_DWORD; Media Type; 2;
-->REG_DWORD; UDF; 1;
-->REG_SZ; Disc Label; PDServer25;
-->REG_DWORD; Set; 1;

Interesting...it looks as if on 26 Sept 2005, someone burned a CD with the label "PDServer25". This demonstrates some pretty interesting potential for time-based information that may be useful to a forensic examiner.

Forensic Analysis Applications

As a forensic nerd, I'm familiar with...either directly or indirectly...a number of tools. Like most folks, I try not to be specific to a single tool, but rather understand what I need to do, and then select the appropriate tool for the job. I've used EnCase (going back as far as v.3), FTK, ProDiscover, and recently I've had an opportunity to work with X-Ways Forensics. I have access to SMART and MacForensicsLab, although I can't admit to having used either to a great extent. I've also seen PyFlag in action, and at one point (several years ago) I even installed TSK/Autopsy on a Dell Inspiron 5150 laptop running Windows.

Before I go any further, let me say that I'm separating data collection from data analysis. If anyone's read my books, you'll know what I'm talking about. When discussing functionality in a forensic analysis application, I'm not going to be discussing the applications ability to acquire data (ie, an image)...only to present it. A great example of this is Matt Shannon's F-Response...Matt has focused solely on allowing incident responders to collect data in a vendor-agnostic manner, allowing them to use any tool they want to acquire an image from a live system.

That being said, all of these tools are just that...tools...and each has it's own strengths and weaknesses. I won't go into detail on that here, because to be honest, at some point, these things really start to become a matter of perspective. By that, I mean that I do certain kinds of analysis...intrusions, breaches, suspicious activity, etc...and I don't do other kings of work (ie, CP). Some tools are great for certain types of analysis and the folks who use them know how to navigate the application to perform those functions really well. Each forensic analysis application provides the user with a layer of abstraction of the data, as well. While the examiner may see the hex data that corresponds to the contents of the image being analyzed, she may also see things like the volume identifier, drive letter, file structure, and icons representing files and directories...all of which are abstraction layers that present and represent the data to her.

However, I don't feel that I'm completely limited by these forensic analysis applications. In many cases, I may have a need that I can fulfill by either using another tool, or by creating my own tools. For example, I do a considerable amount of Registry analysis when analyzing a Windows system. As such, Registry Viewers similar in function to RegEdit don't offer me a great deal of functionality. This is why I wrote RegRipper...and it's also the reason I've written other tools (like the ones on the DVD that ship with my book).

Working with these applications, I've found that in many ways, they're all vastly different...different in the capabilities they provide, and especially different in how you would go about getting them to perform a certain function and then display the results. Most applications abstract packages of data as 'cases' and that's great...each has their own way of requesting and storing the case-specific (examiner, date, etc.) information. Then try just adding an image file to the case...I think you can see where I'm going with this.

The issue I see facing us, as a community of forensic examiners, is that we're making our own jobs harder through complexity. I say "our" because as (heavy) users of forensic analysis applications, we should take it upon ourselves to provide input and feedback to the developers of the forensic analysis applications. We're facing the same issues we always see...storage media is increasing in capacity, data (aka, "evidence") can now be found in more sources and formats (cell phones/PDAs, physical memory/RAM, email .PST/.NSF files, etc.), and the forensic analysis applications themselves are adding to the complexity itself. There's more and more available data to analyze and it appears to me (via my own experience as well as viewing public and vendor lists/forums) that the design of forensic analysis applications is adding to the overall complexity, making it harder to get to the data presentation and reduction that is so important.

My thought is this...a forensic analysis application needs a core set of functionality and capabilities. Beyond that, additional functionality can be added through plugins or modules, as well as scripting capability via an extensive and usable API. A forensic analysis application should be a data presentation application...actual "analysis" needs to be done by the examiner or analyst themselves.

Core Functionality
- Stability - 'nuff said!
- Simplicity - again, this is all relative
- Be able to open/add/import standard and the most popular image file formats
- Be able to recognize and present a wide range of file systems
- Searches (grep/regex, keyword, filename) across all files, including inside files such as archives (zip, bz2, rar, etc.)
- File type/signature analysis
- File Carving
- Timeline creation
- Ownership/permission searches
- Hash creation/comparison
- Image viewing (aka, "Gallery View")
- Segregation of data between 'cases'
- Extensibility (via scripting API, and separate plugins)

This is just my list of core capabilities for forensic analysis apps, and shouldn't be construed as being comprehensive. Like I said before, there are going to be examiners who heavily rely on the Gallery View available in most forensic analysis apps for what they do...and there are going to be examiners (like me) who will start an examination by opening the 'case' and extracting certain files for detailed analysis. It's all a matter of what you do, and your personal preference.

Being a forensics nerd, I do understand economics. I do understand why some forensic analysis apps are designed the way they are...there is money to be made through providing training and support by making your application proprietary. There are forensic applications available and in extensive use for which the training is more about how to navigate the GUI rather than actually do productive work.

Don't get me wrong here...all I'm saying is that IMHO, I'm seeing certain aspects of what we do, and how we do it, as a "community", and I'm thinking...wow, can't this be easier and more straightforward? Shouldn't it be possible to get an analysis application that is stable, presents the data in a straightforward manner, and allows me to perform certain data reduction functions easily and accurately? Instead, why are we faced with applications whose interfaces become more complex and less easy to navigate between major releases, and at the same time loose or break major core, underlying functionality at the same time? And why are we charged thousands of dollars more for this new version? What's the focus here?

My goal here is neither to make forensic analysis so easy that a caveman could do it, nor to make so difficult that only a very select (genetic mutations) few could do it. I simply think that we've gone so far afield with the development of these applications that we've lost sight of what's actually necessary. I'd love to see a forensic analysis application that for one price comes with a core set of functionality (see above) for one price, and is simple and stable, and can be extended via a simple scripting API. Beyond that, include an a la carte menu of plugins or modules that will NOT increase the complexity of the application but instead simply add to its capabilities. For example, say an application that presents the file system within the image in an Explorer-style interface, and then a plugin that will allow the examiner to add .PST files to the case, open them in a similar style interface, and also allow the contents (including attachments) to be viewed, searched, etc...all without crashing the main app.

...or am I just completely out of my mind here?

Process-to-port Mapping

During first responder activities, be they simple troubleshooting or incident response related, one of the important pieces of information that can really provide some insight into the behavior and status of a system is process-to-port mapping.

Why is this information important? Well, it really depends on what you're looking for, but if your initial indicator or notification of a potential security incident is "unusual traffic" originating from a system, then you'd want to know what process was generating that traffic...right? After all, there are a couple of truths you need to keep in mind when troubleshooting or performing IR activities. One is that network traffic never spontaneously emanates from a system without a cause...there's always some process involved. Another is that nothing happens on a system without some code executing as part of a thread/process.

Okay, moving on...

With NT, getting process-to-port mapping information wasn't easy. You had to use a tool like fport to get the information. The same was true for Windows 2000, and it was really cool that as of XP, netstat.exe had the '-o' switch added so that you could get the network connections with the associated PID all on one line (this is great for scripting! =) )

Many folks may not be aware that there was an update to Windows 2000 that added the '-o' capability to netstat.exe on that platform. If you've got Windows 2000 systems, this is a great update to add, so that (as an admin) you have the capability to get the information you need.

Another tool you can use to get this information during IR activities is tcpvcon. I prefer this tool because it can be included in a batch file (reducing overhead), and the output can be sent to .csv format, which is great for parsing with Perl scripts.

Analysis Tip: One of the things you might run across during an engagement is working with admins who are network-centric...or being one of those network-centric admins. For example, you may get some indication of an issue from traffic captures, or IDS/IPS/firewall notifications or logs. In such cases, you very often have a couple of pieces of information available to you, one of them being the source IP of the traffic, which you would likely use to locate the system from which the traffic originated (assuming that it wasn't spoofed). But guess what? You will very likely also have the source port for the traffic...and this will information (if you don't ignore it) may assist you in identifying the process from which the network traffic had been generated. Something as simple as "netstat -ano | find " may be all you need to do to find the process that generated the traffic.

How is this important? Well, one more than one occasion, incident responders such as myself have encountered those who've said, "...we saw some unusual traffic, found the system, and scanned it with [insert AV product name], and found a virus." In such cases, there may be no correlation whatsoever between the traffic and whatever the AV product found (could've been a DLL or a Registry key...) - this is "incident response by assumption/speculation", which is about as bad as "security through obscurity".

Analysis Question

Didier Stevens recently posted a Python script that will create a .VBS script with an embedded executable. This kind of reminds me of the stories about MIT in the late '60's, when the freshmen would try to crash the server, and the admins wrote the "servercrash" script...to sort of remove the mystery and ability to claim bragging rights from the whole mess.

Didier's script presents an interesting opportunity...what would you look for if you were analyzing a system and trying to determine if something like this had been used? Any thoughts? Grab the Python script, maybe install ActivePython, and see what you come up with...