A common task within Incident Response and Digital Forensics (DFIR) is to identify any evidence of execution of something. That evidence helps to paint a story as to what took place on the machine and possibly highlight other pertinent things that may be unknown. Most commonly, this evidence can be derived from an array of locations on the system. Given this fact, malicious actors seek to remove the artifacts of their actions. One of the areas that is overlooked by malicious actors but is a goldmine for DFIR professionals is the System Resource Usage Monitor (SRUM) database that was first introduced in Windows 8.
The SRUM database collects statistics on several things to include network connectivity, network data usage, and application usage. For each of the statistics that are collected, they each can serve a vital role in understanding what an actor may have done, although that wasn’t the purpose of the database.
The database resides in [SystemRoot]\System32\SRU\srudb.dat (Figure 1) and is locked upon the operating system loading. As actions take place that renders the database needing to be updated, those artifacts are stored in the Registry for some time before the database gets updated. Generally speaking, the database is updated at least once an hour. There are Dynamic Link Libraries (DLLs) that are responsible for monitoring and collecting data (Figure 2). The database is in an Extensible Storage Format (ESE), which is a special format that is proprietary to Microsoft and resembles SQL.
Reading the database requires a capability and a few certainly exist. In an effort to use a language that is incorporated in modern Windows operating systems, I wrote a capability, called Invoke-SRUMDump.ps1, in pure PowerShell/ .NET and can be found at https://github.com/WiredPulse/Invoke-SRUMDump. The capability allows a user to retrieve the tables from the database and export them to CSVs for further analysis. This could be done on a live machine or against a SRUM database that was retrieved from another machine.
If the live option is selected, the capability will make a copy of the srudb.dat on the system to retrieve the tables from and query the Registry for any wireless profiles. If the offline option is selected, you will need to supply the path to a saved srudb.dat and a Software hive. In either option, the capability will create a folder on the user’s desktop labeled “srum-[date]” and store the CSVs there (Figure 3).
As previously stated, the data gleaned from this database is enormous. As an example, the Network Connectivity table will highlight what networks the system was connected to, the SSID (if wireless), the amount of time the system was connected, the User’s SID, and the Application (Figure 4).
We’ve only scratched the surface on what the database can provide. In the end, its purpose isn’t for forensics, however, it has become a vital dataset.