T1486

Data Encrypted for Impact

Impact Last updated:

Adversaries may encrypt data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources. They can attempt to render stored data inaccessible by encrypting files or data on local and remote drives and withholding access to a decryption key. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key (ransomware) or to render data permanently inaccessible in cases where the key is not saved or transmitted. In the case of ransomware, it is typical that common user files like Office documents, PDFs, images, videos, audio, text, and source code files will be encrypted and often renamed or tagged with specific file markers. Adversaries may also encrypt critical system files, disk partitions, MBR, virtual machines hosted on ESXi, or cloud storage objects.

What is T1486 Data Encrypted for Impact?

Data Encrypted for Impact (T1486) maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data in MITRE ATT&CK.

This page provides production-ready detection logic for Data Encrypted for Impact, covering the data sources and telemetry it touches: File: File Modification, File: File Creation, Command: Command Execution, Process: Process Creation, Microsoft Defender for Endpoint. The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Impact
Technique
T1486 Data Encrypted for Impact
Canonical reference
https://attack.mitre.org/techniques/T1486/
Microsoft Sentinel / Defender
kusto
let TimeWindow = 1h;
let RenameThreshold = 50;
let ShadowDeleteCommands = dynamic(["vssadmin delete shadows", "vssadmin.exe delete shadows", "wmic shadowcopy delete", "bcdedit /set {default} recoveryenabled no", "bcdedit /set {default} bootstatuspolicy ignoreallfailures", "wbadmin delete catalog", "wbadmin delete systemstatebackup"]);
// Detection 1: Mass file rename/encryption activity
let MassRename = DeviceFileEvents
| where Timestamp > ago(TimeWindow)
| where ActionType in ("FileRenamed", "FileModified", "FileCreated")
| where FileName endswith_any (".encrypted", ".locked", ".crypt", ".enc", ".ransom", ".cry", ".lock64", ".cuba", ".avos", ".avos2", ".play", ".blackbyte")
| summarize
    RenamedFiles = count(),
    UniqueExtensions = dcount(FileName),
    FileTypes = make_set(tostring(split(FileName, ".")[-1]), 10),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessId, InitiatingProcessCommandLine
| where RenamedFiles > RenameThreshold;
// Detection 2: Shadow copy deletion and recovery sabotage
let ShadowDelete = DeviceProcessEvents
| where Timestamp > ago(TimeWindow)
| where ProcessCommandLine has_any (ShadowDeleteCommands)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName;
// Combine both signals
MassRename
| join kind=leftouter (ShadowDelete) on DeviceName
| extend ShadowsDeleted = isnotempty(ProcessCommandLine)
| extend RansomwareConfidence = case(
    RenamedFiles > 500 and ShadowsDeleted, "critical",
    RenamedFiles > 200 or ShadowsDeleted, "high",
    RenamedFiles > RenameThreshold, "medium",
    "low")
| project FirstSeen, LastSeen, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RenamedFiles, UniqueExtensions, FileTypes, ShadowsDeleted, RansomwareConfidence
| sort by RenamedFiles desc

Detects ransomware activity through two correlated signals: (1) mass file encryption indicated by high volumes of file renames to known ransomware extensions (.encrypted, .locked, .crypt, .lock64, .cuba, .avos, .play, .blackbyte), and (2) volume shadow copy deletion and recovery sabotage via vssadmin, wmic, bcdedit, and wbadmin. Correlates both signals on the same device for high-confidence ransomware detection. A combined signal (mass rename + shadow delete) is rated critical.

critical severity high confidence

Data Sources

File: File Modification File: File Creation Command: Command Execution Process: Process Creation Microsoft Defender for Endpoint

Required Tables

DeviceFileEvents DeviceProcessEvents

False Positives

  • Legitimate encryption tools (BitLocker, VeraCrypt, 7-Zip) encrypting large numbers of files during backup operations
  • File migration or archival tools that rename files with new extensions during processing
  • Anti-ransomware tools that create decoy/canary files with ransomware-like extensions for honeypot detection
  • Disaster recovery testing that involves intentional shadow copy deletion as part of DR exercises

Sigma rule & cross-platform mapping

