Alternative Methods of Analysis

Do I need to say it again? The age of Nintendo Forensics is gone, long past.

Acquiring a system is no longer as simple as removing the hard drive, hooking it up to a write blocker, and imaging it. Storage capacity is increasing, devices capable of storing data are diversifying and becoming more numerous (along with the data formats)...all of which are becoming more ubiquitous and common-place. As the sophistication and complexity of devices and operating systems increases, the solution to the issue of backlogs due to examinations requiring additional resources is training and education.

Training and education lead to greater subject-matter knowledge, allowing the investigator to ask better questions, and perhaps even make better requests for assistance. Having a better understanding of what is available to you and where to go to look leads to better data collection, and more thorough and efficient examinations. It also leads to solutions that might not be readily apparent to those that follow the "point and click execution" methodology.

Take this article from Police Chief Magazine, for example. 1stSgt Cohen goes so far as to specifically mention the collection of volatile data and the contents of RAM. IMHO, this is a HUGE step in the right direction. In this instance, a law enforcement officer is publicly recognizing the importance of volatile data in an investigation.

It's also clear from the article that training and education has led to the use of a "computer forensics field triage", which simply exemplifies the need for growth in this area. It's also clear from the article that a partnership between law enforcement, the NW3C and Purdue University has benefited all parties. It would appear that at some point in the game, the LEs were able to identify what they needed, and were able to request the necessary assistance from Purdue and NW3C...something known in consulting circles as "requirements analysis". At some point, the cops understood the importance of volatile memory, and thought, "we need this...now, how do we collect it in the proper manner?"

So what does this have to do with alternative methods of analysis? An increase in knowledge allows you to seek out alternative methods for your investigation.

For example, take the Trojan Defense. The "purist" approach to computer forensics...remove the hard drive from the system, acquire an image, and look for files...appears to have been less than successful, in at least one case in 2003. The effect of this decision may have set the stage for other similar decisions. So, let's say you've examined the image, searched for files, even mounted the image as a file system and hit it with multiple AV, anti-spyware, and hash-comparison, and still haven't found anything. Then lets assume you had collected volatile data...active process list, network connections, port-to-process mapping, etc. Parsing that data, wouldn't the case have been a bit more iron-clad? You'd be able to show that at the time the system was acquired, here are the processes that were running (along with their command line options, etc.), installed modules, network connections, etc.

At that point, the argument may have been that the Trojan included a rootkit component that was memory-resident and never wrote to the disk. Okay, so let's say that instead of running individual comments to collect specific elements of memory (or, better yet, before doing that...), you'd grabbed the contents of RAM? Tools for parsing the contents of RAM do not need to employ the MS API to do so, and can even locate an exited or unlinked process, and then extract the executable image file for that process from the RAM dump.

What if the issue had occurred in an environment with traffic monitoring...firewall, IDS and IPS logs may have come into play, not to mention traffic captures gathered by an alert admin or a highly-trained IR team? Then you'd have even more data to correlate...filter the network traffic based on the IP address of the system, isolate that traffic, etc.

The more you know about something, the better. The more you know about your car, for example, the better you are able to describe the issue to a mechanic. With even more knowledge, you may even be able to diagnose the issue and be able to provide something more descriptive than "it doesn't work". The same thing applies to IR, as well as to forensic analysis...greater knowledge leads to better response and collection, which leads to more thorough and efficient analysis.

So how do we get there? Well, someone figured it out, and joined forces with Purdue and NW3C. Another way to do this is through online collaboration, forums, etc.

Windows Memory Analysis

It's been a while since I've blogged on memory analysis, I know. This is in part due to my work schedule, but it also has a bit to do with how things have apparently cooled off in this area...there just doesn't seem to be the flurry of activity that there was in the past...

However, I could be wrong on that. I had received an email from someone telling me that certain tools mentioned in my book were not available (of those mentioned...nc.exe, BinText, and pmdump.exe, only BinText seems to be no longer available via the FoundStone site), so I began looking around to see if this was, in fact, the case. While looking for pmdump.exe, I noticed that Arne had released a tool called memimager.exe recently, which allows you to dump the contents of RAM using the NtSystemDebugControl API. I downloaded memimager.exe and ran it on my XP SP2 system, and then ran lsproc.pl (a modified version of my lsproc.pl for Windows 2000 systems) against it and found:

0 0 Idle
408 2860 cmd.exe
2860 3052 memimager.exe
408 3608 firefox.exe
408 120 aim6.exe
408 3576 realsched.exe
120 192 aolsoftware.exe(x)
1144 3904 svchost.exe
408 2768 hqtray.exe
408 1744 WLTRAY.EXE
408 2696 stsystra.exe
244 408 explorer.exe

