Skip to main content
SearchLoginLogin or Signup

USB Forensics – Recover more Volume Serial Numbers (VSNs) with the Windows 10 Partition/Diagnostic Event Log

Published onMay 26, 2021
USB Forensics – Recover more Volume Serial Numbers (VSNs) with the Windows 10 Partition/Diagnostic Event Log
·

Synopsis

Forensics Question:
How many Volume Serial Numbers (VSNs) of previously connected devices can be recovered from a single Windows event log?

OS Version:

Microsoft Windows 10 Pro 2004 Build 19041 (Original Tests)

Microsoft Windows 10 Pro 20H2 Build 19042 (Updated previous OS to test if the Event Log got cleared)

Tools:

JLECmd 1.4.0.0, LECmd 1.4.0.0, AXIOM 4.7, Partition-4DiagnosticParser (Developed Tool)

Authors: Alexandros Vasilaras1, Evangelos Dragonas2, Dimitrios Katsoulis3

[email protected], [email protected], [email protected]

Background

Windows 10 introduced a new event log of vital importance for both digital forensic examiners and incident responders. The new Partition/Diagnostic event log is found at C:\Windows\System32\winevt\Logs\ Microsoft-Windows-Partition%4Diagnostic.evtx. We are not the first ones to analyze this artifact, in pursue of extracting and interpreting its valuable information. Harlan Carvey [1], Jason Hale [2][3], forensixchange [4] and Costas K. [5] have all analyzed and shed light into what can be stored in this event log.

One point that has not yet been covered is that up to three Volume Serial Numbers (VSNs) from a device with multiple volumes can be found in this log. For that reason, we developed a tool that automates the extraction of the logged VSNs of a device (either unpartitioned or with MBR partition scheme) by parsing the Partition/Diagnostic event log. This paper will also assist in attributing LNK files and Jump Lists to a device by matching their VSNs to records in the event log.

Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx”

In this event log, information is stored about both removable devices (USB sticks, SD cards, external hard disks) and internal hard disks of a computer (including the disk that runs the operating system). This log stores information either when someone plugs in or out one of these devices, or after booting the computer.

Before describing our methodology, we will present some of the event log’s most important fields. Event logs generated by device removal will list 0 for many values, so we have focused on presenting the logs generated when a device with Master Boot Record (MBR) partition scheme gets connected.

System Section:

  • EventID: The ID of the log file. Will always be 1006.

  • TimeCreated [SystemTime]: Timestamp of the displayed event. In this case, the timestamp that plug in/out occurs, or the timestamp of the internal disk checkup at boot. It is stored in UTC. (Be aware though, that when using Windows’ Event Viewer, timestamps are presented in local time).

  • EventRecordId: Unique number assigned to each record inside the log file (increments by one).

  • Computer: Computer name.

  • Security [UserID]: User’s security identifier (SID). Will always be S-1-5-18 (User SYSTEM).

EventData Section:

  • DiskNumber: In our analysis, we found this number varying in a range between 0-3, with 0 being assigned to the disk running the operating system (OS).

  • IsSystemCritical: This value is usually false, apart from when DiskNumber was 0.

  • BytesPerSector: Bytes per sector (usually 512-defined by the manufacturer) of the device.

  • Capacity: The total capacity of the device (in bytes).

  • Manufacter: The manufacturer of the device. Not always accurate.

  • Model: Model of the device. Not always accurate.

  • SerialNumber: Serial number of the device.

  • ParentId: Information about the device, including Vendor ID, Product ID, Serial Number (potential correlation with registry files).

  • PartitionStyle: The partition scheme of the device. MBR is 0. GPT (GUID Partition Table) is 1.

  • PartitionCount: Number of partitions of the device. Not to be trusted.

  • Mbr: Raw dump of the first 512 bytes of the Master Boot Record of the device. Contains device’s Disk Signature and Master Partition Table.

  • Vbr0: Raw dump of the Volume Boot Record of the device’s 1st partition. Contains the VSN of this partition.

  • Vbr1: Raw dump of the Volume Boot Record of the device’s 2nd partition. Contains the VSN of this partition.

  • Vbr2: Raw dump of the Volume Boot Record of the device’s 3rd partition. Contains the VSN of this partition.

  • Vbr3: In our analysis, we found that this field is not populated with the raw dump of the Volume Boot Record of the device’s 4th partition. If someone wants to determine the existence of a 4th partition, he should examine the Master Partition Table.

