The Database That Windows Built

The following is a lightly anonymised account of a real digital forensics engagement conducted under legal privilege. All individual identifiers have been altered. Technical findings and artifact details are presented as they occurred. We are publishing this case because SRUM.db remains among the most powerful and least known forensic artifacts in Windows environments — a record of application-level network activity that persists long after the applications themselves are gone.

Background — What SRUM Is and Why Nobody Knows About It

The System Resource Usage Monitor (SRUM) is a Windows diagnostic subsystem introduced in Windows 8 and present in every version since. It was designed to support Windows’ battery and power usage diagnostics — the kind of detail that lets your laptop tell you ‘Google Chrome is using 23% of your battery.’ To do this, Windows tracks how much CPU time, memory, and network bandwidth each application consumes, in hourly buckets, continuously, in the background.

The data is stored in an Extensible Storage Engine (ESE) database at C:\Windows\System32\sru\SRUM.db. This file exists on every Windows 8, 10, and 11 machine. It retains data for approximately 30 to 60 days, rolling. It records network bytes sent and received per application, per hour. It includes the application’s full executable path. And — this is the part that matters forensically — it continues to retain historical entries for an application even after that application has been completely uninstalled. The database tracks what happened; it does not audit whether the application currently exists.

Most Windows users have never heard of SRUM. Most IT professionals have never heard of SRUM. In our experience, a significant fraction of practising digital forensic examiners had not added SRUM to their standard collection workflow at the time of this engagement. The suspect in this case had certainly never heard of SRUM. This was his significant misfortune.

The Engagement

How We Were Called In

The company’s legal counsel engaged us after the departure of their VP of Sales, Marcus, to a direct competitor. The circumstances were suspicious: Marcus had given two weeks’ notice, been placed on garden leave immediately as per company policy, and the competitor had launched a remarkably targeted sales campaign against the company’s top forty accounts within six weeks of Marcus’s start date. Those forty accounts corresponded almost exactly to the company’s internal ‘Priority Tier 1’ customer list — a document that was not publicly available and existed only in the company’s CRM and a handful of internal reports.

Marcus, when contacted by legal counsel, had denied taking any company data. He had returned his company laptop voluntarily before being placed on garden leave. The laptop had since been wiped and re-imaged for a new employee. What remained was a forensic image of the drive taken before the wipe — a standard IT practice at this company for all departing executives — and a BitLocker recovery key in the company’s Active Directory.

The image was 512GB. We had it on a drive in our lab by end of that week.

Finding 1: The Absence of Expected Evidence

Standard forensic triage of the image produced results that were notable for what was absent. The Prefetch directory had been cleared — a telling indicator, as Prefetch does not clear itself and Windows does not offer a user-facing option to do so. Browser download history had been cleared. The most recently used file lists in the registry showed only files accessed in the first two weeks of employment and a gap of almost nothing for the final three weeks.

Marcus had been careful. Not careful enough, as it happened, but careful. He had cleared the artifacts most people know about. What he had not done — what almost no one thinks to do — was clear SRUM.db.

SRUM.db is not in any widely distributed ‘anti-forensics’ checklist. It does not appear in the CCleaner interface. It is a system file, locked by the operating system while Windows is running, located in a directory that requires elevated privileges to access. The tooling to parse it barely existed outside specialist forensic communities at the time of this engagement.

Finding 2: SRUM.db — What the Database Contained

# SRUM.db acquisition and parsing from forensic image — offline mount, srum-dump + SOFTWARE hive

cp /mnt/evidence/Windows/System32/sru/SRUM.db /analysis/srum/SRUM.db
cp /mnt/evidence/Windows/System32/config/SOFTWARE /analysis/srum/SOFTWARE
# SOFTWARE hive maps AppID integers to executable paths — required for meaningful output

# Parse with srum-dump (Python)
pip install srum-dump --break-system-packages -q
srum_dump.py --SRUM_INFILE /analysis/srum/SRUM.db \
             --REG_HIVE    /analysis/srum/SOFTWARE \
             --XLSX_OUTFILE /analysis/srum/srum_output.xlsx

# Table of interest: {973F5D5C-1D90-11D3-AEC2-00805FC297D7} (Network Data Usage)
# Columns: AutoIncId, TimeStamp, AppId, UserId, BytesSent, BytesRecvd, ConnectCount

# Filter SRUM Network Data Usage for significant outbound transfers

import pandas as pd

df = pd.read_csv('/analysis/srum/network_data_usage.csv')