Look familiar? Sure it does, albeit the above is only an extract of the output. Memimager.exe appears to work very similar to the older version of George M. Garner, Jr's dd.exe (the one that accessed the PhysicalMemory object), particularly where areas of memory that could not be read were filled with 0's. I haven't tried memimager on a Windows 2003 (no SPs) system yet. However, it is important to note that Nigilant32 from Agile Risk Management is the only other freely available tool that I'm aware of that will allow you to dump the contents of PhysicalMemory from pre-Win2K3SP1 systems...it's included with Helix, but if you're a consultant thinking about using it, be sure to read the license agreement. If you're running Nigilant32 from the Helix CD, the AgileRM license agreement applies.

I also wanted to followup and see what AAron's been up to over at Volatile Systems...his Volatility Framework is extremely promising! From there, I went to check out his blog, and saw a couple of interesting posts and links. AAron is definitely one to watch in this area of study, and he's coming out with some really innovative tools.

One of the links on AAron's blog went to something called "Push the Red Button"...this apparently isn't the same RedButton from MWC, Inc. (the RedButton GUI is visible in fig 2-5 on page 50 of my first book...you can download your own copy of the "old skool" RedButton to play with), but is very interesting. One blogpost that caught my eye had to do with carving Registry hive files from memory dumps. I've looked at this recently, albeit from a different perspective...I've written code to locate Registry keys, values, and Event Log records in memory dumps. The code is very alpha at this point, but what I've found appears fairly promising. Running such code across an entire memory dump doesn't provide a great deal of context for your data, so I would strongly suggest first extracting the contents of process memory (perhaps using lspm.pl, found on the DVD with my book), or using a tool such as pmdump.exe to extract the process memory itself during incident response activities. Other tools of note for more general file carving include Scalpel and Foremost.

So...more than anything else, it looks like it's getting to be a good time to update processes and tools. I mentioned an upcoming speaking engagement earlier, and I'm sure that there will be other opportunities to speak on Windows memory analysis in the future.

Jesse's back!

Jesse blogged recently about being over at the F3 conference in the UK, and how he was impressed with the high SNR. Jesse shared with me that during a trivia contest, one of the teams chose the name, "The Harlan Carvey Book Club". Thanks, guys (and gals, as the case may be)! It's a nice thought and very flattering...though I don't ever expect to be as popular as Jesse or The Shat. ;-)

Upcoming Speaking Engagement

Next month, I'll be in Hong Kong, speaking to the local police, as well as at the HTCIA-HK conference. The primary topic I've been asked to present is Registry analysis, with some live response/memory analysis, as well. The presentations vary from day-long to about 5 hrs, with a 45 min presentation scheduled for Thu afternoon - I'll likely be summing things up, with that presentation tentatively titled "Alternative Analysis Methods". My thought is that I will speak to the need for such things, and then summarize my previous three days of talks to present some of those methods.

Pimp my...Registry analysis

