August 2009

@night 1803 access accessdata active directory admissibility ads aduc aim aix ajax alex levinson alissa torres amcache analysis anjp anssi answer key antiforensics apfs appcompat appcompatflags applocker april fools argparse arman gungor arsenal artifact extractor attachments attacker tools austin automating automation awards aws azure azuread back to basics backstage bam base16 best finds beta bias bitcoin bitlocker blackbag blackberry enterprise server blackhat blacklight blade blanche lagny book book review brute force bsides bulk extractor c2 carved carving case ccdc cd burning ceic cfp challenge champlain chat logs Christmas Christmas eve chrome cit client info cloud forensics command line computer forensics computername conference schedule consulting contest cool tools. tips copy and paste coreanalytics cortana court approved credentials cryptocurrency ctf cti summit cut and paste cyberbox Daily Blog dbir deep freeze defcon defender ata deviceclasses dfa dfir dfir automation dfir exposed dfir in 120 seconds dfir indepth dfir review dfir summit dfir wizard dfrws dfvfs dingo stole my baby directories directory dirty file system disablelastaccess discount download dropbox dvd burning e01 elastic search elcomsoft elevated email recovery email searching emdmgmt Encyclopedia Forensica enfuse eric huber es eshandler esxi evalexperience event log event logs evidence execution exfat ext3 ext4 extended mapi external drives f-response factory access mode false positive fat fde firefox for408 for498 for500 for526 for668 forenisc toolkit forensic 4cast forensic lunch forensic soundness forensic tips fraud free fsutil ftk ftk 2 full disk encryption future gcfe gcp github go bag golden ticket google gsuite guardduty gui hackthebox hal pomeranz hashlib hfs honeypot honeypots how does it work how i use it how to howto IE10 imaging incident response indepth information theft infosec pro guide intern internetusername Interview ios ip theft iphone ir itunes encrypted backups jailbreak jeddah jessica hyde joe sylve journals json jump lists kali kape kevin stokes kibana knowledgec korman labs lance mueller last access last logon lateral movement leanpub libtsk libvshadow linux linux forensics linux-3g live systems lnk files log analysis log2timeline login logs london love notes lznt1 mac mac_apt macmini magnet magnet user summit magnet virtual summit mari degrazia mathias fuchs md viewer memorial day memory forensics metaspike mft mftecmd mhn microsoft milestones mimikatz missing features mlocate mobile devices mojave mount mtp multiboot usb mus mus 2019 mus2019 nccdc netanalysis netbios netflow new book new years eve new years resolutions nominations nosql notifications ntfs ntfsdisablelastaccessupdate nuc nw3c objectid offensive forensics office office 2016 office 365 oleg skilkin osx outlook outlook web access owa packetsled paladin pancake viewer path specification pdf perl persistence pfic plists posix powerforensics powerpoint powershell prefetch psexec py2exe pyewf pyinstaller python pytsk rallysecurity raw images rdp re-c re-creation testing reader project recipes recon recursive hashing recycle bin redteam regipy registry registry explorer registry recon regripper remote research reverse engineering rhel rootless runas sample images san diego SANS sans dfir summit sarah edwards saturday Saturday reading sbe sccm scrap files search server 2008 server 2008 r2 server 2012 server 2019 setmace setupapi sha1 shadowkit shadows shell items shellbags shimcache silv3rhorn skull canyon skype slow down smb solution solution saturday sop speed sponsors sqlite srum ssd stage 1 stories storport sunday funday swgde syscache system t2 takeout telemetry temporary files test kitchen thanksgiving threat intel timeline times timestamps timestomp timezone tool tool testing training transaction logs triage triforce truecrypt tsk tun naung tutorial typed paths typedpaths uac unc understanding unicorn unified logs unread updates usb usb detective usbstor user assist userassist usnjrnl validation vhd video video blog videopost vlive vmug vmware volatility vote vss web2.0 webcast webinar webmail weekend reading what are you missing what did they take what don't we know What I wish I knew whitfield windows windows 10 windows 2008 windows 7 windows forensics windows server winfe winfe lite winscp wmi write head xboot xfs xways yarp yogesh zimmerman zone.identifier

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.

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.

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 and 4-5 in the next. 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:


    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:


    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:


    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 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.

Author Name

Contact Form


Email *

Message *

Powered by Blogger.