Are you sure you extract all the available Volume Serial Numbers (VSNs) that reside in the Windows 10 Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx”?

[UPDATE 1/2 (May 2021): We are really grateful that this article made it to the finals of this year’s Forensic 4:cast awards, for the category “DFIR Article of the Year“!!! Your nominations got us there. I cannot describe in words how thankful I am to this DFIR community for this nomination! If you enjoyed our article and have not yet voted, voting is still open here: https://forensic4cast.com/forensic-4cast-awards/2021-awards/ . Be sure to also check the great work that has been done, in the other two articles that made it to the finals as well.]

[UPDATE 2/2 (May 2021): I am super excited to announce that a more formal version of this article has been published by DFIR Review. We are thankful to both our reviewers and to this great community, for the opportunity to share our work and the motivation to keep pushing forward our DFIR research. You can find our published paper here: https://dfir.pubpub.org/pub/h78di10n/release/1]

Greetings DFIR community! It has been a while since my last post, but juggling between work, life and research can be intimidating, as many of you already know. Nonetheless, today I am super excited to share with you the results of my latest collaborative research. We finally submitted our work for review and I cannot wait to hearing our reviews (fingers crossed)! This research post was a combined effort of me and another two amazing individuals, who are both DFIR-researchers and digital forensic experts, Alexandros Vasilaras and Dimitrios Katsoulis. It is thanks to Dimitrios, that we also have a tool (written in Python) to share with our DFIR community, so as to help you all skip the trouble of manually parsing VSNs. But before writing about this, let’s start from the beginning.

Our main goal is to present to you how to fully utilize this Event Log, so as to extract current and previously existed VSNs of a device (either Unpartitioned or with MBR partition scheme) with multiple Volumes. This presentation will assist in attributing LNK files and Jump Lists to such a device, even if the device has been formatted or worse, wiped.

I feel obliged to highlight the fact that this research is a non-profit one. We have not collaborated with any forensic software company, or any other third party entity. We do not have any personal or any kind of profit out of it. This research is merely a result of our own interest and personal time. By sharing this research, we are only trying to help the DFIR community and contribute back to it. We highly appreciate and use every and each one of the tools mentioned throughout this research. We hope that this research will be beneficiary for both DFIR practitioners and forensic software companies. Thank you.

Windows 10 introduced the Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx”. This log is without any doubt of vital importance for both digital forensic examiners and incident responders. 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.

On the other hand, one point that has not yet been covered efficiently in the existing literature, is that in this Event Log, there can be found both current and previously existed VSNs of the same device, as well as up to 3 VSNs of a device with multiple Volumes. In our research, we attempted to address this point, in order to unveil more of the hidden gems located in this Event Log, as well as highlight the importance of including its analysis in everyday investigations.

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). More particularly, this log stores information either when someone plugs in or out one of these devices, or after booting the computer. But what type of information does it store exactly?

Previous work [2][3][4][5], has answered this question in detail. Despite that, there are still fields that have not been explained, but thankfully most of them are self-explanatory (e.g. IsTrimSupported). It is out of the scope of this research to stressfully present all of the remaining fields in this log file. Before describing our methodology, we will present some of the Event Log’s fields, emphasizing on those that are most needed. Due to the fact that when a device gets disconnected, many of the afore-mentioned values will be 0, we are entirely focusing on presenting the equivalent values to when a device (with 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 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 at the disk running the 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 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 1^st Partition. Contains the VSN of this Partition.
• Vbr1: Raw dump of the Volume Boot Record of the device’s 2^nd Partition. Contains the VSN of this Partition.
• Vbr2: Raw dump of the Volume Boot Record of the device’s 3^rd 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 4^th Partition. If someone wants to determine the existence of a 4^th Partition, he should examine the Master Partition Table.

As can be seen above, this Event Log not only stores the VSN of the 1^st Partition of a connected device, but also the VSNs of the 2^nd and 3^rd Partitions. Even after a user has formatted his device (leading to the loss of the Volume’s VSNs for good), 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 is concerned.

Before presenting our analysis, it must be clarified that when a device with GPT partition scheme is connected, the values that are stored are not the same. This Event Log requires further research for the purpose of fully understanding what is logged, when devices with such partitioning scheme, are connected to the computer. Furthermore, the nature of the device (e.g. SSD Drive) and the type of connection (e.g. SATA hard disk plugged in an USB adapter and then in the computer) will populate some of the above-mentioned fields differently.

What is more, bear in mind that this log’s lifespan is relatively short (Event Log gets cleared every Windows 10 major update). On the other hand, between minors updates it remains as is (in our analysis we updated our system from 19041 to 19042 and it remained intact).

Operating System:

• 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)

Parsing LNK Files and JumpLists:

• JLECmd 1.4.0.0
• LECmd 1.4.0.0
• AXIOM 4.7

Event Log Viewing, Parsing and Analyzing:

• Event Viewer
• FullEventLogView v1.58
• Evtx Explorer/EvtxECmd 0.6.0.3
• AXIOM 4.7
• USB Detective 1.6.1

For this analysis, we used a Kingston Patriot USB device with 32GB, which we plugged in/out several times in a computer running Windows 10 2004 (Build 19041). The USB device had MBR partition scheme and 4 equals in size NTFS partitions.

One feature that characterizes uniquely a Volume/Partition inside a device, is its Volume Serial Number. VSN is located inside the Volume Boot Record 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 long-LE) and is assigned when the device gets partitioned.

