Hats Off Security

The USB forensics thread can continue until the end of time, or at least the end of my free space on here, with this in mind I am only showing you the basics of USB forensics. I may cover more depth in later posts, I may not. What I can tell you is if I do, I wont be using that bloody Seagate Hard Disk!!

For the final part of this puzzle we are going to visit a file not yet seen:

%WINDIR%\inf\setupapi.dev.log

This is very similar to the setupapi.log from Windows XP, except Microsoft moved it slightly further away. They have a habit of doing this I suspect its to charge more for consultancy or something.

Setupapi.dev.log can be viewed in a highly complex program known as Notepad, this program baffled many a developer by using a feature called “word wrap”. Seriously just turn it on and resize their window, then sit back and laugh!

As you can see highlighted above is the Device Serial Number all the way back from Part 1. This is the string you will need to search for to find the device. The area in the red square is showing the time the device was first connected.

WARNING!! The time shown above is in the System local time not UTC!!

I was going to put that warning in red, but after the word wrap incident I don’t think the dev’s could handle it.

And typically the Seagate Hard Disk decided, like a petulant child, not to bother showing up in the log. I tried a search on the Serial Number, GUID, PID and VID. Nothing!

Last time device was connected

We know the first time the device was connected, now we need to know the last.

A change from Windows XP worth pointing out, this next step used to be how you found out the first time a device was connected, now it’s for the last time (from Vista upwards), I am sure Microsoft had their reasons and I strongly suspect word wrap was involved somehow.

Go to the following Key (again):

SYSTEM\CurrentContolSet\Enum\USB\VID###&PID###

If you are using Registry viewer you will see the last write time of this key. This is the last time the device was connected. It is also possible to confirm the last time a specific user used the device by going to:

NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\<GUID>

These times are in UTC not system local time. Timestamps are annoying and this is one of those times! I would recommend recording everything in UTC and annotating which were displayed in local system time. This helps with your time line.

Having all this information is all well and good, but right now all we can say for sure is that a USB device was used on this machine. Just because someone logged on to that machine doesn’t make them the target of the investigation. As forensic investigators we need to ensure that all of the links in the chain are connected. We need to prove User X used USB Device Y in Machine Z (we also need to say when it happened, but that’s for part 7!)

What do we know so far?

• 2x Devices are relevant to this investigation
• A ‘generic’ USB device was attached
• named “FOR408-USB”
• with a serial Number of 92B0564

• A Seagate USB Hard Drive was also attached
• named “My Drive”
• with a serial number of 2GE4D91T

In order to find which user had these devices plugged in, we need the GUID. This can be found under the previously seen key:

SYSTEM\MountedDevices

From this previous screen capture we can see the Generic USB device highlighted. After \??\Volume you can see there is a string. This string is in fact the GUID of the device, make a note, you will need this later.

As you may recall, we could not find the key entry for the USB Hard Disk at this stage, the GUID for that device is actually remarkably hard to find (this could well be due to knowledge limitations, however I shall not be beaten). Should the investigation into the USB devices be stopped here? Nay! To the Nay sayers, I say Nay!

I will start off with the easy win. The USB Flash drive known as FOR408-USB. The GUID for this device is:

C0B07669-E061-11EF-825F-000C291334BA

Now we move onto the NTUser.dat, if you have lots and lots of users…. you have my sympathy, just kidding, try Grep see if that works, if not…. read previous statement.

I however have a strong suspicion that this one user (me) is the target of this investigation, how do I know? Simple. I told me.

So I open the NTUser.dat file and browse to the following key

NTUser.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\Mountpoints2

As you can see the GUID matches, proving this device was used by this user!

What about the other device?

So this annoyed me a little, I know the other device was used by this user, so I wanted to be able to prove it. I manually looked through the other GUIDs in the list to see if there were any tells. Luckily for me, there was!

It turns out my USB Hard Disk has vanity issues and likes to carry around it’s own icon! This is far from forensically sound, but it does make me think this is the same device. I test the theory by plugging the device in to see if this file (e:\FreeAgentGoNext.ico) exists:

And it does! So I figured that the GUID shown has a good chance of being the USB Hard Disk:

C0B076C9-E061-11E3-825F-000C291334BA

I did a search in the SYSTEM hive for this string and found it in the Mounted Devices section

Still not 100% proof, but certainly proves that a device with the same GUID, as a device which holds an icon file, with an identical name to the Seagate drive, was plugged into that machine.

It may be a coincidence but the Hex value for this GUID is also the same Hex value for the E: drive letter in the Mounted Devices key (0073B5A4007E000000000000) possibly showing that the USB Hard Disk was the last device to be associated with the drive letter E:

Adding to that the NTUser.dat reference to E:\FreeAgentGoNext.ico certainly reinforces that theory.

Final thoughts

I will admit there was a fair amount of luck involved with finding the GUID for the “My Drive” device, and it’s not 100% proof. But I believe that if you can convince a non-biased technical person that this device was plugged into that machine using only the evidence above, then you have a good enough case to attempt to convince a jury. As previously stated, make a note and move on.

Finding the last Drive letter used by the USB device is actually quite simple…. or at least it should be! Go to the following Key:

SYSTEM\MountedDevices

Each drive letter is listed, however in my example on the VM the E: drive has no usable data in it (correction at the bottom of the page). The Seagate drive is not identifiable in the list, neither the volume name or serial number are in the descriptions, I am assuming this is because of the previous issues with it being an actual Hard Disk and not flash memory.

