Sunday, May 27, 2012

New Project, Tool testing


One of the advantages of running a computer forensic company is that I get to buy lots of tools to use. When I was working for other companies I would have to wait for budget cycles and submit justification for tool purchases, but for the last 7 years I’ve been able to buy them as I needed them. In those 7 years we’ve accumulated a lot of tools that we use for different specializations and a body of knowledge related to them that I feel could be better utilized to share with all of you.



With that in mind I think it would be interesting to see how all these tools compare when working on the same forensic image. So with that in mind I’m going to start making some test images to see how data is interpreted from the same disk but in different image formats. I am going to start with the identification, not recovery, of deleted files and go from there.



My initial tool list to test includes:

Encase v. 7.04

FTK v. 4.01

Smart 3-26-12

X-ways forensics v. 16.5

SIFT v. 2.13



Any other tool you want us to test? Let me know in the comments below

I'll post my results as we finish a round of tests and as always a large case could easily distract me!

Wednesday, May 16, 2012

CEIC 2012 - Anti Anti Forensics

Hello possible CEIC attendee reader,
                                                            My class 'anti-anti forensics' will be tuesday at 2:00pm and is apperantly full from what I saw in the regestration page. For those of you who wanted to attend it but didn't get to sign up they normally allow people to queue up at the door to take vacant spots/empty space.

So why would you want to queue up? I'm happy you asked! In this class I plan to preview some research we've been doing on the NTFS $logfile. While I'm not ready to give a presentation dedicated to that, I've submitted to blackhat for that (please pick me blackhat reviewers), I will be showing what I consider to be amazing new tricks to defeat anti forensic tools using the NTFS $logfile.

As in prior presentations I will make my slides available on the blog afterwords for anyones review, but I don't feel that they really ever capture everything that I talk about. I'm much more of a talker than a slide writer so my slides typically just cover major topics and points rather than the details that I would hope you want to hear.

See you there!

Tuesday, May 8, 2012

New tools for shadow copes

Hello Readers,
                         I think a lot of us are still using the old tool Shadowcopy to explore shadowcopies from forensic images mounted. While we know how to mount volume shadow copies to mount points within our system, I personally always liked the interface shadowcopy provided me to jump between restore points and browser their contents. Since Shadowcopy hasn't been updated in over a year one I was happy to new someone else pick up the guantlet of a GUI based VSS explorer.

The entrant? Shadowkit which is currently available for free on the website www.shadowkit.com. I've tested the tool on my own systems it's quick and has some nice features that I've been wanting from Shadowexplorer such as:

1. File list exporting
2. Filtering shadow copies of your local system versus shadow copies from mounted images
3. drop downs for machine names as well as individual volumes backed up, preventing confusion with imported shadow copies
4. MAC and attributes displayed within the interface for each file
5. The ability to open files within the tool without having to export them, it places them in a temp directory for viewing
6. Extension filtering

In talking to the author he has more features planned with an eye towards the needs of the DFIR community so I'm expecting good things.

Monday, April 23, 2012

NCCDC 2012 Wrap up post

Hello Friends,
                        This post is here to give links to the two presentations I gave at NCCDC for those interested and contacts to red team members for those interested in known more about what happened to them.

Red Team Debrief PPT: https://skydrive.live.com/redir.aspx?cid=c252230f74663370&resid=C252230F74663370!848&parid=C252230F74663370!126&authkey=!AEdgB9WG-fF3pd0

Responding to the incident: https://skydrive.live.com/redir.aspx?cid=c252230f74663370&resid=C252230F74663370!849&parid=C252230F74663370!126&authkey=!ADnYRFJV9VCMK08

Red Teamers:
Mubix @mubix on twitter
Chris Nickers: @indi303 on twitter
Ryan Jones: @lizborden on twitter

i'll get more email addresses and twitter names and update this post as I hear back from them.

If you would like to watch the red team debrief, albeit with some bad audio, you can watch it here:
http://t.co/4umtDJnB

Monday, March 12, 2012

See you at CEIC

