Detecting data exfiltration with SRUM network usage

Network Data Usage is one of the few places on a Windows host that records per-process bytes against per-user attribution against a specific network. It does not record destinations, URLs, or content. Treat it as a triage and corroboration source, not a packet capture. Used with proxy logs and filesystem timelines, it closes exfiltration cases that EDR alone could not.

What the table actually carries

{973F5D5C-1D90-4944-BE8E-24B94231A174} — Network Data Usage. Each hourly row holds:

• TimeStamp — bucket boundary (OLE date).
• AppId — resolves to a process via SruDbIdMapTable.
• UserId — resolves to a SID.
• InterfaceLuid — Windows LUID for the network interface.
• L2ProfileId — opaque GUID; resolve through NetworkList\Profiles in the registry.
• L2ProfileFlags — bitmask: 0x100 wired, 0x200 wireless, 0x400 WWAN.
• BytesSent, BytesRecvd — counters per sample, per process.

What it does not carry: URLs, file names, packet payloads, destinations.

The workflow

1. Acquire and recover. Pull the entire sru\ directory and the SOFTWARE hive. Replay logs if dirty — see how to fix a dirty SRUDB.dat.
2. Open Network Data Usage. In the in-browser parser or SrumECmd. The parser tab already resolves AppId and UserId.
3. Sort by BytesSent desc. Export to CSV if you want to work the numbers in a spreadsheet.
4. Baseline, do not threshold blindly. Cloud-sync clients, browsers and update agents legitimately move gigabytes. The signal is a process that normally talks little suddenly sending a lot: powershell.exe, pwsh.exe, cmd.exe, curl.exe, archivers, anything from %TEMP% or %AppData%, anything unsigned.
5. Attribute. The resolved UserId (SID) tells you whose session. The resolved AppId names the binary. A departing employee's SID against a 7z.exe or curl.exe row is a lead.
6. Check the network. L2ProfileFlags decodes to wired / Wi-Fi / mobile broadband. Outbound traffic over a personal hotspot to bypass corporate egress filtering is the textbook exfiltration tell.
7. Time-box. Use TimeStamp to align against the suspect's resignation, a known compromise window, or after-hours activity.

A textbook signal

A pwsh.exe row, UserId resolved to the suspect's SID, BytesSent ≈ 1.4 GB across three consecutive evening buckets, L2ProfileFlags indicating mobile broadband. That combination — unusual process + unusual volume + named user + after hours + bypass network — is the exfiltration fingerprint. It does not tell you the files.

For the what, pivot:

• USN journal — file deletes, renames, archive creates in the same window.
• MFT — staging directories, archive files, file sizes that match transfer volumes.
• Prefetch — execution of archivers, curl, rclone, aws.exe.
• AmCache — SHA-1 of any custom binary referenced in the suspect rows.
• EVTX — PowerShell 4104 script-block logs, Sysmon 3 network connections (if the host had Sysmon).

Real EDR overlap

Modern EDR records process-level network traffic too. SRUM still wins when:

• EDR was not deployed during the suspicious window.
• EDR was disabled by the adversary; DPS rarely is.
• EDR retention does not cover the timeframe.
• The transfer happened on a personal hotspot the EDR's cloud was not reachable through.

The strongest exfiltration cases stack EDR, proxy/firewall, SRUM, and filesystem evidence. If any one of those is missing, the others usually fill the gap.

Limits to state honestly

• Hourly bucketing: cannot claim a precise transfer minute from short- term rows. You can claim "between 22:00 and 23:00 UTC".
• No destination: SRUM cannot prove where the data went. Proxy logs or NetFlow do that.
• Cumulative counters per sample include retransmits. Headline numbers are correct; per-packet claims are not.
• The LT siblings aggregate weekly. Use them for "did anything happen in the past year"; do not pin a specific hour from an LT row.

Further reading

• Using SRUM in a forensic investigation
• SRUM tables explained
• SRUM vs Prefetch vs Amcache