What does ransomware look like in the USN journal?

A sustained burst of DataOverwrite | Close records across thousands of files within a short window, followed by mass RenameNewName | Close events whose new names share an identical suffix or random extension. Some families also write the ciphertext to a new file and delete the original — a FileCreate of a same-stem-different-extension file paired with a FileDelete of the original in the same second.

Which MITRE ATT&CK technique maps to the encryption burst?

Primarily T1486 Data Encrypted for Impact for the DataOverwrite/RenameNewName burst itself, with adjacent techniques surfacing in nearby journal evidence: T1490 Inhibit System Recovery (Volume Shadow Copy deletion), T1485 Data Destruction, and T1083 File and Directory Discovery for the pre-encrypt enumeration.

Can the USN journal tell me which process ran the ransomware?

No. The journal records file lifecycle, not actor identity. Pair the encryption-burst timestamp with Security.evtx event 4663 (object access — requires SACLs configured ahead of time) or Microsoft-Windows-Sysmon/Operational event 11 (file create) to attach a process and user to the burst.

How do I tell ransomware apart from BitLocker conversion or backup software?

Three differentiators. BitLocker conversion produces continuous DataOverwrite but no RenameNewName — ransomware always renames. Backup software (Veeam, Macrium) hits a destination volume, not the source's user-profile directories. Office autosave bursts are transient; ransomware DataOverwrite rates stay monotonic until the host runs out of files.

What is shadow-copy deletion and does it show up in $UsnJrnl?

Shadow-copy deletion is the ransomware step that removes Volume Shadow Copies to prevent rollback. The actual VSS state lives in $WSC-managed namespaces and does not appear directly in $UsnJrnl. What you do see in the journal moments before the encrypt burst is FileCreate of vssadmin.exe-launched temp files and, on instrumented hosts, the corresponding Sysmon event 1 process-creation records.

Detecting ransomware activity in the USN journal

Ransomware is one of the cleanest signals you will ever read in the USN journal. Whatever the operator did upstream — credential theft, lateral movement, persistence implants, shadow-copy deletion — the encrypt phase touches the filesystem with a uniform, high-volume, monotonically increasing pattern that stands out from the surrounding noise even months later. Every operator I have ever responded to has tried to camouflage one part of the kill chain. Nobody has yet figured out how to camouflage encrypting tens of thousands of files in five minutes.

This post is the playbook for finding that pattern. The setup assumes you have already pulled $J and parsed it, and that the reason bitmask is no longer a mystery.

The canonical encrypt-phase pattern

Most modern ransomware (LockBit 3.0, BlackCat/ALPHV, Royal, Akira, the various post-Conti spin-offs, Play, Black Basta) follows the same three-step recipe per file:

Open the file for read.
Overwrite the content in place, or write a new file alongside and delete the original.
Rename to add a marker extension (.locked, .lockbit, an 8-to-16-character random string, or in a few families none at all).

In the journal that produces, per file:

DataOverwrite | Close
DataOverwrite | Close
...           ← one per write block
RenameOldName | Close   (old: document.docx)
RenameNewName | Close   (new: document.docx.locked)

Across thousands of files in a few minutes. The two diagnostic signals are:

Bursts of DataOverwrite within a short window. Normal Windows activity rarely produces sustained DataOverwrite on non-database files. Office save, browser cache compaction and IDE rebuilds produce transient spikes; ransomware produces a monotonic floor that does not let up until the host runs out of files to encrypt or the operator stops the binary.

Mass RenameNewName events with a tightly clustered new-name suffix. The ratio of RenameNewName to total active files explodes during encryption. The cluster signature — same fixed string, or same .{8} random pattern, on 80%+ of renames in the window — is what separates ransomware from any legitimate workload.

This corresponds primarily to T1486 Data Encrypted for Impact in MITRE ATT&CK, with adjacent journal evidence covering T1490 (Inhibit System Recovery) and T1485 (Data Destruction).

A detection recipe that holds up in court

Working through a parsed journal:

