Data Encrypted for Impact

This is what most people actually mean when they say "ransomware": an adversary encrypting files on a system, deliberately making them unusable, typically as leverage for extortion. It's the final, visible act of many destructive intrusions, the moment an attack stops being invisible and becomes a business-halting emergency.

Unlike most techniques on this platform, this one isn't subtle by the time it's discovered. The goal isn't to stay hidden, it's to be unmissable, since the whole point is forcing a response. But the setup leading to this moment, gaining access, moving through the network, positioning for maximum impact, often happens quietly for hours or days before the encryption itself begins.

By the time file encryption actually starts, an attacker has usually already done the hard work: gained access, escalated privileges, mapped out what's valuable, and often already stolen a copy of sensitive data before encrypting anything (so they can threaten to leak it too, not just hold it hostage). The encryption itself is often fast and automated, deployed across many hosts at once to maximize damage before anyone can react.

The technical signature is usually a burst of file-write and rename activity across many files in a short window, often accompanied by a new, unfamiliar file extension appended to everything that got touched, and frequently a ransom note dropped into affected directories.

Data source: endpoint process-creation telemetry (Sysmon Event ID 1) whose command line names the target share and new extension, plus PowerShell script-block logs (Event ID 4104)

{
  "file": {
    "path": "C:\\Users\\Shared\\report.docx.locked",
    "extension": "locked"
  },
  "host": {
    "name": "FILE01"
  },
  "event": {
    "action": "modification",
    "category": "file"
  },
  "process": {
    "name": "encryptor.exe"
  }
}

Prebuilt Elastic rule: Ransomware - Detected - Elastic Defend

Hunting for this after the fact means looking at what already happened rather than catching it in progress; a real encryption event is usually already an emergency by the time anyone's searching logs for it. Filter file-modification events for an unusually high count against a single process.entity_id in a short window, then check what that process actually is and where it came from (its parent process, its file path) to understand how it got there.

The ransom note, if one was dropped, is often the fastest confirmation: a new text or HTML file appearing in the same directories as the encrypted files, usually with an unmissable name.

Legitimate backup software, disk encryption tools, and some data-protection utilities can produce a burst of file-write activity that superficially resembles this pattern, which is exactly why Elastic's guidance calls out whitelisting verified tools rather than trusting volume alone.

The distinguishing signal is usually the file extension pattern and the ransom note: legitimate encryption tools don't rename files to obscure, randomized extensions across an entire directory tree, and they don't drop a note demanding payment. Coordinated security testing that deliberately simulates ransomware is the other common false positive, which is why coordinating test windows with the security team matters.

• MITRE ATT&CK T1486: Data Encrypted for Impact
• Elastic Security: Ransomware - Detected - Elastic Defend

1 scenario in this catalog covers T1486. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →