AWS Identity and Access Management (IAM) roles are a key security feature in AWS that allow services, applications, or users to assume temporary permissions to interact with AWS resources. IAM roles are commonly used to grant access without hardcoding credentials.

AWS Elastic Compute Cloud (EC2) is a web service that let’s AWS customers to create and manage virtual machines, also called instances.

To leverage a IAM role within an EC2 instance, the role needs to be first attached to the instance. When the instance is launched, it will assume that role and obtain temporary security credentials without the necessity of leveraging static credentials. These credentials are generated by AWS STS (security token service), and going forward I will be refering to these as “STS credentials”.

IAM role operation within EC2 is supported by Instance Metadata Service (IMDS). IMDS is an interface that is leveraged by EC2 workloads to retrieve metadata of the instance, including, for example, instance ID, AMI ID, and networking information. IMDS also allows to retrieve STS credentials for the IAM role attached to the EC2 instance. STS credentials can be retrieved in 2 ways:

• IMDSv1, a legacy version that accepts simple HTTP GET requests. This version was lacking security controls, so Amazon introduced IMDSv2.

• IMDSv2, the updated version of IMDS, which leverages session-based authentication and reduces risks of certain abuse techniques, e.g. server-side request forgery (SSRF) that existed in IMDSv1.

In an event of threat actor gaining access to an EC2 instance, they can compromise the currently active STS credentials of the attached IAM role, and leverage that with a malicious intent.

Lab setup and overview

To conduct tests, I used AWS free tier to configure the testing environment. This setup involved:

• Creating a VPC and enabling VPC flow logs.

• Configuring CloudTrail to log events and write them into an S3 bucket.

• Creating an IAM role that will be compromised.

• Setting up an EC2 instance with the IAM role attached, while configuring IMDSv2 as optional to allow testing both IMDSv1 and IMDSv2 versions.

Once the environment was ready, I SSH’ed into the EC2 instance and performed the following experiments:

• Extracted STS credentials:

  • Used IMDSv1 and IMDSv2 to retrieve the STS credentials for the attached IAM role.

• Tested AWS CLI access:

  • Configured AWS CLI on the EC2 instance to use the extracted STS credentials and ran various test scenarios.

  • Configured AWS CLI on my local system with the same credentials to replicate the test scenarios outside the instance.

With the compromised STS credentials, I executed the following actions:

• Enumerated S3 bucket with CloudTrail logs using “s3 ls” command.

• Enumerated EC2 Instances using “describe-instances” command.

• Verified identity for the STS credentials using “get-caller-identity” command.

Summary of findings

• In my tests, when both IMDSv1 and IMDSv2 are available on an EC2 instance, there will be one set of credentials created for each of them. This is interesting behavior, however there would not be any way to distinguish which one was generated for IMDSv1 and which one for IMDSv2, without actually querying them on the EC2 instance while credentials are still active.

• STS credential extraction via IMDS would not be visible in CloudTrail or VPC logs. Host-based forensics of the EC2 instance would be required to detect the initial credential extraction.

• All API actions that leveraged extracted credentials were logged with the same identity (including instance ID from where the STS credentials were extracted) regardless of location. The fact of instance ID presence within the role session name, demonstrates that AWS maintains the original context of where the credentials were initially issued, even when those credentials are used from completely different environments. This is significant because it means that while the credentials can be used anywhere, the logging still ties all actions back to the original EC2 instance from which they were obtained.

• While identity details will remain consistent, both source IP addresses and user agents can be used to distinguish between actions that happened within the EC2 instance and from an external IP.

• CloudTrail comprehensively logs all API calls with these credentials, including successes, failures, and identity verification attempts.

Experiments deep dive

STS credentials extraction

IMDSv1

The IP address 169.254.169.254 is important in relation to IMDS because it serves as the dedicated link-local address through which EC2 instances can query metadata, including retrieving STS credentials. This means EC2 instance does not require Internet connection in order to query instance metadata, including STS credentials of the attached IAM role.

Easiest way to query IMDSv1 and extract the STS credentials generated for attached IAM role is to run a curl command pointing to 169.254.169.254. Code snippet presented below does just that, retrieves the STS credentials for “iam-role-blog-research-20250217” IAM role.

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/iam-role-blog-research-20250217

The STS credentials were returned in a form of JSON:

{
  "Code" : "Success",
  "LastUpdated" : "2025-02-17T17:57:35Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA2UC3DTBG65TLTQAU",
  "SecretAccessKey" : "6aS1bKIcB...Ocz3FJP+/",
  "Token" : "IQoJb3JpZ2luX2VjEFEYCIQ...8FOFSoiYkSWOnc5Nw==",
  "Expiration" : "2025-02-18T00:31:41Z"
}

IMDSv2

IMDSv2 works little differently, and STS credentials can be retrieved with the following sequence of commands:

• Retrieve IMDS session token. This should not be confused with STS credentials. IMDS session token is what differentiates IMDSv2 from IMDSv1. This security measure was specifically introduced to prevent SSRF (server-side request forgery) attacks. The token is retrieved via PUT request towards "http://169.254.169.254/latest/api/token". The command would look like this, where we set environmental variable TOKEN to the output of PUT request:

  TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

• TOKEN variable now can be leveraged to query IMDS and export the STS credentials via curl command:

  curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/iam-role-blog-research-20250217

• The STS credentials retrieved via IMDSv2 will be presented in exactly the same JSON format as what we saw in IMDSv1 example, however the actual credentials will be different:

  {
    "Code" : "Success",
    "LastUpdated" : "2025-02-17T17:56:52Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIA2UC3DTBGQTU3AUTM",
    "SecretAccessKey" : "gPznXQzVxajv6...BMyMslV",
    "Token" : "IQoJb3JpZ2luX2VjEFIaCXVzLWVhc3Qt...DGsgN9CmeRzA==",
    "Expiration" : "2025-02-18T00:31:41Z"
  }

Analysis

Now when we extracted the STS credentials of the attached IAM role, I would like to understand if any of the events related to STS credentials extraction would appear in AWS logs. I leveraged this tool to extract CloudTrail and VPC logs that were captured for my lab environment. In the tool I leveraged the STS credentials I previously extracted from the EC2 instance via IMDSv1. Analysis results:

• The VPC logs would not be helpful here, which is expected since there were no network connections established with dedicated link-local IP address 169.254.169.254.

• The ClourTrail logs will not show the events of threat actor retrieving STS credentials with neither IMDSv1 nor IMDSv2. However, we will see the AssumeRole events that are triggered either at EC2 instance startup or after the STS credentials were expired. One interesting discovery I made is STS will generate two separate sets of credentials - one for IMDSv1 and another for IMDSv2. The AssumeRole events will be generated for both credentials simultaneously (in my case the recorded timestamp was “2025-02-17T17:56:41Z”, the time when I launched the instance).