There are some great tools out there for viewing the Registry in an acquired image. EnCase has this, as does ProDiscover (I tend to prefer ProDiscover's ability to parse and display the Registry...) and AccessData's Registry Viewer. Other tools have similar abilities, as well. But you know what? Most times, I don't want to view the Registry. Nope. Most times, I don't care about 90% of what's there. That's why I wrote most of the tools available on the DVD that ships with my book, and why I continue to write other, similar tools.

For example, if I want to get an idea of the user's activity on a system, one of the first places I go is to the SAM hive, and see if the user had a local account on the system. From there, I go to the user's hive file (NTUSER.DAT) located in their profile, and start pulling out specific bits of information...parsing the UserAssist keys, etc...anything that shows not only the user's activities on the system, but also a timeline of that activity. Thanks to folks like Didier Stevens, we all have a greater understanding of the contents of the UserAssist keys.

Now, the same sort of thing applies to the entire system. For example, one of the tools I wrote allows me to type in a single command, and I'll know all of the USB removable storage devices that had been attached to the system, and when they were last attached. Note: this is system-wide information, but we now know how to tie that activity to a specific user.

On XP systems, we also have the Registry files in the Restore Points available for analysis. One great example of this is the LEO that wanted to know when a user had been moved from the Users to the Administrators group...by going back through the SAM hives maintained in the Restore Points, he was able to show approximately when that happened, and then tied that to other activity on the system, as well.

So...it's pretty clear that when it comes to Registry analysis, the RegEdit-style display of the Registry has limited usefulness. But it's also clear that there really isn't much of a commercial market for these kinds of tools. So what's the answer? Well, just like the folks who get their rides or cribs pimped out on TV, specialists bring a lot to the table. What needs to happen is greater communication of needs, and there are folks out there willing and able to fulfill that need.

Here's a good question to get discussion started...what's good, easy-to-use and easy-to-access format for a guideline of what's available in the Registry (and where)? I included an Excel spreadsheet with my book...does this work for folks? Is the "compiled HTML" (ie, *.chm) Windows Help format easier to use?

If you can't think of a good format, maybe the way to start is this...what information would you put into something like this, and how would you format or organize it?

Pimp my...live acquisition

Whenever you perform a live acquisition, what do you do? Document the system, write down things like the system model (ie., Dell PowerEdge 2960, etc), maybe write down any specific identifiers (such as the Dell service tag) and then acquire the system. But is this enough data? Are we missing things by not including the collection of other data in our live acquisition process?

What about collecting volatile data? I've had to perform live acquisitions of systems that had been rebooted multiple times since the incident was discovered, as well as systems that could not be acquired without booting them (SAS/SATA drives, etc.). Under those circumstances, maybe I wouldn't need to collect volatile data...after all, what data of interest would it contain...but maybe we should do so anyway.

How about collecting non-volatile data? Like the system name and IP address? Or the disk configuration? One of the tools available on the DVD that comes with my book lets you see the following information about hard drives attached to the system:

DeviceID : \\.\PHYSICALDRIVE0
Model : ST910021AS
Interface : IDE
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x41ab2316
Serial No : 3MH0B9G3

DeviceID : \\.\PHYSICALDRIVE1
Model : WDC WD12 00UE-00KVT0 USB Device
Interface : USB
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x96244465
Serial No :

Another tool lets you see the following:

Drive Type File System Path Free Space
----- ----- ----------- ----- ----------
C:\ Fixed NTFS 17.96 GB
D:\ Fixed NTFS 38.51 GB
E:\ CD-ROM 0.00
G:\ Fixed NTFS 42.24 GB

In the above output, notice that there are no network drives attached to the test system...no shares mapped. Had there been any, the "Type" would have been listed as "Network", and the path would have been displayed.

Does it make sense to acquire this sort of information when performing a live acquisition? If so, is this information sufficient...or, what other information, at a minimum, should be collected?

Are there conditions under which I would acquire certain info, but not others? For example, if the system had not been rebooted, would I dump the contents of physical memory (I'd say "yes" to that one)...however, if the system had been accessed by admins, scanned with AV, and rebooted several times, would it do me any good at that point to dump RAM or should I simply document the fact that I didn't, and why?

Would this information be collected prior to the live acquisition, or immediately following?

What are your thoughts...and why?

PS: If you can think of a pseudonym I can use...think of it as a "hacker handle" (that thing that Joey from Hackers kept whining about), but REALLY cool, like "Xzibit", let me know. Oh, yeah...Ovie Carroll needs one, too. ;-)

Pimp my...forensics analysis

How often do you find yourself in the position where, when performing forensic analysis, you end up either not having the tools you need (ie, the tools you do have don't show you what you need, or don't provide you with useful output)? Many of the tools we use provide basic functionality, but there are very few tools that go beyond that, and are capable of providing what we need over a large number of cases (or in some instances, even examination to examination). This leads to one of the major challenges (IMHO) of the forensic community...having the right tool for the job. Oddly enough, there just isn't a great market for tools that do very specific things like parse binary files, extract data from the Registry, etc. The lack of such tools is very likely due to the volume of work (i.e., case load) that needs to be done, and to a lack of training...commercial GUI tools with buttons to push seem to be preferred over open-source command line tools, but only if the need is actually recognized. Do we always tell someone when we need something specific, or do we just put our heads down, push through on the investigation using the tools and skill sets that we have at hand, and never address the issue because of our work load?

With your forensic-analysis-tool-of-choice (FTK, EnCase, ProDiscover, etc.), many times you may still be left with the thought, "...that data isn't in a format I can easily understand or use...". Know what I mean? Ever been there? I'm sure you have...extract that Event Log file from an image and load it up into Event Viewer on your analysis system, only to be confronted with an error message telling you that the Event Log is "corrupted". What do you do? Boot the image with LiveView (version 0.6 is available, by the way) and log into it to view the Event Log? Got the password?

The answer to this dilemma is to take a page from Xzibit's book and "pimp my forensics analysis". That's right, we're going to customize or "trick it out" our systems with the tools and stuff you need to do the job.

One way to get started on this is to take a look at my book [WARNING: Shameless self-promotion approaching...], Windows Forensic Analysis; specifically at some of the tools that ship on the accompanying DVD. All of the tools were written in Perl, but all but a few have been "compiled" into standalone EXEs so that you don't have to have Perl installed to run them, or know anything about Perl -- in fact, based on the emails I have received since the book was released in May 2007, the real limiting factor appears to be nothing more than a lack of familiarity with running command line (CLI) tools (re: over-dependence on pushing buttons). The tools were developed out of my own needs, and my hope is that as folks read the book, they too will recognize the value in parsing the Event Log files, Registry, etc., as well as the value of the tools provided.

Another resource is the upcoming Perl Scripting for Forensic Investigation and Security, to be published in the near future by Syngress/Elsevier.

What do these two resources provide? In a nutshell, customized and customizable tools. While a number of tools exist that will let you view the Registry in the familiar (via RegEdit) tree-style format, how many of those tools will translate arbitrary binary data stored in the Registry values? How many will do correlation, not only between multiple keys within a hive, but across hives, as well?

How many of the tools will allow you to parse the contents of a Windows 2000, XP, or 2003 Event Log file into an Excel spreadsheet, in a format that is easily sorted and searched? Or report on various event record statistics?

How many of these tools provide the basis for growth and customization, in order to meet the needs of a future investigation? Some tools do...they provide base functionality, and allow the user to extend that functionality through scripting languages. Some are easier to learn than others, and some are more functional that others. But even these can be limiting sometimes.

The data is there, folks...what slows us down sometimes is either (a) not knowing that the data is there (and that a resource is a source of valuable data or evidence), and (b) not knowing how to get at that data and present it in a usable and understandable manner. Overcoming this is as simple as identifying what you need, and then reaching out to the Xzibits and Les Stroud's of the forensic community to get the job done. Rest assured, you're not the only one looking for that functionality...

Some new things...

I've been offline and not posting for a while, I know...not much time to post with so much going on during my day job (but that's a Good Thing).

