← Back to parser

Using SRUM in a forensic investigation

What SRUM is good at proving

SRUM is one of the richest activity datasets Windows keeps about itself. In an investigation it can answer:

  • Was an application running on a given date? Every row of Application Resource Use has a TimeStamp and an AppId. If chrome.exe has a row for 2026-04-12 14:00 with FaceTime > 0, the app was visible to a user.
  • How much data did an application exfiltrate? Network Data Usage rows carry BytesSent per application per network profile. A spike from a process that normally talks little is a strong indicator.
  • What network was the laptop on when the breach happened? Network Connectivity rows give precise FILETIME connect/disconnect timestamps per Wi-Fi profile.
  • Was the device on battery or plugged in? Energy Usage event rows show every AC/DC transition with timestamps.

A worked example: data exfiltration

You suspect a departing employee staged data on a USB stick and uploaded it. You have an image of their workstation taken three days after their last day. Here's a SRUM-led approach:

  1. Acquire C:\Windows\System32\sru\* and the SOFTWARE hive from the image. (Where is SRUDB.dat located on Windows?)
  2. Parse the database. Drop it into the SRUM parser or run SrumECmd. (How to parse SRUDB.dat without installing anything)
  3. Filter Network Data Usage to the suspect's UserId (resolved via SruDbIdMapTable to their SID).
  4. Sort by BytesSent desc for the window of suspicion (last 14 days of employment). Look for non-browser processes with multi-hundred-MB outbound bytes — OneDrive.exe, Dropbox.exe, custom utilities, or pwsh.exe.
  5. Cross-check Network Connectivity for the same time range — was the device on corporate Wi-Fi, a mobile hotspot, or unknown SSID?
  6. Pivot to Application Resource Use for those processes to confirm foreground use vs background autoupload.

The combination — process + bytes + network — is far stronger than any single source.

A worked example: malware persistence

A SOC alert fires on a low-prevalence binary executed yesterday morning.

  1. Get the IdMap row for the binary path. If the row exists, the malware ran at some point.
  2. Pull all Application Resource Use rows for that AppId, sorted by TimeStamp. The earliest row dates first execution; subsequent rows show recurrence intervals — a strong signal for scheduled-task or run-key persistence.
  3. If background CPU cycles continue with no foreground time, the process is running silently.
  4. Cross-reference Network Data Usage rows for the same AppId to see if it phoned out.

Cautions

  • SRUM rounds heavily. A 5-minute browser session may show up as a single 60-minute bucket. Don't claim minute-by-minute resolution from short-term tables.
  • FaceTime > 0 means the UI was visible — not that a human was looking at it. RDP sessions, kiosks, and unattended login screens all register.
  • The Long-Term tables aggregate weekly. Don't compare LT byte counts one-to-one with short-term rows.
  • An attacker with SYSTEM can stop the SRUM service and wipe the file. Always check the file's NTFS MFT entry for unexpected modification timestamps.

Related reading

Frequently asked questions

Is SRUM evidence admissible in court?
Yes — courts in the US, UK, and EU have accepted SRUM-derived testimony. As with any digital evidence, the acquisition chain of custody and the parsing methodology must be documented.
Can SRUM prove a user was at the keyboard?
Indirectly. The FaceTime column on Application Resource Use captures time the app's UI was visible, which usually correlates with active use. It is not the same as confirmed human input.
How precise are SRUM timestamps?
Row TimeStamps are bucketed to the SRUM sample interval (typically 60 minutes). Energy events and network connection events are precise to the second.
Can an attacker tamper with SRUDB.dat?
Yes, with SYSTEM privileges they can stop the SRUM service and overwrite the file. Look for inconsistent row counts, gaps in TimeStamp sequences, or recent modification timestamps on the file itself.
Does SRUM record private/incognito browsing?
It records bytes the browser process used, but not URLs visited. So you'll see Chrome sent 200 MB on a given hour, but not where to.