• In order to investigate the STS credentials extraction via IMDS, you would need to leverage host-based forensic artifacts of the affected EC2 instance.

Leveraging compromised STS credentials

For both experiments I leveraged the STS credentials that I extracted before, specifically the ones with the AccessKeyID “ASIA2UC3DTBG65TLTQAU” produced via IMDSv1.

Testing STS credentials within an AWS EC2 instance

First I configured the AWS CLI within an EC2 instance to utilize the extracted STS credentials:

aws configure set aws_access_key_id "ASIA2UC3DTBG65TLTQAU"
aws configure set aws_secret_access_key "6aS1bKIcBGKkxm..."
aws configure set aws_session_token "IQoJb3JpZ2luX2VjEFIaCXVzLW..."
aws configure set region us-east-1

Then I launched the test commands, that would (1) list S3 bucket with CloudTrail logs, (2) enumerate EC2 Instances, and (3) verify identity for the STS credentials.

aws s3 ls
aws ec2 describe-instances
aws sts get-caller-identity

I observed that with the STS credentials I previously extracted via IMDSv1:

• I could successfully list S3 buckets.

• I received an "UnauthorizedOperation" error when attempting to list EC2 instances for the account (this is expected as my IAM role did not have the necessary permissions to perform the ec2:DescribeInstances action).

• I could retrieve the identity information showing I was using the assumed IAM role.

Testing the same credentials outside of AWS

I exported the exact same temporary credentials obtained via IMDSv1, and created a “stolen-creds-research” profile on my local machine in AWS CLI:

aws configure --profile stolen-creds-research
AWS Access Key ID: ASIA2UC3DTBG65TLTQAU
AWS Secret Access Key: 6aS1bKIcBGKkxmsrJYe/
Default region name: us-east-1
Default output format: json
aws configure set aws_session_token "IQoJb3JpZ2luX2VjEF..." --profile stolen-creds-research

Then, using the created profile, I repeated the same operations as in the previous test:

aws s3 ls --profile stolen-creds-research
aws ec2 describe-instances --profile stolen-creds-research
aws sts get-caller-identity --profile stolen-creds-research

The results were identical to those from within the EC2 instance, demonstrating that temporary credentials maintain the same permissions regardless of where they're used.

CloudTrail logs analysis

I extracted and analyzed the CloudTrail logs to find evidence of my testing operations.

• All actions, whether performed within AWS or externally, were recorded in logs with the compromised AccessKeyId (ASIA2UC3DTBG65TLTQAU). In addition to that, the actions were recorded with the same identity, including the instance ID from where the credentials were extracted!

arn:aws:sts::730335516749:assumed-role/iam-role-blog-research-20250217/i-0242db56002b56caf

• While the principal remains the same, the source IP address changes depending on where the credentials are used:

  • EC2 Instance: 18.204.198.227 (AWS IP)

  • External Machine: 74.64.xx.xx (my local IP)

• The logs include the AWS CLI version and operating system, which differ between environments:

  • EC2: aws-cli/2.17.18 md/awscrt#0.19.19 ua/2.0 os/linux#6.1.127-135.201.amzn2023.x86_64

  • External: aws-cli/2.24.5 md/awscrt#0.23.8 ua/2.0 os/macos#22.6.0 md/arch#x86_64

• AWS CloudTrail thoroughly logs all API calls, including:

  • Successful operations (S3 bucket listing)

  • Failed operations with detailed error messages (the error I got after running “aws ec2 describe-instances”)

  • Identity verification actions (GetCallerIdentity)

References

