SRUM.db — System Resource Usage Monitor

Every hour, Windows silently records exactly how many bytes each application sends and receives over the network — and it does not stop recording when the application is uninstalled. For investigators facing a wiped machine, SRUM.db is frequently the last artifact standing between a defensible finding and an inconclusive report.

What Is SRUM.db?

The System Resource Usage Monitor (SRUM) is a Windows diagnostic subsystem introduced in Windows 8 (October 2012) that tracks per-application resource consumption. It records CPU cycles, memory usage, network bytes transferred, and energy consumption for every application that executes on the system — regardless of whether that application is a signed OS component, a third-party installer, or a renamed command-line tool dropped into %TEMP%. The data is persisted in an Extensible Storage Engine (ESE) database at a fixed system path, and it is updated approximately every 60 minutes by the Diagnostic Policy Service (DiagTrack).

SRUM was designed to power the Windows Resource Monitor and App History tabs in Task Manager. Microsoft uses it for telemetry, energy profiling, and bandwidth metering on metered connections. From a forensic perspective, however, its value is far greater: SRUM provides hourly-resolution network transfer data per application per user per network interface. This granularity means an investigator can determine not just that an application ran, but when it ran, how much data it moved, and which network adapter it used — information that no other single artifact provides.

The ESE database contains multiple tables, each identified by a GUID. The three tables of primary forensic interest are: {973F5D5C} (Network Data Usage), which records bytes sent and received per application per hour; {D10CA2FE} (Application Resource Usage), which tracks CPU cycle time and context switches; and {FEE4E14F} (Network Connectivity), which logs connection durations and interface associations. Critically, SRUM data persists after an application is uninstalled. The database records what happened, not what currently exists on disk.

Location & Format

File Paths

Database Format

SRUM.db uses the Extensible Storage Engine (ESE), also known as JET Blue. This is the same database engine that underpins Active Directory (ntds.dit), Exchange Server mailbox stores, and Windows Search (Windows.edb). ESE databases use a write-ahead logging model: changes are first written to transaction log files (.log), then committed to the main .db file during checkpoint operations. Forensically, this means uncommitted entries may exist only in the log files. A “dirty shutdown” recovery (using esentutl /r) can replay these logs into the database before parsing.

Each application is identified internally by an integer AppId. This integer is mapped to the full executable path via the SRU\{D73F1D5C}\IdMap table, but meaningful resolution requires cross-referencing the SOFTWARE registry hive. Without the SOFTWARE hive, parsed output will show integer identifiers instead of paths like C:\Users\jdoe\AppData\Local\Temp\rc.exe. Always collect both files.

Internal Table Structure

What It Reveals

SRUM answers a specific class of investigative questions that other artifacts either cannot answer at all or can only answer partially. The following questions are directly answerable from SRUM data:

• Which applications transferred data over the network, and how much? — The {973F5D5C} table records BytesSent and BytesRecvd per application per hour, providing total transfer volumes attributable to a specific executable.
• What was the bytes-sent-to-bytes-received ratio? — A high BytesSent with minimal BytesRecvd (e.g., 260:1 ratio) indicates data exfiltration, not synchronization or browsing. A roughly 1:1 ratio suggests interactive traffic or bidirectional sync.
• When did the transfers occur? — Timestamps have hourly precision. An investigator can build an hour-by-hour transfer timeline showing when exfiltration started, how long it lasted, and when it stopped.
• Was a specific application running even though it has been uninstalled? — SRUM entries persist after an application is removed from disk. The ExeInfo field (resolved via SOFTWARE hive) retains the full original path.
• How much CPU time did an application consume? — The {D10CA2FE} table records ForegroundCycleTime and BackgroundCycleTime in 100-nanosecond units, showing whether the application was actively used or ran silently in the background.
• Which network interface was used for each transfer? — The InterfaceLuid column identifies the adapter (Ethernet, Wi-Fi, VPN tunnel, USB tethering). This can prove that data was exfiltrated over a personal hotspot rather than the corporate network.
• Was the application running in the foreground or background? — The FaceTime and ForegroundContextSwitches fields distinguish between user-interactive applications and silent background processes. A tool with zero foreground time and high network transfer is suspicious.
• What is the full executable path? — Via AppID resolution against the SOFTWARE hive, the exact path is recoverable: C:\Users\jdoe\AppData\Local\Temp\rc.exe rather than just a process name.
• Which user account was responsible? — The UserId field maps to a specific SID, attributing network activity to an individual user account even on shared workstations.
• What was the network profile in use? — The {FEE4E14F} table’s L2ProfileId identifies the Wi-Fi SSID or network connection name, proving which network the machine was connected to during the transfer.