A couple of new things have popped up recently that I wanted to share with everyone. First, Didier Stevens has produced an update to his UserAssist program, for parsing the UserAssist Registry keys on a live system. This update parses the GUIDs, giving you even more information about the user's activities. This is something that I'll have to add to my own tools that parse the same keys, but during post-mortem analysis.

Second, Peter Burkholder over at Ellipsis has produced a patch for running my Forensic Server Project (FSP) on *nix-variant systems, to include MacOSX. I have said from the very beginning that this could be done, and Peter has gone and done it! Very cool!

Jesse Kornblum has released md5deep 2.0, which has some new features and bug fixes...check it out.

If I've missed anything, please drop me a line and let me know...

Registry Analysis

You've probably noticed a huge gap between posts...sorry about that. Contrary to popular belief, I don't just sit around all day writing books. ;-) In addition to actually working, I like to think about ways to make my job easier, and to make the final product of my analysis better. Like many, I've known for sometime that considerable, valuable data exists in the Registry...there's a quite a bit there, whether you're looking for evidence of devices attached to the system, or of user activity. One of the things I've noticed is that there are a good number of tools available that allow you to do Registry data extraction...that is, pull data from the Registry, presenting the data found in a key or value. AccessData has their Registry Viewer, tools such as EnCase and ProDiscover allow you to visualize the Registry data...however, all of these are just tools, and each has their own strength and weakness.

One of the issues that confronts us today is knowing what we're looking at or looking for. Having a tool present data to us is nice, but if we don't know how that data is populated, then what good is the tool when some one-off condition is encountered? If the analyst does not understand how the artifact in question is created or modified, then what happens when the data that he or she expects to see is not present? Remember Jesse's First Law of Computer Forensics and my own subsequent corollary?

Why is this important? Well, for one, there's been a great deal of discussion about antiforensics lately, starting with a couple of articles in CIO and CSO magazines. "Antiforensics" and "counterforensics" (thanks to Richard for definitions) are not new concepts at all...the use of such activities has been around for quite some time. However, systems are becoming more and more complex, and at the same time, feature-rich. One of the benefits of Windows XP, for example, is that the feature-rich nature of the operating system goes some lengths in offsetting the inherent antiforensic features of the operating system.

So...let's try to come full circle...Registry analysis comes into play in assisting the investigator in determining what happened, and in many cases, when. Registry analysis can provide key or corroborating data. No tool out there will provide everything an investigator needs...it's up to the investigator to understand what's needed (ie, which Registry keys pertain to a particular P2P client, or which show the files most recently accessed with an image viewing utility?) and then understand how to get it. There are tools out there that do not have pretty GUIs and buttons you can push that will provide you with that information.

Conference Presentations

I noticed from Anton's blog that the DFRWS 2007 papers were posted and available. I agree with Anton, a couple of the presentations are interesting. I was aware of Andreas's work with the Vista Event Log format, and transforming them into plain text...cool stuff.

Rich Murhpey had a paper entitled Automated Windows event log forensics, which I thought was interesting. In his paper, Rich points to "repairing" Event Log files that have been corrupted, using the method made available by Capt. Stephen Bunting. I can't say that I agree fully with this, as the Event Log files can be easily parsed directly from their binary format. Rich provides the beginnings of this in his paper, and more detailed information is available in my book. Rich also goes into extracting event records from unallocated space using Scalpel, but the file header he uses specifically targets the header and not event records in general (again, check out Windows Forensic Analysis for details on this). Extracting event records (and other objects that contain timestamp information, such as Registry keys) from unallocated space, the pagefile, or a RAM dump takes a bit more work, but it's definitely an achievable goal. Knowing the structure of these objects, we can locate the "magic number", perform some checking to ensure that we indeed have found a valid object, and then extract the information. Oh...wait...that's how the brute force EProcess parsing tools work on RAM dumps! ;-)

