Monday, August 10, 2009

Focus on Forensics Linkfest

Last week was wild at work.

Not only did I get to borrow some neat hardware for drive work, I also tried to provide some perspectives and opinions on “forensically-sound” image capture.

On top of that, I also had just enough time to really play with Harlan Carvey’s RegRipper on a real (non-investigation related) image capture.  More on that later in the post.

It was a very crazy week but I felt oddly satisfied; that I had begun to get a handle on some nagging things.

Documentation is Everything

Shop-talking this week about incident-response in general, and “what-if” scenarios, I had the opportunity to share the importance of establishing and documenting what was done when a suspect system is focused upon.  Please note: I am not a forensic expert (IANAFE) but there are some some basic common sense things that need to be done.  Particularly when it isn’t clear at the onset if the system drive will just be wiped and reimaged or if it needs to be officially escalated to internal or external law-enforcement groups.

As such, it seems imperative that the responder approach the system with the thought in mind of preservation of the machine state as well as documentation of what was done; just in case one has to explain what occurred with the drive/system along the way.

As I don’t personally have any such standard templates that would fit the bill, I had to go looking for some that we could use in a pinch.  Luckily I found enough to get me covered for now, and certainly will inspire me when I have the time to design our own.

  • forensic it chain of custody document – docstoc – search page for related documents of that theme.  There were quite a number of good looking forms.  I didn’t have time to try to figure out the download process, but even then, I was able to view them and get a better sense of what I was looking for.

  • Forensic Bibliography – E-Evidence Information Center – great resource page with lots of direct links to PDF and other documents related to evidence collection worksheets, search-warrant templates, and chain-of-custody tracking.  I snagged more than a few forms from this site.

  • NHTCU Good Practices Guide for Computer based Electronic Evidence - (PDF) – Useful whitepaper that discusses issues and processes needed around electronic evidence collection.

  • Sample chain of custody form – United States Department of the Navy.

  • USSS Best Practices Guide to Seizing Electronic Evidence v3 – United States Secret Service “pocket-guide”. Update: it has been noted and observed in the post comments that information in this guide seems dated (internal pdf properties give a document year of 2006).  And as commenter Erik notes the guide mentions pulling network connectivity and powering system off. Yet as incident responders know; obtaining network traffic captures (at least for a period) as well as running system memory dump/image, and process/port/endpoint mappings could provide additional clues and information that will be irrevocably lost if the system is simply powered off almost immediately upon seizure. -cv.

  • Authors for Hacking Exposed Computer Forensics – WaybackMachine Internet Archive – The original site of this book appears gone, but some of the links back to forensic checklists, kit suggestions, and forms still live on. Found a few more goodies here.

  • Technology Pathways Resource Center – Technology Pathways – Simply one of the best collections of updated and current forensic documentation, whitepapers, tool downloads, and general subject material there is out there; period.  A must-bookmark page.  I only wish it had an RSS feed to monitor for updates.

Image Capture: Forensic Style: Part One

As I mentioned, I finally got my hands on a Windows system that seemed great to use as a test-bed.  I had worked the better part of a morning a few weeks ago prepping a special-build XP Pro system-deployment to be used for hand-on-testing of applicants to our team.  I took a base system image for the hardware used, then stripped off all the non-essential applications, removed some accounts, set it up to auto-log-in to a restricted user account desktop (after a successful boot by the applicant).  It worked great and I dusted off some cobwebs from my brain in the process.  When done I captured an ImageX WIM of the system, to make redeployment easy in the future of this particular one-use system.

Before I wiped and reimaged it (I use it for image-building for that particular hardware model) I figured now was a great chance to try to practice capturing a “forensic” image file and then have it to practice on.

The first step was getting a forensically “sound” image of the drive.

To do that corrected with no doubt, it is clear that the preferred method is to use a physical write-block device in-line between the drive and the OS used to capture the image.  Something I don’t (yet) have.

I’ve been looking between two primary models:

I’m not sure which would be better but luckily I was able to find a very current review by a forensic professional that seemed to provide a great comparison between the two.

It seemed to find both very good choices, though the Tableau product seemed to have the edge.

They are pricy (if self-bought) seeming to fall in the $250 - $300 range (with cable sets). But seem a critical piece of hardware for forensic-level system captures.

A non-forensically-sound alternative would be a USB drive adapter such as one of these.

