Thank you to Daniel Dickerman and Chad Tilbury for initially sending me down this rabbit hole!
Evidence surrounding the use of USB devices is an often sought-after forensic treasure trove, due to its verbosity in the operating system, as well as the Windows Registry. The difficulty comes in attempting to make sense of all this data. When the many, disparate breadcrumbs of usage are pulled together in a coherent assemblage of user activity, the results can be shocking in their clarity.
Remember that usually, USB investigation is happening in the complete absence of any of the USB devices being investigated. The notion that we can determine what USB devices have ever been attached to a system even though the devices are no longer present, is astonishing to the uninitiated.
Unfortunately, this evidence often can only withstand scrutiny in the absence of the USB devices being reported. An odd statement indeed. The issue has to do with incorrect, inconsistent, and poorly documented nomenclature
For anyone who has been doing forensics for any period of time, you will be familiar with the location of USB device artifacts in the registry. We have often started in the USBSTOR key, and then drilled down to identify the USB device. After identifying the device Vendor and Product, we proceed to the subkey of that key, and we see the values as shown in the diagram below.
It has long been held (and reported) that this value is the serial number of the device. Unfortunately, as with many things in forensics, the devil is in the details. As it turns out, Microsoft themselves report that this is variously an “iSerialNumber”, or a “Product ID”. Oddly enough, in the places where they call this the Product ID, they identify a different value as the Serial Number. As you can see, this can become confusing!
In the diagram below, a command in Powershell lists some values regarding the above two USB devices. Clearly, what we have been calling the serial number does not conflate with what the identification in Powershell calls a serial number.
As if that wasn’t confusing enough, according to Microsoft, https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/usbspec/ns-usbspec-_usb_device_descriptor, the string listed above under pnpdeviceid is also identified as an “iSerialNumber”, and defined as, “... a device-defined index of the string descriptor that provides a string that contains a manufacturer-determined serial number for the device.” You will see in the following research that they are NOT reporting the “manufacturer-determined serial number”.
I have also now seen the value from above under serial number referred to as a “SCSI serial number”. The problem with this is that the value is not coming from under the SCSI key in the registry (although it could).
As an aside, it might come as a surprise to many forensicators that the USBSTOR key does NOT contain all USB devices that have been attached. Run your eyes up the registry path and you will see a key named SCSI.
This key also contains USB connected device information. WHAT??? The difference has to do with how the device identifies to the computer. But that is a conversation for another day.
It turns out that the number being referred to as the serial number is very much an arbitrary value, and I don’t just mean “serial numbers” with an ampersand (&) as the second character. We were told that this meant the value was generated by the computer at the time of insertion, and not from the factory when the USB device was built. It turns out this is not exactly correct. If you are confused, you are not alone. Oh, and it gets worse! It seems that the serial numbers reported above (no matter which ones you pick), are often not even the actual device serial number!
To demonstrate this, I conducted a number of tests against 3 different USB devices. The first device I tested was a bare 2.5” Seagate drive. The model number is ST2000LM007, and the serial number is WCC1YLWG, as seen below taken directly from the label on the hard drive.
If you are like me, you would expect that if this was plugged into a computer via USB, it is this serial number that would appear. I connected the drive to a computer directly via the SATA channel on the motherboard. I then used a program called GSmartControl to report the serial number. Interestingly, the GSmartControl menu listed the device as seen below, and identified it correctly, as did the computer’s Device Manager.
 |  |
The program then listed properties of the drive. Below, we see the expected serial number.
I then disconnected the hard drive and connected it to a T-300D Super Speed Toaster (Disk Dock) as shown below. This Disk Dock connects to the computer via USB 3.0.
Now I don’t know about you, but I would have expected a device such as this to simply be a pass-through device. An adapter of sorts. As it turns out, that is not true. As in the previous example, I used GSmartControl to look at the properties of the hard drive. It now listed the drive as seen below, as well as in Device Manager. Clearly not the same.
 |  |
What became even more concerning, was the change in serial number, as seen from the properties of GSmartControl below. As if that is not odd enough, it can also be seen that the drive is now being reported as a 3.5” device, and it is most certainly not.
Of course, this drags me further down the rabbit hole. Is the drive dock NOT simply a pass-through device?
One of the benefits of a digital forensics lab and a pack rat mentality, is that I have a wide variety of computers, operating systems, and software to mix, match, and test with. So the next thing I did was remove the original hard drive and insert a different one. In fact, an entirely different make and model. It still identified with the same serial number as the previous drive. Are we starting to see potential investigative issues? So far in my journey, I have determined that I could plug multiple different devices into my computer (via the dock), and they would all have the same “serial number”. Let’s call this Computer 1.
I tried the setup on a different computer we will call Computer 2. As if by magic, GSmartControl now showed me all of the correct information including serial number. Well now I have even bigger problems. Why would it work properly on Computer 2 but not Computer 1? What does the computer have to do with it?
Now the troubleshooting started, because I MUST figure out this anomaly. I remembered that the night before, Computer 2 (that showed the correct results) had updated Windows to 21H2. I then checked Computer 1, and its OS versions was 21H1. Surely it couldn’t be an OS issue. I tried a third machine (Computer 3) with OS version 20H2. Again, I got the incorrect results. I then updated Computer 1 and 3 to 21H2. Before you ask, no I had no concrete reason to believe that the OS was the issue, but it was the first place I started to look. After the updates, the two machines still reported the incorrect information.
The only other software in play was GSmartControl. I knew from my recent updating of the FOR498 courseware that there was no new update to GSmartControl, but after thinking about it, I realized that to test on Computer 2, I had downloaded GSmartControl from its website that day. The other machines already had GSmartControl on them. Although I had checked about 2 weeks before, I checked the GSmartControl version, and sure enough, the version I downloaded to Computer 2 was v1.1.4. It had just been updated in recent days. The version on Computer 1 and 3 was v1.1.3. Aha! I updated the versions on Computer 1 and 3, and they were now reporting the correct information.
Problem solved. Or so I thought. Even though all three computers now showed correct information in GSmartControl, Windows (via Powershell) still reported incorrect information. In fact, the same incorrect information that the older version of GSmartControl had shown. The Powershell output is below. Note the “serial number” matches the incorrect “serial number” reported by v1.1.3 GSmartControl.
We now have Windows and GSmartControl disagreeing on a key piece of information, and we can conclusively state that GSmartControl is correct and Windows is wrong, based on comparison to the actual label of the hard drive. It’s almost like the older version of GSmartControl asked Windows what it thought about the drive, and the newer version decided to think on its own. Fortunately, we see from the SCSI key shown below, that the “serial number” or device ID of 6&1dad96a8&0&000000 seems to be consistent between at least Windows and its Registry, as seen above and below.
That consistency (as expected) was not maintained between different machines. So what is a forensicator supposed to do about this? Oh but wait. It gets worse.
I decided to test another connection method. Connecting the test Seagate drive to the computer via a USB adapter. Namely the Apricorn SATAWire SATA to USB adapter for bare drives, as seen below.
I own quite a few of these, so I randomly selected 3 of them, and they will hereinafter be referred to as Apricorn 1, Apricorn 2, and Apricorn 3. Wow. What an eye opener. Details had no consistency at all. Below is the Seagate drive attached to the computer with 3 different Apricorn devices.
Apricorn 1
Apricorn 2
Apricorn 3
None of the three agreed with each other, and only Apricorn 2 showed the correct serial number. Wouldn’t we have thought that again, these are simply pass-through devices?
This all led me to wonder what happens with portable USB hard drives, so I performed testing on two different models. The first was a 2 TB Samsung T5 SSD as shown below.
The serial number on the casing of the drive was S4B4NV0KA00344J.
I connected the drive to the computer via the USB cable supplied by the manufacturer. I then used the vendor specific Samsung software to report the drive. It agreed with the label on the drive, as shown below.
GSmartControl v1.1.3 did not agree, but GSmartControl v1.1.4 did, as shown below.
The serial number on the casing of the drive was S4B4NV0KA00344J.
I connected the drive to the computer via the USB cable supplied by the manufacturer. I then used the vendor specific Samsung software to report the drive. It agreed with the label on the drive, as shown below.
GSmartControl v1.1.3 did not agree, but GSmartControl v1.1.4 did, as shown below.
GSmartControl v1.1.3 did not agree, but GSmartControl v1.1.4 did, as shown below.
 v1.1.3 |  v1.1.4 |
Sadly, Windows agreed with v1.1.3, which was the wrong Serial Number. In fact, there was no indication or marking anywhere on or inside the drive that would support any of the numbers reported by Windows or v1.1.3.
Just to be sure that the Samsung T5 (a specialty drive for sure) wasn’t a unique occurrence, I performed the same testing on a Seagate 4 TB USB HDD. The data on the label is shown below, with a Serial Number of NA84FYGR.
Windows agrees with this Serial Number.
It is worth noting though, that what we have been told is the serial number, is actually not. The Windows registry reports as a non-unique serial number.
Let’s now take a look at what is actually inside the plastic enclosure. The actual hard drive inside the enclosure is shown below, with the indicated serial number.
GSmartControl (both versions) reports the actual drive correctly.
We are now being told that the actual serial number is the “SCSI Serial Number”, reported in the Microsoft-Windows-Partition/Diagnostic.evtx.
Clearly it is seen that the Serial Number being reported is for the enclosure and not for the actual hard drive. Now I don’t know about you, but if I am investigating hard drives, I want the details of the hard drive, and not the plastic container.
What we have then discovered, is that in most cases, external portable devices are not properly reported in Windows, at least insofar as what regards a Serial Number. This becomes incredibly problematic when your forensic reports says that the device serial number is “ABCD”, and an opposing expert says it is “EFGH”. Who is right? It is tough to convince a court that your tool is right and the label from the manufacturer is wrong. Are you examining a plastic container? Or are you examining a hard drive? What you do matters. Lives are affected by the work of digital forensics practitioners.
The most important takeaways here are twofold. First, even though Windows does a deplorable job of reporting a serial number, and can’t even agree with itself what a serial number is, my testing has shown that whatever the value is, it is consistent throughout that instance of the device on the system. Second, stop calling any of these values serial numbers. A serial number is a unique value assigned by the builder of a product. It is not what some piece of software arbitrarily decides to assign to it. That becomes a tracking ID, or Windows Assigned Device ID. Maybe we should start referring to this value as a WADID. In my humble opinion, that is a far more accurate depiction of the value shown.
Finally, it behoves you as an examiner to understand and be able to explain this properly. Have I figured out why Windows stupidly does what it does in this regard? Absolutely not. What I have figured out though, is that no matter what Microsoft chooses to call it in their literature, we can do better, and we can be more accurate. And do better, we must. Be better than a tool.
Kevin J. Ripa is the President and CEO of The Grayson Group of Companies and has been involved in numerous complex cyber-forensic investigations. He can be contacted via his website at www.computerpi.com.