The Generic USB device *is* in the list with the serial number

But as you can see from the details of the data, there is no mention of a drive letter.

In an ideal world highlighting the last drive letter (seen above under as \DosDevices\E:) would have, in its description, the serial number of the last attached device. I believe it is not there because the Seagate hard drive was the last device to use the E: drive, which as we saw in a previous post was quite stubborn about sharing its serial number.

Conclusion. Fail?

You may be wondering why this is lack of data may be important, after all its just a fail right? Wrong. By including this in your report you are showing that you have covered the bases, there is an explanation as to why the drive letter is not showing the data you expected. If this is missed out of a report which ends up in court the defence lawyer will use it to show that you are omitting data which may “prove” his client innocent. Obviously this is not the case, but you do not want the guilty to be let off because of a lack of confidence from the jury in your technical integrity.

Obviously that’s a worse case scenario, but even if you wind it down a little; I write every technical report as if another person with a higher level of experience than myself will criticise it. That way you find yourself justifying the parts of the report that don’t work.

Does this lack of data prove anything?

Yes. This proves that both devices were not present at the same time, if they were there would be another drive letter present. After all

• A: – Reserved for floppy drives (still!!)
• C: – Main system drive by default
• D: – CD-ROM by default
• E: – Next available drive letter

of course check to make sure the other drives are being used at their default settings! You may look silly if there is no CD-ROM and your report assumed there was.

To prove it does work

Just to show you what you would expect to see, I had a look at my Windows 7 host live registry and found the USB device was last plugged in as the H: drive on my machine.

E: drive has no usable data in it

***Late Addition***

Disk Signature

I would like to make a correction to the first paragraph of this post, I stated that “E: drive has no usable data in it” after continuing research I have discovered that is not accurate. The data held under E: does have useful information in it! From the screen capture above we can see the Hex value “00 73 B5 A4” this is the “Disk Signature” of the drive used. Using a Hex editor like HxD it is possible to open the physical disk and find this string under 0x000001B8-0X000001BB – this is where I have found it in relation to “00 55” marking the end of the MBR sitting at 0x000001FE-0x000001FF on the devices I had available to me.

This ID assigned to the Master Boot Record (MBR) so is not  permanent, but if the disk has not been formatted or you can recover the data around the MBR, it may help to prove this device was connected.

On to Part 4 of our ongoing discoveries about USB forensics.

A quick recap

So far we have managed to get details of two devices which have been connected to our image. We have looked at how to get:

• Unique Serial Number
• Vendor, Make & Model
• Product ID & Vendor ID
• Volume Name

We are now going to move on to the Volume Serial Number, this is created by Windows Vista and up Operating Systems each time the device is formatted. We will be looking in the EMDMgmt key for the Volume Serial Number, which according to this Technet blog around Windows Vista, is where the Operating system store details regarding “Ready Boost”; the idea behind Ready Boost was to use external USB devices as additional memory to increase performance. It never really took off. In my opinion this is a good thing from a forensics stand point, would we really want to be chasing down another USB device that has memory artefacts on it? I personally would rather have as much evidence in one place as possible. Especially when it comes to large scale jobs.

USB Hard Drive vs. USB Stick

As I mentioned in Part 3, one of the devices we are looking at is a cylindrical hard drive, it will be interesting to see if the Volume Serial Number exists in this key, as obviously it wont be fast enough to pass the benchmark…… let’s go find out.

Navigate to the following key:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

And you will see the following

As you can see “My Drive” which we identified as the Hard Drive is listed, and above that we see “FOR408-USB”, so the answer is yes, it will be listed here!

I have highlighted here the string at the end of the Key name, this is a Decimal value of the Volume Serial Number, which is a Hexadecimal value (isn’t the registry fun…..). Convert this value, using Windows Calculator is probably easiest,  into the Hex and you have your Volume Serial Number.

The Volume Serial Number of this device is “40034B65”. To confirm that this is correct there is another tool we can use, which is a command line tool called “Vol.exe”, this requires you to have the device connected, so use appropriate protection and document when and why you did it. The output of Vol.exe is shown below:

As you can see, the Volume Serial Number matches what we worked out manually above. Therefore showing that this device was installed on this machine and has not been formatted since (this is an important footnote, the Volume Serial Number can change for the device if it is formatted, as the Volume Serial Number is allocated after the Format!).

Make a note of the Volume Serial Number and the Volume Name for use in analysing the Link (.lnk) files, which I will cover later, as they can correlate this device to those Link files.

***Late Addition***

An important side note: As I have done more investigations I realised that this key will not be populated if the machine is deemed “too fast” for Ready Boost. This also changes depending on the OS

• Windows 7 – If an SSD is present Ready Boost is defaulted to off
• Windows 8 – If an SSD is present the system will test to see if Ready Boost is required

The reasoning behind turning off Ready Boost as far as I can tell is to do with write times to an SSD. As we all know SSDs are not as write tolerant as the older cylindrical disks therefore automatic defrag is disabled as is pre-fetch (which is another pain in the backside from a forensics standpoint!).

Knowing more about Ready Boost means that it should hopefully help to understand why a drive may not appear as expected in the EMDMgmt key; Windows wouldn’t attempt to make a cylindrical disk a Ready Boost device as there would be no increase in performance associated with it.