Most ransomware does roughly the same thing on disk: enumerate files, read each one, write an encrypted copy alongside, and delete the original. Every one of those steps shows up in $MFT.
The three telltale patterns
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 or report.encrypted or report.{guid}. Counting how many such pairs appear in a short time window is one of the cleanest ransomware indicators in $MFT.
A burst of SI-created timestamps clustered within seconds. Normal user activity creates files in spurts of one or two at a time. Ransomware creates hundreds or thousands. Plot SI-created timestamps as a histogram and the attack window shows up as a vertical spike.
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 reused. You can recover the names, sizes, and timestamps of the originals from those slots.
What $MFT does not tell you
$MFT confirms the what and when. It does not tell you which process did the writing. For that you need:
- Prefetch and ShimCache for evidence of which executable ran
$UsnJrnlto see the order of file create/delete/rename operations- Memory forensics if the machine is still live and the process is still resident
But $MFT alone often answers the most urgent questions: when the attack started, how widespread it is, and which files were touched.
A note on ransom note files
Most families drop a ransom note in every affected directory, with a name like HOW_TO_DECRYPT.txt or README_FOR_DECRYPT.html. These notes have identical content, identical sizes, and creation times tightly clustered. Walking $MFT for many identical-size text files spread across many directories often finds them before any name pattern does.