Another good Sunday Funday come and gone. I want to make these contests fun and accessible for you and for those vendors who have graciously provided prizes worth your time and effort! Have an idea of how to make Sunday Funday better? Comment here or email me firstname.lastname@example.org. Also remember that this Friday we will be doing another Forensic Lunch and we will be showing the first alpha of our Plist parsing tool. You can register for the Forensic Lunch here to be notified when it begins and any changes and ask questions! If you want to be on the video chat for Forensic Lunch and have something to talk about email me email@example.com!
Today we are going back to the understanding series before I get more side tracked and wanting to write another topic. We’ve covered 6 artifacts so far in stitching together what it takes to really show usage but we are not done yet! Now we need to talk about a registry key first introduced in Windows Vista called EMDMgmt. Harlan has talked about it here: http://windowsir.blogspot.com/2013/04/plugin-emdmgmt.html and earlier in his blog as well. EMDMgmt or External Memory Device Management is part of the ‘Readyboost’ service first provided in Vista. Whether Readyboost is enabled or not the EMDMgmt key will be populated with all available external storage devices where it could write Readyboost data. In order to make sure it can uniquely identify a volume it includes both the driver identification and volume serial number of the attached device.
This is important for us in our investigations because it is the only key outside of Mountpoints to be able to link which external device found in the system registry corresponds to which volume serial number/volume name stored in the LNK files/Jump lists. To quote the Microsoft technet article found here:
ReadyBoost consists of a service implemented in %SystemRoot%\System32\Emdmgmt.dll that runs in a Service Host process, and a volume filter driver, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd is short for External Memory Device, the working name for ReadyBoost during its development.) When you insert a flash device like a USB key into a system, the ReadyBoost service looks at the device to determine its performance characteristics and stores the results of its test in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, seen in Figure 1.
Now many times you will see USB mentioned here but its not just USB devices you will find in this key. I find eSATA, USB, Firewire, local disks, anything non system drive storage that is plugged in will be stored here with the driver identification, volume label and volume serial number. This can be very helpful when you are trying to understand why a device you know was accessed does not appear in the USBStor. There are times when either a) a device isn’t USB b) the driver loads a hybrid driver (cdrom/storage) and the drive will be appear as a local disk instead.
The one problem for analysts is that Readyboost is disabled by default on SSD drives on at least Windows 7 (part of the Windows 7 optimization for SSDs). This can lead to a lot of false positives of anti-forensics or spoliation from an inexperienced examiner. So you are back to timeline analysis to determine which drives were plugged in at what time if you have a SSD user.
Now if the system is Vista or 7 (Have not checked 8) and your suspect does not have a SATA drive this key is created by default. If it does not exist check to see if the readyboost service was disabled (some users complain about its performance) but that disable would have to have occurred before the first external storage device was plugged in. Otherwise you have a good indication of anti-forensics if this is missing.
EMDMgmt is something I’ve learned to rely on and tools like Woanware’s USBDeviceForensics and TZworks USBStor Storage Parser relies on to uniquely match drives. If you haven’t looked at it before I would encourage you to do so, it will make your life much easier!
Tomorrow we continue to wrap up the current understanding series!