What ransomware looks like in $MFT

Ransomware does roughly the same thing on every host, every time: enumerate files, read each one, write an encrypted copy, delete the original. Every step lands in $MFT. If you know what the shape looks like, you can confirm an incident is a ransomware run within minutes of getting the MFT, without ever finding the binary or reading the ransom note.

This is the pattern, the variations I have seen, and how I separate ransomware from other forms of mass file activity that look superficially similar.

The three signals

Extension changes en masse. A new file appears with the same parent directory and base name as an existing file, but with a different extension. report.docx becomes report.docx.locked, report.encrypted, report.crypted_{guid}, or report.docx.[victim_id].lockbit. Counting how many such pairs appear in a short window is one of the cleanest indicators of ransomware in $MFT. Hundreds in a minute, on a single user's profile or share, is the signature.

A burst of $STANDARD_INFORMATION created timestamps clustered within seconds. Normal user activity creates files in spurts of one or two. Ransomware creates them by the thousand. Plot SI created timestamps as a histogram across the suspected window and the encryption run shows up as a vertical spike that drowns out the baseline. The width of the spike tells you how fast the ransomware ran (multi-threaded modern variants finish a user profile in under a minute; older single-threaded ones take longer and the spike spreads).

Deleted originals matching encrypted duplicates. For each report.docx.locked there is typically a matching report.docx whose IN_USE flag is now cleared. The deleted record sits in $MFT until the slot is reused. You can recover the original's name, sizes, and timestamps from the deleted slot directly. Pair this with the $UsnJrnl FILE_DELETE reasons in the same window and the operation order becomes unambiguous.

Variations worth knowing

Not every family follows the same pattern. The variations I see:

• In-place encryption. Some families (older Sodinokibi variants, certain Conti builds) open the original file, write the encrypted bytes back into the same file, and rename. No separate "encrypted copy" file exists; the deleted-original pattern disappears. $UsnJrnl DATA_OVERWRITE for thousands of files in a minute is still loud, and the rename leaves a RENAME_OLD_NAME / RENAME_NEW_NAME pair.
• Intermittent encryption. BlackCat and several recent families encrypt only chunks of the file (every other 100 KB block, for instance) to speed up the run. The file size barely changes, the modification time updates, but the $DATA clusters are mostly intact. Looks lighter in $MFT but the USN journal still shows the writes.
• Renaming-only. A handful of "fake ransomware" wipers rename files without encrypting them. The MFT pattern is identical to a real ransomware run; only file content analysis tells the two apart.
• Network drive impact. Many families enumerate mapped drives and encrypt across the network. The local MFT shows fewer changes than you would expect for a real incident; the file server's MFT carries the bulk.

Ransom notes

Most families drop a ransom note in every affected directory, with a name like HOW_TO_DECRYPT.txt, README_FOR_DECRYPT.html, restore-files.txt, or a brand-specific variant. The notes have identical content, identical size, and creation times clustered within the same window as the encryption. Walking the MFT for many identical-size text or HTML files spread across many parent directories often finds them before any name pattern does.

The notes are also forensically useful as a baseline. Their creation time is essentially the "earliest moment ransomware was active in this directory" stamp. If a directory has a note dated 02:14 but encrypted files dated 02:09 in the same directory, the ransomware enumerated and encrypted before dropping the note. That tells you a little about the family's flow.

What $MFT does not tell you

The MFT confirms the what and when. It does not tell you which process did the writing, where the operator came in, or how the ransomware got onto the host. For those:

• Prefetch, Amcache, and Shimcache for evidence of which executable ran in the window.
• Sysmon Event ID 1 for process creation with command line, parent, and hashes.
• Security Event 4688 for process creation if command line auditing was enabled.
• USN journal $J for the precise order of file open/read/write/rename/delete operations.
• RAM dump if the machine is still live and the encryption process is still resident. Sometimes you get the encryption key in memory.
• Browser history and email artifacts for the initial access vector.

The MFT alone answers the urgent operational questions: when the run started, how widespread it is, and which files were touched. That is enough to make the recovery decision. Attribution is a separate exercise that uses the MFT as one input.

VSS deletion as a tell

Most ransomware families try to delete Volume Shadow Copies before they start encrypting, because VSS snapshots would let the victim restore without paying. The usual command is vssadmin delete shadows /all /quiet. This leaves:

• A Windows System Event Log entry (Event ID 8224 for VSS service messages).
• A Sysmon Event ID 1 for the vssadmin.exe invocation if Sysmon is deployed.
• The fresh-but-empty VSS state on the host. vssadmin list shadows returns nothing or only post-incident snapshots.

If you see a host with no VSS snapshots and \$Extend\$UsnJrnl MFT record sequence numbers indicating recent recreation, you have ransomware preparation even if the encryption run has not visibly started yet. See VSS and $MFT for what you might still recover.

The triage sequence I follow

1. Pull $MFT and $UsnJrnl:$J from the suspected host (or the snapshot, if VSS still has one from before).
2. Parse the MFT with MFTECmd or mft_dump. Sort SI created descending. Look at the top 1,000 entries.
3. If the top entries cluster within a window of minutes and many of them have unusual extensions, you have a ransomware footprint.
4. Pull the matching deleted records. Their $FILE_NAME attributes give you the original filenames. Now you know what was encrypted.
5. Cross-reference with the USN journal. FILE_CREATE for the encrypted file plus FILE_DELETE for the original at the same instant confirms the pattern.
6. Identify the ransom note: a small file with an unusual name (HOW_TO_DECRYPT, RECOVERY, README_RESTORE) appearing in many directories at the same time. Its content names the family.
7. Pivot from the family name to known IOCs: file hashes, C2 domains, registry persistence, and known kill chain artifacts in your other logs.

That sequence usually takes under thirty minutes on a single host and gives you enough to decide containment and start recovery planning.

Further reading

• The DFIR Report's ransomware case studies. Each writeup pairs MFT and journal evidence with the rest of the kill chain.
• LockBit, BlackCat, Cl0p technical analyses on The Record and Microsoft Security Blog. Family-specific MFT footprints differ in detail.
• MITRE ATT&CK, T1486 Data Encrypted for Impact. The technique catalog for what ransomware does and the artifacts each behavior leaves.