I’ve been presenting today at the European Network Forensics and Security Conference in Holland. It is not a big event but there were some very interesting people in attendance including Laura Chappell from Wireshark University and James Lyle from NIST. I had not met either before but look forward to communicating more with them in the future.
I was presenting today on the subject of extracting just the information we perceive we need from a case rather an always imaging an entire drive, or more commonly now, a gaggle, bunch, collection (what is the term for multiple drives) of drives which regularly can exceed a TB. Now I know the purists amongst you will shout foul, the whole drive is best evidence and I do not disagree with you; but when dealing with, for example, a fraud case where the predominant evidence will be found in email, an accounting partition and chat logs, why ‘initially’ image vast amounts of data when we know where to start. It is very straight forward to image out just a .pst file or just take a partition and this can reduce processing and searching times tremendously. This does not mean that you never image the drive, however when we have multiple machines to look at why initially image them all when the pertinent data might be available in key containers.
A number of Police Forces in the UK and I’m led to believe ACPO too are looking at a methodology of pre-imaging triage to try and reduce workloads and backlogs and I am in general agreement with this.
There are a bunch of ways of extracting what you need. On a live machine you can simply write your own script to search a machine and extract just the files you need. For example, open notepad and just enter:-
xcopy "%systemdrive%\documents and settings\*.pst" /h /s
..save the text file as a batch file (myprog.bat) and put it on a USB key or external drive. When you plug the drive in to a machine and run the batch file it will search all folders under documents and settings and copy back any .pst file it finds. Easy as that! You could make a couple of subtle changes and it would find and copy back all the thumbs.db files which you could parse out in Encase, FTK, Vinetto and have a pretty good idea what images were on the machine. Quite handy.
xcopy "%systemdrive%\documents and settings\*bs.db" /h /s
If you want things to feel a bit more ‘forensic’ then use dd on the target system to extract what you need:-
You could use this method with Helix and use either the Windows terminal on a live machine or boot to the swanky new Ubuntu Linux side and do it there. You can then MD5 the file and off you go.
The argument is even more compelling with live servers in a corporate environment. Tell a sysadmin that you are going to shut down his email server for 8 hours while you image it and he will go a rather nasty colour. Do a live response and just take the pertinent .edb or whatever, files and everyone is happy and you likely have all you need. The same argument can be made when looking at a RAID array. The ‘Financial Director’ under investigation will rarely, if ever, have access to the RAID controller to hide any data anywhere clever on the array disks. So in that situation, do a live response on his machine and figure out what disk partitions/folders he has access to and just go and get those. Imaging the appropriate partition on a RAID will give you everything you need and saves a shed load of time trying to figure out the striping pattern.
I appreciate this blog entry is overly simplistic and all these decisions should be made on a case by case basis with full comprehension of what is potentially being missed, however the modern investigator should be aware of these techniques and use them where appropriate.