Overview

Data Encrypted for Impact (T1486) describes adversary activity where files, drives, or entire systems are encrypted to deny the victim access to their own data. Attackers accomplish this either to extort a ransom payment in exchange for a decryption key (ransomware) or, in destructive campaigns, to permanently destroy data with no intent to recover it (wiper malware). Targets range from individual workstations to VMware ESXi hypervisors hosting dozens of virtual machines.

Every security team needs detection coverage here because encryption activity is frequently the last observable event before an incident becomes a disaster. By the time ransomware is visibly encrypting files, the attacker has often had days or weeks of dwell time performing reconnaissance, credential theft, and staging. Detecting the precursors — and the encryption activity itself as early as possible — is the difference between a contained incident and a full business interruption event.

Attacker Perspective

Threat actors deploy data encryption after completing earlier intrusion phases, using it as the final destructive or monetization payload to maximize leverage against the victim organization.

• Human-operated ransomware (e.g., LockBit, BlackCat/ALPHV): Operator manually deploys a compiled ransomware binary across the environment using PsExec or Group Policy, often targeting domain-joined systems with a command like psexec.exe \\* -d -c locker.exe --encrypt --key [key] after obtaining Domain Admin credentials.
• ESXi hypervisor targeting (e.g., Black Basta, Royal): Attacker SSHs directly into an ESXi host, uses esxcli vm process list to enumerate running VMs, shuts them down with vim-cmd vmsvc/power.off [vmid], then executes a Linux ELF ransomware binary that targets .vmdk, .vmx, and .nvram files in the datastore directories.
• Worm-propagating ransomware (e.g., WannaCry, NotPetya): Malware self-propagates over SMB using EternalBlue (MS17-010), encrypting files autonomously on each newly compromised host without requiring operator interaction, generating high-volume file write events across the network simultaneously.
• Cloud storage encryption (e.g., AWS S3 abuse): Attacker with stolen IAM credentials uses aws s3 cp or the AWS SDK to re-encrypt S3 objects using a customer-controlled KMS key, then deletes the original objects, rendering data unrecoverable without the attacker’s key material.

This technique is attractive because it is extremely difficult to reverse without either the decryption key or clean backups, giving attackers strong financial or destructive leverage with a single well-timed action.

Detection Strategy

Required Telemetry

• Windows — File System Activity (Sysmon Event ID 11): Enable Sysmon with a configuration that captures FileCreate events. Deploy Sysmon via GPO with a config that includes rules for high-volume file extensions and known ransomware note filenames. Without Sysmon or an EDR equivalent, file-level activity is invisible to most SIEMs.
• Windows — Process Creation (Sysmon Event ID 1 / Security Event ID 4688): Enable process creation auditing via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. For full command-line logging, also set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Sysmon Event ID 1 is preferred as it includes hashes and parent process GUIDs.
• Windows — Volume Shadow Copy Deletion (Security Event ID 4688 + Sysmon Event ID 1): Ransomware almost universally deletes VSS snapshots. Look for vssadmin.exe, wmic.exe, and bcdedit.exe invocations. These are captured by process creation events once command-line logging is enabled (see above).
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging = Enabled, or registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Required to catch PowerShell-delivered ransomware droppers.
• Windows — Service Installation (Security Event ID 7045 / System Log): Ransomware operators frequently install services for persistence or lateral execution. Ensure System event log collection is enabled and forwarded to your SIEM.
• Windows — SMB Lateral Movement (Security Event ID 4624 / 4648 / 5140): Enable Logon auditing (Audit Logon = Success, Failure) and Object Access auditing for network shares (Audit File Share = Success, Failure) to catch lateral spread over SMB Admin Shares.
• Linux/ESXi — Auditd File and Process Events: Add auditd rules to monitor writes to critical directories and execution of suspicious binaries: -a always,exit -F arch=b64 -S execve -k exec_monitor and -w /vmfs/volumes/ -p wa -k esxi_datastore_writes. For ESXi specifically, enable remote syslog forwarding to your SIEM via esxcli system syslog config set --loghost=udp://[SIEM_IP]:514.
• Linux/ESXi — Shell History and SSH Logs: Collect /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) and ESXi’s /var/log/shell.log and /var/log/hostd.log. These capture SSH logins and interactive commands run against hypervisors.
• Cloud (AWS) — CloudTrail: Ensure CloudTrail is enabled in all regions with S3 data events (s3:PutObject, s3:DeleteObject, s3:CopyObject) and KMS events (kms:CreateKey, kms:PutKeyPolicy, kms:Encrypt) logged. Without S3 data events explicitly enabled, object-level encryption activity is not captured.
• EDR Telemetry: If your organization uses CrowdStrike, Microsoft Defender for Endpoint, SentinelOne, or similar, ensure the agent is deployed and reporting. EDR provides the richest file and process telemetry and is the primary detection surface for this technique on endpoints.