Our entire analysis focused on “Microsoft-Windows-Partition%4Diagnostic.evtx”. To that extent, we did not examine any registry files of the target computer, that could assist us in any kind of correlations.

To begin with, we connected/disconnected the USB device and observed how the log got populated. Afterwards, we created and accessed various files in all of the USB device’s Partitions. Our purpose was to create LNK files and Jump Lists that could help us make connections.

After a certain amount of data was created, we started deleting the partitions, one by one, starting from the last one. As a result, the whole USB device appeared as unallocated space. The USB device was then completely re-formatted into 3 “new” NTFS Partitions. This whole process was repeated another time, resulting in the creation of 1 “last” NTFS partition that took up the whole available space.

Lastly, for completeness purposes, we made another 2 connections/disconnections. We connected a Kingston 8GB device with FAT32 and EXT3 file systems (2 Partitions). Then we formatted the FAT32 Partition and created an exFAT instead. After re-connecting the USB device, we checked if the same or similar information was stored in the Event Log.

Our analysis consists of 4 phases namely: Phase 1 (4 Partitions), Phase 2 (format and 3 Partitions), Phase 3 (format and 1 Partition) and Phase 4 (FAT32, EXT3 and exFAT).

Phase 1-(4 Partitions)

Firstly, we collected all the available LNK Files and Jump Lists that we created and documented all the Volume Names and VSNs they included (using JLECmd 1.4.0.0, LECmd 1.4.0.0 and AXIOM 4.7 – See Image 1):

Then we analyzed the Event Log and managed to attribute 3 of the above VSNs and their respective Volume Names to the same device. We failed to attribute the 4^th (presented in Image 1 within the red box) as it was not stored inside the log. Regardless of that, we managed to prove that a 4^th Partition indeed existed in this device, by examining Master Partition Table’s entries inside MBR. In NTFS Volumes, VSN starts at offset 0x48 (4 bytes long-LE) of the VBR. See below, fractions of the Event Log, that helped us in attributing the VSNs (See Image 2):

Serial Number: 007B01149030
Disk Signature: CE0DF460
How Many Partitions (from MPT): 4
1^st Volume File System: NTFS
1^st Volume Serial Number: C8B91B23
2^nd Volume File System: NTFS
2^nd Volume Serial Number: 76D3169C
3^rd Volume File System: NTFS
3^rd Volume Serial Number: 56EE2567
4^th Volume File System: Could not be determined by analyzing the log
4^th Volume Serial Number: Could not be determined by analyzing the log

Overlooking “Microsoft -Windows-Partition%4Diagnostic.evtx”, could possibly mislead the investigator into hypothesizing that there were many devices connected to the computer, due to the diversity of VSNs, Volume Names and assigned Drive Letters. Whereas, if this log is included in the analysis, there is a lot of information that could help him make safer assumptions, about the number of devices plugged in the computer.

Phase 2-(format and 3 Partitions)

After deleting all the Partitions of the USB device, we created 3 new NTFS Partitions and repeated the same process as Phase 1. The results were similar. Following is a list of all the VSNs that were retrieved from the LNK files we created in Phase 2 (See Image 3):

