How to detect mass file encryption

Threat snapshot

Mass file encryption is the moment ransomware becomes visible to the victim. Every other stage of the kill chain, initial access, execution, defense evasion, lateral movement, is designed to stay hidden. The encryption phase is designed to be impossible to ignore. But by the time encryption is running, the attacker has already completed their positioning and the window for prevention has closed. What remains is containment: limiting how many files are encrypted, on how many hosts, before the process is stopped.

Log360 detects active encryption through the behavioral signatures that all file-encrypting ransomware families share regardless of their specific implementation. Every encryptor must open files, rename or replace them with encrypted versions, and repeat this process at scale. That high-velocity file system activity, far outside any normal business baseline, is what the detection rules target. A ransomware encryptor operating against a full drive generates file system events at rates that stand out immediately against any normal usage pattern.

This use case maps to T1486 (Data Encrypted for Impact) and covers three specific detection vectors: bulk file modification anomalies, suspicious file rename patterns consistent with encryption-in-progress, and ransom note creation. Together these give a SOC team multiple overlapping signals that an active encryption event is underway, each with slightly different timing in the attack sequence.

Mass file encryption, at a glance

How mass file encryption works

Ransomware encryptors follow a consistent operational pattern regardless of the specific cryptography they use. Understanding that pattern is what makes behavioral detection reliable even against new ransomware families with no prior signature.

File handle acquisition via Restart Manager

Before encrypting a file, the encryptor must be able to open it. Files that are currently open by running applications cannot be encrypted while those applications hold file handles. To work around this, modern ransomware encryptors load the Windows Restart Manager DLL (RstrtMgr.dll) to identify which processes are holding handles on target files, then terminate those processes or request that they release their handles. This behavior, a non-system process loading RstrtMgr.dll, is a reliable early indicator that an encryptor is about to begin operating on a host.

Bulk file modification

The core encryption operation generates file system events at a rate that is categorically different from normal user or application activity. An encryptor processing a 500GB volume of user files may generate thousands of file write and rename events per minute. Windows file audit logging (Event 4663) captures these events, and an anomaly rule comparing the current modification rate against a historical baseline flags the outlier immediately.

File rename patterns

Most ransomware encryptors rename files with a new extension after encrypting them, either replacing the original extension or appending a new one. LockBit appends a random extension. Dharma appends a structured identifier containing a victim ID and contact email. Makop appends a pattern including a random string and the ransomware family name. These rename events appear as file rename operations in the Windows audit log and generate a detectable pattern when they occur at high velocity and with consistent new extension formatting.

Ransom note creation

After encrypting files in a directory, most encryptors create a ransom note file in that directory. The note is typically an HTML or text file with a consistent name across all directories (e.g., README.txt, DECRYPT_FILES.html, RESTORE_FILES.txt). An encryptor working through a file tree will create the same filename in hundreds of directories within a short window, generating a pattern of identical filename creation events across many paths that has no legitimate analogue in normal business activity.

Real-world campaigns

LockBit: high-speed encryption with random extension appending

LockBit is documented as one of the fastest ransomware encryptors, with encryption of large volumes completing in under an hour. It appends a random alphanumeric extension to encrypted files and creates a ransom note named after the extension in every directory it processes. The combination of high-velocity file rename events and uniform ransom note creation across hundreds of directories simultaneously is the behavioral signature that Log360's bulk file modification rule catches.

Dharma/CrySiS: structured extension with victim identifier

Dharma appends a structured extension pattern containing a victim ID, attacker email address, and the family identifier (e.g., .id-[victimID].[email].dharma). This consistent structure across all renamed files makes the rename pattern recognizable even before the rename rate itself triggers a threshold-based rule. Dharma typically operates more slowly than LockBit, which means threshold-based rules may take longer to fire; pattern-based rename detection catches it earlier.

Makop: RstrtMgr.dll loading as an early indicator

Makop and several other ransomware families explicitly load RstrtMgr.dll as part of their pre-encryption file handle management. Process creation and DLL load monitoring can catch this behavior before any files are encrypted, providing a brief window where isolation can prevent encryption entirely rather than just limiting its scope.

Business impact

• Every second of detection delay translates directly to additional encrypted files: An active encryptor operating at typical speeds can encrypt tens of thousands of files per minute on a high-performance host. A five-minute detection delay on a single host may mean hundreds of thousands of encrypted files that cannot be recovered without either the attacker's decryption key or a clean backup.
• File server hosts amplify the damage dramatically: An encryptor running on a file server with access to shared network drives encrypts files on behalf of every user whose data is stored on that server. The blast radius of a single file server compromise is proportional to the volume of data it hosts.
• Ransom note creation confirms encryption is already complete in those directories: By the time a ransom note is created in a directory, every file in that directory has already been encrypted. Ransom note detection confirms active encryption but cannot be used to prevent encryption in directories where notes have already been written.

Detecting mass file encryption with Log360

The rules below target the specific behavioral signals generated by file-encrypting ransomware. For file audit events to be captured, Windows Object Access auditing must be enabled for file system objects on the monitored volumes. Without file audit logging enabled at the volume level, the bulk modification and rename pattern rules cannot fire.

Attack chain visibility

Investigation playbook

Step 1: Confirm active encryption and scope

• Query Log360 for the volume and rate of file modification events on the alerting host. Identify when the rate spike began, which process is generating the file events, and which directories are being affected. The process name and path generating bulk file events is the encryptor binary.
• Check whether the file events show a consistent new extension being appended to renamed files. If so, search the Log360 alert history for the same extension pattern on other hosts, which would indicate the encryptor has already been distributed via lateral movement.
• Identify which user account owns the process generating the file events. If it is a SYSTEM or service account, the encryptor was likely deployed via a remote service installation (PsExec pattern). If it is a user account, that account's credentials have been compromised and used to run the encryptor interactively or via a scheduled task.

Step 2: Determine blast radius across the environment

• Query all hosts in the environment for the same encryptor binary hash or process name identified in step 1. Lateral movement prior to encryption typically means the encryptor binary was distributed to many hosts before execution was triggered. Hosts that have the binary but have not yet started encryption are still preventable.
• Check whether file servers or hosts with high-volume shared storage are affected. Encryption running on a file server affects all connected users' files, not just the files local to the server host. Identify all network share connections to the affected host.

Step 3: Assess recoverability

• Query the shadow copy deletion detection rules (Disabled Volume Snapshots, Diskshadow Script Mode) for events on the affected hosts. If shadow copies were deleted prior to encryption, local recovery is not available.
• Contact the backup team immediately to verify whether the most recent clean backup predates the attacker's initial access. If the attacker had dwell time before encryption, backups taken during the dwell period may themselves contain attacker tooling.

Response and remediation

Immediate actions

• Network isolation takes priority over everything else: Disconnect the host from the network before any other action. An encryptor running on an isolated host can only encrypt local files. An encryptor running on a network-connected host may be accessing network shares and encrypting files on behalf of other users simultaneously.
• Do not kill the encryptor process while the host is still network-connected: Terminating the encryptor process may trigger additional destructive payloads in some ransomware families. Isolate first, then assess whether terminating the process is appropriate.
• Identify and isolate all hosts where the same encryptor binary is present: If lateral movement preceded encryption, multiple hosts may have the binary staged but not yet executing. Isolating those hosts before execution begins is the highest-impact containment action available.

False positive tuning