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 and 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 and push notifications. Each row aggregates one hour of activity for one application identifier (the SHA1 of the application binary path) and 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 and 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 and 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 and 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 and VPN traffic at hour granularity.
The network connectivity table records connection state per network interface: when the interface was up, when it was down and what network identifier (SSID for WiFi, profile for ethernet) was active. For travelling executive investigations this table reconstructs network connectivity timeline across hotels, conferences and 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 and the timestamps. But browser history can be cleared by the user and is silent on non-browser exfil paths (file sync clients, custom scripts, command-line tools). SRUM cannot be cleared by normal user action and 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 and Firefox history databases with forensic timestamps and 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 and its activity.
Parsing the SRUM Database
The ESE format used by SRUM is the same format Microsoft uses for the Active Directory database and 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 and 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 and is the step where most analysis tooling differentiates itself. The Sherlock methodology runs the translation automatically and 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 and 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 and 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) and 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.