← Back to blog

Detecting ransomware activity in the USN journal

Even when the binary is gone, ransomware leaves a very distinctive fingerprint in $UsnJrnl:$J. A walkthrough of the patterns to look for, with the matching reason-code combinations.

4 min read

Ransomware is one of the cleanest signals in the USN journal. Whatever else an operator did — credential theft, lateral movement, persistence — the encrypt phase touches the filesystem with a uniform, high-volume pattern that stands out even months later. This post walks through what that pattern looks like and how to find it.

The setup assumes you have already pulled the $J and parsed it (the parser on this page works; so do usnrs and others). If you need a refresher on the reason bitmask, our reason-code post is the field reference.

The canonical pattern

Most modern ransomware (LockBit, BlackCat/ALPHV, Royal, Akira, the post-Conti variants, etc.) follows the same three-step recipe per file:

  1. Open the file for read.
  2. Overwrite the content in place — or write a new file alongside and delete the original.
  3. Rename to add a marker extension (.locked, .lockbit, a random 8-char string, or none at all for some families).

In the journal that produces, for each file:

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

The two distinctive signals are:

  • Bursts of DataOverwrite within a short window across thousands of files. Normal file activity rarely produces continuous DataOverwrite for non-database files.
  • Mass RenameNewName events with identical new-extension tails. The ratio of new-name records to total active files explodes during encryption.

For mappings to MITRE ATT&CK techniques, this corresponds primarily to T1486 Data Encrypted for Impact and adjacent renaming behaviours.

A practical detection recipe

Working through a parsed journal:

  1. Histogram the DataOverwrite events per minute. Plot them or just bucket by minute and look for the cliff. Normal Windows hosts show a steady low baseline (a handful per minute) interrupted by application bursts (Office save, Chrome cache). Ransomware shows a sustained 50–500× spike that does not stop until the host runs out of files.
  2. Cluster the RenameNewName events. Group by their new extension or by a regex over the new name. If 80% of renames in a window have the same suffix or the same .{8} pattern, you're looking at an encryptor.
  3. Cross-check FileDelete | Close. Some families write the cipher to a new file and delete the original. Pair this with a FileCreate of a same-stem-different-extension file emitted in the same second.
  4. Pull the parent directory. Ransomware that encrypts every directory under the user profile or every share will hit Users\<user>\Documents, Users\<user>\Desktop, every mapped drive root. The MFT-resolved full paths make this trivial.

The parser on this site exposes the reason filter directly — set it to DataOverwrite for step 1 and RenameNewName for step 2.

What the data looks like

A redacted excerpt from a real LockBit 3.0 case:

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 is encrypted within the same wall-clock second. The new extension is a uniform 9-character random string — strong cluster signal for step 2.

Beyond the encrypt phase

The journal also catches preparatory and cleanup behaviour:

  • Shadow copy deletion: not actually visible in $J (lives in $WSC-managed namespaces), but a FileCreate of vssadmin.exe-launched temp files appears moments before the encrypt burst.
  • Discovery scans: many families enumerate the volume by directory listing, which produces no journal entries — but if the operator dropped tools like adfind.exe or PsExec.exe, you'll see their FileCreate events.
  • Note delivery: every modern family writes a ransom note in every encrypted directory. A FileCreate of the same filename (README.txt, HOW_TO_DECRYPT.html, etc.) across many directories in the same minute is the lazy regex that catches most of them.

What the journal won't tell you

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

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

A note on baseline noise

A few legitimate behaviours look superficially like ransomware:

  • Disk-level encryption deployment (BitLocker initial conversion) produces a continuous DataOverwrite burst — but it does not produce RenameNewName events. Easy false positive to rule out.
  • Backup software like Veeam or Macrium can produce DataOverwrite bursts on the destination volume. Always cross-check the user/path.
  • Office's autosave or Visual Studio rebuilds burst briefly. The minute-level histogram makes them obvious — they're transient, ransomware is monotonic.

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