Key Indicators

• Volume Shadow Copy deletion: Source: Windows Security/Sysmon process creation events. Field: CommandLine. Patterns: vssadmin delete shadows /all /quiet, wmic shadowcopy delete, bcdedit /set {default} recoveryenabled No, bcdedit /set {default} bootstatuspolicy ignoreallfailures. Any one of these from a non-backup process is high-fidelity.
• High-volume file rename/overwrite in short timeframe: Source: Sysmon Event ID 11 (FileCreate) or EDR file events. Field: TargetFilename. Pattern: hundreds of file write events per minute on common document extensions (.docx, .xlsx, .pdf, .jpg, .sql) followed by creation of unfamiliar extensions like .locked, .enc, .lckd, .ALPHV, .lockbit. High volume in a short window is the signal.
• Ransom note file creation: Source: Sysmon Event ID 11 / EDR. Field: TargetFilename. Pattern: filenames matching README*.txt, HOW_TO_DECRYPT*.txt, RECOVER_FILES*.html, !!!NOTICE!!!, DECRYPT_INSTRUCTIONS* written to multiple directories. Writing the same filename pattern to many directories is almost exclusively ransomware behavior.
• Suspicious process spawning encryption-related utilities: Source: Sysmon Event ID 1 / Security Event ID 4688. Fields: ParentImage, Image, CommandLine. Pattern: cmd.exe or powershell.exe spawning cipher.exe /w (wipe free space), or unknown binaries in C:\Users\Public\, C:\Windows\Temp\, C:\ProgramData\ executing with no prior software installation record.
• ESXi VM shutdown and datastore file writes: Source: ESXi shell.log / hostd.log. Fields: command strings. Pattern: vim-cmd vmsvc/power.off or esxcli vm process kill followed immediately by writes to /vmfs/volumes/ paths, or execution of a new ELF binary from a non-standard path like /tmp/.
• Disabling Windows Defender or other security tools: Source: Sysmon Event ID 1 / Security Event ID 4688. Field: CommandLine. Patterns: Set-MpPreference -DisableRealtimeMonitoring $true, sc stop WinDefend, netsh advfirewall set allprofiles state off. Security tool tampering immediately before or during encryption is a strong co-indicator.
• AWS CloudTrail: Mass S3 object deletion/re-encryption: Source: CloudTrail. Fields: eventName, requestParameters.bucketName, userIdentity.arn. Pattern: single IAM principal calling s3:DeleteObject or s3:CopyObject at high volume (hundreds of events per minute) across multiple buckets, especially combined with kms:CreateKey by the same principal.
• Lateral movement via PsExec or remote service creation: Source: Security Event ID 7045 (new service) + Event ID 4624 (Type 3 network logon). Pattern: service named with random characters (e.g., PSEXESVC or a randomized name) installed from a remote source, correlated with a Type 3 logon from an unusual source IP within the same timeframe.

Detection Logic