Forensic Use Cases

1. Data Exfiltration Detection

The most common forensic use of SRUM is proving data exfiltration. A departing employee renames rclone.exe to rc.exe, syncs corporate file shares to a personal MEGA account, then uninstalls the tool and clears Prefetch. The renamed executable no longer exists on disk, but SRUM retains hourly records showing C:\Users\jdoe\AppData\Local\Temp\rc.exe transferred 8.5 GB outbound over four hours with a 260:1 send-to-receive ratio. The InterfaceLuid confirms the transfer occurred over the corporate Ethernet adapter, not a personal hotspot.

2. Malware C2 Communication

An unknown executable in C:\ProgramData shows periodic network activity at 60-minute intervals — consistent with beacon-based command-and-control. Each hourly entry shows approximately 2–4 KB sent and 1–2 KB received, a pattern characteristic of heartbeat check-ins. SRUM provides the timeline even after the malware is removed by endpoint detection, allowing the investigator to determine the total duration of the compromise.

3. Unauthorized Application Usage

An organization prohibits Tor Browser and personal VPN clients. A user installs Tor Browser, uses it, then deletes the entire Tor directory. Prefetch entries age out or are cleared. However, SRUM retains entries for firefox.exe (Tor’s browser component) showing network activity through an interface that resolves to a SOCKS proxy — and the AppId resolution via the SOFTWARE hive reveals the full path was C:\Users\[user]\Desktop\Tor Browser\Browser\firefox.exe, not the standard Firefox installation path.

4. Timeline Reconstruction After Anti-Forensics

When a subject has cleared Prefetch, wiped browser history, run CCleaner, and deleted files from the Recycle Bin, SRUM provides an independent hourly timeline of application network activity. Because SRUM is not targeted by any widely distributed cleanup tool, the timeline survives cleanup operations that destroy every other artifact. Investigators can reconstruct which applications were active during the incident window and correlate SRUM timestamps with event log entries that also survived the cleanup.

5. Insider Threat Volume Correlation

In insider threat cases, investigators often need to correlate document access with upload volume. SRUM’s hourly BytesSent totals can be aligned with $UsnJrnl entries showing file reads or Security.evtx 4663 events showing object access. If 4,200 files totaling 6.2 GB were accessed between 22:00 and 02:00, and SRUM shows 6.1 GB outbound from a cloud sync tool during the same window, the correlation is dispositive.

Acquisition Methods

Live System — Volume Shadow Copy

:: Create a new Volume Shadow Copy to access the locked SRUM.db
vssadmin create shadow /for=C:

:: Note the Shadow Copy Volume Name from the output, e.g.:
:: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3

:: Copy SRUM.db from the shadow copy (bypasses file lock)
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Windows\System32\sru\SRUM.db C:\Evidence\SRUM.db

:: Copy the SOFTWARE hive (required for AppID resolution)
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Windows\System32\config\SOFTWARE C:\Evidence\SOFTWARE

:: Also collect the transaction logs for dirty-shutdown recovery
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Windows\System32\sru\SRU*.log C:\Evidence\

:: Delete the shadow copy when done
vssadmin delete shadows /shadow={shadow-id} /quiet

Live System — Raw Copy Utilities

:: Using KAPE (Kroll Artifact Parser and Extractor)
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target SRU

:: Using RawCopy (can bypass NTFS locks)
RawCopy.exe /FileNamePath:C:\Windows\System32\sru\SRUM.db /OutputPath:C:\Evidence\

:: Using Velociraptor (remote collection via VQL)
:: Artifact: Windows.KapeFiles.Targets with target "SRU"
:: Or directly: SELECT * FROM glob(globs="C:/Windows/System32/sru/*")

Forensic Image — Direct Extraction

# Mount the forensic image (read-only)
mount -o ro,noexec,nodev /dev/sdb1 /mnt/evidence

# Copy SRUM.db and SOFTWARE hive
cp /mnt/evidence/Windows/System32/sru/SRUM.db /analysis/srum/
cp /mnt/evidence/Windows/System32/config/SOFTWARE /analysis/srum/
cp /mnt/evidence/Windows/System32/sru/SRU*.log /analysis/srum/