Once again, the Event Log kept tracking the various VSNs, allowing us to keep attributing them to that particular device. Let’s take a look at another Event ID 1006 entry that was logged during Phase 2 (See Image 4):

Serial Number: 007B01149030
Disk Signature: CE0DF460
How Many Partitions (from MPT): 3
1^st Volume File System: NTFS
1^st Volume Serial Number: 54F63E46
2^nd Volume File System: NTFS
2^nd Volume Serial Number: D803E772
3^rd Volume File System: NTFS
3^rd Volume Serial Number: 30239D59

This time the Event Log helped us attribute all the VSNs to the device. We validated this match, comparing Partition entries in MPT and corresponding VSNs. We will skip the results of Phase 3, as they were similar to those of Phase 1 and Phase 2.

To conclude with, we will present what information was stored in the Event Log during Phase 4.

Phase 4-(FAT32, EXT3 and exFAT)

After plugging in the USB device with the FAT32 and EXT3 Partitions, the following information was logged in the Event Log (See Image 5). In FAT32 Volumes, VSN starts at offset 0x43 (4 bytes long-LE) of the VBR:

Serial Number: 001CC0EC3458F110E5F31400
Disk Signature: 0047356E
How Many Partitions (from MPT): 2
1^st Volume File System: FAT32
1^st Volume Serial Number: 6A844219
2^nd Volume File System: Could not be determined by analyzing the log
2^nd Volume Serial Number: Could not be determined by analyzing the log

Unfortunately, EXT3 Partitions, being a File System from a different operating system, are not recognized by this Event Log and as a result no relevant information is logged. However, we found VSN for the FAT32 Volume and managed to prove that a 2^nd Partition indeed existed in this device, by examining Master Partition Table inside MBR.

Closing this analysis, after plugging in the USB device with the exFAT and EXT3 Partitions, the following information was logged in the Event Log (See Image 6). In exFAT Volumes, VSN starts at offset 0x64 (4 bytes long-LE) of the VBR (See Image 6):

Serial Number: 001CC0EC3458F110E5F31400
Disk Signature: 0047356E
How Many Partitions (from MPT): 2
1^st Volume File System: exFAT
1^st Volume Serial Number: 2C50410B
2^nd Volume File System: Could not be determined by analyzing the log
2^nd 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 recovered, along with the 2 entries in the MPT of the MBR.

We developed a tool (written in Python), that helps automate the process of extracting all the logged VSNs that reside in the “Microsoft-Windows-Partition%4Diagnostic.evtx”, for each device that was connected to the target computer. During our research, our tool appeared to be the only one that could successfully extract all stored VSNs (current and previously existed throughout the whole log) from 1^st, 2^nd and 3^rd Partitions respectively, whereas other tools were limited to the VSN of the 1^st Partition only.

Currently, our tool extracts effectively VSNs from devices that:

1. Are either Unpartitioned or have MBR partition scheme,
2. Have up to 3 Volumes. Moreover, information about the existence of a 4^th Partition, can be extracted from the Event Log as well (up to this day however, VSN for the 4^th VBR is not stored in the Event Log) and
3. Have Volumes (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, throughout “Microsoft-Windows-Partition%4Diagnostic.evtx”, in which case the tool will return a list of VSNs that ever existed in it. Investigators can choose to output the result of the tool to a report file (.html or .csv format supported).

Examining the output report, investigators can also find out when approximately a particular VSN changed, and even determine if a format operation or any other masquerade attempt, took place on the device itself (such as manually altering the VSN of a given volume of the device, with a hex editor).

In addition, they are given the option to extract information (including the stored VSNs for any device that has the 3 above-mentioned characteristics) for all the devices that were connected to the target computer. 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 tool and its documentation, along with the event log we used in our analysis, 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

Taking everything into consideration, in this post we tried to outline the importance of examining “Microsoft-Windows-Partition%4Diagnostic.evtx”, especially in cases where device attribution is needed. Even though this artifact was first 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 help automate this process. There is definitely 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.

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.

[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).

I really hope you enjoyed this post. If you found value in it, share it with any DFIR fellow that might find it useful. In my next post, Dimitrios will share with us, a full walkthrough of his tool “Partition%4DiagnosticParser”. Stay tuned!