← Back to parser

Detecting data exfiltration with SRUM network usage

What SRUM can and cannot tell you

SRUM's Network Data Usage table records, per hourly bucket: which process sent how many bytes, under which user, over which network. It does not record destinations, URLs, or file contents. That makes it a powerful triage and corroboration source, not a packet capture.

The method

  1. Acquire and recover the database. If it's dirty, run soft recovery first — see How to fix a dirty SRUDB.dat.
  2. Open it in the SRUM parser and select the Network Data Usage tab.
  3. Sort by BytesSent descending. Export to CSV if you want to work the numbers in a spreadsheet.
  4. Baseline, don't threshold blindly. Browsers, update agents and cloud-sync clients legitimately move gigabytes. The signal is a process that normally talks little suddenly sending a lot: powershell.exe, cmd.exe, archivers, or an unsigned binary.
  5. Attribute. The resolved UserId (SID) tells you whose session. The resolved AppId tells you the program. A departing employee's SID against a 7-Zip or curl.exe row is a strong lead.
  6. Check the network. L2ProfileFlags decodes to Wired / Wi-Fi / Mobile broadband. Exfiltration over a personal hotspot to dodge corporate egress filtering shows up clearly here.
  7. Time-box. Use the TimeStamp to place the transfer relative to the employee's resignation, a known compromise window, or after-hours activity (the Anomalies tab flags off-hours patterns automatically).

Worked signal

A pwsh.exe row, user = the suspect's SID, BytesSent ≈ 1.4 GB across three consecutive evening buckets, L2ProfileFlags = mobile broadband — that combination (unusual process + volume + user + off-hours + bypass network) is the textbook exfiltration fingerprint. It won't tell you the files; pivot to the USN journal and MFT for that.

Limits to state honestly in a report

  • Hourly bucketing — you cannot claim a precise transfer minute.
  • No destination — SRUM cannot prove where the data went.
  • Counters are cumulative per sample and can include retransmits.

State these plainly; they make the evidence you do present more credible.

Related reading

Frequently asked questions

Can SRUM show what data was stolen?
No — SRUM records byte counts per process, not file names or content. It tells you which process sent how much, over which network, and under which user. You corroborate the 'what' with USN journal, MFT, or DLP.
What byte threshold indicates exfiltration?
There is no universal number. Baseline the process: a backup agent sending 2 GB is normal; powershell.exe or a custom binary sending 200 MB outbound is not. The parser's Anomalies tab flags >50 MB in a single sample as a starting point.
Which SRUM table do I use?
Network Data Usage ({973F5D5C-1D90-4944-BE8E-24B94231A174}). BytesSent is the outbound counter; AppId and UserId resolve to the process and user; L2ProfileId maps to the network.
Can it detect exfiltration over a VPN or hotspot?
It detects the bytes regardless of destination. L2ProfileFlags distinguishes wired / Wi-Fi / mobile broadband, which often reveals an unexpected network (personal hotspot) used to bypass corporate egress controls.
Is SRUM enough on its own for an exfiltration case?
It is strong circumstantial evidence (process + volume + user + network + time). Pair it with proxy/firewall logs, DLP, and filesystem timelines for a complete, defensible case.