The Most/Recent Articles

Showing posts with label forensic tips. Show all posts
Showing posts with label forensic tips. Show all posts

Daily Blog #44: Forensic Tips - Shadow Access

Forensic Tips - Shadow Access

Hello Reader,
              I'm going to take a break today from the web 2.0 series for two reasons. 1. I'm not ready to write up the next post yet until I've reviewed the rest of the javascript that is parsing the message headers and contents we talked about last week. 2. A method I've been using for shadow access apparently isn't well understood and if it saved time in my lab it will save time in yours. Also as a reminder we are doing another Forensic Lunch this friday 8/9/13 where we talk about new updates in our research and answer forensic questions from you guys.

To get notified when the Youtube viewing link becomes available click here: https://plus.google.com/u/0/events/c9gklmj2cjhfdou01fjlhskcgkk

If you want to talk about your research on the Forensic Lunch give me an email and I'll invite you to the video chat room, dcowen@g-cpartners.com

Accessing shadow copies in Windows from SIFT:

Now if you have been following Joachim Metz's updates to libvshadow you would see there is now a native version for Windows. There are some steps you have to take to get this to compile that you can find here:
https://code.google.com/p/libvshadow/wiki/Building

You need to build it in Windows using cygwin or Visual Studio and get a third party package called dokan located here: http://dokan-dev.net/en/

Now this takes a bit of time and some experience with compiling code and if you go the Visual Studio route knowledge of Visual Studio, Joachim has given a great tutorial but I've still met people who have had issues with it. So if you want access to all the system files we talked about that are stored in the shadow volumes that aren't available to you using vssadmin/api routes, such as the $mft, $logfile, $usn journal and more, then I'll give you an easy work around.

Step 1. Download SIFT http://computer-forensics.sans.org/community/downloads
Step 2. If you don't already have vmware workstation/vmware player then download it from www.vmware.com
Step 3. If your image is a multipart e01, aff, etc.. then mount your image using ewmount/affmount first to make it appear as single raw image
Step 4. Use vshadowmount to mount the single raw image, whether whole or virtual and this is where the key step is. When you do this step pass in an extra option: -X allow_other as seen below:
vshadowmount -X allow_other  /mnt/
Step 5. Point FTK Imager to a image file located on \\siftworkstation\ and add each volume shadow you want to extract data from.

You can see Joachim's mounting instruction page here which references this fact:
https://code.google.com/p/libvshadow/wiki/Mounting

but what this not clearly spell out is that if you don't clear that option from fuse.conf you will not be able to allow non root users access to the mounted directory. Allowing non root users is necessary for how i'm using SIFT/libvshadow for is exposing the mounted shadows to Windows. Not allowing non root users affects your ability to let CIFS expose the mounted shadow copies to other networked machines. This network share access to mounted volume shadow copies in Linux what I do to speed things along on machines I don't have the native windows libvshadow compiled on, or where dokan fails to compile.

I mount with vshadhowmount -X allow_other and then I point FTK Imager to the \\siftworkstation network shares that it exports by default and access the shadow copies as raw images in FTK Imager to export out the system files not exposed with the native Linux NTFS driver.

Hopefully this is helpful and in the near future all our tools will adapt enough where we don't have to do this, but until then this works 100% of the time for me when all else fails.

Also Read: Daily Blog #43

Making Forensics Faster

Making Forensics Faster by David Cowen - Hacking Exposed Computer Forensics Blog


Hola Reader,
                     There are always bigger hard drives, at least for the near future, and more devices available to individuals every day. While the everyday work flow for an individual is drastically improved, hopefully, by obtaining this additional storage and processing power it only further compounds the amount of evidence a computer forensic examiner has to go through. 

It's not uncommon now for a single person to have over a terabyte of data between their laptop, desktop, mobile phone, tablet, hosted email, file sharing and backup services. The question then becomes how do we keep up with the larger volumes of data without allowing each individual to take a month to process.

There are several options out there, depending on your choice of tools (encase, SIFT, FTK, Prodiscover, SMART, etc...) to really speed up the processing of the evidence so you can get full text indexes built and artifacts parsed. In most cases the answer comes down to:


1. Faster CPUs to process the evidence
2. More RAM to process the evidence
3. Distributing the workload across multiple systems (if your software permits this)
4. Faster storage to hold the evidence

In my lab we've approached this from all of these points.

1. Faster CPUs to process the evidence
We have multi cored, multi processor CPUs on our systems. What we've found is that typically, unless we are password cracking, that the I/O from the disks can't keep up with resources available. Meaning our CPUs are never maxed out. So the CPUs are not the bottleneck for getting more speed.

2. More RAM to process the evidence
We have machines with up to 49GBs of ram, under large loads we sometimes see usage into the 30GBs but again because of I/O from the disks more than enough is available. So the RAM is not the bottleneck for getting more speed.

3. Distributing the workload across multiple systems (if your software permits this)
We've tried using FTK's feature that allows multiple systems to distribute processing across them. The problem comes in that the evidence is still being stored and accessed from system. Again the issue comes up the I/O from the disks can't keep up with amount of requests being made from the additional systems now requesting data to process over the network. So distributed processing alone did not speed up processing.

4. Faster storage to hold the evidence
Here we find the greatest benefit. Initially we bought large direct attached storage RAIDs to store and process our evidence. While these systems get us I/O speeds around 100-200MBs depending on the type of disks it still wasn't enough speed to max out the CPUs and RAM. So we started looking around at other options. When you start looking at larger/faster storage systems things can get very expensive, very quickly.

If we had a very large budget we could have gone for a RAMSAN, http://www.ramsan.com/, and gotten a couple terabytes of storage at 4GBs a second read and write speeds. That kind of I/O would clearly max out most systems attached to it and easily keep up with the demands of a distribute processing system.

Unfortunately we don't have that large of a budget for storage, especially not with the amount of data that we working with. A RAMSAN 810 according to this article, start at $45,000 as of 8/23/11. So we look at the midline prosumer range of solid state storage as they are faster than similar SAS 15k drives but priced around the same in the most cases for larger sizes. Most prosumer SSD disks can go up to 300-400MBs a seconds and are connected via SATA meaning you could easily turn them into a small RAID and load your images there. However again the cost of doing this can quickly scale up depending on the amount of storage you need to hold the evidence.

Instead we have been implementing is a middle of the road approach. Instead of loading the entire evidence set into faster storage we purchased a PCI-E based SSD card from amazon with read speeds of 1.5GBs and write speeds of 1.2GBs  it has a smaller amount of storage (we opted for 240gbs) but allows the most heavy part of the processing (dealing with all the data extracted from the forensic images) to be done on the fastest storage. To accomplish this in FTK we pointed the ADTemp directory to the PCI-E SSD card and our processing speeds improved dramatically. We were able to complete a full text index of a 149GB full forensic image in 1 hour. This test wasn't even optimal as the forensic image wasn't even copied onto faster RAID storage but instead was just attached via USB3.

We've since ordered PCI-E SSD cards for all of our evidence processing servers and will post most benchmarks as we move forward in our testing and processing. I would also like to expand our SSD storage to include the evidence storage media and database media but I'm doing this one step a time to find out what parts are getting me the largest increases in speed for the dollar.

Paul Henry (@phenrycissp on twitter) has already taken this a step further by putting all his pieces onto SSD SATA storage and integrating in the PCI-E SSD card for his temporary directory. His new issue is finding test images large enough to show meaningful results since its' processing so quickly So if you have a test image 100GBs or larger, please let him know!