Using SRUM in a forensic investigation
5/17/2026
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.exehas a row for 2026-04-12 14:00 withFaceTime > 0, the app was visible to a user. - How much data did an application exfiltrate? Network Data Usage rows
carry
BytesSentper 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:
- Acquire
C:\Windows\System32\sru\*and the SOFTWARE hive from the image. (Where is SRUDB.dat located on Windows?) - Parse the database. Drop it into the SRUM parser or run SrumECmd. (How to parse SRUDB.dat without installing anything)
- Filter Network Data Usage to the suspect's
UserId(resolved viaSruDbIdMapTableto their SID). - Sort by
BytesSentdesc 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, orpwsh.exe. - Cross-check Network Connectivity for the same time range — was the device on corporate Wi-Fi, a mobile hotspot, or unknown SSID?
- 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.
- Get the IdMap row for the binary path. If the row exists, the malware ran at some point.
- 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.
- If background CPU cycles continue with no foreground time, the process is running silently.
- 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 > 0means 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
MFTentry 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.