Detecting data exfiltration and USB copying with the USN journal

After ransomware, the second-most-common DFIR question we hear is "did anything walk out of here?". The USN journal is one of the cheapest places to answer it. It records every create, every rename, every data extend — which means that USB exfil, cloud-sync staging, and the classic "drop everything in a temp folder before zipping" all look very distinctive when plotted on a timeline.

This post is the playbook for finding those patterns.

USB drives are easy mode

When a user attaches a removable volume, Windows assigns it a new drive letter and the file system on the device gets its own $UsnJrnl if it is NTFS. But when files are copied from the system you're investigating to the USB, the source volume's journal still records the read side as a series of accesses — and, more importantly, the destination journal (if you have the USB image) shows the writes.

What you typically have:

• The source disk's journal — shows what was opened/closed and any temporary files.
• The registry hives — SYSTEM\MountedDevices, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 and Setup hardware events to identify which USB was connected.
• The destination volume's journal, if the device was NTFS and you can image it — this is where you see the actual files.

The first signal on the source side: a cluster of file opens in a tight time window targeting the user's documents/desktop/downloads tree. Opens don't always produce USN records, but the file system caches and AV scans that follow them often do (touching attributes triggers BasicInfoChange | Close).

A more decisive signal arrives if the attacker zips the data first: a FileCreate of an .7z, .zip, .rar or random-named file at a temp path, followed by sustained DataExtend | Close records until the file reaches its final size.

The classic staging-then-copy pattern

A common pattern, mapped to T1074 Data Staged in MITRE ATT&CK:

FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
DataExtend | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\customers.csv
DataExtend | Close   ...
…
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3.zip
DataExtend | Close   ...           ← lots of these, file grows large
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (cleanup)

Three signals together:

• A burst of FileCreate in a single staging directory.
• Subsequent DataExtend on a single archive whose final size approximates the sum of the staged files.
• A delete sweep of the staging directory shortly after the archive is created.

Filter for FileCreate in \AppData\Local\Temp\, \Public\, \Downloads\ or other writable user-tree locations, and look for clusters in time of >50 files in <60 seconds. This is what insider-theft and infostealer-malware operations look like on disk.

Cloud-sync staging

OneDrive, Dropbox, Google Drive — all maintain a local sync folder. Anything dropped in it gets uploaded the moment the agent picks it up. Two signals:

• Bulk RenameNewName into the sync folder from Desktop\, Documents\ or Downloads\. The rename half-pair tells you the file's prior parent; the new parent is the sync folder.
• DataExtend | Close on files inside the sync folder that did not have a corresponding FileCreate from any user app. The sync agent itself writes these — i.e., these are downloads — but the creates are what you want for uploads.

If you want a name-based filter, the canonical sync directories on Windows are \Users\<u>\OneDrive\, \Users\<u>\Dropbox\ and \Users\<u>\Google Drive\. Tools listed in the CISA TLP-WHITE insider threat resources have similar baseline assumptions.

Heuristics that actually work

After several engagements, the heuristics that tend to flag real exfil are:

1. Burst-of-creates: more than N FileCreate events in a single directory within T seconds. Tunable to baseline. We start at N=50, T=60.
2. Archive-after-burst: a single FileCreate of a file with a known archive extension (.zip, .7z, .rar, .tar.gz) within minutes of a burst-of-creates, with subsequent DataExtend accumulating to a multi-MB size.
3. Mass-rename across boundaries: RenameNewName records whose new parent path is structurally different from the old (Documents → OneDrive, Desktop → Public, etc.). Easy to express as a regex on the resolved full paths.
4. Off-hours bursts: any of the above outside of business hours for that user. Pair with the user's Security.evtx logon events for confirmation.

The parser on this site exposes time-window filtering and per-reason filters that make 1–3 a click each. For (4), export to CSV and pivot on hour-of-day.

What you won't see

A few real exfiltration techniques produce no useful USN signal:

• Direct upload from memory via a browser or PowerShell — the data never lands on disk, so the journal has nothing.
• Reading a network share — the source side is whatever filesystem the share lives on, often not yours.
• Screen capture as exfil — produces only the creation of one or two image files.
• Printing — leaves only \Windows\System32\spool\PRINTERS\ activity, which is its own forensic artefact, not really a USN concern.

For a fuller threat-model perspective, the MITRE Exfiltration tactic page lists every technique and where it leaves residue. USN handles maybe a third of them directly; the rest need event logs, network captures, or browser history.

Working example

Here's the kind of CSV you'd export from a real engagement to demonstrate exfil:

That timeline is a smoking gun. Without the journal, you'd have to reconstruct it from the registry, Prefetch, and shadow copies — five times the work, half the confidence.