Windows SRUM Forensics

Windows SRUM Forensics: Tracking Execution, Network Activity, and Resource Usage

7 min readMay 18, 2026

Section 1: What Is SRUM and Why It Matters

This section introduces the System Resource Usage Monitor, where it came from, and why investigators should know it exists.

The System Resource Usage Monitor (SRUM) was introduced in Windows 8. Despite its forensic value, it is absent from most forensics books and overlooked in most online material. Microsoft built it to track system resource consumption for operational purposes, not for forensic use. That distinction does not reduce its investigative value.

What it tracks:

CPU cycles per application
Network bytes sent and received per process
Power and energy consumption
Push notification activity
Network interface and SSID associated with execution events

Why it matters: SRUM allows you to correlate process execution with network activity, specific user accounts, and wireless network profiles. On a real system, this produces a detailed picture of user and application behavior that is difficult to fully erase.

A limited view of SRUM data is visible to the end user via Task Manager under the App History tab. The forensically useful data lives in the backend database and is not surfaced through any standard Windows UI.

Section 2: Artifact Location and Database Format

This section covers where SRUM stores its data and what format it uses.

The SRUM database is located at:

%SystemRoot%\System32\SRU\SRUDB.dat

On a standard Windows installation this resolves to:

C:\Windows\System32\SRU\SRUDB.dat

The database uses the Extensible Storage Engine (ESE) format, also called JetBlue. This is the same format used by Microsoft Exchange, Active Directory, and Windows Search. Investigators familiar with those artifacts will recognize it immediately.

The SRUM database is not written to continuously. It is updated once per hour or on system shutdown. Between writes, data is temporarily staged in the Windows Registry at:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions

What it tracks: The registry staging location. Why it matters: If the system was shut down abnormally, or if you are working close to an event in time, the ESE database on disk may not reflect the most recent activity. Always check both locations.

Timestamps in the registry are stored in UTC using 64-bit FILETIME format. Use a timestamp decoder utility such as decode to convert them to a human-readable format.

Section 3: Acquiring the SRUDB.dat File from a Live System

This section covers why direct file copy fails and two reliable methods to acquire the database from a live system.

The SRUM database is locked by the operating system while Windows is running. Attempting to copy it directly via Windows Explorer or the command line produces a file-in-use error. Two acquisition methods work around this.

3.1 Method 1 — FTK Imager

FTK Imager can access locked files by reading directly from the raw volume rather than through the file system API.

Steps:

Open FTK Imager
Go to File > Add Evidence Item
Select Logical Drive and choose the C: drive
Navigate to C:\Windows\System32\SRU\
Right-click SRUDB.dat and select Export Files
Save to your working directory

Why it matters: This method works on a live system without requiring a full disk image and without disturbing the running OS.

3.2 Method 2 — Volume Shadow Copy

If Volume Shadow Copies exist on the target system, you can access a prior version of the database. This is useful when the current database has been partially or fully cleared.

Open an administrative command prompt. Non-administrative prompts will fail with a permissions error.

List available shadow copies:

vssadmin list shadows

Copy the Shadow Copy Volume path from the output. Then create a symbolic directory link on the desktop, replacing the path below with the one from your output:

mklink /d srum \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\

The trailing backslash is required. Omitting it causes an “incorrect parameter” error and the link will not be accessible.

Navigate through the symlink:

cd srum
cd Windows\System32\SRU\
copy SRUDB.dat C:\Users\<user>\Desktop\SRUDB2.dat

Why it matters: Shadow copies may contain SRUM data from days or weeks prior. If an attacker cleared or replaced the live database, older copies can preserve evidence of earlier activity.

Section 4: Parsing SRUDB.dat with SRUM-DUMP

This section covers available parsing tools, how to run SRUM-DUMP, and what the output contains.

4.1 Tool Options

Several tools can parse the SRUM ESE database. The two most common:

Get Honeyknows’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Tool Cost Notes SRUM-DUMP Free Python script + standalone .exe, outputs Excel, no Python install required EnCase (SRUM inscript) EnCase is paid, inscript is free Requires the commercial EnCase platform

SRUM-DUMP is the recommended option for most investigators. It was written by Mark Baggett, SANS SEC573 Lead Author, and is available as both a Python script and a compiled standalone executable.

4.2 Running SRUM-DUMP

SRUM-DUMP produces an Excel spreadsheet containing all parsed forensic data from the SRUM database.

Before running, review the usage parameters:

srum_dump.exe -el

Basic usage:

srum_dump.exe -i SRUDB.dat -o outfile.xlsx -t srum_template.xlsx

To include wireless network profile names (SSIDs) in the output, supply the SOFTWARE registry hive:

srum_dump.exe -i SRUDB.dat -o outfile.xlsx -t srum_template.xlsx -r SOFTWARE

Two templates are included with the tool. Use either as a starting point. The template controls which data is extracted and how columns are formatted.

If you prefer not to use the command line, double-clicking srum_dump.exe launches an interactive mode that prompts for each required value.

Section 5: Reading the Output Spreadsheet

This section describes each sheet in the SRUM-DUMP output and what forensic value it provides.

The output Excel file contains the following sheets:

Sheet What It Contains Network Usage Process name, user SID, interface, SSID, bytes sent, bytes received, total bytes Application Resource Usage Executable name, user SID, CPU time, foreground time Network Connections Connection-level detail per interface Push Notification Data Application push notification activity Energy Usage Power state and consumption per application Energy Usage (Long Term) Extended power history

5.1 Network Usage Sheet

This is the highest-value sheet for most investigations.

What it tracks: Which process transferred data, which user account ran it, which network interface and SSID were active, and exactly how many bytes moved in each direction.

Why it matters: If you are investigating data exfiltration, this sheet can show a specific executable transferring a specific byte count while connected to a specific wireless network. The example used in the referenced presentation shows nc.exe (Netcat) with bytes sent and received, tied to a SID and SSID. That is a complete picture of a data transfer event.

5.2 Application Resource Usage Sheet

What it tracks: Executables run on the system, user SIDs, CPU time consumed, and foreground activity time.

Why it matters: This sheet confirms execution of specific tools even if prefetch or other execution artifacts have been wiped. CPU time and foreground time together indicate whether an application was actively used or ran silently in the background.

5.3 Resolving SIDs to Usernames

SRUM stores user identity as a SID. To resolve a SID to a username on the live system:

wmic useraccount get name,sid

Standard SID RIDs:

500 = Built-in Administrator
501 = Guest
1001 and above = Standard user accounts

Section 6: Forensic Summary

This section consolidates what SRUM provides and where it fits in a broader Windows investigation.

SRUM is a high-value artifact for the following investigative scenarios:

Data exfiltration investigations: Correlate process execution with byte transfer volumes and network identity
User activity reconstruction: Determine which applications a specific user ran, for how long, and when
Malware triage: Identify unusual executables with high CPU usage or unexpected network transfers
Timeline building: Cross-reference SRUM data with prefetch, event logs, and browser artifacts for a complete picture

SRUM data survives many basic anti-forensic actions because it is a system-level database written by the OS itself, not the user. It is also available through Volume Shadow Copies, which extends its reach into historical activity.

The two things to always check:

The ESE database on disk at C:\Windows\System32\SRU\SRUDB.dat
The registry staging path at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions

References and Credits

13Cubed (Richard Davis) — “Windows SRUM Forensics” (YouTube)
Mark Baggett — SRUM-DUMP tool, SANS SEC573 Lead Author (Github)
SANS ISC InfoSec Forums — System Resource Utilization Monitor overview article (linked in video description)
Champlain College — SRUM Forensics Presentation (hosted via SANS Summit Archives, linked in video description)

Honeyknows

Windows SRUM Forensics