Detecting ransomware encryption by behavior, not file extension
An earlier version of this post was an Elastic Watcher that alerted when files appeared with extensions like .locky, .encrypted or .crypt. It was a reasonable first attempt and it is not how I would do it now. This is the replacement.
Why extension lists fail
- The list is stale on arrival. Many current families generate a random extension per victim. A static list only catches the families that were already known when it was written.
- It fires too late to be precise. By the time one file has the extension, thousands do. An alert that triggers on any single match will produce one alert per file.
- It misses in-place encryption. Some families overwrite file contents and keep the original name.
File names are an attribute the attacker chooses. The behavior is not: to encrypt a file share, something has to touch a very large number of files in a very short time.
Detection 1: many file types become one
When ransomware runs, one process renames documents, spreadsheets, images and databases, and they all come out with the same new extension. Counting distinct extensions before and after separates that from ordinary bulk operations.
This version uses Defender for Endpoint file events in Microsoft Sentinel.
let window = 5m;
let min_renames = 200;
DeviceFileEvents
| where TimeGenerated > ago(1h)
| where ActionType == "FileRenamed"
| extend NewExt = tolower(extract(@"\.([^.\\]+)$", 1, FileName)),
OldExt = tolower(extract(@"\.([^.\\]+)$", 1, PreviousFileName))
| where isnotempty(NewExt) and NewExt != OldExt
| summarize Renames = count(),
Folders = dcount(FolderPath),
OldExts = dcount(OldExt),
NewExts = dcount(NewExt),
SampleNewExt = take_any(NewExt)
by DeviceName, InitiatingProcessFileName, InitiatingProcessId, bin(TimeGenerated, window)
| where Renames >= min_renames and Folders >= 10 and OldExts >= 3 and NewExts <= 2
The last line carries the logic. A process that renames at least 200 files across at least 10 folders, starting from three or more file types and ending with one or two, is either ransomware or something you want to know about anyway.
Tuning. Thresholds depend on the environment, so run it in report-only mode for a couple of weeks first. Expect hits from bulk file converters, photo and media tools, and some backup and sync agents. Exclude those by signed process and path, not by name alone. Endpoint agents also sample and cap high-volume file events, so the counts you see are a floor, not a total.
Detection 2: the same note in every folder
Ransomware usually drops a ransom note in each directory it touches. One file name created in dozens of folders on the same host within minutes is unusual enough to alert on, and it works even when the files are encrypted in place.
In Splunk, against the CIM Endpoint data model:
| tstats summariesonly=true dc(Filesystem.file_path) as folders count
from datamodel=Endpoint.Filesystem
where Filesystem.action=created Filesystem.file_name IN ("*.txt", "*.hta", "*.html", "*.url")
by Filesystem.dest, Filesystem.file_name, _time span=5m
| `drop_dm_object_name(Filesystem)`
| where folders >= 20
Tuning. Software installers and source control checkouts also create many identically named files, such as README.txt or LICENSE.txt. An exclusion list for those names on build servers and developer workstations is usually enough.
Detection 3: a canary file
The cheapest high-confidence signal is a decoy: a few files in a share that nobody has a reason to open, with file access auditing enabled on just those files. Any modification or rename is an alert. It needs no thresholds and no baseline, and it is the one I would add first on a file server.
Where this fits
All three of these are impact-stage detections. If one fires, the attacker has already had access for hours or days. They are the last line, and they are worth having because the lines before them sometimes fail. The earlier, cheaper catch is the preparation step: see catching shadow copy deletion before the encryption starts.
MITRE ATT&CK reference: T1486, Data Encrypted for Impact.