The detection logic for Data Encrypted for Impact (T1486) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Volume Shadow Copy Deletion via vssadmin

    Expected signal: Sysmon Event ID 1: Process creation for vssadmin.exe with 'delete shadows /all /quiet' command line. Windows Security Event ID 4688 with same details. VSS Event ID 8224 in System log confirming shadow deletion.

  2. Test 2Recovery Sabotage via bcdedit

    Expected signal: Sysmon Event ID 1: Two process creation events for bcdedit.exe with /set commands. Windows Security Event ID 4688 with command line auditing. Registry modification events for BCD store changes.

  3. Test 3Mass File Encryption Simulation

    Expected signal: Sysmon Event ID 11: 100 file creation events for .docx files, followed by 100 file rename events to .docx.encrypted. The burst of file operations in a short time window from a single process is the key telemetry pattern.

  4. Test 4Ransom Note Drop Simulation

    Expected signal: Sysmon Event ID 11: 10 file creation events for README_DECRYPT.txt in different directories. The identical filename across multiple directories is the key pattern.


Response Playbook

Triage

  1. IMMEDIATELY assess scope: how many files and endpoints are affected? Is encryption actively in progress?
  2. Identify the encrypting process: what executable is performing the file operations? Check its digital signature, file hash, and origin
  3. Determine the ransomware variant: examine the file extension (.locked, .encrypted, etc.) and any ransom notes dropped on disk
  4. Check for lateral movement indicators: is the ransomware spreading via SMB, WMI, PsExec, or GPO? Are other endpoints showing similar activity?
  5. Review the kill chain: how did the ransomware arrive? Check email logs, web proxy, RDP logs for initial access
  6. Check backup status: are backups intact? Have shadow copies been deleted? Is the backup server compromised?

Containment

  1. IMMEDIATELY isolate affected endpoints from the network — use EDR network isolation, VLAN quarantine, or physical disconnection
  2. Disable the compromised user account(s) in Active Directory and revoke all active sessions
  3. If spreading via SMB: disable SMB at the network level or block port 445 between workstations (not to file servers)
  4. If spreading via Group Policy: disconnect the domain controller or revoke the malicious GPO immediately
  5. Power off affected systems ONLY if encryption is actively in progress and you cannot isolate — this preserves encryption keys in memory for potential recovery
  6. Block the ransomware binary hash across all endpoints via EDR or application whitelisting
  7. Isolate the backup infrastructure to prevent encryption of backup data

Evidence Collection

  1. Ransom notes (README.txt, DECRYPT_FILES.html, etc.) — these identify the ransomware variant and may contain negotiation URLs
  2. The ransomware executable binary for reverse engineering and hash-based blocking
  3. Sysmon Event ID 11: File creation events showing the encryption pattern and volume
  4. Sysmon Event ID 1: Process creation events for the ransomware and all pre-encryption commands (vssadmin, bcdedit, wbadmin)
  5. Windows Security Event ID 4688: Process creation with command line auditing for shadow delete commands
  6. Memory dump of the encrypting process — may contain encryption keys for file recovery
  7. Windows Event ID 524: System catalog deleted (backup catalog deletion)
  8. ESXi shell history and vim-cmd logs if virtual machines were targeted

Escalation Criteria

  • ! Any confirmed ransomware encryption activity — this is always a critical incident requiring full IR response
  • ! Shadow copy deletion (vssadmin delete shadows) — this indicates imminent or active encryption and the attacker is destroying recovery options
  • ! Multiple endpoints affected simultaneously — indicates automated propagation (worm behavior)
  • ! Domain controller compromise — the ransomware may have been deployed via Group Policy
  • ! Backup server compromise — if backups are encrypted or deleted, recovery options are severely limited
  • ! ESXi hypervisor targeted — virtual machine encryption can take down entire infrastructure segments
  • ! Evidence of double extortion — data exfiltration detected before encryption (check for large outbound transfers)

Investigation Guide

Forensic Artifacts

  • > Ransom notes dropped in encrypted directories (README.txt, DECRYPT_*.html, HOW_TO_RECOVER.txt)
  • > Sysmon Event ID 11: File creation events for encrypted files and ransom notes
  • > Sysmon Event ID 1: Process creation for the ransomware executable and pre-encryption commands
  • > Windows Event ID 524: System Catalog was deleted (wbadmin catalog deletion)
  • > VSS Event ID 8224: Volume Shadow Copy Service error (shadow deletion confirmation)
  • > Registry: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run — ransomware persistence
  • > Registry: HKCU\Control Panel\Desktop\Wallpaper — changed to ransom note image
  • > Prefetch: [RANSOMWARE_NAME].EXE-*.pf — execution evidence and loaded DLLs
  • > MFT ($MFT): Timestamps of encrypted files showing encryption progression pattern
  • > ESXi: /var/log/shell.log — commands targeting .vmdk, .vmx files