Definitely, these provide NO physical write-block protection, though they do offer a convenient way for a support technician or analyst to test and recover files/system off a drive externally. 

In fact, I was able to borrow Mr. No’s Vantec device and test a slew off drives we’ve had on the shelf and sort the good from the bad, in addition to wiping the good ones. I’ll be ordering the Rosewill model soon for my own personal use.  Price for these ranges from $15-$35 depending on brand and features.  Local deals may be even better.

Image Capture: Forensic Style: Part Two

Since I didn’t have a real write-block device, and it was just a test-system capture, I chose to just use a forensic LiveCD to capture the drive-image from the internal drive and save the image to a USB attached storage drive. In theory these disks attempt to provide a software-based OS write-blocked access to the suspect drive for image capture and/or examination.  As I have learned, that may be nice but only a physical write-block device (properly used) can guarantee no write-back to the suspect drive.

For a free solution here are the ones I considered for this exercise…certainly not a complete list of options and some well-known names have not been included in this particular post.

I could have used a  Windows FE boot disk to do the work, then run Data Recovery Software by ADRC to capture a RAW or IMG single-file image, including all the sector info from the physical drive.  It isn’t specifically for “forensic” grade image capture but it would have given me a single-file image in a format I could mount as a virtual drive for examination.

Or I could also have used the Win FE/PE disk along with FTK Imager / FTK Imager Lite from AccessData.  It allows capture of a physical drive in several forensic formats along with dd format. (For more info see this Forensics 101: Acquiring an Image with FTK Imager – SANS forensics blog post).

Or I could also have used the Win FE/PE disk along with ProDiscover Basic from Technology Pathways.  It allows capture of a physical drive in the Pro Discover format along with dd format.

Or I could have used the Win FE/PE disk along with the DEFT Extra pack on a USB stick.

Then for a non-Windows “forensics” level option, I considered using my copy of the RAPTOR Forensic LiveCD maintained by Forward Discovery.  See this excellent post Unsung tools - Raptor Forensics by hogfly at his Forensic Incident Response blog for a how-to.  Hogfly covers the MAC edition of the disk, but I use the Windows version.  Process is pretty much identical.

Or I could also have used the CAINE Live CD for a forensic image capture. Its collection tool set includes both Automated Image & Restore (AIR) as well as Guymager to capture a physical drive in several supported formats, including dd format.

In the end, however, I went with the DEFT Linux forensic LiveCD distro and the guymager application.

With that, I captured a single dd file image of the 165 GB SATA internal physical disk 0 to the USB attached hard-drive in just over an hour.

Easy Peasy.

Mounting the captured (dd) image file

I wanted to now mount the single dd image file to my primary Windows system as a virtual physical drive so I could look at the sector information, run some tools against it, etc.

What to do?

Harlan Carvey covers most all the bases at his Windows Incident Response: Mounting a DD image post. It excellently covers all the major bases.

I first tried ProDiscover Basic and it certainly had no problems handling the task.  In addition it provides some at-hand tools and features for examination and case-notation of findings.  However I wanted something a bit more “seamless”.

In the end I went with incredible (and free) ImDisk Virtual Disk Driver.  It installed like a champ and provides read-only mounting options to a slew of different “image-file” formats; including dd.

I also found this dd2vmdk: dd image to vmdk virtual disk image P2V converter (though not what I was focusing on as I rarely use VMware virtualization).  It seems to stand out from others Mr. Carvey mentioned in his post as it is an “on-line” web-based conversion tool. I guess it could be a handy option if you were in a bind somehow for such a tool.

Once mounted with ImDisk, I then proceeded to verify I could (and did) see all the info captured at the sector level with one of my sector-viewer utilities. I could run GREP routines, as well as various forensic first-pass tools.

Then I tossed Harlan’s RegRipper at it.

Previously I had only flirted with the tool. This was the first time I had a “real” system to play with.

I pointed it at some of the target registry-hive files and let it, well, rip!

Looking at the log results I was astounded.  Not so much by how it performed, I understood that already.  What amazed me was what it discovered about the base image I use to build the systems for imaging.

You’ll have to wait for another post just on that, but suffice it to say, there were a tremendous number of artifacts from the image’s former life before I adopted and built upon it.  I was quite stunned by what RegRipper uncovered.

It convinced me then and there that although this tool was designed for the forensics crowd, it has unrealized value for desktop system administrators, builders, and analysts.  Amazingly informative little tool it is!

Forensic Tips and Treats from across the Webs