# Filter: outbound bytes > 1MB in any single hour, sorted by date
significant = df[df['BytesSent'] > 1_000_000].copy()
significant['Timestamp'] = pd.to_datetime(significant['Timestamp'])
significant = significant.sort_values('Timestamp')

print(significant[['Timestamp','ExeInfo','UserId','BytesSent','BytesRecvd']].to_string())

# OUTPUT (condensed — rows above 1MB outbound threshold):
# Timestamp              ExeInfo                                         BytesSent    BytesRecvd
# 2024-██-██ 09:00 UTC   C:\Chrome\Application\chrome.exe               1,247,344    28,441,203  ← normal
# ...
# 2024-██-██ 19:00 UTC   C:\Users\marcus\AppData\Local\Temp\rc.exe      841,209,344  12,441      ← !!
# 2024-██-██ 20:00 UTC   C:\Users\marcus\AppData\Local\Temp\rc.exe    2,947,301,112   8,204      ← !!
# 2024-██-██ 21:00 UTC   C:\Users\marcus\AppData\Local\Temp\rc.exe    1,984,441,203   4,122      ← !!
# 2024-██-██ 22:00 UTC   C:\Users\marcus\AppData\Local\Temp\rc.exe    1,187,203,441   3,841      ← !!
# 2024-██-██ 09:00 UTC   C:\Users\marcus\AppData\Local\Temp\rc.exe      441,203,847   2,104      ← day 2
# 2024-██-██ 10:00 UTC   C:\Users\marcus\AppData\Local\Temp\rc.exe    1,102,847,203   1,844      ← day 2

# rc.exe: total BytesSent = 8,503,406,250 bytes = ~8.5 GB outbound
# BytesRecvd: negligible (32,556 bytes total) — one-way upload, not a sync
# Executable path: AppData\Local\Temp\rc.exe — non-standard location, disguised name

The name rc.exe told us immediately what we were looking at. Rclone — the open-source cloud synchronisation tool used in data exfiltration operations — is commonly renamed and placed in temporary directories specifically to avoid detection by name-based EDR rules. The binary had been named rc.exe and placed in Marcus’s AppData\Local\Temp directory. It had transmitted 8.5 gigabytes of data outbound across two evenings. It had received 32,556 bytes in return — consistent with rclone’s acknowledgement traffic when uploading to a remote destination.

The binary was gone. The Prefetch entry was gone. The registry keys were gone. Every trace Marcus had been able to reach had been erased. SRUM had recorded each hour of operation regardless, because SRUM does not care whether an application exists. It cares whether it ran. rc.exe had run. SRUM had written it down.

Finding 3: Identifying the Destination — VSS Shadow Copy Recovery

Knowing that 8.5 GB had been transmitted was significant. Knowing where it had gone was essential for the civil case. The forensic image contained three VSS shadow copies created by Windows Update and System Restore operations. We mounted each one and searched for rclone configuration files.

# VSS shadow copy search — rclone.conf recovered from shadow 3 days before laptop return

# Search all shadow copies for rclone config:
for shadow in /mnt/shadow1 /mnt/shadow2 /mnt/shadow3; do
    find $shadow -name 'rclone.conf' -o -name '.rclone.conf' 2>/dev/null
    find $shadow -path '*/rclone/*' 2>/dev/null
done

# RESULT — shadow copy #2 (dated 3 days before laptop return):
# /mnt/shadow2/Users/marcus/AppData/Roaming/rclone/rclone.conf  ← FOUND

cat /mnt/shadow2/Users/marcus/AppData/Roaming/rclone/rclone.conf

# Content:
[remote]
type = mega
user = ████████████████@proton.me
pass = ████████████████████████████  # rclone-obscured password (not plaintext but reversible)

# Destination: MEGA cloud storage
# Account email: Proton Mail address (anonymous registration — no KYC)
# rclone obscured passwords are trivially reversible:
# rclone reveal ████████████████████████████
# Output: [plaintext password — not reproduced here]

The configuration file had survived in a shadow copy. The destination was MEGA — a cloud storage provider popular in exfiltration cases for its free 20 GB tier, end-to-end encryption, and permissive terms of service. The account was registered to a Proton Mail address that Marcus had not used for any other identifiable purpose. We did not attempt to access the MEGA account — that is a matter for law enforcement with appropriate process.

Finding 4: Correlating Upload Windows with Company Data Access

# CRM access log + LNK files — 40-account Priority Tier 1 browse, report export, then rclone upload 37 min later

# SRUM upload window 1: 2024-██-██ 19:00-22:00 UTC = 15:00-18:00 Eastern

