How do you detect mass file encryption?

Detect mass file encryption by scoring the shape of file activity per process rather than matching file names or hashes. A single process renaming or rewriting hundreds of files across many directories within minutes, especially to one or a few new extensions or with rising entropy, is the core signal. Compute it in your EDR or SIEM in short windows, exclude your known backup, sync and archive agents, and weight unsigned binaries in user-writable paths. Pair it with shadow-copy deletion and service-stop signals, and automate host isolation on a high-confidence score.

Detecting Mass File Encryption: Write, Rename and Entropy Bursts

Ransomware families change names, languages and encryption schemes every few months, but the act of encrypting data has to happen on the endpoint, and it looks the same each time: a single process reading, rewriting and often renaming hundreds or thousands of files across many directories in minutes. We build detections on that rate and breadth rather than on file names or hashes, because those are the first things an affiliate changes.

Signals at a Glance

Signal	Where	ATT&CK
One process renaming or rewriting hundreds of files across many directories in minutes	EDR file events, Sysmon 11/23	T1486
Many files renamed to the same new extension	EDR file rename events	T1486
Entropy of rewritten files rises to near-random	EDR content telemetry	T1486
Original file deleted or overwritten after a new copy is written	Sysmon 23/26, EDR	T1485
Burst touches network shares as well as local disks	SMB audit, EDR	T1486

Rate and Breadth

The strongest single feature is the combination of volume, directory spread and a small number of distinct extensions. Backup, sync and AV scanners also touch many files, so the aim is a score on shape, not a raw count. This hunt ranks processes by renames and directory spread in five-minute windows:

// Microsoft Defender / Sentinel (KQL) - rename bursts by process
DeviceFileEvents
| where Timestamp > ago(1h)
| where ActionType == "FileRenamed"
| extend oldExt = tolower(tostring(split(PreviousFileName, ".")[-1]))
| extend newExt = tolower(tostring(split(FileName, ".")[-1]))
| where oldExt != newExt
| summarize renames=count(), dirs=dcount(FolderPath), newExts=dcount(newExt),
            topExt=take_any(newExt)
          by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath,
             bin(Timestamp, 5m)
| where renames > 200 and dirs > 20 and newExts <= 3
| order by renames desc
// tune/validate: exclude your backup, sync and archive agents by path and signer.

Not every family renames. Some overwrite in place and keep the original name, so pair the rename hunt with a write-rate hunt keyed on the same process and on content entropy where your EDR exposes it:

// KQL - in-place rewrite bursts (no rename) from a single unsigned process
DeviceFileEvents
| where Timestamp > ago(1h)
| where ActionType == "FileModified"
| summarize modified=count(), dirs=dcount(FolderPath), exts=dcount(tolower(tostring(split(FileName, ".")[-1])))
          by DeviceName, InitiatingProcessFileName, InitiatingProcessSHA256, bin(Timestamp, 5m)
| where modified > 500 and dirs > 25 and exts > 10
// A document-wide rewrite across many extensions is the shape of an encryptor.
// tune/validate: thresholds depend on host role (file servers will be noisy).

Tuning and Response

Baseline per host role. A file server running backup or deduplication legitimately touches thousands of files; a laptop doing so from a binary in a user profile does not.
Weight unsigned or recently created binaries, and processes launched from user-writable paths, far above signed backup agents.
Treat share-side bursts as the same signal: encrypting over SMB shows up as one workstation writing to many shares, so correlate file-server audit with the source host.
Automate containment on a high-confidence score: isolate the host and disable the account, because every minute of encryption is more data lost. Pair this with the shadow-copy and service-stop signals for confidence.

Vetted sources

Use the SigmaHQ and Elastic ransomware behaviour rules, Splunk ESCU file-activity searches and MITRE CAR analytics as starting points, and the CISA #StopRansomware advisories for the surrounding tradecraft. Always baseline your own environment — backup, sync and deduplication software looks like ransomware to a naive threshold.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Rate and Breadth

Tuning and Response

Build Detections That Fire

Endpoint Ransomware Detection

Detection Hub

Canary File Detection