Rule 1 (Broad — High Sensitivity): Volume Shadow Copy Deletion Attempt
IF process_name IN ["vssadmin.exe", "wmic.exe", "powershell.exe", "cmd.exe"] AND command_line CONTAINS_ANY ["delete shadows", "shadowcopy delete", "recoveryenabled No", "bootstatuspolicy ignoreallfailures"] AND NOT parent_process IN ["backup_agent.exe", "veeam_agent.exe", "commvault.exe"] THEN alert HIGH

This catches the near-universal ransomware pre-encryption step of destroying recovery options. Expected volume is very low (near zero) in most environments without the listed backup exclusions; tune exclusions to your backup software’s exact process names.

Rule 2 (Broad — High Sensitivity): High-Volume File Extension Change in Short Window
IF file_event_type = "FileCreate" OR file_event_type = "FileWrite" AND file_extension IN [".locked", ".enc", ".crypt", ".lckd", ".lockbit", ".ALPHV", ".ryk", ".conti"] AND COUNT(events) BY host, user WITHIN 60 seconds > 20 THEN alert CRITICAL

Catches active encryption in progress by looking for bulk creation of files with known ransomware extensions. Alert volume depends heavily on your threshold; start at 20 and tune upward if legitimate software triggers it (uncommon for these extensions). Pair with a separate rule watching for any new extension appearing on 10+ files/minute from the same process.

Rule 3 (Moderate Precision): Ransom Note Filename Written to Multiple Directories
IF file_event_type = "FileCreate" AND file_name MATCHES_REGEX ["(?i)(readme|decrypt|recover|how.to|restore.files|ransom|instructions).*\.(txt|html|hta|htm)"] AND COUNT(DISTINCT directory_path) BY host, process_id WITHIN 5 minutes > 5 THEN alert CRITICAL

Ransomware drops a note in every directory it encrypts; this pattern of the same filename prefix appearing in many distinct directories from a single process is extremely rare in legitimate software. Expected false positive rate is very low.

Rule 4 (High Precision): Security Tool Tampering Immediately Preceding Bulk File Writes
IF (command_line CONTAINS_ANY ["DisableRealtimeMonitoring", "sc stop WinDefend", "advfirewall set allprofiles state off", "taskkill /IM MsMpEng.exe"]) AND WITHIN 10 minutes SAME host: file_write_count > 100 AND file_extension_new_count > 3 THEN alert CRITICAL

This correlates two behaviors — AV/EDR disabling and high-volume file writes — which together are a very strong signal of active ransomware execution. False positive rate is near zero; this rule requires correlation capability in your SIEM (e.g., Splunk transaction, Sentinel join query, Elastic EQL sequence).

Tuning Guidance

• Backup software (Veeam, Commvault, Backup Exec, Windows Server Backup): These products legitimately access VSS, write large numbers of files rapidly, and may call vssadmin. Exclude by adding parent_process IN ["veeam_agent.exe", "veeamservice.exe", "cvd.exe", "beremote.exe", "wbengine.exe"] to VSS deletion and file write rules. Verify the process path matches the legitimate installation directory (e.g., C:\Program Files\Veeam\) to avoid masquerading.
• Disk encryption tools (BitLocker, VeraCrypt, PGP): IT-managed full-disk encryption can trigger file write volume rules during initial encryption. Exclude known management processes: process_path STARTS_WITH "C:\Windows\System32\manage-bde.exe" or process_name = "VeraCrypt.exe" when correlated with a legitimate change ticket. Consider allowlisting by hash rather than process name to prevent masquerading.
• File compression and archive utilities (7-Zip, WinRAR, robocopy): Bulk file operations during scheduled archiving jobs can trigger high-volume file write alerts. Tune by excluding known scheduled task accounts: user IN ["svc_backup", "svc_archive"] and verifying activity falls within expected maintenance windows using time-based conditions.
• Developer and CI/CD tools: Build pipelines (MSBuild, npm, Maven) generate large numbers of file writes in short periods. Scope file-write volume rules to sensitive directories (C:\Users\, D:\Data\, network shares) rather than C:\Windows\, C:\Program Files\, or known build output paths like C:\build\ or C:\src\.
• Antivirus quarantine operations: AV products may rename files to quarantine extensions that superficially resemble ransomware extensions. Exclude by process_name IN ["MsMpEng.exe", "avgnt.exe", "mbam.exe"] on file rename/extension change rules, and verify the process is running from its expected installation path.