# CRM access log (filtered for marcus@company.com, same date):
# Time (Eastern)  Action                    Record Accessed
# 13:44:02         VIEW  Contact              Priority Tier 1 — [Account A]
# 13:44:48         VIEW  Contact              Priority Tier 1 — [Account B]
# 13:45:19         VIEW  Contact              Priority Tier 1 — [Account C]
# ... (40 consecutive Contact views, all Priority Tier 1 accounts, 13:44-14:22)
# 14:22:41         RUN   Report               'My Accounts — Full Export with Contact Details'
# 14:23:04         DOWNLOAD  Report Result    my_accounts_export_20240██.csv  (2.3 MB)
# [15:00 Eastern = 19:00 UTC — rclone upload begins in SRUM]

# Time elapsed between CRM report download and rclone upload start: 37 minutes

# LNK file analysis (Windows Recent items — not all cleared):
# C:\Users\marcus\AppData\Roaming\Microsoft\Windows\Recent\
# Surviving LNK files:
# 2024-██-██ 14:01  → D:\Shared\Sales\████ Pharma\Customer_Analysis_FY2024.xlsx (14.2 MB)
# 2024-██-██ 14:08  → D:\Shared\Sales\Strategic\Pricing_Model_Confidential_v4.xlsm (8.8 MB)
# 2024-██-██ 14:15  → D:\Shared\Sales\████ Pharma\Pipeline_Q4_2024_Internal.pptx (44.1 MB)
# [14 additional LNK files, all network share paths, all within 90-minute window]

The LNK files were the unexpected bonus. Marcus had cleared the Prefetch and the browser history, but he had not cleared his Windows Recent items — the shortcut files that Windows creates automatically whenever a file is opened, and which record the full path of the target file including network share paths. Fourteen LNK files survived, all pointing to network share locations, all timestamped within a 90-minute window immediately preceding the rclone upload.

The picture the evidence painted was complete. CRM access for 40 Priority Tier 1 accounts, followed by a full export of contact details, followed by opening 14 large sales and pricing files from the network share, followed by 8.5 GB of outbound transfer via a renamed rclone binary to a MEGA account registered to a Proton Mail address. Then the cleanup. Then the laptop return two weeks later.

Reconstructed Timeline

What This Engagement Teaches Us

For Digital Forensic Examiners

1. Add SRUM.db to your standard collection checklist for every Windows 8+ investigation. It is at C:\Windows\System32\sru\SRUM.db, it requires the SOFTWARE registry hive to decode AppIDs meaningfully, and it must be acquired offline (VSS or image mount) because the operating system locks it on a live system. It retains ~30–60 days of per-application network usage regardless of whether the application still exists.
2. The SRUM retention window of 30–60 days means timing matters for collection. If you are engaged more than 60 days after the suspected exfiltration, SRUM may have already purged the relevant entries. Request device preservation immediately. Do not wait for the evidence to come to you.
3. An application appearing in SRUM with very high BytesSent and negligible BytesRecvd is a strong indicator of a one-way upload. Legitimate sync applications (OneDrive, Dropbox in sync mode) show roughly proportional send and receive. A 260:1 BytesSent:BytesRecvd ratio for an unknown executable in AppData\Temp is not a sync. It is an exfiltration.
4. Always enumerate VSS shadow copies when SRUM or other artifacts suggest deleted evidence. Configuration files, browser profiles, and recently deleted documents frequently survive in shadows even when the live filesystem has been cleaned.

For Security Engineers & Incident Responders

1. SRUM is a detection source, not just a forensic artifact. On a live system, parsing SRUM.db via a scheduled task or endpoint agent can identify applications transferring anomalous outbound data volumes in near-real-time — particularly useful for detecting renamed rclone or similar tools that evade name-based EDR rules.
2. Rclone exfiltration is ubiquitous in both insider threat and ransomware affiliate cases. Standard detection approaches (looking for ‘rclone.exe’ in process names or Prefetch) fail trivially against renamed binaries. Behavioral detection — looking for SRUM network usage anomalies, large outbound transfers to MEGA/Backblaze/Wasabi/S3-compatible endpoints — is more robust.
3. Windows Recent Items (LNK files) are frequently overlooked in anti-forensics cleaning. They persist in %APPDATA%\Microsoft\Windows\Recent\ and are not cleared by most commercial cleaning tools unless specifically configured. They record the full UNC path of network share files when accessed.
4. For HR and legal teams: a forensic image of the device before wipe is cheap insurance. The image in this case was taken as a standard procedure — not because the company suspected Marcus specifically. That image, and SRUM.db within it, was the difference between a civil case that settled within three months and one that could have dragged on for years without evidence.