Pages

Saturday, January 05, 2013

There Are Four Lights: USB-Accessible Storage

There's been a good deal of discussion and documentation regarding discovering USB devices that had been connected to a Windows system, as this seems to be very important to a number of examiners.  In 2005, Cory Altheide and I published some initial information, and over the years since then, that information has been expanded, simply because it continues to grow.  For example, Rob Lee has published valuable checklists via the SANS Forensics Blog, and Jacky Fox recently published her dissertation, which includes some interesting and valuable information regarding interpreting some of the information that is available regarding user access to USB devices via the Registry.  Ms. Fox determined that when a USB device is connected to a system and mounted as a volume, that volume GUID is added to the MountPoints2 key for all logged in users, not just the user logged in at the console.

Further, Mark Woan recently updated information collected by his USBDeviceForensics tool, to include querying some additional keys/values.

Regarding the additional keys/values that Mark's tool is querying, Windows 7 and 8 systems have additional values beneath the device keys in the System hive, specifically a "Property" key with a number of GUID subkeys.  This blog post provides some very good information that facilitates further searches, which leads use to information regarding a time stamp value that pertains to the InstallDate, as well as one that pertains to the FirstInstallDate.

So what?  Well, let's take a look at the MS definition for the FirstInstallDate:

Windows sets the value of DEVPKEY_Device_FirstInstallDate with the time stamp that specifies when the device instance was first installed in the system.

Pretty cool, eh?  This is what MS says about the InstallDate time stamp:

This time stamp value changes for each successive update of the device driver. For example, this time stamp reports the date and time when the device driver was last updated through Windows Update.

Ah, interesting. So it would appear that, based on the MS definitions for these values, we now have the information about when the device was first connected to the system available right there in the Registry.  I'm not saying that we don't have to go anywhere else...rather, I'm suggesting that we have corroborating data that we can use to provide an increased relative confidence (a phrase that you usually see in my posts regarding timelines) in the data that we're analyzing.

Something that hasn't been addressed is that most of the publicly-available processes that are currently being used are not as complete as they could be.  Wait...what?  Well, this is where specificity of language within the DFIR community comes into play...it turns out that the processes are actually really very good, as long as all we're interested in is specifically USB thumb drives or external drives.  However, there are devices that can be connected to Windows systems via USB and accessed as storage devices (digital cameras, iStuff, smartphone handsets), that do not necessarily become apparent to analysts using the commonly-accepted tools, processes and checklists.  We can find these devices by looking beneath other Registry keys, as well as in other locations beyond the Registry, and by correlating information between them.  This is particularly useful when counter-forensics techniques have been used (however unintentional...), as not everything may be completely gone, and we may be able to find some remnant (LNK file, shellbags, deleted Registry keys/values, Windows Event Log, etc.) that will point us to the use of such devices.

One of the pitfalls of interpretation of Registry data, as Ms. Fox pointed out in her dissertation, is that we often don't have current, up-to-date databases of all devices that could be connected to a Windows system, so we might see vendor ID (VID) and product ID (PID) values within key names beneath the Enum\USB key, but not know what they translate to...I've found Motorola devices, for instance, that required a good deal of searching in order to determine which smartphone handset was pointed to by the PID value.  As such, no process is going to be 100%, push-a-button complete, but the point is that we will know that the data is there, we know to get it, and we know how to use it.

Full analysis of USB-accessible storage media can be extremely important to a number of exams, such as illicit image and IP theft cases.  Many examiners used to think that sneaking a thumb drive into an infrastructure was a threat...and it still is; these devices get smaller and smaller every day, while their capacity increases.  But we need to start thinking about other USB-accessible storage, such as smartphones and iDevices, not because they're easily hidden, but because they're so ubiquitous that we tend to not focus on them...we take them for granted.

A Mapping Technique
The EMDMgmt subkey (within the Software Registry hive) names include the serial number for the mounted volume (VSN), which is also included in the MS-SHLLLINK structure, which itself is found in Windows shortcut/LNK files, as well as Windows 7 and 8 Jump Lists.  By correlating the VSNs from multiple sources, I was able to illustrate access to external storage devices in a manner that overcomes the shortcoming identified by Ms. Fox.  What I've done is used code to parse through the LNK structures (LNK files in the Recent folder, for example, and the LNK streams within the Jump Lists) to list the VSNs, looking for the one (or two, or however many...) that point to the device identified in the EMDMgmt subkey name.

9 comments:

  1. Where do you factor setupapi.dev.log in win 7 / setupapi.log xp/vista into your equations. From my experience it is a great listing of first plug in /driver install dates per device that starts when the OS is installed and is appended too instead of updated.

    ReplyDelete
  2. David,

    My view of the use of the setupapi.dev.log file hasn't changed at all. The purpose in mentioning the Registry values is to point out where some new information came from and how it applies.

    Thanks.

    ReplyDelete
  3. Harlan, thank you for the mapping technique and for the references, really valuable.

    The new data pointed out regarding USB devices remember me an old work (never completed) I made on "Properties" subkeys found under IDE, USBSTOR, STORAGE\Volume (etc.) keys. I should try to resurrect it =)

    ReplyDelete
  4. Captain Picard would be proud of your title to your post.

    ReplyDelete
  5. John Wulff9:53 AM

    The EMDMgmt subkey contains a wealth of information that I had been avoiding/missing in my attempts to garner all available information on a system, especially relating to USB drive activity. Thanks for bringing this to the forefront. It was very eye-opening to me.

    ReplyDelete
  6. John,

    I'm glad that you found this information useful. For this, as well as for other analysis methodologies, there is a lot of info that is available that can be used to really build a much more solid picture of what you're looking at...

    ReplyDelete
  7. Jimmy_Weg11:31 AM

    Ms. Fox determined that when a USB device is connected to a system and mounted as a volume, that volume GUID is added to the MountPoints2 key for all logged in users, not just the user logged in at the console.

    I haven't read Jacky's paper yet, but my sense is that the bold-face portion of the above quote is the pivotal part of her findings. I bring this up because I've seen multi-user systems in which the GUID appears for only one user. So, if I understand correctly, if I log on, switch users, and plug in a thumb, the GUID should appear under both user's MP2 with the same time stamp.

    Nevertheless, some study of user activity may allow you to infer who stuck the device in the machine. There are probably more anomalies with USB exams than any other, from what I've seen over the years.

    ReplyDelete
  8. Jimmy,

    ... the GUID should appear under both user's MP2...

    When you switched users, was the other one logged out?

    ...some study of user activity may allow you to infer who stuck the device in the machine.

    Oh, definitely. Maybe not infer so much as tie it down with a bit more certainty.


    There are probably more anomalies with USB exams than any other, from what I've seen over the years.

    I think that's largely for a couple of reasons...

    First, developing information about USB device analysis is a process in and of itself. When Cory Altheide and I did our initial research, there was no thought given to disconnecting and reconnecting a device multiple times during the same boot session. Then when Rob Lee provided updated information, it doesn't appear that anyone thought to have multiple users logged in at the same time.

    Second, USB device analysis is a process...and most analysts do not appear to want a process, they want a button. I spoke to someone at PFIC that asked me how they could locate the USB devices connected to a system, and I pointed them to Rob's resources, my book, etc. He asked the question again...it turns out, following a checklist isn't what he was looking for...he was looking for a button to push.

    ReplyDelete
  9. Jimmy_Weg10:01 PM

    When you switched users, was the other one logged out?

    As I mentioned, I didn't test this yet. I'm just guessing that this is the scenario in which Jacky's observation would hold true. I would think that both users must be logged on to the system.

    ReplyDelete