When the Alert Fires: Investigation Steps

1. Verify the alert is real. Pull the raw event directly from your SIEM or EDR console and confirm the file write events, VSS deletion command, or ransom note creation actually occurred with the logged timestamps and process details. Do not proceed based solely on a dashboard summary — confirm the source log entry exists and the fields are populated as expected.
2. Identify the affected host and user account. Determine the hostname, IP address, OS version, and the user account associated with the triggering process. Flag immediately if the account is privileged (Domain Admin, local Administrator, service account with broad access) or if the host is a server, domain controller, or ESXi hypervisor, as these dramatically increase blast radius.
3. Pull the full process tree and command-line history. Using your EDR (CrowdStrike Process Tree, MDE Device Timeline, SentinelOne Deep Visibility) or Sysmon events filtered by host and the 30 minutes prior to the alert, reconstruct the full parent-child process chain. Identify how the ransomware binary arrived — was it spawned by cmd.exe, a document, a remote service, or a scheduled task?
4. Examine files written to disk and network connections. Query Sysmon Event ID 11 (FileCreate) and Event ID 3 (NetworkConnect) for the malicious process’s PID over the incident timeframe. Identify the ransomware binary’s drop location (e.g., C:\Windows\Temp\), hash it against VirusTotal, and check for any C2 callback or exfiltration connections — many modern ransomware groups exfiltrate data before encrypting (double extortion).
5. Assess the scope of encryption and check for lateral movement. Query your SIEM for Event ID 4624 Type 3 logons, 4648 (explicit credential logon), and 5140 (network share access) originating from the affected host in the 24 hours prior to the alert. Cross-reference with any remote service installations (Event ID 7045) or PsExec artifacts on other hosts to determine how many systems are affected.
6. Hunt for persistence mechanisms added by the attacker. Search for new scheduled tasks (Event ID 4698), registry run key modifications (Sysmon Event ID 13 targeting HKCU\Software\Microsoft\Windows\CurrentVersion\Run), new services (Event ID 7045), or new local admin accounts (Event ID 4720 + 4732) created in the 48 hours preceding the encryption event. These indicate the attacker had dwell time and may have left backdoors.
7. Make the escalation and containment decision. If encryption is confirmed active or the process tree shows a known ransomware binary with VSS deletion and lateral movement, this is a confirmed incident — escalate to Incident Commander immediately and move to containment. If the alert shows only a single indicator (e.g., one ransom-named file, no matching process, no VSS deletion), document your findings, flag as suspicious requiring monitoring, and check with the system owner before isolating to avoid disrupting legitimate operations.

Response Playbook

Containment

• Isolate affected hosts immediately — keep them powered on. Use your EDR console to network-isolate the host (CrowdStrike: Contain Host; MDE: Isolate Device; SentinelOne: Network Quarantine). Do not power off — memory may contain encryption keys, running processes, or attacker artifacts needed for forensics. If no EDR is available, place the switch port in a quarantine VLAN via your network team.
• Disable the affected user account. In Active Directory, use Disable-ADAccount -Identity [username] or the ADUC console immediately. If the account is a service account, coordinate with application owners before disabling, but still act quickly. For cloud environments, disable the IAM user or revoke the access key via aws iam update-access-key --status Inactive.
• Block identified C2 infrastructure at the perimeter. Submit any observed outbound IPs, domains, or URLs from the network connection analysis to your firewall team and DNS sinkholes immediately. Also block at the web proxy and EDR policy level. Check threat intelligence feeds (VirusTotal, MISP, your TIP) for related infrastructure.
• Kill the malicious process if still running. Via your EDR’s remote response shell, identify the ransomware PID and terminate it: taskkill /PID [pid] /F (Windows) or kill -9 [pid] (Linux/ESXi). Preserve the binary by copying it to a forensic location before terminating if possible, and record its full path and hash.
• Revoke active sessions and tokens. Force a sign-out of all active sessions for the affected account: in Azure AD use Revoke-AzureADUserAllRefreshToken; in AWS revoke active sessions by attaching a deny-all policy to the IAM entity. For on-premises, reset the account password immediately, which invalidates Kerberos TGTs (after the default ticket lifetime expires — contact your AD team to force a purge if needed).
• Protect backup infrastructure. Immediately verify that backup systems and offline/immutable backup repositories are still intact and not accessible from compromised segments. If backups are network-accessible, isolate them proactively until the scope of compromise is known.

