Why SRUM matters: SRUM is the Windows internal record that survives even when application event logs are cleared. It tracks every application execution including those that never wrote a Sysmon event or a security log entry. Investigators recovering a 60-day window of system activity get application identifier, foreground time, network bytes plus power state per hour-bucket.
What SRUM Actually Records
The Windows System Resource Usage Monitor is a system service that aggregates per-application telemetry into an ESE (Extensible Storage Engine) database located at C:\Windows\System32\sru\SRUDB.dat. The database accumulates statistics across several extension tables: application use information, network connectivity, network data usage, energy estimator plus push notifications. Each row aggregates one hour of activity for one application identifier (the SHA1 of the application binary path) plus stores the metric values for that hour.
The 60-day window is the default retention configured by Windows. Older entries roll off as new entries are written. The database is approximately 320 MB at full retention which is small enough to acquire in seconds even on field-deployed forensic hardware. The schema is documented through the EseUtil tool plus through the Yogesh Khatri DFIR research published at swiftforensics.com which is the reference primary source for SRUM internals.
The Three Most Forensically Valuable Tables
The application use information table records foreground time, focus time, processor time plus user input time for each application identifier per hour. For an investigator asking what an executive was working on during a specific hour, this table answers the question with hour-level precision. The application identifier is the SHA1 of the binary path which means investigators can correlate SRUM activity to specific binaries even if the binary was later deleted: the SHA1 record persists in SRUM after the binary is gone.
The network data usage table records bytes sent plus received per application per network interface per hour. For an exfil investigation this is the table that matters: SRUM shows which application accounted for an unusual upload spike during a specific hour even if the network monitoring tooling was bypassed. The data is broken down by network interface so investigators can distinguish wired ethernet, WiFi plus VPN traffic at hour granularity.
The network connectivity table records connection state per network interface: when the interface was up, when it was down plus what network identifier (SSID for WiFi, profile for ethernet) was active. For travelling executive investigations this table reconstructs network connectivity timeline across hotels, conferences plus office locations. Correlating connectivity timeline with application network data usage produces a high-fidelity picture of what the user did from each location.
SRUM Versus Browser History for Exfil Investigations
Browser history is the obvious first artifact in any exfil investigation: it shows the URLs the user visited plus the timestamps. But browser history can be cleared by the user plus is silent on non-browser exfil paths (file sync clients, custom scripts, command-line tools). SRUM cannot be cleared by normal user action plus records network bytes for every process regardless of whether it appeared in a browser history database. For exfil investigations SRUM is the corroborating artifact that confirms or refutes the browser-history-based theory.
The Sherlock Browser Viewer handles the browser side of the investigation: parsing Chrome, Edge plus Firefox history databases with forensic timestamps plus URL reconstruction. SRUM analysis runs alongside Browser Viewer output: the two artifacts together let an investigator answer questions like whether unusual bytes-out volume on a specific hour correlated with browser activity or with some other application identifier. When the network bytes are attributed to a process that does not appear in browser history, the investigation pivots to identifying that process plus its activity.
Parsing the SRUM Database
The ESE format used by SRUM is the same format Microsoft uses for the Active Directory database plus the Windows search index. ESE tools (esentutl, ESEDatabaseView from Nirsoft, libesedb from Joachim Metz) can dump the raw tables. For forensic work the published parsers handle the SRUM schema translation: srum-dump from Mark Baggett, SRUM-DUMP from CrowdStrike plus the SRUM extension in KAPE produce CSV output suitable for timeline ingest.
The parsing step that catches most first-time investigators is the application identifier translation. SRUM stores application identifiers as opaque blob references into a separate map table. The raw network data usage row will say something like AppId 4127 sent 2.3 GB. Translating AppId 4127 to the actual binary path requires looking up the AppMap table plus is the step where most analysis tooling differentiates itself. The Sherlock methodology runs the translation automatically plus produces output indexed by binary path which is the form investigators actually need.
Practical Limits and Caveats
SRUM has hour-level granularity not minute-level. An investigator asking what application sent 500 MB at 14:23 on a specific day will get the hour-bucket answer of 14:00 to 15:00 not the precise minute. For most exfil investigations the hour-level answer is sufficient because the network traffic anomaly is usually visible at hour resolution. For investigations requiring minute-level precision SRUM needs to be combined with NetFlow logs or endpoint network telemetry.
SRUM does not record specific URLs or specific remote IPs. The network data usage table records bytes per application per interface but not the specific destinations. For destination IP analysis SRUM needs to be combined with DNS cache, browser cache or endpoint firewall logs. The Sherlock incident response engagements use SRUM as the activity-baseline artifact plus correlate it against the specific destination evidence from other sources.
Volume Shadow Copy snapshots preserve historical SRUM database state. If the system has VSS enabled the historical SRUM contents can extend the effective retention window back by months. For long-tail investigations always check for VSS snapshots before concluding the 60-day window has rolled off.
Adding SRUM to the IR Triage Checklist
For organizations building incident response capability the SRUM database belongs in the standard triage acquisition list alongside event logs, registry hives plus Master File Table. The acquisition step is fast (under one minute on a live system), the file is small (under 350 MB at full retention) plus the analytical yield is high. For Sherlock customers handling internal investigations the SRUM artifact is one of the strongest answers to the question of what an application actually did during a specific time window even when other logging sources are silent.