Behavioral analysis of user file operations with SRUM
Unveiling forensic insights and pitfalls of SRUM data
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)