For those interested in time synchronization, check out A brief study of time...no, Stephen Hawking did not present this year - though, how cool would that be?! Not only is he one of the greatest minds of our time, but he's been portrayed on The Simpsons, and he's appeared in a quite funny excerpt from Star Trek:TNG! A complete set of media appearances can be seen here. For a brainiac, king-of-all-nerds kind of guy, he really rocks!

Going back to Rich's paper, the theme of DFRWS 2007 was "file carving", and the forensic challenge seems to have gone off fairly well. If you're at all interested in some of the cutting edge research in file carving, take a look at the challenge and results.

More on (the) UserAssist keys

Didier Stevens has continued some of his excellent work regarding the UserAssist keys in the Registry. This morning, he posted an entry that explains part of the value names that appear when you decode (ie, un-ROT-13) the names. He has added the capability of providing an explanation to his UserAssist tool.

When you decode the value names from beneath the UserAssist\{GUID}\Count keys, you see that the value names begin with "UEME_" and include names like "RUNPIDL" and "RUNCPL", to name just a few. Since research into these Registry entries began, no one has really known or explored what these refer to...until now. Didier has done an excellent (say "excellent" the way Mr. Burns...more data on Wikipedia...does from "The Simpons", while tenting your fingers...) job of digging into what they mean, as well as providing that explanation via his tool.

If you get a chance, please be sure to thank Didier for his work, and if you see him at a conference, buy him a beer!

Addendum, 5 Sept: Rich over at ForensicZone.com has an interesting web page posted about extracting UserAssist key value names from memory dumps. This is a very interesting move on Rich's part...I've been looking at memory dumps and finding the "magic numbers" for Registry keys and values, but I have yet (due to time constraints) to go as far as writing code to pull out the key/value structures. The interesting thing about this (I think...being the complete nerd that I am) is that if we dump the contents of physical memory and then are capable of parsing out images used by each process as well as the memory used by each process, we can then (potentially) find Registry keys and values that we can associate with a specific process, but have yet to be written to disk! In addition, we know from the Registry key structure that the keys (albeit not the values) have a timestamp associated with them, increasing their evidentary value. Great catch, Rich! I hope you and Didier keep up the great work you've been doing!

Addendum, 7 Sept: Wow, when things get rolling, it's amazing! Didier and I have exchanged a couple of emails discussing various aspects of the UserAssist keys and some of the more esoteric settings that are out there, and according to some, have actually been used! Didier's a veritable fountain of energy and enthusiasm when it comes to researching this kind of thing, so keep an eye on his blog for more good things!

TechTalk Interview

Back on 10 June, I did an interview on TechTalk, and I saw today that it's posted here. There's some other news...CNN, weather, etc...before the actual interview.

Check it out, give it a listen. Also be sure to check out some of the other shows in the archives.

Vista IR

I recently started doing some testing of IR tools on Vista, using Vista Ultimate (32-bit) installed into a VMWare Workstation 6.0 virtual machine.

Part of my testing involved running some tools on Vista to see how they worked, and another part involved mounting the *.vmdk file for my Vista VM using the latest versions of VDK and VDKWin.

