I love FTK 2.2.1

I am going to interrupt the series to just write a small love note to accessdata.

Dear FTK,

I know we've had some tough times together in the past. Me cussing at a crashed indexed, you not responding to my mouse clicks. There were times I thought we wouldn't last and that I would find someone else who would fulfill my needs. Then I saw the new you (FTK 2.2.1) and when I actually exported the emails from a indexed search into a recreated recursive directory path from the PST folder structure that it came from I held my breath. When I then saw that actual MSG files were contained in the right folders my heart skipped a beat. Then when I saw that the attachment was actually in place in the MSG ... I knew everything would work out.

Love,
G-C Partners, LLC

Seriously though, for those who didn't immediately get this joke alot of the forensic tools available to the market for the last 10 years have had some real gaps of functionality that made our lives torture. 

One of these most basic features missing was the ability to export an email found when reviewing an image in a forensic tool back to a msg or pst instead of just a text export or html export that wasn't even compliant to the rfc specifications needed for most tools to convert it. If we didn't have it in msg or pst most lawfirms and ediscovery firms could not process it.

FTK 2.2.1 has fixed that issue and for this my office will gain many, many hours of producivity back instead of running my very long process to reassemble the data from other tool outputs.

Back to the series in the next post, thanks for reading.

Also Read: What did they take when they left? Part 4 (External Devices) - Where did it go and what did they take?

Read More

What did they take when they left? Part 4 (External Devices) - Where did it go and what did they take?

Howdy Reader,

It's been quite some time since my last blog post, I apologize. Things have been pretty busy, apparently the recession/depression has really spurred civil crimes and I had a very nice vacation. 

In our last time together we discussed more detectable methods of how suspects remove data from their systems. I've left off the most common and lengthy portion of the post so I could give it the detail and supporting documentation it deserves. 

In this post we will finish the concept exploring method 3 in this post. This series does focus on Microsoft windows systems as they are the most popular business system in use, I will write another linux or mac specific series at another time.

Method 3 – Copying data to an external drive

1. How did they take data from the system
   

   
   

   The first step you should take in a windows system is examining the contents of the registry keys that track storage devices plugged into the system. Inside these registry keys located under the system registry file under the system control sets are at least three keys keeping track of three types of external storage devices:
   

   
   

   1. USB Devices
      

   USB storage devices have their information store under the USBSTOR key found under:
   

   system\currentcontrolset\enum\usbstor
   

   
   

   1. Firewire Devices
      

      
      

   Firewire devices that are also storage devices can be found in the system registry under the system control set as well at:
   

   
   

   System\currentcontrolset\enum\sbp2
   

   
   

   1. eSATA Devices
      

      
      

   eSATA devices that are plugged into the system can be found in the system registry under the system control as well at:
   

   
   

   system\currentcontrolset\enum\ide
   

   
   

   It's important to know that the type of eSATA enclosure (for instance I was testing with a Simpletech Prodive) will not appear in the IDE registry key. The type and serial number of the drive will appear in the registry but you will have no way to identify what enclosure the drive was in from the registry. Of course you can compare the drives in enclosure to find the right drive but if drafting a subpoena you will not be able to specify what enclosure the drive is in.
   

   
   

   1. Responsive to all types of devices:
      

   
   

   There are additional versions under the system key some of which are duplicates of currentcontrolset so make sure to check each one. Each controlset that is numbered such as controlset001 is a configuration state of the system that booted successfully at one time. The currentcontrolset points to the numbered controlset that was last booted from successfully.
   

   
   

   An easy way to parse out these registry entries is with RegRipper which creates a nice text file with all the most useful parts of the registry for the forensic examiner but in its latest version does not include the sbp2 key but I'm sure it will be added soon.
   

   
   

   There is one registry entry under these keys for each storage device that has been attached to the computer since it was first installed if these keys do not exist or are empty then someone has run a system cleaner as the key will only get created on the first attachment of a storage device except for IDE which will exist if their is an IDE drive in the system. Remember these entries are in the system registry so it applies to every user who has used the system. This means that if you have a multi user system you still will have to verify who plugged it in during the times and dates we find. These entries will contain digital cameras, thumb drives, external hard drives, ipods, cell phones, anything that provides some type of storage and will be accessed as a drive letter. Each entry will contain the parent id, the vendor id and what is marked as the serial number of the device. The serial number reported to windows is not always the serial number printed on the physical device and this varies by manufacturer so when requesting these devices in a subpoena or other form make sure to specify it 'as reported to Microsoft Windows'.
   

   
   

   The last written date of the registry key for each device entry tells you the last time the device was plugged into the system. We can determine the first time the device was plugged into the system by searching for the device name we found in the USBSTOR/SBP2/IDE keys and searching for it in the setupapi.log file found in the 'windows' directory in windows xp and in the setupapi.dev.log located under 'windows\inf' in Vista.
   

   
   

   To find out each additional time the device was plugged into the system we can look at the backed up copies of the system registry located in the restore points. For Windows XP this is located under the 'system volume information folder\rp'. There is a new version of regripper for restore point registry examination called ripxp that will run the ripper not only against the current registry file but also all the previous copies of it in the restore points.
   

   
   

   Windows Vista restore points are renamed to "system restore" points and utilize the shadow copy service to make a separate volume where previous versions of files and system files are kept depending on the configuration and version of windows vista. You can use programs such as Shadow Explorer to access these volumes on a live system (or an image running in a vm) where you can browse the point in time back up of each partition on the system for the same registries. I have not found a forensic tool to date that can mount these shadow volumes in the way that shadow explorer can.
   

   
   

2. What did they take
   

   
   

   If our suspect did not wipe the system clean of the information we now know all of the external devices they could have copied information to. Determining the extent of what they have copied on to these devices is not as well recorded by the system. There are several ways that a suspect may attempt to copy data to the external drive.
   

   
   

   1. Backup programs
      

      There are a variety of backup programs a suspect can use. Some of them will come bundled with the external media and others are built into the operating system. We can determine what backup program the suspect ran from the techniques discussed in part 2. Once you've identified the software used a quick google should reveal what if any logging the software left behind. For instance in Carreker Corporation v. Cannon et al (4:06-cv-00175-RAS-DDB) we found the use of Dantz Retrospect which creates a log file for each of the backups performed logging the configuration, directories backed up, files backed up and total data copied for each backup done with the software.
      

      
      

   2. Copy programs
      

      Some suspects will choose to use utilities such as robocopy or xxcopy to copy the data to external media. In those cases the techniques discussed in part 2 will help you identify what program they used and when they copied the data.
      

      
      

   3. Standard copy and paste
      

      If our suspect copied the data to some external media with just a copy and paste or drag and drop there will be no record that I have found to date to reflect it.
      

      The next thing we have to determine is what they copied on to the external drive. There are two reliable methods generated by Windows automatically that can tell us what files and/or directories they accessed from the external media.
      

      
      

      1. LNK Files
         

      Windows shortcut or 'LNK' (pronounced link) files have been a standard feature of windows since windows 95. LNK files as most forensic examiners refer to them are created for a variety of reasons. What is most important to us for this method is that for files and directories opened in windows explorer a LNK file will be created in the users recent directory ('\documents and settings\user name\recent' in windows xp, '\users\user name\recent' in windows vista) and if a program such as Microsoft office is associated with the file then a second lnk file will be located in the program's own recent directory located in the application data directory. The LNK file in its normal usage allows a user to quickly access the file that it points to. We can examine the LNK files and see which of them show that the file or directory it points to existed on an external disk. For more information on LNK files read this or this. For a free utility that will parse these files and other try Windows File Analyzer (most forensic tools have this capability already either built in or through some provided script).
      

      
      

      The LNK file tells us many important facts about a file that it points to.
      

      1. The time the file was first accessed on this computer
         

         The created date of the LNK file will tell you the first time the file was accessed through windows explorer, this captures the first access to the file. If the modification date varies from the creation date then you have the last time the file was opened as well.
         

      2. The time the file was first created on the media it resides on
         

         The LNK file captures the creation, modification, access dates as well as the size of the file that it points to within the LNK file structure. This allows us to know the creation time of the file which reflects the first time the file was copied onto the media. We can then determine when the data our suspect has taken was first copied on to the media. We will only know this if the suspect accesses the files or directories after copying them to the disk.
         

      3. The name, type and volume serial number of the media the file resided on.
         

         Using this we can determine which files accessed came from external media and match it up to those devices we identified in this section.
         

         
         

      1. MRU
         

         Most Recently Used entries in the registry exist for multiple types of applications and windows components. They keep track of the last files opened by the user for that application but they only track the file opened and the date on which the file was opened. The only way to determine if the path where the file was opened was on external media is to check if the drive letter shown was not local to the system. You can easily pull out most MRUs with regripper.
         

At this point we can now determine what external devices were in use and what files we can determine were placed there. The last two methods to discuss are copying data to network locations and uploading data to file hosting websites.

Also Read - Links to All parts: 

What did they take when they left? Part 4 (External Devices) - Where did it go and what did they take?

What did they take when they left? Part 3 - Where did it go and what did they take?

What did they take when they left? Part 2 – Finding out what they ran before they left

What did they take when they left? Part 1 - Detecting CD Burning

Read More