Lion Cipher Lab

Reconstruct application and network usage from the Windows SRUM database

• Digital Forensics & IR (DFIR)
• Intermediate
• ~60 min
• Free · no account required

Why it matters

One of the hardest questions in an investigation is also one of the most important: did data leave this machine, which program moved it, and roughly how much? Full packet capture would answer it, but almost nobody has full packet capture of the moment that mattered. What Windows does have, sitting on nearly every modern machine and mostly unknown to the people using it, is SRUM -- a built-in record of how many bytes each application sent and received, bucketed by time. That means that days or weeks after a suspicious event, with no special logging set up in advance, you can often still say…

What you'll learn

• explaining what SRUM (System Resource Usage Monitor) is: a Windows feature that records per-application resource use -- including bytes sent and received per network interface -- into a database, so it becomes a historical record of what each app did
• locating the artifact and its supporting files: the ESE database at C:\Windows\System32\sru\SRUDB.dat and the SOFTWARE registry hive that SrumECmd needs to turn cryptic IDs into real application names
• understanding why the live SRUDB.dat is LOCKED by Windows and cannot simply be copied, and using a method that reads a locked system file (a Volume Shadow Copy, or esentutl's copy) to get a usable copy
• parsing the database with Eric Zimmerman's SrumECmd into readable CSVs -- Network Usage, Network Connections, Application Resource Usage, Energy, and Push Notifications
• reading the Network Usage table to answer a real investigative question: which application sent the most bytes in a chosen time window, and roughly how much
• quantifying it: sorting by BytesSent, taking the top talkers, and summing bytes across an hour range to produce an approximate MB figure you can put in a report
• correlating SRUM with the execution artifacts (Prefetch, Amcache) so 'this program ran' becomes 'this program ran AND moved this much data' -- a stronger story than either alone
• the honest limits that keep the analysis defensible: SRUM flushes to disk roughly HOURLY so the most recent activity may not be in the DB yet, retention is finite (often ~30-60 days) so old activity ages out, the byte counts are Windows' own accounting and are ESTIMATES not packet-accurate, and attribution is to an application and a user SID, not to a human with certainty
• knowing what SRUM does NOT tell you -- destination IPs, ports, or content -- and therefore why you pair it with firewall/proxy/NetFlow logs to turn 'app X moved 400 MB' into 'to where, and what'

Steps in this lab

1. What SRUM is, and why an investigator cares
2. Get SrumECmd
3. Why you can't just copy the file — and how to copy it anyway
4. Parse it into CSVs
5. Answer the real question — who moved the most data?
6. Correlate — turn 'it ran' into 'it ran AND moved data'
7. The honest limits — read this before you report a number
8. Wrap up and clean up

Open the full interactive lab →