Hello Readers,
                        Looks like I'll be speaking at CEIC Tuesday afternoon 2:00pm on "Anti Anti Forensics". If you've enjoyed the blog/books/tweets I hope you'll come as we get into how I go about detecting and sometimes overcoming wiping/system cleaners in a hands on lab.

Tuesday, March 6, 2012

Making forensics faster

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!

Tuesday, February 28, 2012

The best feature you never knew existed

Bonjour Reader!,
I know I have large gaps in my blog posts, its not for a lack of ideas but it is for a lack of time. With the economic recovery in full swing in the legal world we are very busy.

However, I still need to finish my new book and start getting back to blogging more regularly so please feel free to harass me on twitter @hecfblog if I don't write a post once a week.

In this short post I am going to point out a feature in FTK that has existed since 3.3 atleast that I never knew existed. The feature is called 'export lnk contents' in ftk 3.3 and 'export LNK metdata' in ftk 4.0 and it may be the one feature that I wish existed in FTK for the last 8 years of using it. When I've mentioned what this feature is and what it does to fellow examiners each of them has said the same two things:

1. "Woh! This going to save me so much time!"
2. "Why didn't they tell everyone this was here?!"

So in relation to point number 2, let me do that for them.

HEY EVERYONE, FTK will now export out all of the metadata of a lnk file and the contents of the parsed lnks to a file (from atleast 3.2-4.0)!

It can do this with one, some or all LNK files just highlight them, right click a lnk and the context menu will show the option! Suddenly all the manual copy and pasting into a spreadsheet or running other tools (like tzworks lslnk) are no longer necessary. This is especially great when it comes to carved LNK files that may not actually be valid and break many third party tools when they try to parse them.

What all does it export you say?
Keep reading!

Surely there is no way they snuck in a feature everyone wanted and didn't tell anyone?
I sure didn't see it!

It must be missing something right?
Not that I can see! It exports out into a tab seperated file:
* Shortcut File - Name of the LNK file
* Local Path - The path to the file the LNK file is pointing to
* Volume Type - The type of volume (Fixed, Removable, CDROM) of the volume being accessed
* Volume Label - The volume label for the volume being accessed
* Volume Serial Number - The VSN of the volume being accessed
* Network Path - If this was done over the network, the full UNC path to the file
* Short Name - The 8.3 name of the file
* File Size - Size of the file in bytes
* Creation time (UTC) - When the file the LNK file is pointing to was created
* Last write time (UTC) - When the file the LNK file is pointing to was modified
* Last access time (UTC) - When the file the LNK file is pointing to was accessed
* Directory - If file the LNK file is ponting to is a directory
* Compressed - If file the LNK file is ponting to is compressed
* Encrypted - If file the LNK file is ponting to is encrypted
* Read-only - If file the LNK file is ponting to is marked read only
* Hidden - If file the LNK file is ponting to is marked hidden
* system - If file the LNK file is ponting to is marked as a system file
* Archive - If file the LNK file is ponting to is marked as to be archived
* Sparse - If file the LNK file is ponting to is 'sparse'
* Offline - If file the LNK file is ponting to is offline
* Temporary - If file the LNK file is ponting to is a ntfs temporary file
* Reparse point - If file the LNK file is ponting to is extended directory information
* Relative Path - The relative path to the LNK file
* Program arguments - Any arguements stored for the execution of the program
* Working directory - Where the executable will default for reads/writes without a path
* Icon - What icon is associated with the executable if any
* Comment - This is an outlook feature, not sure why its included
* NetBIOS name - The network names of the system the LNK file was accessing
* MAC address - The MAC of the system the LNK file was accessing

So the next time you are working a case in FTK and you want to know what was being accessed from external drives (and you are checking shell bags and other artifacts seperately of course) then make a filter for all file with the extension 'LNK' and right click on one and export all of them to TSV. Import that TSV into excel, sort by Local Path and your done! This may be one the biggest time savers I've found in FTK in years and I now use it on every case.

Have you found a feature you love that everyone seems to miss? Leave it in the comments below.