Tuning Guidance

Keep the encrypted file extension list updated with emerging ransomware variants — new families constantly introduce new extensions. For shadow copy deletion detection, this should have zero tolerance for false positives in most environments — any unauthorized shadow delete warrants immediate investigation. Allowlist specific IT processes and scheduled tasks that legitimately manage shadow copies (e.g., backup rotation scripts). For the mass file rename detection, adjust the threshold based on your environment — creative teams or data processing pipelines may rename many files legitimately. Consider deploying canary files (honeypot files with monitoring) in key directories for early ransomware detection before mass encryption begins.


Hunting Queries

Hunt for volume shadow copy deletion and recovery sabotage commands. This is a critical pre-encryption indicator used by virtually all ransomware families. Shadow copy deletion before file encryption is the single highest-confidence ransomware precursor.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has_any (
    "vssadmin delete shadows",
    "vssadmin.exe delete shadows",
    "wmic shadowcopy delete",
    "bcdedit /set",
    "wbadmin delete catalog",
    "wbadmin delete systemstatebackup"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 (CommandLine="*vssadmin*delete shadows*" OR CommandLine="*wmic*shadowcopy delete*" OR CommandLine="*bcdedit*/set*recoveryenabled*no*" OR CommandLine="*wbadmin delete catalog*" OR CommandLine="*wbadmin delete systemstatebackup*")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort - _time

Hunt for mass service stopping targeting security, backup, and database services. Ransomware like Conti, REvil, and Royal systematically stop VSS, SQL Server, backup agents (Veeam), and antivirus services before beginning encryption to prevent file locks and detection.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has_any (
    "net stop", "sc stop", "taskkill /f",
    "Stop-Service"
)
| where ProcessCommandLine has_any (
    "vss", "sql", "svc$", "backup", "veeam",
    "sophos", "symantec", "mcafee", "defender",
    "exchange", "oracle", "mysql", "postgres"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 (CommandLine="*net stop*" OR CommandLine="*sc stop*" OR CommandLine="*taskkill /f*" OR CommandLine="*Stop-Service*") (CommandLine="*vss*" OR CommandLine="*sql*" OR CommandLine="*backup*" OR CommandLine="*veeam*" OR CommandLine="*sophos*" OR CommandLine="*symantec*" OR CommandLine="*mcafee*" OR CommandLine="*defender*" OR CommandLine="*exchange*" OR CommandLine="*oracle*" OR CommandLine="*mysql*" OR CommandLine="*postgres*")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort - _time

Hunt for ransom note file creation across multiple directories. Ransomware drops identical ransom notes (README.txt, DECRYPT_FILES.html, HOW_TO_RECOVER.txt) in every encrypted directory. Multiple ransom notes appearing simultaneously across directories is a definitive ransomware indicator.

Hunting — KQL
kql
DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType in ("FileRenamed", "FileCreated")
| where FileName has_any ("README", "DECRYPT", "RECOVER", "RESTORE", "HOW_TO", "RANSOM", "_readme", "!!!")
| where FileName endswith_any (".txt", ".html", ".hta", ".png", ".bmp")
| summarize NoteCount=count(), UniqueNames=dcount(FileName), Directories=dcount(FolderPath) by DeviceName, InitiatingProcessFileName, FileName
| where NoteCount > 5
| sort by NoteCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11 (TargetFilename="*README*" OR TargetFilename="*DECRYPT*" OR TargetFilename="*RECOVER*" OR TargetFilename="*RESTORE*" OR TargetFilename="*HOW_TO*" OR TargetFilename="*RANSOM*" OR TargetFilename="*_readme*" OR TargetFilename="*!!!*") (TargetFilename="*.txt" OR TargetFilename="*.html" OR TargetFilename="*.hta" OR TargetFilename="*.png" OR TargetFilename="*.bmp")
| stats count as NoteCount, dc(TargetFilename) as UniqueNames by host, Image
| where NoteCount > 5
| sort - NoteCount

Atomic Red Team Tests

Test 1 Volume Shadow Copy Deletion via vssadmin
windows

Simulates the pre-encryption shadow copy deletion performed by virtually all Windows ransomware families including WannaCry, REvil, Conti, Maze, BlackCat, and Royal. This is the most common ransomware precursor activity. NOTE: This will actually delete shadow copies if run as Administrator.

Command

powershell
vssadmin.exe delete shadows /all /quiet

Cleanup

powershell
echo Shadow copies cannot be restored once deleted. Ensure backups exist before testing.

Expected Telemetry

Sysmon Event ID 1: Process creation for vssadmin.exe with 'delete shadows /all /quiet' command line. Windows Security Event ID 4688 with same details. VSS Event ID 8224 in System log confirming shadow deletion.

Expected Detection

Alert fires immediately on vssadmin delete shadows command. KQL: ShadowsDeleted=true, RansomwareConfidence=high. SPL: ShadowDeletes > 0, RansomwareConfidence=high. This is a zero-tolerance detection.

Test 2 Recovery Sabotage via bcdedit
windows

Simulates ransomware disabling Windows Recovery Environment using bcdedit, as performed by WannaCry, NotPetya, LockerGoga, and many other ransomware families. This prevents the user from booting into recovery mode after encryption.

Command

powershell
bcdedit /set {default} recoveryenabled no && bcdedit /set {default} bootstatuspolicy ignoreallfailures

Cleanup

powershell
bcdedit /set {default} recoveryenabled yes && bcdedit /deletevalue {default} bootstatuspolicy

Expected Telemetry

Sysmon Event ID 1: Two process creation events for bcdedit.exe with /set commands. Windows Security Event ID 4688 with command line auditing. Registry modification events for BCD store changes.

Expected Detection

Alert fires on bcdedit commands that disable recovery. KQL: Matches ShadowDeleteCommands pattern. SPL: Captured in ShadowDeletes count. Both commands together are a strong ransomware indicator.

Test 3 Mass File Encryption Simulation
windows

Simulates ransomware file encryption by creating test files and renaming them with a .encrypted extension, mimicking the mass file rename pattern produced by ransomware. Creates 100 files to trigger the threshold-based detection.

Command

powershell
mkdir %TEMP%\df00tech_ransom_test 2>nul & for /L %i in (1,1,100) do (echo test_data_%i > %TEMP%\df00tech_ransom_test\file_%i.docx & ren %TEMP%\df00tech_ransom_test\file_%i.docx file_%i.docx.encrypted)

Cleanup

powershell
rmdir /s /q %TEMP%\df00tech_ransom_test

Expected Telemetry

Sysmon Event ID 11: 100 file creation events for .docx files, followed by 100 file rename events to .docx.encrypted. The burst of file operations in a short time window from a single process is the key telemetry pattern.

Expected Detection

Alert fires when RenamedFiles exceeds the threshold (50). With 100 encrypted files, KQL: RenamedFiles=100, RansomwareConfidence=medium (would be high if combined with shadow deletion). SPL: EncryptedFiles=100.

Test 4 Ransom Note Drop Simulation
windows

Simulates ransomware dropping ransom notes in multiple directories, as performed by all major ransomware families. Creates identical ransom note files in multiple subdirectories to mimic the pattern of per-directory ransom notes.

Command

powershell
for /L %i in (1,1,10) do (mkdir %TEMP%\df00tech_ransom_test\dir_%i 2>nul & echo YOUR FILES HAVE BEEN ENCRYPTED > %TEMP%\df00tech_ransom_test\dir_%i\README_DECRYPT.txt)

Cleanup

powershell
rmdir /s /q %TEMP%\df00tech_ransom_test

Expected Telemetry

Sysmon Event ID 11: 10 file creation events for README_DECRYPT.txt in different directories. The identical filename across multiple directories is the key pattern.

Expected Detection

Hunting query fires on README_DECRYPT.txt creation across multiple directories (NoteCount=10, Directories=10). This pattern of identical ransom notes in multiple folders is a definitive ransomware indicator.

Related Detections

Tactic Hub

Detection Variants (1)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.