Histogram DataOverwrite per minute. Bucket by minute and look for the cliff. A baseline Windows host runs at single-digit DataOverwrite per minute. Encryption ramps to 50-500x that and stays there. Plot it or pivot in a spreadsheet — the shape tells you instantly.
Cluster RenameNewName events by new extension. Group on the new name's extension or on a regex over the new name. If 80%+ of renames in a window share an identical suffix or match the same fixed-length random pattern, that is an encryptor.
Pair FileDelete | Close with FileCreate of same-stem-different-extension. Some families (LockBit's older variants among them) write ciphertext to a new file and delete the original. Look for a FileCreate whose stem matches a recently deleted file, both in the same wall-clock second. Same FileReferenceNumber on the create as a recent rename is conclusive.
Walk the parent directories via $MFT. Resolve the parent reference for the affected files. Ransomware sweeps user profiles, mapped network drives and Users\Public\. A scope limited to a single subdirectory is much more likely to be Office autosave or a backup tool gone wrong.

The parser on this page exposes per-reason filtering directly. Set it to DataOverwrite for step 1 and RenameNewName for step 2. Steps 3 and 4 want a CSV export and a pivot table.

What it looks like on real data

A redacted excerpt from a LockBit 3.0 case I worked on:

2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameOldName Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameNewName Close   C:\Users\ana\Desktop\notes.docx.HLJkNskOq
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\quarterly.xlsx
...

Every file in the directory encrypted within the same wall-clock second. The new extension is a uniform nine-character random string — a strong cluster signal for step 2 and the marker LockBit 3.0 uses to bind ciphertext to the operator-specific keystream.

Beyond the encrypt phase

The journal also catches preparatory and cleanup behaviour around the burst.

Shadow-copy deletion is not visible in $J directly — VSS state lives in $WSC-managed namespaces — but operator-launched vssadmin.exe, wmic.exe shadowcopy delete, wbadmin.exe delete catalog and bcdedit.exe /set invocations all touch temp files in \Windows\Temp\ or \Users\<u>\AppData\Local\Temp\. Those FileCreate records appear moments before the encrypt burst. Pair with Sysmon event 1 for the actual process tree.

Discovery scans are mostly invisible to the journal — read-only directory enumerations produce nothing. But tool drops do. adfind.exe, PsExec.exe, BloodHound's SharpHound output and similar tooling produce FileCreate events in their working directories, usually in \ProgramData\, \Users\Public\ or \Users\<u>\AppData\Local\Temp\.

Ransom-note delivery. Every modern family drops a note in every encrypted directory. README.txt, HOW_TO_DECRYPT.html, restore-my-files.txt, family-specific names. A FileCreate of the same filename across many parent directories in the same minute is the lazy regex that catches the vast majority of them.

Pre-encrypt staging. Some operators stage exfil before encrypting — see the exfil detection post. Look for archive FileCreate events with .zip, .7z, .rar extensions in the hour before the encrypt burst.

What the journal will not tell you

The journal records changes, not actors. To attach a user or a process to the encrypt burst:

Security.evtx event 4663 (object access) — requires SACLs configured ahead of time, which they almost never are.
Microsoft-Windows-Sysmon%4Operational.evtx event 11 (file create) and event 1 (process create) — the gold standard if Sysmon was deployed.
Prefetch and AmCache for the ransomware binary itself, even after the operator deletes it.

For the broader response playbook, CISA's #StopRansomware guide is the authoritative reference.

Distinguishing ransomware from legitimate bursts

A few real workloads can superficially look like ransomware on the wrong filter:

BitLocker initial conversion produces continuous DataOverwrite but no RenameNewName. Ransomware always renames. If your RenameNewName count is flat, it is not ransomware.

Backup software (Veeam, Macrium, Acronis) produces DataOverwrite on the destination volume, not on the user's Documents and Desktop. Cross-check user and path.

Office autosave and Visual Studio rebuilds spike for a few seconds and stop. Ransomware is monotonic. The per-minute histogram makes that obvious.

Disk-image restoration writes large amounts of data but to a \\?\Volume{...} device path, not a user profile. The parent-directory resolution catches it.

If your detection logic produces zero alerts on a healthy baseline, it is underspecified. The signal you want is the combination of DataOverwrite rate, RenameNewName rate, and same-extension clustering — not any one of those alone.