As can be seen above, this event log not only stores the VSN of the 1st partition of a connected device, but also the VSNs of the 2nd and 3rd partition. Even after a user has formatted his device (leading to the loss of the assigned VSNs), previous VSNs can still be retrieved from the event log and attributed to his device.

These features are what make this log one of the most valuable sources of information, when attributing VSNs to devices. Before presenting our analysis, the limitations of this research will be presented.

Limitations and Points of Consideration

-Registry Analysis is out of the scope of this research. This research focuses on the forensic examination of “Microsoft-Windows-Partition%4Diagnostic.evtx” event log only. This should not mislead a forensic investigator to avoid examining the Windows registry, or any other source of evidence that could be relevant to his investigation.

-Our research is limited to devices with either unpartitioned (no partition scheme present) or MBR partition schemes. Devices with GPT partition scheme populate this event log in a different manner. Their forensic examination is part of our future work. What is more, if a device has four partitions, the event log will not hold information about the 4th partition. As a result, the VSN of the 4th partition cannot be retrieved from this event log.

-Our research includes devices with either FAT32, NTFS, exFAT or EXT3 file systems. Devices with a different file system populate this event log in a different manner. Their forensic examination is part of our future work.

-It should be noted that this event log’s lifespan is relatively short. This event log gets cleared every major Windows 10 update. Minor Windows updates do not clear the log. In our analysis, we updated our operating system from version 19041 to version 19042 and the log remained intact.

- It should be taken into consideration that the device type (e.g. solid state drive), as well as the type of connection (e.g. SATA hard disk plugged in an USB adapter and then into the computer) will populate this event log differently.

-Forensic examiners should acknowledge the possibility that different devices (typically from the same vendor), may share the same serial number (not to be confused with Volume Serial Number). This could mislead a forensic examiner into making wrong assumptions regarding their VSNs. A forensic examiner should always validate the results reported from the tools he uses.

Methodology Used

One feature that uniquely characterizes a partition is its Volume Serial Number (VSN). VSN is located inside the Volume Boot Record (VBR) and is assigned during high level format. Its offset and length vary, depending on the file system used by the device (NTFS, ExFAT etc.). VSN is used by LNK Files and Jump Lists to point at the volume where their target files reside (or used to reside before a wipe/format action took place on the device). Attribution is one of the reasons why VSN is so important in digital forensic investigations.

Another important feature that identifies a device with MBR partition scheme (GPT uses disk GUID instead), is its disk signature. Disk signature is located inside the Master Boot Record, at offset 0x1b8 (4 bytes little-endian) and is assigned when the device gets partitioned.

For our analysis, we used the following equipment (See Table 1):

Test Computer’s Operating System

Windows 10 2004 (Builds 19041 and 19042 after updating)

USB Devices

  1. Kingston Patriot 32GB USB device (with MBR partition scheme and 4 equals in size NTFS partitions)

  2. Kingston 8GB USB device (with MBR partition scheme, one FAT32 partition and another EXT3 partition)

Software

JLECmd 1.4.0.0, LECmd 1.4.0.0, AXIOM 4.7

Table 1

The research methodology we used consisted of four phases (experiments):

  • Phase 1: At this phase, the Kingston Patriot 32GB USB device was plugged in/out several times to/from the test computer. While the device was connected, several files were accessed (located in all four partitions) in order for LNK files and Jump Lists to be created. After a certain amount of data was created, we proceeded with the forensic examination of the event log, the LNK files and the Jump Lists.

  • Phase 2: At this phase, we deleted all the partitions of the Kingston Patriot 32GB USB device and created three new NTFS partitions. We repeated the same process as in Phase 1 (connections/ disconnections, accessing files in all partitions). After a certain amount of data was created, we proceeded with the forensic examination of the Event Log, the LNK files and the Jump Lists.

  • Phase 3: At this phase, the Kingston 8GB USB device was plugged in/out several times to/from the test computer. Shortly after, we proceeded with the forensic examination of the Event Log.

  • Phase 4: At this phase, we deleted the FAT32 partition of the Kingston Patriot 8GB USB device and created a new exFAT partition. We repeated the same process as in Phase 3 (connections/ disconnections). Shortly after, we proceeded with the forensic examination of the Event Log.

