Detecting data exfiltration and USB copying with the USN journal

After ransomware, the second-most-common DFIR question is some variant of "did anything walk out of here?". The USN journal is one of the cheapest places to start answering it. Every USB copy, every cloud-sync upload and every drop-everything-in-a-temp-folder-then-zip operation leaves a recognisable shape in $J — recognisable enough that with two filters and a parent-path pivot you can usually triage a candidate exfil window in under twenty minutes.

This post is the playbook for finding those patterns, broken down by exfil channel.

USB drives leave the cleanest trail

When a user attaches a removable volume, Windows assigns it a drive letter and, if the volume is NTFS, the device gets its own $UsnJrnl. Files copied to the USB land in the destination journal as FileCreate | Close plus a stream of DataExtend | Close records. Files copied from the source disk leave a softer trail on the source side: open and close events that often produce BasicInfoChange | Close from AV scanning and file-system caching that follows the read.

What you typically have on a real engagement:

• The source disk's journal. Shows what was opened, any temp or archive files created, and the final delete sweep if the user tidied up.
• The registry hives. SYSTEM\MountedDevices, SYSTEM\CurrentControlSet\Enum\USBSTOR, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2, and setupapi.dev.log together identify which physical device was attached and when. Parse them with the registry parser.
• The destination volume's journal, if you have the USB image. This is where the actual file writes live.

The decisive signal on the source side is the archive-before-copy pattern, because most users with anything to hide reach for 7-Zip or Explorer's built-in compression before they walk the drive out: a FileCreate of a .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 path is usually \Users\<u>\AppData\Local\Temp\, \Users\<u>\Desktop\ or the root of the user profile.

For the USB identification side, cross-reference the timestamps in the journal against Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx events for connection/disconnection — the EVTX parser makes this a few-clicks job. Pair with LNK files under \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ and jump lists for explicit user-opened-from-USB evidence.

The classic staging-then-archive pattern

Maps to T1074 Data Staged in MITRE ATT&CK and looks like this on disk:

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 in sequence:

1. A burst of FileCreate in a single staging directory.
2. A subsequent FileCreate plus rolling DataExtend on a single archive, whose final size approximates the sum of the staged files.
3. A delete sweep of the staging directory shortly after the archive is closed.

Each signal alone is noisy. Combined, they are diagnostic. Filter for FileCreate in \AppData\Local\Temp\, \Users\Public\, \Downloads\ and other writable user-tree locations, then cluster by parent directory and look for >50 creates inside 60 seconds. That cadence catches insider-theft staging and most infostealer workloads. Drop known build paths (node_modules\, target\, Debug\, Release\, obj\, .next\, dist\) from the filter; they produce identical-shaped bursts and will dominate your results otherwise.

Cloud-sync staging

OneDrive, Dropbox, Google Drive and Box all maintain a local sync folder and push everything inside it the moment the agent picks it up. The journal exposes two diagnostic patterns:

Bulk RenameNewName into the sync folder. The new parent is \Users\<u>\OneDrive\, \Users\<u>\Dropbox\, \Users\<u>\Google Drive\ or \Users\<u>\Box\; the old parent is Desktop\, Documents\ or Downloads\. The rename half-pair preserves the file's original parent reference, which means you can prove provenance even after the file is gone.

DataExtend | Close on files inside the sync folder without a corresponding user-app FileCreate. These are the agent itself writing — downloads from the cloud-side to the local copy. The creates are what you want for the upload direction. Background sync agents like OneDrive.exe and Dropbox.exe also write log files in their AppData\Local\ subdirectories, which gives you another way to bracket the activity if the rename evidence is sparse.

Less common but worth knowing: some operators script a Copy-Item into a junction or symlink that points at the cloud folder, which produces ReparsePointChange records in addition to the rename pair.

BITS, native upload tools and living-off-the-land exfil

A pattern I have seen more often in recent ransomware engagements: the operator uses bitsadmin.exe or PowerShell's Start-BitsTransfer to push files out, sometimes to attacker-controlled cloud storage with valid certificates. The journal shows:

• FileCreate of BITS job state files under \ProgramData\Microsoft\Network\Downloader\ (matching qmgr.db, qmgr0.dat, qmgr1.dat).
• For uploads, the source files staged into \Users\<u>\AppData\Local\Microsoft\BITS\ immediately before the transfer.

Pair with Microsoft-Windows-Bits-Client%4Operational.evtx event IDs 59 (job created), 60 (job transferred) and 61 (job complete) — the EVTX bridge for BITS exfil is one of the cleanest pieces of correlation available.

Similar story for rclone.exe and MEGAsync.exe. These produce predictable file-create signatures in their app directories and log files; check \Users\<u>\AppData\Roaming\rclone\ for the configuration that lists the destination.

Heuristics that earn their keep

After enough engagements, the heuristics that consistently flag real exfil:

Burst-of-creates. More than N FileCreate events in a single directory within T seconds. Tune to baseline; N=50, T=60 is the starting point for desktop hosts.

Archive-after-burst. A single FileCreate of a file with .zip, .7z, .rar, .tar.gz, .tar.zst or .iso extension within minutes of a burst-of-creates, with rolling DataExtend accumulating to multi-MB. The archive size roughly matches the cumulative staged-file size.

Mass-rename across directory boundaries. RenameNewName records whose new parent path is structurally different from the old — Documents\ to OneDrive\, Desktop\ to Users\Public\, Downloads\ to \AppData\Local\Microsoft\BITS\. Easy to express as regex on the MFT-resolved full paths.

Off-hours bursts. Any of the above outside the user's normal business hours. Cross-reference with Security.evtx 4624 logons for the actual session boundaries.

Delete sweep after archive. A FileDelete cluster on the staging directory after the archive is closed. This is the user trying to tidy up. The cluster shape — many files deleted within seconds, all sharing a parent — is unusual outside of dev/build workflows.

The parser on this page exposes time-window and per-reason filters that make burst detection and rename clustering a click each. For off-hours analysis, export to CSV and pivot on hour-of-day.

What you will not see in $UsnJrnl

A few real exfiltration techniques produce no useful USN signal:

• Direct upload from memory via a browser POST, Invoke-WebRequest -InFile from a variable, or curl piping from Get-Content. Nothing lands on disk.
• Reading from a network share the source side does not own. The journal on your host has nothing because the file did not live there.
• Screen capture as exfil. Only the screenshot files land on disk; the actual data leaves via the rendered image.
• Printing. Leaves only \Windows\System32\spool\PRINTERS\ activity, which is its own forensic artefact.
• DNS or ICMP tunnelling. Nothing touches disk; pivot to network captures and Sysmon event 3.

For these, pivot to EVTX, Sysmon network connections (event 3), browser history, SRUM for per-process network bytes, RAM dumps, or PRINTERS spool artefacts. The MITRE ATT&CK Exfiltration tactic page lists every technique with notes on where it actually leaves residue.

A worked example

The kind of CSV you might export from a real engagement to demonstrate exfil:

That timeline is a smoking gun. Without the journal you would reconstruct it from the registry, Prefetch, shadow copies and OneDrive's own logs — five times the work, half the confidence.

Further reading

• MITRE ATT&CK — the Exfiltration tactic and T1074 Data Staged for the full taxonomy.
• CISA, insider threat resources — the baseline assumptions and detection thresholds in their playbook are close to what holds up in a real corporate environment.
• The DFIR Report — multiple long-form intrusions document the exfil-then-encrypt pattern step by step, with USN evidence in the timeline. The closest thing to a public ground-truth corpus for what these patterns look like in practice.