The System Resource Usage Monitor (SRUM) is a favourite of mine, as the data that is recorded in it can tell you a story about what was happening on a machine during a particular time of interest.
The purpose of this post isn’t to dive into the technical aspects of the SRUM as there are plenty of great posts that do that. I wanted to simply show how particular activity such as a bulk download from a network share or upload to a cloud storage site would be reflected in the SRUM records.
I first learnt about SRUM while listening to DFIR extraordinaire, Yogesh Khatri, on the ‘Forensic Lunch’ podcast with David Cowen & Matthew Sayer. Yogesh released a paper, “Forensic implications of System Resource Usage Monitor (SRUM) data in Windows 8”, that paper outlined the ins and outs of the SRUM. From that point on, various tools have been developed to read in the SRUM data and parse the results as neatly formatted csv files.
SRUM was first introduced in Microsoft Windows 8 systems. It is enabled by default in Windows and collects various data running on a machine in blocks of ~1 hour. At a high level the data collected includes:
- App Push Notification
- Energy Usage
- Network Activity
- Processes Run
The collected data is initially sent to a key in the SOFTWARE hive temporarily before being written to SRUDB.dat at ‘C:\Windows\System32\SRU\SRUDB.dat’. The SRUDB.dat is an Extensible Storage Engine (ESE) database which we have seen before on Windows machines, most commonly in the Windows Search database.
When you open ‘Task Manager’, and click on the ‘App History’ tab, the data listed there is being pulled from the SRUM. The message indicates that 30 days of resource usage is available for the current user.
The beauty of the SRUM is that even if an application is deleted, uninstalled or executed from a portable hard drive, those records will be recorded.
On the ‘Details’ tab there is additional data that you can see through the ‘Task Manager’ UI relating to CPU time and bytes that have been read and written for each of the running processes.
Parsing the SRUM database
To parse the SRUM database, we need a copy of the SRUM which is located in ‘c:\windows\system32\sru\srudb.dat’ and also a copy of the SOFTWARE registry hive.
We have an enterprise licence for Eric Zimmerman’s KAPE tool which automates the entire process of grabbing a copy of the SRUDB.dat and parsing the data in a matter of seconds, it is fantastic. You can also obtain a free copy of KAPE for non-commercial purposes here – https://www.kroll.com/en/services/cyber-risk/incident-response-litigation-support/kroll-artifact-parser-extractor-kape
Without KAPE, you can still use Eric’s ‘SrumECmd’ command line tool which is the backend program for that particular KAPE module. Get SrumECmd here – https://github.com/EricZimmerman/Srum.
Note: If you are working with a SRUDB.dat that has been copied from a live machine, it is likely to be in a ‘Dirty State’. Eric’s readme for ‘SrumECmd’ steps through the process of repairing the SRUDB.dat.
With your SOFTWARE hive and SRUDB.dat copied to the same directory, use the ‘-d’ switch, and output the results to csv files using ‘SrumECmd.exe’.
The results will be saved into CSV files in your output folder.
Testing & Results
I replicated typical actions taken by a user such as copying data from a network share onto the machine and uploading data from the machine to cloud storage via an internet browser. To see if we can identify those actions, we need to take a closer look at the ‘NetworkUsages_Output.csv’ report.
In the screenshot above we can see some key columns in the report:
- Timestamp: Recorded in UTC, time the activity was recorded not necessarily when the activity took place.
- Executable Information: Path of the executable responsible for the data transfer.
- SID & Username: User account.
- Bytes Received: Data in bytes received across the network by the device.
- Bytes Sent: Data in bytes sent across the network by the device.
- Interface Type: Wired [CSMACD] or Wireless [IEEE80211]
I noted the date and time I transferred data so I could easily identify any corresponding records in the reports. The entries below detail what action I took and what the records looked like in the NetworkUsages_Output.csv’ report.
Activity 1 – On 10 September 2021 – Uploaded 4.7 GB file to a Dropbox account by copying the data into the Dropbox sync folder setup on the local machine.
We can see here that dropbox.exe sent 5020212461 bytes (5.02 GB) over the ethernet connection.
Activity 2 – On 14 September 2021 – Uploaded 4.5 GB to OneDrive using the Microsoft Edge browser.
We can see here that msedge.exe (Microsoft Edge) sent 6353738389 bytes (6.35 GB) over the ethernet connection.
I am not sure why there is such a discrepancy between the size of the files uploaded and the bytes uploaded here as no other data was uploaded to OneDrive during my testing. OneDrive can be choppy when uploading via a browser so perhaps this is as a result of certain files being restarted if it hit an issue during the uploading process.
Activity 3 – On 29 September 2021 – Copied ~70GB of data from a network share to the local machine.
We can see here that explorer.exe (Windows Explorer) received 83918261697 bytes (83.9 GB) over the ethernet connection.
Activity 4 – On 29 September 2021 – Uploaded 3GB to Google Drive using the Microsoft Edge browser.
We can see here that msedge.exe (Microsoft Edge) sent 3213419462 bytes (3.2 GB) over the ethernet connection.
The chart below is generated by using the records from the Timestamp, BytesReceived and BytesSent columns across the entirety of the data set. Using Excel you can create a simple pivot chart and then generate a graph/chart of your liking.
You can see the large red spike relates to ‘Activity 3’ where ~84GB of data came across the wire onto the machine. A large blue spike would also be cause for concern in most scenarios be it data exfil by an attacker or insider threat.
The Wrap
The SRUM is an invaluable piece to any investigation puzzle. You would be wise to validate, verify and build on these records by looking at other user activity such as internet browsing records, userassist, file access, USB device history and registry artefacts.
Keep in mind, there are only 30-60 days of data retained in the SRUM database. As an example, there are 30 days of records for the application information and 60 days for network usage records. That may seem like a lot of time, but when it comes time to investigate, the clock may have been ticking for weeks and you will want to preserve this data quickly.
-BM
Digital Forensics 