IR Tools
I started off by downloading (via IE7) a couple of tools...specifically Autorunsc.exe and Tcpvcon.exe. Both seemed to work quite well, the only real hiccup being the GUI EULA dialog that pops up if you run the tools without the "/accepteula" switch (either way, the tools create a Registry key...be sure you understand and document this as part of your IR methodology if you're using these tools). An interesting part of the tcpvcon output was the amount of IPv6 stuff visible.

My next steps are to test additional tools, as well as the use of WMI-based tools.

Extracting Files from a Vista VM
Mounting the Vista VM as a read-only file system/drive letter on my XP system went off without a hitch. I was already in the process of updating the VDK drivers and VDKWin GUI files, and on a whim I pointed the mount utility at the Vista VM *.vmdk file. I was pleasantly surprised to see the VM mounted as J:\. As expected, some of the directories (specifically, System Volume Information) could not be accessed...this is due to ACLs on those objects. However, I had fairly unrestricted access to the rest of the file system.

A friend mentioned to me recently that the offsets for the Last Run time and runcount in Vista Prefetch files is different from those of XP. I extracted a Prefetch file from the Vista VM and opened it in UltraEdit to look for the offset for the last run time. I found what appeared to be a FILETIME object at offset 0x80, and modified my existing code to extract those 8 bytes. The result matched up quite nicely:

C:\Perl>vista_pref.pl d:\hacking\vista_autorunsc.exe-7bca361f.pf
Last Run = Mon Aug 20 22:50:43 2007 (UTC)

I also tried running some of the Registry parsing tools (using the Parse::Win32Registry module by James McFarlane) against files extracted from the Vista VM. I started with a Perl script that would parse the contents of the UserAssist key - here's an extract of the results:

C:\Perl\reg>pnu.pl d:\hacking\vista_ntuser.dat
LastWrite time = Mon Aug 20 22:53:02 2007 (UTC)
Mon Aug 20 22:53:02 2007 (UTC)
UEME_RUNPATH
UEME_RUNPIDL
UEME_RUNPIDL:%csidl2%\Accessories\Command Prompt.lnk
UEME_RUNPATH:C:\Windows\System32\cmd.exe
Tue Aug 14 18:47:55 2007 (UTC)
UEME_RUNPATH:C:\Windows\system32\control.exe
Wed Jul 11 20:37:27 2007 (UTC)
UEME_RUNPATH:C:\Windows\system32\Wuauclt.exe

That seems to work quite nicely! It looks like I won't have any trouble accessing the raw Registry files using James' module, at least not on 32-bit versions of Vista, so that's good news!

There's still more testing and analysis to do, but this is a good start!

Copying Files

I've been party to or heard a good number of discussions lately regarding USB removable storage devices, and one of the topics that invariably comes up is, how can you determine which files were copied from the system to a thumb drive, or vice versa.

In most instances, folks are working only with the image of a system, and do not have access to the thumb drive itself. They can easily find the information that tells them when a thumb drive was first connected, and when it was last connected...and then the next question is, what files were or may have been copied to the thumb drive (or from the thumb drive to the system)?

The fact is that Windows systems do not maintain a record of file copies or moves...there is simply no way for a forensic analyst to look at the image of a system and say which files were copied off of the system onto a thumb drive. In order to determine this, you'd need to have the thumb drive (or other media) itself, and be able to see that you had two files of the same or similar size (you can also compare the files with md5deep or ssdeep), one of which is on each piece of media. From there, you could then check the file MAC times and possibly make some conclusions regarding the direction of transfer.

Many times in a conversation on this topic, someone will bring up Windows shortcuts or LNK files. To be honest, I'm not really sure why this comes up, it just seems to be the case. Shortcuts can be created manually, of course, but with regards to files, they are created when a user double-clicks a file, such as a Word document, to open it. Repeated testing on my part (including testing done by others) has yet to turn a method by which normal (as in "normal user activity") dragging-and-dropping a file or using the "copy" command will result in a Windows shortcut file being created.

Does anyone out there have any thoughts or input on tracking this kind of activity, having nothing more than a single system image to analyze? If so, I'd appreciate hearing from you.

IR "Best Practices"

I know it's been a while since I've posted, but work has been really keeping me busy...that's an excuse that we all use, but that's my story and I'm stickin' with it!

So, I've been talking to a number of different folks recently, having discussions during my travels to and fro about incident response and computer forensics. Many times, the issue of "best practices" has come up and that got me thinking...with no specific standards body governing computer forensics or incident response, who decides what "best practices" are? Is it FIRST? After all, they have "IR" in their name, and it does stand for "incident response". Is it the ACPO Guidelines that specify "best practices"?

Well, the easy answer (for me, anyway) is that "it depends". Funny, haha, I know. But in a sense, it does. "Best practices" depend a great deal on the political and cultural makeup of your organization; I've seen places where the incident response team has NO access to the systems, and must request data and information from the network operations staff, which has their own daily tasks and requirements.

But all that aside, we can focus on the technical details of responding to Windows systems. When we say "best practices", we can specify the information we need to get in order to properly assess the situation/incident, how to go about getting it (retrieve it locally, remotely, via live acquisition, via post-mortem exam, etc.), and in what order to retrieve that data (the ACPO Guidelines specify dumping the contents of physical memory last, rather than first...), etc.

For example, we know that during live response, anything we do is going to leave an artifact. So, why not specify what data you're going to collect and the method by which you're going to collect that data? Then determine the artifacts that are left through testing, and document your procedure and artifacts (hint: things like batch files and scripts can constitute "documentation", particularly when burned to CD), and implement that procedure via some means (ie, batch file, script, etc.).

One of the questions that invariably comes up during discussions of live response and "best practices" is, can data collected via live response be used as evidence in court? I would suggest that the answer is, "why not?" After all, an assault victim can be treated by EMTs, operated on by a surgeon, and cared for in a hospital, and the police can still collect evidence and locate and prosecute the perpetrator, right? It's all about documentation, folks.

Book Review

Donald Tabone posted a review of my book, Windows Forensic Analysis, here.

In his review, Mr. Tabone included this:

What I dislike about the book:

- No mention of Steganography techniques/tools which Chapter 5 could have benefited from.

Back in the fall of '06, while I was writing the book, I sent out emails to a couple of lists asking folks what they would like to see in a book that focuses on forensic analysis of Windows systems; I received very few responses, and if memory serves, only one mentioned steganography. In this book, I wanted to focus specifically on issues directly related to the forensic analysis of Windows systems, and I did not see where steganography fit into that category.

Interestingly enough, Mr. Tabone did not mention what it was he wanted to know about steganography. Articles have already been written on the subject (SecurityFocus, etc.) and there are sites with extensive lists of tools, for a variety of platforms.

I would like to extend a hearty "thanks" to Mr. Tabone for taking the time and effort to write a review of my book, and for posting it.

Incidently, Hogfly posted a review of my book, as well. Be sure to read the comments that follow the review, as well.

Thoughts on RAM acquisition

As a follow-on to the tool testing posts, I wanted to throw something else out there...specifically, I'll start with a comment I received, which said, in part:

Tool criteria include[sic] whether the data the tool has acquired actually existed.

This is a slightly different view of RAM acquisition (or "memory dumping") than I've seen before...perhaps the most common question/concern is more along the lines of, does exculpatory evidence get overwritten?

One of the issues here is that unlike a post-mortem acquisition of a hard drive (ie, the traditional "hook the drive up to a write-blocker, etc."), when acquiring or dumping RAM, one cannot use the same method and obtain the same results...reproduceability is an issue. Because you're acquiring the contents of physical memory from a running system, at any given point in time, something will be changing; processes process, threads execute, network connections time out, etc. So, similar to the live acquisition of a hard drive, you're going to have differences (remember, one of the aspects of cryptographic hash algorithms such as MD5 is that flipping a single bit will produce a different hash). I would suggest that the approach we should take to this is to accept it and document it.

That being said, what are some of the questions that we can anticipate addressing, and how would/should we answer them? I'll take a stab at a couple of basic questions (and responses), but I'd really like to see what others have to say:

1. Did you acquire this data using an accepted, validated process?

In order to respond to this question, we need to develop a process, in such a way as to validate it, and get it "accepted". Don't ask me by whom at this point...that's something we'll need to work on.

2. Did this process overwrite evidence, exculpatory or otherwise?

I really think that determining this is part of the validation process. In order to best answer this question, we have to look at the process that is used...are we using third-party software to do this, or are we using some other method? How does that method or process affect or impact the system we're working with?

3. Was this process subverted by malware running on the system?

This needs to be part of the validation process, as well, but also part of our analysis of the data we retrieved.

4. Did you add anything to this data once you had collected it, or modify it in any way?

This particular question is not so much a technical question (though we do have to determine if our tools impact the output file in anyway) as it is a question for the responder or examiner.

As you can see, there's still a great deal of work to be done. However, please don't think for an instant that I'm suggesting that acquiring the contents of physical memory is the be-all and end-all of forensic analysis. It's a tool...a tool that when properly used can produce some very valuable results.

Tool Testing Methodology, Memory

In my last post, I described what you'd need to do to set up a system in order to test the effects of a tool we'd use on a system for IR activities. I posted this as a way of filling in a gap left by the ACPO Guidelines, which says that we need to "profile" the "forensic footprint" of our tools. That post described tools we'd need to use to discover the footprints within the file system and Registry. I invite you, the reader, to comment on other tools that may be used, as well as provide your thoughts regarding how to use them...after all, the ACPO Guidelines also state that the person using these tools must be competent, and what better way to get there than through discussion and exchange of ideas?

One thing we haven't discussed, and there doesn't seem to be a great deal of discussion of, is the effects of the tools we use on memory. One big question that is asked is, what is the "impact" that our tools have on memory? This is important to understand, and I think one of the main drivers behind this is the idea that when IR activities are first introduced in a court of law, claims will be made that the responder overwrote or deleted potentially exculpatory data during the response process. So...understanding the effect of our tools will make us competent in their use, and we'll be able to address those (and other) issues.

When a process is created (see Windows Internals, by Russinovich and Solomon for the details, or go here), the EXE file is loaded into memory...the EXE is opened and a section object is created, followed by a process object and a thread object. So, memory pages (default size is 4K) are "consumed". Now, almost all EXEs (and I say "almost" because I haven't seen every EXE file) include an import table in their PE header, which describes all of the dynamic link libraries (DLLs) that the EXE accesses. MS provides API functions via DLLs, and EXEs access these DLLs rather than the author rewriting all the code used completely from scratch. So...if the necessary DLL isn't already in memory, then it has to be located and loaded...which in turn, means that more memory pages are "consumed".

So, knowing that these memory pages are used/written to, what is the possibility that important 'evidence' is overwritten? Well, for one thing, the memory manager will not overwrite pages that are actively being used. If it did, stuff would randomly disappear and stop working. For example, your copy of a document may disappear because you loaded Solitaire and a 4K page was randomly overwritten. We wouldn't like this, would we? Of course not! So, the memory manager will allocate memory pages to a process that are not currently active.

For an example of this, let's take a look at Forensic Discovery, by Dan Farmer and Wietse Venema...specifically, chapter 8, section 17:

As the size of the memory filling process grows, it accelerates the memory decay of cached files and of terminated anonymous process memory, and eventually the system will start to cannibalize memory from running processes, moving their writable pages to the swap space. That is, that's what we expected. Unfortunately even repeat runs of this program as root only changed about 3/4 of the main memory of various computers we tested the program on. Not only did it not consume all anonymous memory but it didn't have much of an affect on the kernel and file caches.

Now, keep in mind that the tests that were run were on *nix systems, but the concept is the same for Windows systems (note: previously in the chapter, tests run on Windows XP systems were described, as well).

So this illustrates my point...when a new process is loaded, memory that is actively being used does not get overwritten. If an application (Word, Excel, Notepad) is active in memory, and there's a document that is open in that application, that information won't be overwritten...at worst, the pages not currently being used will be swapped out to the pagefile. If a Trojan is active in memory, the memory pages used by the process, as well as the information specific to the process and thread(s) themselves will not be overwritten. The flip side of this is that what does get "consumed" are memory pages that are freed for use by the memory manager; research has shown that the contents of RAM can survive a reboot, and that even after a new process (or several processes) have been loaded and run, information about exited processes and threads still persists. So, pages used by previous processes may be overwritten, as will pages that contained information about threads, and even pages that had not been previously allocated. When we recover the contents of physical memory (ie, RAM) one of the useful things about our current tools is that we can locate a process, and then by walking the page directory and table entries, locate the memory pages used by that process. By extracting and assembling these pages, we can then search them for strings, and anything we locate as "evidence" will have context; we'll be able to associate a particular piece of information (ie, a string) with a specific process. The thing about pages that have been freed when a process has exited is that we may not be able to associate that page with a specific process; we may not be able to develop context to anything we find in that particular page.

Think of it this way...if I dump the contents of memory and run strings.exe against it, I will get a lot of strings...but what context will that have? I won't be able to associate any of the strings I locate in that memory dump with a specific process, using just strings.exe. However, if I parse out the process information, reassembling EXE files and memory used by each process, and then run strings.exe on the results, I will have a considerable amount of context...not only will I know which process was using the specific memory pages, but I will have timestamps associated with process and threads, etc.

Thoughts? I just made all this up, just now. ;-) Am I off base, crazy, a raving lunatic?

Tool Testing Methodology

As I mentioned earlier, the newly-released ACPO Guidelines state:

By profiling the forensic footprint of trusted volatile data forensic tools,

Profiling, eh? Forensic footprint, you say? The next logical step is...how do we do this? Pp. 46 - 48 of my book make a pretty good start at laying this all out.

First, you want to be sure to document the tool you're testing...where you found it, the file size, cryptographic hashes, any pertinent info from the PE header, etc.

Also, when testing, you want to identify your test platform (OS, tools used, etc.) so that the tests you run are understandable and repeatable. Does the OS matter? I'm sure some folks don't think so, but it does! Why is that? Well, for one, the various versions of Windows differ...for example, Windows XP performs application prefetching by default. This means that when you run your test, depending upon how you launch the tool you're testing, you may find a .pf file added to the Prefetch directory (assuming that the number of .pf files hasn't reached the 128 file limit).