# If the database was not cleanly shut down, recover with esentutl
esentutl /r SRU /d /l /s /mnt/evidence/Windows/System32/sru/

Parsing Tools & Analysis

Parsing with srum-dump

# Install srum-dump
pip install srum-dump

# Parse SRUM.db with SOFTWARE hive for AppID resolution
srum_dump.py --SRUM_INFILE /analysis/srum/SRUM.db \
             --REG_HIVE    /analysis/srum/SOFTWARE \
             --XLSX_OUTFILE /analysis/srum/srum_output.xlsx

# Output: Excel workbook with one sheet per SRUM table
# Sheet "Network Data Usage" = {973F5D5C} table
# Sheet "Application Resource Usage" = {D10CA2FE} table
# Sheet "Network Connectivity" = {FEE4E14F} table

Parsing with SrumECmd (Eric Zimmerman)

:: Parse to CSV with full AppID resolution
SrumECmd.exe -f C:\Evidence\SRUM.db -r C:\Evidence\SOFTWARE --csv C:\Analysis\SRUM_Output

:: Output files:
::   SrumECmd_NetworkUsages_Output.csv
::   SrumECmd_AppResourceUsage_Output.csv
::   SrumECmd_NetworkConnections_Output.csv
::   SrumECmd_EnergyUsage_Output.csv

Analysis Script — Top Data Senders

# Identify applications with the highest outbound network transfers

import pandas as pd

df = pd.read_csv('/analysis/srum/SrumECmd_NetworkUsages_Output.csv')

# Filter for entries with more than 1 MB outbound in a single hour
suspicious = df[df['BytesSent'] > 1_000_000].copy()

# Group by executable path, sum total bytes sent
summary = suspicious.groupby('ExeInfo').agg(
    TotalBytesSent=('BytesSent', 'sum'),
    TotalBytesRecvd=('BytesRecvd', 'sum'),
    HourCount=('BytesSent', 'count'),
    FirstSeen=('Timestamp', 'min'),
    LastSeen=('Timestamp', 'max')
).sort_values('TotalBytesSent', ascending=False)

# Calculate send:receive ratio
summary['Ratio'] = (summary['TotalBytesSent'] / summary['TotalBytesRecvd'].replace(0, 1)).round(1)

print(summary.head(10).to_string())

Sample Output

ExeInfo                                           TotalBytesSent  TotalBytesRecvd  HourCount  FirstSeen            LastSeen             Ratio
C:\Users\jdoe\AppData\Local\Temp\rc.exe           9,126,805,504   35,103,232       4          2026-02-14 22:00     2026-02-15 02:00     260.0
C:\Program Files\Google\Chrome\Application\chr..  1,847,229,440   24,891,043,840   720        2025-12-01 08:00     2026-02-28 17:00     0.1
C:\Program Files\Microsoft OneDrive\OneDrive.exe  982,614,016     1,024,458,752    360        2025-12-15 09:00     2026-02-28 16:00     1.0
C:\Windows\System32\svchost.exe                   412,385,280     1,847,627,776    720        2025-12-01 00:00     2026-02-28 23:00     0.2
C:\Program Files\Zoom\bin\Zoom.exe                224,198,656     687,412,224      48         2026-01-06 10:00     2026-02-27 15:00     0.3

Retention & Persistence

Anti-Forensics Resilience

SRUM.db is one of the most resilient forensic artifacts on a Windows system. It is protected by the operating system’s file locking mechanism, stored in a privileged system directory, and not included in the target lists of any widely distributed cleanup tool.

MITRE ATT&CK Detection Mapping

SRUM data provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Mark Baggett, “srum-dump — SRUM Database Parser” — https://github.com/MarkBaggett/srum-dump
2. Arsenal Recon, “SRUM Expert” — https://arsenalrecon.com
3. Eric Zimmerman, “SrumECmd — SRUM Parser” — https://ericzimmerman.github.io/
4. SANS Institute, “SRUM Forensics — The Artifact Windows Doesn’t Want You to Know About” — https://www.sans.org/blog/
5. 13Cubed, “SRUM Analysis for DFIR” — https://www.13cubed.com/blog
6. Microsoft, “System Resource Usage Monitor” — https://learn.microsoft.com
7. ForensicArtifacts.com, “Windows SRUM Artifact Definition” — https://github.com/ForensicArtifacts/artifacts
8. NirSoft, “ESEDatabaseView” — https://www.nirsoft.net/utils/ese_database_view.html