@night 1803 access accessdata active directory admissibility ads aduc aim aix ajax 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 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 leanpub libtsk libvshadow linux linux-3g live systems lnk files log analysis log2timeline login logs london love notes lznt1 mac mac_apt macmini magnet magnet user summit 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 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 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 wmi write head xboot xfs xways yarp yogesh zimmerman zone.identifier

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

Post a Comment

  1. LNK files in the user's "recent" folder are created only when a file is opened, and not merely copied (on the same or on a different volume). So, if the files that have been copied out the system have not been opened (slightly before or after the copy operation), there will be no LNK files corresponding to these files.
    Furthermore, even in the case that these files have been opened, you must already have an idea of the time frame in which the copy operation took place or of the name of the copied files (in order to filter out those LNK files that have not been copied).

    So, unless under very specific circumstances (you already know the names of the copied files and the time frame in which the copy operation took place, the files have been opened), there is no general technique to tell if a file *with a given name* (nothing can be told on the actual content of the file from its name) has been copied out (and not simply opened).

  2. Agreed which is why I stated to look for lnk files pointing to the external drive itself. We are looking for indications of access to the data copied to the drive and later accessed.

    We cannot determine exactly what was copied entirely unless their tool left behind some kind of log or catalog.

  3. yes, we cannot, and even if the tool used to copy files generated a log, we can only tell if a file with a given name was copied out at a given time, but not *what* was actually stored in that file, unless we also have a copy of the file on the external storage.
    So, perhaps it wouldn't be a bad idea to state more explicitly in your orginal post that the circumstances under which we can determine which *data* (and not only which files) has been copied out are very special and, unfortunately, do not occur very often.
    I'm afraid that a beginner might misunderstand the contents of your post and overlook the issues we raised in these comments, and consequently assume that it is always possible to give an answer to the questions stated in the title of your post.
    By the way, I really enjoy reading your blog, and find it very informative and -- as in this case -- able to provide excellent food for thoughts.

  4. Good point, I'll update the blog to reflect this.

    Typically we infer what was copied based on the matching size, directory structure and file names contained on the original and external media but without access to the external media to verify it we are always making an educated guess.

    I guess that is what makes it computer forensic science, you have to pose your hypothesis and prove it. Even in the case of just proving what was copied to an external drive.

    Since we are discussing it. It's also important to note and probably update the post to reflect that in the courts you must be able to explain this to the extent that a judge will understand it and grant your request to inspect the external drive.

  5. I read your blog and have been reading along.I don't know what to say except that I have enjoyed reading. Nice blog.

  6. I also have been following your blog and I have found it to be invaluable.

    Thank you for the time you have spent (and hopefully will spend) putting this together.

  7. I have observed that even if the file is not opened but just trying to open it results in .lnk file getting created. For example if the viewer software is not installed on the computer and we try to open that file the lnk file gets created.

  8. I timeline documents, spreadsheets, etc and look for sequential date/time stamps within a coouple of seconds of one another. Large blocks of these indicate that some operation (like a copy or print) was carried out and usually helps you quantify or narrow your search down for logs, programs, etc. Typically i'll use the File Created or Last written date/time stamps as the others are too easliy modified by virus programs and other "standard" routine access.



Author Name

Contact Form


Email *

Message *

Powered by Blogger.