So, what testing tools do you want to have in place on the testing platform? What tools do we need to identify the "forensic footprint"? Well, you'll need two classes of tools...snapshot 'diff' tools, and active monitoring tools. Snapshot 'diff' tools allow you to snapshot the system (file system, Registry) before the tool is run, and again afterward, and then will allow you to 'diff' the two snapshots to see what what changed. Tools such as InControl5 and RegShot can be used for this purpose.

For active monitoring tools, I'd suggest ProcessMonitor from MS SysInternals. This tool allows you to monitor file and Registry accesses in real-time, and then save that information for later analysis.

In order to monitor your system for network activity while the tool is run, I'd suggest installing PortReporter on your system as part of your initial setup. The MS KB article (click on "PortReporter") also includes links to the MS PortQry and PortQryUI tools, as well as the PortReporter Log Parser utility for parsing PortReporter logs.

As many of the tools used in IR activities are CLI tools and will execute and complete fairly quickly, I'd also suggest enabling the Process Tracking auditing on your test system, so that the event record for process creation will be recorded.

Okay, so all of this covers a "forensic footprint" from the perspective of the file system and the Registry...but what about memory? Good question! Lets leave that for another post...

Thoughts so far?

Are you Security Minded?

Kai Axford posted on his blog that he's been "terribly remiss in his forensic discussions". This originated with one of Kai's earlier posts on forensic resources; I'd commented, mentioning my own books as resources.

Kai...no need to apologize. Really. Re: TechEd...gotta get approval for that from my Other Boss. ;-)