As the above illustrates, system admins can find value in the field of forensics.  The following are a series of posts that could be of interest to both groups.

Did I mention I found some new tools?

Yep. I did.  And I was taught how to share!  Lucky you!

  • Forensic Focus Blog – OK. Not really a “tool” but does provide great regular blog linkage to tools as well as software and hardware reviews of a forensics bent.

  • List of Cell Phone Forensic tools — PenTestIT – I’m only interested in Windows forensics and really don’t have a need for cell-phone forensics.  However this is a important field in electronic forensics and should be given the time it deserves.  So this is a great post for the curious or to get some basics.  I suppose some of these might apply to flash-based storage cards (often found in use on cell phones) which would apply just a bit as they sometimes are seen in/with Windows systems as well.

  • Announcing OffVis 1.0 Beta. – Microsoft Research & Defense – Free tool from the MS folks to examine and visualize “…the binary file format used by Microsoft Word, PowerPoint, and Excel.”  Neat particularly when looking at malware-tainted/exploited files of those formats.

  • Open Source Digital Forensics page. Great link resource maintained by Brian Carrier that includes (among many other things) pages with Open Source Windows Forensic Tools and Unix-based Tools.  Bookmark this site fast!

  • Sophos updates free Anti-Rootkit tool - H Security – news that there is a new (and free) Sophos Anti-Rootkit tool available. Registration is required for download but you can never have enough updated rootkit tools at your disposal to scan a target system.  It’s important not just to avoid self-infection but also to see if a possible “a trojan/root-kit did it, not me” defense is possible or supported.

Speaking of Rootkits…

There was news at Black Hat this year of a new boot-kit that could subvert TrueCrypt WDE systems. Please see this GSD Security and Forensics Linkfest: Duck & Cover edition post for the background info if you aren’t familiar with Stoned-Vienna.

Well, the (generally respectable) debate between the TrueCrypt camp and the author and the security folks continues.  It’s been very informative to me on the whole as I work with WDE solutions and find boot-kits particularly fascinating; more-so when paired with WDE protection.

With that in mind, here are some updated/current discussions on the whole thing worth looking at.

For the record I see accuracy in both side’s positions on the matter.

Whew!

Glad to get these links up.

Cheers for now.

--Claus V.

7 comments:

Erik said...

Whatever you do, don’t follow the instructions in the "USSS Best Practices Guide to Seizing Electronic Evidence v3"! It contains a lot of obsolete methods that led to destruction of evidence. Here are some examples from the Guide:

Guide text: "If networked [...] Unplug power to router or modem."

- How about placing a network tap inline with the network to dump some network activity to a pcap file (I prefer using dumpcap)? This file could later on be analysed with network forensics tools like NetworkMiner in order to provide valuable evidence about what the computer was used for!


Guide text: "If computer is “on” and the screen is blank, move mouse or press space bar (this will display the active image on the screen). After image appears, photograph the screen. Unplug power cord from back of tower."

- They totally missed the fact that the RAM memory should be dumped!

Sigh... United States Secret Service should know better. Maybe the guide was old, I wasn’t able to find any publication date in the document.

Miha said...

Could you please go into some detail which commands do you use to capture and then apply (if that need arrises) with ImageX.

Also since you were working on a XP system, would you have made any changes (either capturing or applying) if Vista, Win 7 was the OS.

I know there are several articles on how to use this tool, but I'd greatly appreciate if you'd share the commands you're using.

Claus said...

@ Erik -- Excellent observations. I'm thinking you are quite correct in identifying it as "dated" material. I'll make an update to the post tonight (if time allows) to reflect that catch of yours.

As you wonderfully state, finding a system in a "live" state is a real bonus for incident responders. Network traffic captures as well as memory dumps can provide critical information that would otherwise be lost if the machine is powered-down. It could really make the difference in showing suspect intent/activity or that of a trojan/malware. Not to mention end-point trails outside of the machine for additional clues or discovery.

In my sysadmin world, I see too many times when deskside techs get a malware call they just do an immediate cleaning without attempting to capture valuable memory,process-endpoint mappings, etc. through a RAM dump. That is a critical loss of information. How much more-so for a forensic responder?

Hopefully (I assume most forensic pros are already aware of this) more folks will come to realize the value and benefit of memory image acquisition. Goodness knows there are some excellent (and free/OpenSource) tools to do that now.

