# SRUM on Windows 11: Reconstructing App, Network and Power Use

URL: https://www.mytechnician.tech/labs/srum-srudb-dat-windows-11-forensics/
Published: 2026-08-08 | Author: Ankit Kumar
Track: Forensic artifact | Difficulty: Intermediate | Authorization: defensive
Time required: 35 min
Verified on: Windows 11 24H2 (build 26100.2894), Hyper-V VM on an internal-only virtual switch, SrumECmd 0.6
MITRE ATT&CK: T1020
Tags: Forensics, Network Forensics, Execution Artifacts, Windows 11
Summary: SRUDB.dat records how much data each application sent and received, hour by hour, for around 30 days. It is the only standard Windows artifact that ties a program to network volume.

## What SRUM Answers That Nothing Else Does

Every other execution artifact tells you a program ran. SRUM tells you **how much data it moved**.

The System Resource Usage Monitor was built so Windows could show you the Data Usage screen in Settings. As a side effect it maintains roughly 30 days of per-application, per-user, roughly-hourly records of CPU cycles consumed, bytes sent, bytes received, and which network interface was in use.

For two questions in particular there is no substitute:

- *Was this thing exfiltrating data?* A background process with gigabytes in the sent column is not ambiguous.
- *What was hammering the CPU at 3am last Tuesday?* SRUM has an hourly bucket for it.

## The Database

`C:\Windows\System32\SRU\SRUDB.dat` is an ESE (Extensible Storage Engine) database — the same engine behind Exchange and the Windows Search index. Alongside it sit `SRU*.log` transaction logs.

The tables are named by GUID rather than anything readable, and the mapping from GUID to meaning lives in the **SOFTWARE registry hive**, not in the database. This is why every SRUM parser asks for `SOFTWARE` as a second input — without it, application IDs stay as numbers instead of resolving to executable paths.

The tables that matter:

| Table | Contents |
|---|---|
| Network Data Usage | Bytes sent/received per app, per interface, per hour |
| Network Connectivity | Which network the machine was on, and when |
| Application Resource Usage | CPU cycles, foreground/background time, disk I/O per app |
| Energy Usage | Battery drain per app (laptops) |

### Step 1: Collect the database, its logs, and the SOFTWARE hive

All three, or the parse will be incomplete or unreadable:

```
robocopy C:\Windows\System32\SRU C:\cases\srum /E
robocopy C:\Windows\System32\config C:\cases\srum SOFTWARE SOFTWARE.LOG1 SOFTWARE.LOG2
```

`SRUDB.dat` is locked on a running system. If `robocopy` fails, work from a disk image or use a raw-access copy tool — do not try to force it on a live machine that matters.

### Step 2: Parse with the SOFTWARE hive supplied

```
SrumECmd.exe -f C:\cases\srum\SRUDB.dat -r C:\cases\srum\SOFTWARE --csv C:\cases\out
```

`-r` points at the registry hive. Skip it and the output is populated with unresolved IDs.

You get one CSV per table. Open `*_NetworkUsages.csv` first.

### Step 3: Sort network usage by bytes sent

`BytesSent` descending, and read down the `ExeInfo` column.

The top of that list on a normal machine is a browser, a cloud sync client, Windows Update, and a mail client. What draws attention:

- An executable running from `AppData`, `Temp`, or `ProgramData` with meaningful volume
- A system-sounding binary with a sent/received ratio the real component would never produce
- Sustained transfer during hours the machine's user was not present
- Any process you cannot account for at all

Note the **ratio**, not just the total. Normal browsing is heavily received-weighted. A process with far more sent than received is moving data *off* the machine, which is a different shape entirely.

### Step 4: Pin down the timing

The `Timestamp` column buckets to roughly an hour. Filter to a single suspicious executable and sort chronologically. You are looking for:

- When transfer started — often the clearest available estimate of when a compromise became active
- Whether it is continuous or periodic — regular hourly or daily buckets suggest scheduled beaconing rather than a person
- When it stopped, if it did

### Step 5: Establish which network it happened on

Cross-reference `*_NetworkConnections.csv` for the same time window. This resolves whether the transfer happened on the corporate LAN, home Wi-Fi, or a tethered phone — which materially changes what it means and who else needs to know.

### Step 6: Corroborate

SRUM shows volume, not content. Before drawing conclusions, confirm the process itself:

- [Prefetch](https://www.mytechnician.tech/labs/prefetch-files-windows-11-proving-execution/) for run count and history
- [Amcache](https://www.mytechnician.tech/labs/amcache-hve-windows-11-forensics/) for the SHA-1, so you can identify the binary
- [The firewall log](https://www.mytechnician.tech/labs/read-windows-firewall-log-pfirewall-windows-11/) for destination addresses, if it was enabled

## Limits Worth Knowing

**Roughly 30 days, and that is not guaranteed.** Retention depends on activity and available space. Check the oldest timestamp in your parse before treating absence as meaningful.

**Data is buffered in the registry before it is committed.** Recent activity — up to about an hour — may sit in `HKLM\SYSTEM\CurrentControlSet\Services\rdyboost\Parameters\Srum` rather than in the `.dat`. On a live capture you can miss the most recent hour.

**No destinations.** SRUM records volume per application, not the IP addresses it talked to. For destinations you need firewall logging, Sysmon Event ID 3, or a network capture.

**Hourly granularity.** Fine for "when did this start", useless for correlating events seconds apart.

## Related

- [Windows 11 forensic artifacts overview](https://www.mytechnician.tech/labs/windows-11-forensic-artifacts-program-execution/)
- [Reading the Windows firewall log](https://www.mytechnician.tech/labs/read-windows-firewall-log-pfirewall-windows-11/)
- Consumer guide: [removing cryptominer malware](https://www.mytechnician.tech/tips/remove-cryptominer-malware-windows-11/) — SRUM's CPU history is how you confirm the timeline there

## FAQ

### Why does my SRUM parse show numbers instead of program names?

You did not supply the SOFTWARE registry hive. The mapping from SRUM's internal application IDs to executable paths lives in the registry, not in the database. Re-run with `-r` pointing at a copy of `C:\Windows\System32\config\SOFTWARE`.

### Does SRUM record which IP addresses a program connected to?

No. It records bytes sent and received per application, per interface, per hour — volume only. For destination addresses you need the Windows firewall log with logging enabled, Sysmon Event ID 3, or packet capture. SRUM tells you something moved and roughly when; it cannot tell you where.

### Can SRUM be cleared?

`SRUDB.dat` can be deleted with administrator rights, and Windows will recreate it empty. As with other artifacts, that is conspicuous: a machine with months of uptime and a SRUM database starting yesterday is anomalous on its face. There is no supported way to selectively remove individual entries.

### Is SRUM present on desktops, or only laptops?

Present on both. The Energy Usage table is only meaningful on battery-powered devices, but Network Data Usage and Application Resource Usage populate on desktops exactly the same way.

---

Source: https://www.mytechnician.tech/labs/srum-srudb-dat-windows-11-forensics/ — My Technician Security Labs.
Authorization: defensive. This write-up is published for defensive and educational use on systems you own or are authorized to test.
More labs: https://www.mytechnician.tech/labs/