T1486Impact

Data Encrypted for Impact

The final stage of a ransomware intrusion: mass file encryption. By the time files are locked it is late, but the encryption burst itself is detectable. Here is the behavior and the rules that catch it early.

Run it live: Ransomware Detection & Recovery

A container range where a real AES encryptor locks a victim's files, a poll-based EDR flags the .locked burst and ransom note, and a reset restores from backup. Detonate it from a button and watch the EDR fire.

Launch it

Data Encrypted for Impact is the payload, the moment a ransomware crew converts access into leverage by encrypting files across the environment. Everything before it (phishing, credential theft, lateral movement) exists to reach this step at scale. Detecting the encryption itself is a last line, but it is a real one: mass encryption has a loud, unusual signature that normal user activity does not.

What it looks like

A single process opening, reading, and rewriting a large number of files in quick succession.
New file extensions appearing in bulk (.locked, .encrypted, or a random string).
A ransom note written into many directories (README.txt, HOW_TO_DECRYPT.html).
A spike in file-write throughput and, often, deletion of shadow copies (vssadmin delete shadows).
High Shannon entropy on the rewritten files, the fingerprint of encryption.

Detect it: Sigma (shadow-copy deletion, the reliable precursor)

sigma / ransomware-shadowcopy-deletion.yml

title: Shadow Copy Deletion via VSSAdmin or WMIC
id: 0f1a2b3c-lock-4d5e-6f70-tyrian000002
status: stable
logsource:
  category: process_creation
  product: windows
detection:
  vssadmin:
    Image|endswith: '\\vssadmin.exe'
    CommandLine|contains|all:
      - 'delete'
      - 'shadows'
  wmic:
    Image|endswith: '\\wmic.exe'
    CommandLine|contains: 'shadowcopy delete'
  condition: vssadmin or wmic
level: high
tags:
  - attack.impact
  - attack.t1486
  - attack.t1490

Deleting shadow copies is one of the most reliable pre-encryption signals: legitimate software almost never does it, and ransomware almost always does, to stop you rolling back. Pair it with a behavioral rule on mass file modification so you catch families that skip the vssadmin step.

Detect it: Wazuh (mass file change via FIM)

wazuh / ossec.conf + local_rules.xml

<!-- 1. Watch the data directory in near real time (ossec.conf) -->
<syscheck>
  <directories check_all="yes" realtime="yes">/srv/data</directories>
  <frequency>10</frequency>
</syscheck>

<!-- 2. Alert on a burst of modifications (local_rules.xml) -->
<group name="ransomware,attack,">
  <rule id="100486" level="12" frequency="30" timeframe="60">
    <if_group>syscheck</if_group>
    <field name="syscheck.event">modified</field>
    <description>Possible ransomware: mass file modification burst (T1486)</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>

  <rule id="100487" level="13">
    <if_group>syscheck</if_group>
    <field name="syscheck.path">\.locked$|\.encrypted$|README.*DECRYPT</field>
    <description>Ransomware artifact: encrypted extension or ransom note written</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>
</group>

Respond

Isolate the host the moment the burst rule fires, before it reaches file shares.
Kill the encrypting process by name/hash and preserve it for analysis.
Restore from an offline or immutable backup; test that restore before you need it.
Hunt backward for the entry point, encryption is the end of a chain you can shorten next time.

Tyrian's Ransomware Detection & Recovery scenario runs a real AES encryptor against a victim's files, raises EDR alerts on the .locked burst and ransom note, and restores from a one-time backup on reset. You arm and detonate it from the browser, so you can test your own detection and recovery timing safely.

Test this detection on your own SIEM

Launch the Ransomware Detection & Recovery range, fire T1486, and measure how fast you catch it. $5 free credit, no card.

Start free More techniques