Analysis

The forensic examination of each aforementioned phase, is presented below:

Phase 1

To begin with, we examined all the available LNK Files and Jump Lists that were found within the test computer. Their analysis helped determine both volume label (a.k.a. volume name) and VSNs of the Kingston Patriot 32GB USB device (using JLECmd 1.4.0.0, LECmd 1.4.0.0 and AXIOM 4.7 - See Image 1):

Image 1: VSNs, Volume Names of Phase 1

Next, we analyzed the event log and were able to attribute three of the above VSNs, along with their respective volume labels to the same device. We failed to attribute the 4th (presented in Image 1 within the red box) as no information about it was stored within the event log. In NTFS volumes, VSN starts at offset 0x48 (4 bytes little-endian) of the VBR. See below snapshots of the event log, which helped us in attributing the VSNs (See Image 2):

Image 2: Information about the device stored in the event log

Serial Number: 007B01149030

Disk Signature: CE0DF460

1st Volume File System: NTFS

1st Volume Serial Number: C8B91B23

2nd Volume File System: NTFS

2nd Volume Serial Number: 76D3169C

3rd Volume File System: NTFS

3rd Volume Serial Number: 56EE2567

4th Volume File System: Could not be determined by analyzing the log

4th Volume Serial Number: Could not be determined by analyzing the log

Phase 2

In Phase 2, we repeated the same process as we did in Phase 1. However, this time the event log helped us attribute all the VSNs to the device. This is because the device had three partition and information for all of them was successfully retrieved from the event log. We will skip the details as the results were similar with previous Phase.

Phase 3

In FAT32 partitions, VSN starts at offset 0x43 (4 bytes little-endian) of the VBR. Some of the evidentiary data that was retrieved from the event log is shown below (See Image 3):

Image 3: Information about the device stored in the event log

Serial Number: 001CC0EC3458F110E5F31400

Disk Signature: 0047356E

1st Volume File System: FAT32 (determined by examining its VBR [6])

1st Volume Serial Number: 6A844219

2nd Volume File System: Could not be determined by analyzing the log

2nd Volume Serial Number: Could not be determined by analyzing the log

Unfortunately, EXT3 partition is not recognized by this event log and as a result, no relevant information is logged.

Phase 4

In exFAT partitions, VSN starts at offset 0x64 (4 bytes little-endian) of the VBR. Some of the evidentiary data that was retrieved from the event log is shown below (See Image 4):

Image 4: Information about the device stored in the Event Log

Serial Number: 001CC0EC3458F110E5F31400

Disk Signature: 0047356E

1st Volume File System: exFAT

1st Volume Serial Number: 2C50410B

2nd Volume File System: Could not be determined by analyzing the log

2nd Volume Serial Number: Could not be determined by analyzing the log

Once again, no information could be retrieved for the EXT3 partition, whereas the VSN for the exFAT partition was successfully retrieved.

Tool Development

We developed a tool (written in Python), that automates the process of extracting all the logged VSNs that reside in the “Microsoft-Windows-Partition%4Diagnostic.evtx”. During our research (November 2020), our tool appeared to be the only one that could successfully extract all stored VSNs (current and previously existed throughout the whole log) from 1st, 2nd and 3rd partitions, whereas other tools were limited to the VSN of the 1st partition only.

Currently, our tool extracts VSNs from devices that

  1. Are either unpartitioned or have MBR partition scheme,

  2. Have up to three partitions and

  3. Have partitions (or more specifically VBRs) that belong to any modern Microsoft Windows file system (namely NTFS, FAT32 and exFAT).

Using our tool, investigators are able to search for a specific serial number of a device, and the tool will return a list of all VSNs that were retrieved from the Partition/Diagnostic event log. Investigators can choose to output the result to a report file (.html or .csv format supported).

In addition, they are given the option to extract information (such as serial numbers, VSNs) for all the devices (with the three above-mentioned characteristics) that were connected to a computer (as long as their connections/disconnections were logged in “Microsoft-Windows-Partition%4Diagnostic.evtx”). This method supports exporting the results to a report file as well (Full Report feature). This report will offer a holistic view of the computer and historical information about device connections.

Both the tool and its documentation are available here: https://github.com/theAtropos4n6/Partition-4DiagnosticParser.