In fact, I was amazed to see a while back that there are actually power-kits designed for seizure of a system to keep it powered up full-time with NO power-down when seized and removed off-site for processing. I guess those would be in special circumstances but it is amazing (and positive) that these capabilities now exist.

Claus said...

@ Miha - I wouldn't ever recommend use of ImageX for forensic-quality imaging of a system.

It is a (Microsoft OS) file-based imaging solution and as such, captures none of the information found in unallocated sectors of the physical hard-drive.

It would be like taking a photo and cutting all the background elements out.

I'm assuming your asking for "normal" image captures and deployment scenarios?

Please take a look at these earlier posts I have done. They should contain most of the info you are asking about in good detail: Grand Stream Dreams: ImageX - Welcome to the Imaging X-Zone, Command-Line Voodoo: from fdisk to diskpart.

You might also want to look at the ImageX GUI (GImageX) free utility. Couple that with a supported WAIK and you have some GUI help if you aren't comfortable with the CLI.

From my ImageX X-Zone post:

To capture the image, type: imagex /compress maximum /capture c:\ z:\images\image.wim "image name"

You can leave off the "/compress maximum" if you want the image at "normal" level or use "/compress fast" for a larger, but faster image capture process.

You must specify the specific full capture drive letter and path to where you want to put the image. I used "z:\images\" as my example, yours will differ.

To restore an imagex WIM:

Run the following command: imagex /apply z:\images\image.wim 1 c:

You may want to add the extra option /verify at the end to verify your image laydown...just remember that that adds time to the deployment.

Note the "1" we used. This means to use the 1st image in the .wim file. If you have multiple images in a single .wim file you will need to know which "index number" image you want and use that number accordingly.

Other thoughts, you must first have a formatted/partitioned drive. ImageX doesn't "wipe" any existing files off so if you don't, the image files will be restored directly on-top of the preexisting files. I always use DiskPart to first clean the drive MBR, recreate my partitions, then format. THEN apply the image. Also the WIM only captures per-partition, not the entire physical drive if multiple partitions are present. If so you need to capture/restore each one accordingly. If you are cloning/deploying images to different systems, you will need to sysprep the system before taking your imagex WIM as well.

ImageX is a really great tool for working with Windows systems; XP, Vista, Windows 7, Sever 200x, Win 2K.

I love it, though there are lot of other free/Open Source Drive Imaging and Cloning Solutions if you are looking for an alternative. Many are "easier" to use than ImageX.

Hope this helps.

Cheers!

--Claus V.

Claus said...

@ - Erik - Forgot to mention the value of getting captures from a live system as well. Particularly useful if the system is running a form of whole-disk encryption. Depending on the suspect's cooperativeness, it might be the only time to quickly get a look at the system and/or RAM contents.

When powered off that access could be lost until PW surrender by the suspect and/or cracked by the examiner using WDE password attacks.

--BTW--I just noticed that my new blog-template uses gravitar images in the comments. yuck. That's not me, but a default image from the original template. I need to pull that off tonight as well. Sheesh....

Cheers!

--Claus V.

Erik said...

@Claus: True... Network traffic captures can sometimes be the only thing available. Especially for embedded systems. I mean, nowadays we can have rogue printers, routers, gaming consoles, NAS's, TV’s and toasters! These systems are usually very hard to do a forensic analysis of since memory and disk info is hard to get hold of. But network traffic can on the other hand be collected very easily.
The need to analyse networked embedded systems was actually one of the reasons for why I decided to start developing NetworkMiner in the first place.

Another cool thing about network forensics is that network sniffing can be made without the knowledge of the machine’s owner. This enables, for example, law enforcement to remotely capture network traffic of a suspect (after being granted proper wiretapping permissions of course) and analyse the captured traffic to decide whether or not they want to do a house search.

Claus said...

@ Erik -- NetworkMiner rocks the house! I've used it a few times to reassemble packet-capture data and it was incredible. Seems to run OK on most systems off a USB stick as well (big plus).

I've done a few posts here at my blog about it from time to time.

Not being a hard-core packet/network dude it was still very simple to use and attach to my capture data, then sort out the high-points for what I was interested in.

Awesome and valuable tool and I'm not just saying that.

That's really where my interest in the forensics/sysadmin stuff merges; there are techniques, skills, and tools (many free/Open Source) that are excellent crossovers in both disciplines. By learning about these, both groups can benefit and improve.

Cheers!

--Claus V.