• “AWS Instance Metadata Service: A Quick Refresher” by Syed Hasan (https://syedhasan010.medium.com/aws-instance-metadata-service-a-quick-refresher-4b61ed9af23a)

• AWS documentation: “Access instance metadata for an EC2 instance” (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)

• “Daily Blog #751: Sunday Funday 2/16/25” by David Cowen (https://www.hecfblog.com/2025/02/daily-blog-751-sunday-funday-21625.html)

Tools used

• CloudTrail and VPC flow log collector (https://github.com/ilyakobzar/dfir-tools/blob/main/cloudtrail_vpc_log_collector.py)

ShellBags were introduced in Microsoft Windows to provide a consistent and personalized interface to users when interacting with directories through the Windows Explorer application. This includes, but is not limited to:

• Icon size, position, view mode (e.g., list, details, tiles).

• Window size, and location.

• Recording information for local drives, network shares, and removable devices.

ShellBags are a well-known and well-documented registry-based forensic artifact that is highly valuable in forensic analysis, as they allow investigators to determine which directories a user accessed via Windows Explorer and when. Another key advantage of ShellBags is that they retain data for accessed directories even after those directories have been deleted from the file system.

In this post, I want to explore if there are any specifics in how Windows 11 records ShellBags for common user operations within Windows Explorer, with a specific focus on timestamps that indicate user interactions with directories, i.e. “FirstInteracted” and “LastInteracted” fields.

Limitations

• The experiments were performed on Windows 11 Pro, version 24H2, OS build 26100.3194.

• There were no ShellBag entries for any of the directories covered in the experiments prior to me beginning the tests.

Executive summary

ShellBags entries were updated only when the user actively navigated to a directory in Windows Explorer. Edge cases, such as directory creation via the command line, copying or moving directories and files, or merely clicking on directories, did not trigger ShellBag updates.

Please refer to the section “Experiments” for the detailed documentation on the performed tests and results.

Experiments

I performed a series of tests covering some common operations users perform on a daily basis:

• Test #1: A directory created in the command line.

• Test #2: A file being copy and pasted.

• Test #3: A directory being copy and pasted.

• Test #4: A file being cut and pasted.

• Test #5: A directory being cut and pasted.

• Test #6: A directory being opened from file explorer.

• Test #7: A directory being opened from the desktop.

• Test #8: A directory being clicked on from file explorer.

• Test #9: A directory being clicked on from the desktop.

Test #1

The main investigative question I want to answer with this experiment - in an event of a directory created in the command line, would a ShellBag entry be created for the directory?

In this test I leveraged “mkdir” command to create a directory “C:\_Data\Tests\01_dir_created_in_cmd_line\”. I manually recorded the following time stamp when the directory was created “2025-02-15T00:50:24Z”. There was no ShellBag entry created for the directory “C:\_Data\Tests\01_dir_created_in_cmd_line\”.

With that said, the ShellBag entry was not created in an event of a directory created in the command line.

Test #2

The main investigative question I want to answer with this experiment - in an event of file copy and paste, would a ShellBag entry be updated for the directory where the file was copied to?

In this test I leveraged Windows Explorer copy and paste functionality for the file that was copied to a directory “C:\_Data\Tests\2_file_copy_paste\”. I manually recorded the following time stamps during the experiment:

• Opened the target directory: 2025-02-15T00:52:46Z

• Pasted the file: 2025-02-15T00:56:31Z

• Closed the target directory: 2025-02-15T00:59:05Z

The time stamp “2025-02-15T00:52:44Z” was recorded for the target directory, which corresponds with the time when I opened the directory (recorded within the “FirstInteracted” field of the ShellBag entry). There was no time stamp recorded within the “LastInteracted” field.

With that said, the operation of copying a file did not update the ShellBag entry for the target directory.

Test #3

The main investigative question I want to answer with this experiment - in an event of directory being copy and pasted, would ShellBag entries be updated for both the target directory and the copied directory? To answer the question, I explored two scenarios covered below. I leveraged Windows Explorer copy and paste functionality to copy test folders.

The first scenario is when a directory “3_folder_copy_paste” was copied from the desktop to a directory “C:\_Data\Tests\”. I manually recorded the following time stamp when the directory was pasted: “2025-02-15T01:00:56Z”. I did not observe ShellBag entry created neither for the source directory “3_folder_copy_paste” neither located on the desktop, nor for the copied directory “C:\_Data\Tests\3_folder_copy_paste\”.

The second scenario is when a directory “3.1_folder“ was copied from the desktop to “C:\_Data\Tests\3.1_folder_copy_paste\”. I manually recorded the following time stamps during the experiment:

• Target directory created: 2025-02-15T01:33:33Z

• Opened the target directory: 2025-02-15T01:35:20Z

• Pasted the directory: 2025-02-15T01:37:46Z

• Closed the target directory: 2025-02-15T01:38:47Z

The time stamp “2025-02-15T01:35:20Z” was recorded for the target directory “C:\_Data\Tests\3.1_folder_copy_paste\”, which corresponds with the time when I opened the directory (recorded within the “FirstInteracted” field of the ShellBag entry). There was no time stamp recorded within the “LastInteracted” field.

With that said, the operation of copying a directory did not update ShellBag entries neither for the directory that was copied nor for the target directory where directory was copied to.

Test #4

The main investigative question I want to answer with this experiment - in an event of file being cut and pasted, would a ShellBag entry be updated for the directory where the file was pasted to?

In this test I leveraged Windows Explorer cut and paste functionality for the file that was moved to a directory “C:\_Data\Tests\4_file_cut_paste\”. I manually recorded the following time stamps during the experiment:

• Opened the target directory: 2025-02-15T01:03:30Z

• Pasted the file: 2025-02-15T01:04:47Z

• Closed the target directory: 2025-02-15T01:06:31Z

The time stamp “2025-02-15T01:03:30Z” was recorded for the target directory “C:\_Data\Tests\4_file_cut_paste\”, which corresponds with the time when I opened the directory (recorded within the “FirstInteracted” field of the ShellBag entry). There was no time stamp recorded within the “LastInteracted” field.

With that said, the operation of moving a file did not update the ShellBag entry for the directory where the file was pasted to.

Test #5

The main investigative question I want to answer with this experiment - in an event of directory being cut and pasted, would ShellBag entries be updated for both the target directory and the moved directory? To answer the question, I explored two scenarios covered below. I leveraged Windows Explorer cut and paste functionality to move test folders.

The first scenario is when a directory “5_folder_cut_paste” was copied from the desktop to a directory “C:\_Data\Tests\”. I manually recorded the following time stamp when the directory was pasted: “2025-02-15T01:11:46Z”. I did not observe ShellBag entry created neither for the source directory “5_folder_cut_paste” neither located on the desktop, nor for the target directory “C:\_Data\Tests\5_folder_cut_paste\”.

The second scenario is when a directory “5.1_folder“ was copied from the desktop to “C:\_Data\Tests\5.1_folder_cut_paste\”. I manually recorded the following time stamps during the experiment:

• Target directory created: 2025-02-15T01:40:23Z

• Opened the target directory: 2025-02-15T01:41:40Z

• Pasted the directory: 2025-02-15T01:43:03Z

• Closed the target directory: 2025-02-15T01:44:01Z

The time stamp “2025-02-15T01:41:40Z” was recorded for the target directory “C:\_Data\Tests\5.1_folder_cut_paste\”, which corresponds with the time when I opened the directory (recorded within the “FirstInteracted” field of the ShellBag entry). “LastInteracted” ShellBag field also recorded the same time stamp - “2025-02-15T01:41:40Z”.

With that said, the operation of moving a directory via cut and paste did not update ShellBag entries neither for the directory that was copied nor for the target directory where directory was copied to.

Test #6

The main investigative question I want to answer with this experiment - in an event of directory being opened via Windows Explorer from a non-desktop location, would a ShellBag entry be updated for the directory?

In this test I leveraged Windows Explorer double click operation to open the target directory “C:\_Data\Tests\6_dir_opened_from_file_explorer\”. I manually recorded the following time stamps during the experiment:

• Opened the target directory: 2025-02-15T01:13:16Z

• Closed the target directory: 2025-02-15T01:15:14Z

The time stamp “2025-02-15T01:13:16Z” was recorded for the target directory “C:\_Data\Tests\6_dir_opened_from_file_explorer\”, which corresponds with the time when I opened the directory (recorded within the “FirstInteracted” field of the ShellBag entry). There was no time stamp recorded within the “LastInteracted” field.

With that said, the operation of opening a directory via Windows Explorer from a non-Desktop location does update the ShellBag entry. This behavior is expected and was present in prior versions of Windows.

Test #7

The main investigative question I want to answer with this experiment - in an event of directory opened from the Desktop, would ShellBag entries be updated for the directory?

In this test I leveraged Windows Explorer double click operation to open the target directory “%USERPROFILE%\Desktop\7_dir_opened_from_desktop\”. I manually recorded the following time stamps during the experiment:

• Opened the target directory: 2025-02-15T01:22:10Z

• Closed the target directory: 2025-02-15T01:24:42Z

The time stamp “2025-02-15T01:22:10Z” was recorded for the target directory “%USERPROFILE%\Desktop\7_dir_opened_from_desktop\”, which corresponds with the time when I opened the directory (recorded within the “FirstInteracted” field of the ShellBag entry). There was no time stamp recorded within the “LastInteracted” field. Interestingly enough, the flag “HasExplored” was set to FALSE in the ShellBag entry.

With that said, the operation of opening a directory via Windows Explorer from a Desktop location does update the ShellBag entry. This behavior is expected and was present in prior versions of Windows. However, “HasExplored” was set to FALSE.

Test #8

The main investigative question I want to answer with this experiment - in an event of directory being clicked on (one time click to select the directory, without navigating to the directory) within Windows Explorer from a non-desktop location, would ShellBag entries be updated for the directory?

In this test I leveraged Windows Explorer single click operation to select the target directory “C:\_Data\Tests\8_dir_clicked_from_file_explorer”. I manually recorded the following time stamps during the experiment:

• Clicked the target directory: 2025-02-15T01:26:55Z

• Un-clicked the target directory: 2025-02-15T01:28:05Z

ShellBag entry for “C:\_Data\Tests\8_dir_clicked_from_file_explorer\” was not created.

With that said, the operation of single click on a directory within Windows Explorer from a non-desktop location, did not update the ShellBag entry for the target directory will not be updated.

Test #9

The main investigative question I want to answer with this experiment - in an event of directory being clicked on (one time click to select the directory, without navigating to the directory) within Windows Explorer from the Desktop location, would ShellBag entries be updated for the directory?

In this test I leveraged Windows Explorer single click operation to select the target directory “%USERPROFILE%\Desktop\9_dir_clicked_from_desktop\”. I manually recorded the following time stamps during the experiment:

• Clicked the target directory: 2025-02-15T01:30:27Z

• Un-clicked the target directory: 2025-02-15T01:31:25Z

ShellBag entry for “%USERPROFILE%\Desktop\9_dir_clicked_from_desktop\” was not created.

With that said, the operation of single click on a directory within Windows Explorer from the Desktop location, did not update the ShellBag entry for the target directory will not be updated.

References

• The theme for this post was inspired by David Cowen’s Sunday Funday challenge! (https://www.hecfblog.com/2025/02/daily-blog-744-sunday-funday-2925.html)

• “Windows ShellBag Forensics in Depth” by Vincent Lo (https://www.giac.org/paper/gcfa/9576/windows-shellbag-forensics-in-depth/128522)

Tools used

• ShellBags Explorer and SBECmd by Eric Zimmerman (https://ericzimmerman.github.io/#!index.md)

ChatGPT desktop app uses LevelDB's write-ahead logging (WAL) mechanism to temporarily store the cache of conversation history.

The WAL log is written to disk after ChatGPT application (i.e. associated process tree) is terminated, which may happen either at system shutdown/reboot or if the user exits the application. The exact location of the binary: “%UserProfile%\AppData\Local\Packages\OpenAI.ChatGPT-Desktop_2p2nqsd0c76g0\LocalCache\Roaming\ChatGPT\IndexedDB\https_chatgpt.com_0.indexeddb.leveldb\######.log” (“000003.log” in my case).

The log will stay on disk until the user loggs off from the ChatGPT account within the app. When that happens, the contents of “https_chatgpt.com_0.indexeddb.leveldb\” will be erased.

When the user logs back into the app, the contents of “https_chatgpt.com_0.indexeddb.leveldb\” will be re-created, however, no conversation log will be present in “000003.log”. If you select any of the historical conversations within the ChatGPT app, their contents will be written in a structured way into “000003.log”. Thus, we can potentially distinguish between conversations that were entered directly into the app and historical conversations that the user accessed.

Limitations

• ChatGPT desktop app version 1.2025.021.

• Lab operating system: Windows 10 Pro, version 21H2, OS build “19044.1766”.

• Tests were performed on a freshly installed ChatGPT desktop application. That means if there was a heavy usage of the app, some behaviors may change. LevelDB is known for utilizing WAL as a temporary storage. When the log file reaches 4MB in size, the contents of the WAL binary will be written to a LevelDB database binary (.ldb), as referenced in the article by Alex Caithness (please refer to References section for the article link).

WAL binary structure

Initial processing

To streamline the analysis of the WAL log I leveraged “leveldbutil” application’s “dump” option. This helps to parse the log and present it in more structured format, that we can leverage in both manual and automated analysis.

Here are some of the patterns that can be immediately spotted:

• The data is written in chunks divided by “--- offset #; sequence #” separator. Each chunk contains a set of operations that are executed simultaneously. For example, at offset 0 we only have one operation, however at offset 308 we can see that 20 operations were executed.

• “offset #” - indicates the byte position in the file where each database record starts.

• “sequence #” - a monotonically increasing number that preserves the order of operations, and each operation gets a unique sequence number. The operations can be “put” and “del”.

• “put” - database operation that adds or updates a key-value pair in the database, with the format is typically being "put 'key' 'value'“, e.g. “put '\x00\x00\x00\x002\x00' '\x08\x01'“ from the Figure 2 screenshot.

• “del” - database operation that removes a key-value pair from the database, with the format is typically being “del 'key'“, e.g. “del '\x00\x00\x00\x002\x01\x0c'“ from Figure 3 screenshot.

Initial conversation record

The WAL log shows that ChatGPT begins writing conversations at offset 1816 (please refer to Figure 4 down below), assuming no cached offline conversation records are present (as explained in the "LevelDB WAL" section of this post). Looking at the set of operations, analyst can extract the following valuable information:

• Conversation ID has a pattern that can be matched with the following regex: “$[a-z0-9]{8}\-([a-z0-9]{4}\-){3}[a-z0-9]{12}” (e.g. $6797fd67-a208-800e-ae5c-5bbd51abf7ad). Conversation ID can be used in automation to correlate all messages from the same conversation.

• Authenticated user ID has a pattern that can be matched with the following regex: “\x0aauthUserId"\x1d(user-[^"]+)” (e.g. authUserId"\x1duser-DprP7QKdmuYYyxFV20428vJK). I noticed two patterns in the log - “authUserId” and “accountUserId”. The value in “authUserId” would also be present within “accountUserId” field. In the parser script I export the value of “authUserId”. Each chunk of WAL log (i.e. the set of operations prefixed by “--- offset #; sequence #” separator) that contains conversations, would also store both user auth ID and conversation ID. This comes in handy when we want to parse the log and reconstruct the conversation sequence automatically.

• Title, which is empty for now. That’s consistent with the application behavior, the title will only be generated after the initial assistant response.

• The conversation start time is recorded in the “updateTime” field. Looking at the structure we can see the time stamp is recorded with the following values: “\xa0\x1a\x87W\xff\xe5\xd9A”. The timestamp format is IEEE 754 double-precision floating point number in little-endian format and can be decoded into “2025-01-27T21:40:46.111000 UTC”. In my tests, this time stamp remained intact even after I continued the same conversation after ChatGPT application restarted on the following day. This timestamp represents the date and time when the conversation started. Timestamps will be preserved per conversation, meaning if a single WAL log has multiple conversations, each will have its time stamp. The following regex will match the time stamp pattern: “updateTimeN((?:\x[0-9a-f]{2}|[\x20-\x7E]){8})”.

• The very first user prompt is distinguished from follow-up prompts, and it can be matched with the following regex: “root-nextPrompt"\x04text"([^{]+)” (e.g. root"root-nextPrompt"\x04text"\x13Hello, how are you?”). I want to point out an interesting pattern that is perceived by all messages in the log - they would be ending with opening curly brackets “{“. This pattern can be used to match the end of each message within a conversation. Hereinafter, I will be referring to the human that enters prompts as “user”, and the ChatGPT application responses will be called “assistant” responses.

• The very first assistant response. This is also one of our first pain points when we talk about automation. The responses can be either ASCII (when the assistant responds just with text), or either UTF-8 or UTF-16 (when the assistant adds non-ASCII characters, like emojis, for example). Please refer to Figure 4 as an example, where the response was encoded in UTF-16. Note that assistant responses contain message ID, we will revisit this behavior later.

Conversation title

Let’s look at the WAL log offset 3915, where the application recorded the very first occurrence of the conversation title:

• We can see the previously observed fields, including conversation ID, timestamp, first user prompt, and first assistant response. Generally speaking, within the WAL log there will be many duplicative entries for the messages, so I added deduplication logic to my script.

• However, now the “title” field is not empty and shows the actual title of the conversation. The regex we can use here is “(?<=\x05title"\)(.*?)(?=\x0aisArchivedF")”, thus we avoid situations when the word “title” could appear within either user’s or assistant’s messages.

Follow-up user prompts

The non-initial prompts that were entered by the user, have similar structure as initial prompt:

• The prompts start with “nextPrompt” followed by the message that ends with “{“. However, unlike the initial message that has “root-” prefix, the follow-up messages would contain an ID prefix in GUID format.

• In some cases, there will be a numeric indicator between the GUID and the message (please refer to Figure 6).

• The follow-up prompts can be captured with the following regex: “(?<!root-)nextPrompt"\x04text"([^{]+)(?={)”.

• Note the GUID ID pattern prior to the messages! We’ll revisit this later.

Follow-up assistant responses

The non-initial assistant responses also have a similar pattern to the initial response:

• The messages start with “request-WEB” followed by GUID ID. Assistant messages can sometimes be encoded with UTF-16, UTF-8, or have extra hex characters. I had to create a list of regex patterns that I observed through my tests. This may result in situations when assistant responses would not be properly captured by my script.

• In some cases, there will be a numeric indicator that shows the position of response (please refer to Figure 7).

• Again note the GUID ID pattern here too!

Conversation thread ID

Remember those GUIDs we saw in the “Follow-up user prompts“ and “Follow-up assistant responses“ sections above?

The conversation thread ID is a theoretical term that I came up with. Thread IDs can be used by ChatGPT desktop application to keep track of various conversation threads within the parent conversation. Please refer to Figure 8 for the complete set of messages shared between the user and assistant, showing conversation thread IDs.

I did another test where I changed the topic in the middle of our conversation with ChatGPT. Please refer to Figure 9, where you can see how the conversation thread ID changes when ChatGPT determines the user changing the topic.

Proof-of-concept code

I wrote a PoC script designed to parse and analyze LevelDB WAL file generated by the ChatGPT application. The script will extract conversations, reconstructing the chat history and metadata, including time stamps. The script is leveraging “leveldbutil” application to dump the WAL contents. With that said, you should install “leveldbutil” application in order for the script to work.

The script leverages a series of regex patterns to extract conversation components, user/assistant messages, timestamps, and other metadata by matching specific byte patterns in the WAL entries. The script maintains message ordering and prevents duplicates by tracking message positions and using a deduplication mechanism with normalized message content.

WAL log is complex and may encode data in ASCII, UTF-8, and UTF-16, depending on the chat contents, in addition to that, the format of messages may change and have special characters. The parsed data is organized into a structured format, with each conversation containing a title, user ID, timestamp, and a chronological sequence of messages. The output can be dumped into the “conversations.json” file.

Please note the script is still a PoC and work-in-progress, it will require additional improvements and enhancements. One of the potential improvements is leveraging conversation thread IDs for reconstructing and orderin.

References

• The theme for this post was inspired by David Cowen’s Sunday Funday challenge! Join the cult and submit your posts too! (https://www.hecfblog.com/2025/01/daily-blog-730-sunday-funday-12625.html)

• “Hang on! That’s not SQLite! Chrome, Electron and LevelDB” by Alex Caithness (https://www.cclsolutionsgroup.com/post/hang-on-thats-not-sqlite-chrome-electron-and-leveldb)

• “LevelDB” by Ju Chen (https://chenju2k6.github.io/blog/2018/11/leveldb)

Tools used

• chat_gpt_wal_parser (https://github.com/ilyakobzar/dfir-tools/blob/main/chat_gpt_wal_parser.py)

• leveldbutil (https://github.com/google/leveldb)

• X-Ways Forensics (https://www.x-ways.net/forensics/index-m.html)

Two primary partitioning schemes that are most commonly used by operating systems are Master Boot Record (MBR) and GUID Partition Table (GPT). MBR is a legacy scheme that supports up to 4 partitions per disk with a storage limit of 8TB. GPT is a modern scheme that supports up to 128 partitions, with maximum theoretical storage limitation of 9.4 ZB (9.4 billion TB).

This blog post will be specifically focusing on automated analysis of MBR, which is located at the sector 0 of a physical storage device.

MBR has a length of 512 bytes and has the following structure:

• Bytes 0-445: bootstrap code

• Bytes 446-461: partition table entry 1

• Bytes 462-477: partition table entry 2

• Bytes 478-493: partition table entry 3

• Bytes 494-509: partition table entry 4

• Bytes 510-511: MBR signature (0x55AA)

Each of the 4 partitions defined in MBR has a dedicated table with the length of 15 bytes:

• Byte 0: Bootable flag

• Bytes 1-3: Starting Cylinder-Head-Sector (CHS) address (legacy system, that specifies physical location of the partition on the disk; CHS maps to the disk's physical geometry, where the cylinder represents concentric tracks on the disk platter, the head indicates which disk surface to read from, and the sector specifies the exact segment within that track)

• Bytes 4-4: Partition type

• Bytes 5-7: Ending CHS address

• Bytes 8-11: Starting Logical Block Addressing address (a.k.a. LBA, indicates the first logical sector of the partition)

• Bytes 12-15: Size in sectors

MBR can be targeted by sophisticated malware in several ways. Malicious boot loaders and rootkits can infect the bootstrap code to maintain persistence. Destructive malware like WhisperGate, HermeticWiper can modify the MBR to prevent system boot. I wrote a tool for MBR analysis that performs the following actions:

• Exports MBR

• Parses partition tables

• Hashes both, full MBR, and the bootstrap code section

• Disassembles the bootstrap code, assuming it is written in 16-bit x86 assembly, and adds explanatory comments to clarify some basic code's functionality

The tool (link) can be used for triage and can extract MBR from either system partition or mounted disk image. See example analysis report output on the screenshot below. Try it out and let me know how it works!

References

• Windows support for hard disks that are larger than 2 TB (https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/support-for-hard-disks-exceeding-2-tb)

• File System Forensic Analysis (Fourteenth Printing), by Brian Carrier (https://www.sans.org/profiles/brian-carrier/)

Tools used

• X-Ways Forensics (https://www.x-ways.net/forensics/index-m.html)

• MBR parser (https://github.com/ilyakobzar/dfir-tools/blob/main/mbr_parser.py)

Background

SRUM stands for System Resource Usage Monitor, a technology introduced in Windows 8 and Windows Server 2019 to track the utilization of various system resources such as CPU usage, network activity, and battery consumption. SRUM data is stored in an ESE database located at “%SYSTEMROOT%\System32\sru\SRUDB.dat”.

This post was inspired by the Sunday Funday challenge from my friend and mentor David Cowen. In this post, I will be performing a behavioral analysis of Windows operating system activity recorded in SRUM for the following use cases:

• Uploading data to an online service of your choice.

• Wiping files.

• Copying data between two drives using copy and paste.

Assumptions and limitations

• Lab virtual machine was set up in Parallels Desktop.

• An external USB drive was plugged into the host operating system and attached to the virtual machine as a physical drive.

• Lab virtual machine operating system specifications: Windows 10 Pro, version 21H2, OS build “19044.1766”.

• SRUM database will not be updated with the new data immediately after the process execution. SRUM temporarily stores its records in the SOFTWARE registry hive, which are then written to the actual "SRUDB.dat" database at predefined time intervals. To ensure data was written to the database, I shut down and rebooted the VM after each experiment.

Summary of findings

SRUM database can be useful during forensic investigations, however, if approached without proper testing, analysts may produce misleading and even inaccurate results. Here is a summary of findings (applicable with the limitations outlined above) concerning the 3 use cases mentioned in the Background:

• SRUM can give the most useful insights when you investigate network data transfer. Specifically, bytes sent/received accurately represent the amount of data transferred from the local system. SRUM will also show user SID who launched the process. However, time stamps are not reliable and have a margin of error of approximately 1 hour, which is the case for all SRUM records.

• SRUM would not help investigate wiping operations, especially on relatively small files. Even for major wiping activity, SRUM does not provide valuable evidence that would help to determine the size of wiped data. However, similarly with other operations, SRUM can show the user SID that launched the process.

• SRUM would not help investigate data transfer using Windows Explorer's “copy” and “paste” operation between two physical drives - at least for files with relatively small sizes of ~200Mb.

Writing this blog post has once again reminded me of the ease with which one can accidentally draw misleading conclusions without proper testing and validation.

Detailed analysis

This section outlines the detailed analysis for each of the three scenarios covered in the background and summary of findings sections of this post.

Uploading data to MEGAsync

Time stamps were manually recorded during the experiment with the test file “TEST_FILE_megasync.zip”, size approximately 228 MB:

• “2025-01-13T21:30:00Z” - installed and launched MEGAsync app.

• “2025-01-13T21:34:43Z” - started file upload via “megasync.exe”.

• “2025-01-13T21:36:12Z” - the file was successfully uploaded.

For this analysis, I used the “Network Data Usage” SRUM table with ID “973F5D5C-1D90-4944-BE8E-24B94231A174”.

The below figure shows that there were 2 SRUM records recorded for binary “megasync.exe” with time stamps “2025-01-13T21:36:00Z” and “2025-01-13T21:42:00Z”, with total data transferred 243,057,369 bytes (231.8MB). The test file used in the experiments had a size of 240,070,132 bytes (228.9 MB), which corresponds with the amount of transferred data. In addition to that, the field “UserSid” records the SID (“S-1-5-21-3008292710-2223882278-1454273465-1001” belongs to my user account) of the user who launched the process, which can be valuable during investigations.

However, there were several issues with how the data was recorded in the SRUM database, which may mislead analysts:

• Time stamps recorded within the field “TimeStamp” for the “Network Data Usage” table do not reflect the accurate time of the tested file upload operation. SRUM records are written in batches (every 1 hour, or at system shutdown), and therefore time stamps do not accurately represent when a process was executed:

  • As of “2025-01-13T21:36:00Z” (SRUMid “1589”), the file upload was already completed. However the bytes transferred for that record only show 112,225,071 bytes transferred, which is approximately half of the transferred data.

  • If we zoom out to see neighboring events (see the below screenshot), we can see there were many different events not connected to each other that were recorded with the same time stamps.

• Some of the records in the table do not have any information regarding the application or corresponding user, however do have a significant amount of data transferred (refer to the SRUMid record 1595 on the screenshot below).

To conclude the analysis, SRUM can be partially effective when investigating network data transfer, especially if a threat actor utilized an application that was uncommon for the operating system usage (e.g. a malware executable, or data transfer application like MEGAsync or rclone). In addition to that, user SID recorded in SRUM can help determining who launched the process. However, we cannot rely on time stamps recorded in the database, and keep in mind that SRUM record timestamps have a margin of error of approximately 1 hour.

Wiping files - Python script and CCleaner

Time stamps were manually recorded during the experiment with the test file “TEST_FILE_wiped.zip”, size approximately 228 MB:

• “2025-01-13T21:40:50“ - executed a Python script (link) designed to securely wipe a file. The script was launched using Python from Windows Command Prompt (please refer to parent-child process relationships on the screenshot below). I set the script to execute 5 passes, using the following patterns:

  • Pass 1 and 4: b'\x00'.

  • Pass 2 and 5: b'\xff'.

  • Pass 3: random string of bytes.

For this analysis, I used the “Application Resource Usage” SRUM table with ID “D10CA2FE-6FCF-4F6D-848E-B2E99266FA89”.

There was only one record in the SRUM database that was written after the wiper execution, and that record was for “cmd.exe”, and not for “python.exe”, as we would expect. Number of bytes written and read do not accurately represent the 5 passes of the wiping operation that was performed on the test file.

Due to insufficient evidence, I decided to change the approach and utilize CCleaner application, and wipe open space of my VM’s volume C: (9,635,389,440 bytes or 8.97 Gb).

Here are the time stamps I recorded during the CCleaner experiment:

• “2025-01-15T02:04:45Z“ - installed CCleaner.

• “2025-01-15T02:18:03Z“ - launched CCleaner program.

• “2025-01-15T02:26:15Z“ - started wiping of the C: volume free space.

• “2025-01-15T02:31:55Z” - finished wiping.

CCleaner performed the empty space wiping with 1 pass. For this analysis, I used the “Application Resource Usage” SRUM table with ID “D10CA2FE-6FCF-4F6D-848E-B2E99266FA89”:

• The timestamp was again not reliable and does not show accurate execution time.

• There were 84,585,984 bytes (80.7 MB) read and 76,390,400 bytes (72.9 MB) written, which clearly does not correlate with the amount of empty space wiped (9,635,389,440 bytes or 8.97 Gb).

• Comparing the number of write operations performed by CCleaner with other programs, we can see, for example, “ccsetup631.exe” (CCleaner installer) had more write operations than the actual process that wiped the volume (“CCleaner64.exe“). “TrustedInstaller.exe” and “WmiPrvSE.exe” had a similar number of write operations as CCleaner.

• However, the process “CCleaner64.exe” was executed by the user account with SID “S-1-5-21-3008292710-2223882278-1454273465-1001”, and that can be valuable during investigations.

To conclude the analysis, SRUM does not accurately represent the amount of bytes written during the wiping operation, and therefore cannot be used to estimate the amount of wiped data. In addition to that, the number of write operations may also be inconclusive and potentially misleading. However user SID recorded in SRUM can help determining who launched the process.

Copying data between two drives

Time stamps were manually recorded during the experiment with the test file “TEST_FILE_hdd_transfer.zip”, size approximately 228 MB:

• “2025-01-13T22:01:27Z” - USB drive was attached to lab VM.

• “2025-01-13T22:02:30Z“ - started file transfer from C:\ (NTFS) into E:\ (FAT32).

• “2025-01-13T22:03:25Z” - finished file transfer from C:\ (NTFS) into E:\ (FAT32).

Copy operation was performed by Windows Explorer “copy” (CTRL+C) and “paste” (CTRL+V) operation.

For this analysis, I used the “Application Resource Usage” SRUM table with ID “D10CA2FE-6FCF-4F6D-848E-B2E99266FA89”.

File copy operations on Windows are performed by the process “explorer.exe”. The process acts as both a file browser and an interface that provides user experience within the Windows operating system (Desktop, Start Menu, Taskbar, Control Panel, etc).

Given the nature of the process, we can immediately conclude that file read and write operations are constantly performed by “explorer.exe”, as part of the Windows OS operation. It would be complicated to distinguish between the specific file copy unless the size of that file was large relative to other read and writes operations made by “explorer.exe” on disk.

With that said, here are the results of the SRUM analysis performed after the experiment:

• The time stamps recorded within the field “TimeStamp” for the “Application Resource Usage” table do not reflect the accurate time of the tested file copy and paste operation. This is expected since “explorer.exe” had been running since I logged in to the lab operating system.

• Two SRUM records were written to the database after the file transfer operation started, as shown in the screenshot below, highlighted in yellow. If you compare the records logged earlier that day with those recorded after the file copy operation, you will see that neither the bytes read/written nor the read/write operations show any anomalies. This could be because the test file had a relatively small size (228 MB).

• The sum of bytes read recorded in the SRUM database record after the copy operation has started (yellow rows) is 107,814,168 bytes (102.8 MB), which is half of the size of the transferred file. The sum of bytes written was 4,427,776 bytes (4.2 MB), which is significantly lower to the transferred file size.

To conclude the analysis, I do not think SRUM database can be effectively utilized when dealing with investigations involving data transfer between disk volumes using Windows Explorer.

References

• Microsoft security - guide for incident responders (https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/IR-Guidebook-Final.pdf)

• Forensic implications of System Resource Usage Monitor (SRUM) data in Windows 8 by Yogesh Khatri (https://www.sciencedirect.com/science/article/abs/pii/S1742287615000031)

• Digging Into The System Resource Usage Monitor (SRUM) by Mike Cohen (https://docs.velociraptor.app/blog/2019/2019-12-31_digging-into-the-system-resource-usage-monitor-srum-afbadb1a375/)

Tools used

• CCleaner (https://www.ccleaner.com/ccleaner/download)

• ESEDatabaseView v1.76 (https://www.nirsoft.net/utils/ese_database_view.html)

• FTK Imager v4.7.3.81 (https://www.exterro.com/ftk-product-downloads/ftk-imager-4-7-3-81)

• SRUM-DUMP by Mark Baggett (https://github.com/MarkBaggett/srum-dump)

• Velociraptor (https://docs.velociraptor.app/downloads)

In this post I will be talking about feature pack updates for Windows 10 operating system and how they affect computer forensic examinations. First part covers USB forensic artifacts affected by the update.

Feature updates for Windows 10 are released by Microsoft twice a year and can be considered major updates since they include new functionality, enhancements, visualization updates and many more. Each feature update for Windows 10 has a unique version number that corresponds with month and year of planned release (for example, version 1909 had a planned release date September 2019).

From the forensic standpoint I can define three states of a system that undergoes feature update:

• Pre-update – original system that had the old Windows 10.

• Initial post-update – system that just underwent update with the new feature pack. After the update operating system keeps a snapshot of its original state under “C:\Windows.old\” directory. With this feature Microsoft gives users a chance to revert back to previous version of Windows 10 in case the new configuration and settings were not compatible with the applications used prior to the update. From the forensic standpoint contents of “C:\Windows.old\” would preserve all original operating system artifacts required to perform forensic examination. Referring to USB analysis those artifacts would include HKCU, HKLM\SYSTEM, HKLM\SOFTWARE, setupapi.dev.log, event logs.

• Post-update – system that cleared all temporary files created during the update, and therefore fully transitioned to the new feature version. The cleanup process can either be triggered by operating system 10 days after the update, or can be manually started by user in Windows 10 storage settings. The process would apply several changes to the system, including removing “C:\Windows.old\” directory.

One way to determine the system underwent a feature update is to find a subkey under “HKLM\SYSTEM\Setup” registry key, that would have a format “Source OS (Updated on MM/DD/YYYY HH:MM:SS)”, where “MM/DD/YYYY HH:MM:SS” is the date and time of the feature update.

Assumptions and limitations

• Experiments were performed on Windows 10 feature pack versions 1809 and 1903 (plus version 2004 in the bonus content at the end of this post). It is possible other feature update versions may behave slightly differently.

• The experiments were focused on artifacts that could reveal time stamp information of when USB drives were plugged in to the system (first / last connected, last disconnected and historical connection events), and were not focused on other artifacts, such as for example correlation between device serial number (S/N) and volume names / labels, drive letters for mapped volumes, volume S/N and users interacted with the USB device. 

• Analysis of “initial post-update” (as defined in the background section of this post) was not performed, because “C:\Windows.old\” directory maintained a copy of all artifacts of the operating system prior to the update.

Summary of findings

Experiments showed Windows 10 feature update significantly impacted event logs, registries and other operating system artifacts required for forensic analysis of USB devices that were plugged in to the system prior to the update.

Initial feature pack update cleared majority of the operating system artifacts necessary to perform forensic analysis.

After the update Windows 10 created a new registry key “HKLM\SYSTEM\Setup\Upgrade\”, which will be useful for forensic examinations. Specifically, last disconnect time stamps for USB drives plugged in prior to the update can be determined based on value in “LastPresentDate” for several subkeys under: “HKLM\SYSTEM\Setup\Upgrade\Pnp\CurrentControlSet\Control\DeviceMigration\Devices\”.

Additional tests revealed if there were two feature pack updates installed, it would not be possible to determine time stamps associated with USB devices connected to the system prior to the first update. Only minimal artifacts would remain in registry that in best-case scenario would allow to determine the fact of USB device plugged in to the system at some point.

Detailed analysis

In order to demonstrate how forensic artifacts were altered by the update, I will compare “pre-update” and “post-update” states of the Windows 10 operating system, as defined in the background section of this post.

To begin with, I will show the results of forensic analysis for a system that was updated from Windows 10 version 1809 to version 1903. For the demonstration I used USB drive with device S/N 070A8314CE182019 that was attached to pre-update system on 9/3/2021 at approximately 14:49 local time / 18:49 UTC. Update to version 1903 was started on 9/3/2021 at approximately 15:33 local time / 19:33 UTC.

For each artifact described I will be providing screenshots showing before (pre-update) and after (post-update) states.

• Before the update “Setupapi.dev.log” contained a record of drivers installation for USB drive S/N 070A8314CE182019. The installation started on 9/3/2021 at approximately 14:49:51 local time. After the update “Setupapi.dev.log” was re-created with the first record dated as of 9/3/2021 15:46:25 local time.

• “HKLM\SYSTEM\ControlSet001\Enum\USBSTOR” registry key was removed after the update.

• “HKLM\SYSTEM\ControlSet001\Enum\USB\VID_13FE&PID_5500\%S/N%” – record for USB drive S/N 070A8314CE182019 was removed after the update.

• “HKLM\SYSTEM\ControlSet001\Enum\STORAGE\Volume\%S/N%” – record for USB drive S/N 070A8314CE182019 was removed after the update.

• “HKLM\SYSTEM\ControlSet001\Enum\SWD\WPDBUSENUM\%S/N%” – registry key WPDBUSENUM (portable device enumerator service) containing record of USB drive S/N 070A8314CE182019 was removed after the update.

• “HKLM\SYSTEM\ControlSet001\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}\%S/N%” – showed storage device drivers installed for USB drive S/N 070A8314CE182019. After the update this key was removed.

• “System.evtx” event ID 20001 showed drivers were installed for USB drive S/N 070A8314CE182019 at approximately 14:49:54 local time. After the update event log “System.evtx” was cleared and the earliest record was at approximately 15:45:01 local time.

• “Microsoft-Windows-Kernel-PnP%4Configuration.evtx” series of event IDs 400, 410, 430 referenced drivers installation for USB drive S/N 070A8314CE182019. After the update event log “Microsoft-Windows-Kernel-PnP%4Configuration.evtx” was cleared and the earliest record was at approximately 15:45:01 local time.

• “Microsoft-Windows-Partition%4Diagnostic.evtx”, event ID 1006 showed a record for USB drive S/N 070A8314CE182019 at approximately 14:49:51 local time. After the update the event log “Microsoft-Windows-Partition%4Diagnostic.evtx” was cleared and the earliest record was at approximately 15:45:07 local time.

• “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\” registry key contained volume GUID {50404ddb-0ce7-11ec-b752-000c29fb8cf1} that can be cross-correlated to USB drive S/N 070A8314CE182019. After the update the volume GUID entry was removed.

Based on the experiment results, majority of the operating system artifacts containing evidence of USB devices plugged in to the system were cleared after the update. In the next section I am going to show few artifacts that did not exist before the update and could still contain some information regarding historical USB devices plugged in to the system prior to the update.

• “Setupapi.upgrade.log” log file was created after the update.  In my tests this log contained PnP drivers migration records for the previously initiated USB drives (including USB drive S/N 070A8314CE182019).  

• “HKLM\SYSTEM\Setup\Upgrade\” registry key was created after the update. The following subkeys would be of interest for USB forensics, and in our case will have records for the USB drive that was plugged in prior to the update: “Pnp\CurrentControlSet\Control\DeviceMigration\Devices\SWD\WPDBUSENUM\%S/N%”, “Pnp\CurrentControlSet\Control\DeviceMigration\Devices\USB\%S/N%”, “Pnp\CurrentControlSet\Control\DeviceMigration\Devices\USBSTOR\%S/N%”. As you can notice, “last write” time stamp was updated after the system update, and therefore cannot be relied on during forensic examinations. Value under “LastPresentDate” in the above subkeys could reveal the last time a drive was disconnected from the system.

Bonus content!

Now the question is – would any evidence of the USB drive remain if we perform another update? For these purposes on the newly updated system (version 1903) I installed additional feature update (version 2004). The “HKLM\SYSTEM\Setup\” registry key showed installation for second feature update was started on 9/6/2021 at approximately 16:41:40 local time:

Similar to previous experiments temporary installation files were cleared after the update via Windows 10 storage settings. I compared state of pre-install (version 1903) to post-install (version 2004). The experiment showed that after second update it will not be possible to determine when USB drive in question (S/N 070A8314CE182019) was plugged in. However, we would still be able to determine the fact that USB drive was plugged in at some point – based on registry key value in “HKLM\SYSTEM\MountedDevices\”

References

• Windows 10 versions history (https://docs.microsoft.com/en-us/windows/release-health/release-information)

• Microsoft updates terminology (https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/standard-terminology-software-updates)

Tools used

• Registry Explorer/RECmd (https://ericzimmerman.github.io/#!index.md)

• USB Detective (https://usbdetective.com)