Link to the event log we used throughout this research can be found here: https://github.com/theAtropos4n6/Partition-4DiagnosticParser/tree/main/sampleFile

Conclusion

In this post we outlined the importance of examining “Microsoft-Windows-Partition%4Diagnostic.evtx”, especially in cases where device attribution is needed. Even though this artifact was detected years ago, we have not yet fully explored its wealth of information. Nevertheless, we showed how to manually extract all the available VSNs that are stored in it, as well as developed a tool to automate this process. There is room for further research of this event log, but hopefully the reader will find value in some of the major artifacts that can be found in it.

Future Work

We are planning to analyze how this Event Log handles GPT partition-schemed devices, as well as how it handles different file systems. We have some preliminary results, but they need further investigation.

References

[1] Carvey, H., 2017. Windows Incident Response: Stuff. Windows Incident Response. URL http://windowsir.blogspot.com/2017/10/stuff.html (accessed 11.29.20)

[2] Hale, J., 2018. USB Device Tracking using the Partition/Diagnostic Event Log - Part 1, 2018. . Digital Forensics Stream. URL https://df-stream.com/2018/05/partition-diagnostic-event-log-and-usb-device-tracking-p1/ (accessed 11.29.20).

[3] Hale, J., 2018. USB Device Tracking using the Partition/Diagnostic Event Log - Part 2, 2018. . Digital Forensics Stream. URL https://df-stream.com/2018/07/partition-diagnostic-event-log-and-usb-device-tracking-p2/ (accessed 11.29.20).

[4] Name, Y., n.d. USB storage forensics in Win10 #1 - Events [WWW Document]. Forensics|Exchange. URL https://forensixchange.com/posts/19_08_03_usb_storage_forensics_1/ (accessed 11.29.20).

[5] kacos2000/Win10 [WWW Document], n.d. . GitHub. URL https://github.com/kacos2000/Win10 (accessed 11.30.20).

[6] FAT32 Structure Information - MBR, FAT32 Boot sector introduction - EaseUS [WWW Document], 2021. URL https://www.easeus.com/resource/fat32-disk-structure.htm (accessed 3.31.21).

DFIR Review

The paper makes the valuable point that USB drives may contain multiple volumes, and an investigator could overlook the fact that multiple volumes could come from the same physical USB drive. The “Microsoft-Windows-Partition%4Diagnostic.evtx” event log can provide valuable information about devices that were connected to the computer. A reviewer suggested that it may have been more valuable to examine a GPT partitioned device.

One reviewer commented that the document provided enough background and explanation for them to understand the significance of the authors’ findings and how to utilize their tool. They felt that the paper is accurate and well-documented, and the findings are of use to the field of Windows forensics.

One of the reviewers tested the authors’ Partition%4DiagnosticParser tool using a HP ZBook running Windows 10 Pro (version 1909, OS Build 18363.1316) and a SanDisk Cruzer Fit 32GB. The tool worked as described and provided useful information, including information of all previously connected USB devices, including device serial number, manufacturer, model, first connected time, last connected time, and every VSN associated with the device. Another reviewer tested the authors’ tool using the provided dataset and confirmed that it functioned as intended.

One of the reviewers felt that the paper could have been shorted and more clearly organized. They found that some language could be misleading, for example “Every VSN ever existed on the media” may have been more accurately written “Every VSN recovered from the logs” since older logs may not have been maintained, the GPT partition scheme is not supported, etc. Another example is “Device with serial number x was never connected to the computer” - the word “never” is too definitive because that device might have actually been connected, but the log was cleared.

The reviewer also found some of the labeling of images to be confusing. Another reviewer commented that some of the images used for reference are screenshots that have been cut off (presumably to fit the width of the paper), and so are missing data of importance and the result may be confusing to the reader.

There were also some claims made without explanation. It also would have been helpful to clearly state which partition schemes and file systems are supported and which attributes are logged for each supported file system.

Future Work

Future work could include examining GPT partitioned devices. One of the reviewers suggested testing a second USB device from the same manufacturer and a third USB devices from another manufacturer to compare results.

Reviewers

Lisa Brown (Methodology Review, Validated Review using Reviewer Generated Datasets)

Zheng Jie Chan (Methodology Review)

Amanda Chung (Methodology Review, Verified Review using Author Provided Datasets)

Comments
0
comment
No comments here
Why not start the discussion?