Eradication

• Remove identified persistence mechanisms. Delete any malicious scheduled tasks identified during investigation using schtasks /delete /tn "[task_name]" /f. Remove malicious registry run keys using reg delete [key_path] /v [value_name] /f. Stop and delete malicious services with sc stop [service_name] followed by sc delete [service_name]. Document each one removed.
• Locate and delete all dropped payloads. Search for the ransomware binary by hash across your entire fleet using your EDR’s threat hunting capability (CrowdStrike RTR, MDE Advanced Hunting, SentinelOne Deep Visibility). Remove every instance found. Also search for associated tools dropped during the pre-encryption phase (credential dumpers like Mimikatz, network scanners like Advanced IP Scanner, remote access tools).
• Reset credentials for all affected accounts. Reset passwords for the directly compromised account and any accounts whose credentials may have been harvested during the attack (check for Mimikatz, LSASS dump activity in the process tree). For Kerberos: reset the KRBTGT account password twice (with a replication delay between resets) if a Golden Ticket attack is suspected.
• Audit and remediate lateral movement targets. For every host the attacker touched (identified in step 5 of investigation), perform the same persistence hunt. Treat each as potentially compromised until proven otherwise. Re-image hosts where you cannot confidently account for all attacker activity.
• Rotate exposed secrets and API keys. If the attacker had access to a system storing API keys, database credentials, certificates, or cloud credentials (check browser saved passwords, credential stores, .aws/credentials, .env files), rotate all of them. Coordinate with application and cloud teams.

Recovery

• Verify hosts are clean before reconnecting. Run a full EDR scan and manually review the persistence locations (scheduled tasks, run keys, services, startup folders) on each affected host before removing network isolation. If you cannot achieve high confidence that the host is clean, re-image it from a known-good baseline — this is always the safer option for ransomware incidents.
• Restore data from clean backups. Work with your backup team to restore from the most recent backup predating the intrusion (not just the encryption event — the attacker may have been present for days or weeks). Verify backup integrity before restoring. If restoring to the same infrastructure, ensure it has been cleaned or rebuilt first.
• Re-enable user accounts only after confirming no persistence remains. Before re-enabling any disabled accounts, confirm through EDR and AD audit logs that no new accounts, delegation settings, or group memberships were added by the attacker that could give re-entry. Reset the password to a new strong credential and enforce MFA before the account is used again.
• Monitor affected hosts and accounts for 72 hours post-remediation. Create temporary high-sensitivity detection rules scoped to the previously affected hosts and user accounts. Set lower thresholds and broader scope for this monitoring window to catch any re-compromise or missed persistence. Review alerts manually during this period rather than relying on automation alone.
• Conduct a full post-incident review and update detections. Document the complete attack timeline from initial access through encryption, capturing all TTPs observed. Update your SIEM detection rules with any new IOCs (hashes, C2 infrastructure, filename patterns, registry keys) discovered during the investigation. Brief leadership on the incident scope, business impact, and recommended control improvements (e.g., MFA gaps, backup segmentation, EDR coverage gaps) to prevent recurrence.