Overview

Data Destruction (T1485) is an impact-phase technique where adversaries deliberately overwrite, corrupt, or permanently delete files and data to make recovery impossible — going beyond simple deletion by wiping file contents with random data, politically-motivated images, or garbage bytes. Unlike basic del or rm commands that merely remove filesystem pointers, true data destruction renders files unrecoverable even through forensic analysis, and in cloud environments extends to deleting storage buckets, database instances, virtual machines, and machine images.

Every security team needs to detect this technique because it represents the final, often irreversible phase of an attack — once data is overwritten, the damage cannot be undone without offline backups. Ransomware operators, nation-state actors (e.g., Shamoon, Olympic Destroyer), and insider threats all use data destruction to maximize operational disruption, embarrass organizations, or permanently destroy evidence. Detection before or immediately after execution begins is the only window to limit impact.

Attacker Perspective

Attackers deploy data destruction as a deliberate finishing move — either to maximize damage in a destructive campaign, cover their tracks after exfiltration, or punish a target organization.

• Wiper malware with propagation: Tools like Shamoon use RawDisk drivers to overwrite the MBR and individual files, then spread via SMB Admin Shares using harvested credentials, destroying thousands of systems simultaneously.
• Secure deletion utilities abused: Attackers deploy Sysinternals sdelete.exe -p 3 -s -q C:\ to recursively and permanently overwrite files with multiple passes, leaving characteristic .AAA and .ZZZ renamed artifacts in security logs.
• Linux/macOS shell-based destruction: One-liners like shred -uzn 3 /data/* or find / -type f -exec dd if=/dev/urandom of={} bs=1M \; overwrite file contents in-place before unlinking them, defeating forensic recovery.
• Cloud resource mass deletion: A compromised IAM principal runs aws s3 rb s3://bucket-name --force, aws ec2 terminate-instances, or Azure CLI az vm delete commands in a loop to destroy infrastructure at scale within minutes.

Data destruction is attractive to attackers precisely because its effects are permanent — even a well-resourced victim organization with a mature IR capability cannot reverse overwritten data without verified offline backups, making it an asymmetrically powerful weapon.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Sysmon Event ID 1 or Security Event ID 4688): Enable Sysmon with a configuration that captures CommandLine and ParentImage. For native auditing: enable “Audit Process Creation” via GPO at Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation and set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1 to capture full command lines in Event ID 4688.
• Windows — Object Access (Security Event IDs 4656, 4663, 4658): Enable “Audit Object Access” (file system) via GPO. These events capture file handle requests, accesses, and close operations — critical for detecting SDelete’s rename-before-overwrite behavior and the characteristic .AAA/.ZZZ extensions.
• Windows — Security Log — Privileged Operations (Event ID 4672, 4673): Enable “Audit Sensitive Privilege Use” to detect use of SeBackupPrivilege or SeRestorePrivilege that raw-disk wipers exploit.
• Linux — Auditd: Add the following rules to /etc/audit/rules.d/destruction.rules:
  -a always,exit -F arch=b64 -S unlinkat,rename,truncate,ftruncate -F auid>=1000 -k data_destruction and -w /usr/bin/shred -p x -k shred_exec. This captures file deletion/overwrite syscalls and execution of shred.
• Linux — Auditd for dd abuse: -w /usr/bin/dd -p x -k dd_exec — captures every execution of dd with full argument logging via ausearch -k dd_exec.
• macOS — Unified System Log / Endpoint Security Framework: Use an EDR agent or configure eslogger (macOS 13+) to capture exec, unlink, and write events. Alternatively, enable BSM auditing: add fd (file deletion) and fw (file write) classes to /etc/security/audit_control.
• Cloud — AWS CloudTrail: Must be enabled in all regions with “Data Events” turned on for S3 (log DeleteObject, DeleteBucket) and management events for EC2 (TerminateInstances), RDS (DeleteDBInstance), and EBS (DeleteSnapshot).
• Cloud — Azure Activity Log / Microsoft Entra Audit Log: Ensure Diagnostic Settings route Activity Logs to your SIEM. Monitor Microsoft.Compute/virtualMachines/delete, Microsoft.Storage/storageAccounts/delete, and Microsoft.Sql/servers/databases/delete operations.
• Cloud — GCP Cloud Audit Logs: Enable Admin Activity and Data Access audit logs. Monitor storage.buckets.delete, compute.instances.delete, and cloudsql.instances.delete operations in Cloud Logging.
• ESXi: Enable ESXi shell logging and vCenter event logging. Monitor for vim.VirtualMachine.destroy API calls and direct datastore file deletions via /var/log/hostd.log and /var/log/vpxa.log.
• EDR Telemetry: If available (CrowdStrike, Defender for Endpoint, SentinelOne), enable file modification and raw disk access event collection — EDR is often the highest-fidelity source for this technique.

Key Indicators

• SDelete execution artifacts — Windows Security Log: ObjectName field ending in .AAA or .ZZZ in Event IDs 4656, 4663, or 4658. SDelete renames files to these extensions as part of its overwrite process before deletion.
• SDelete process creation — Sysmon/4688: Image field contains sdelete.exe or sdelete64.exe; CommandLine contains flags like -p (passes), -s (subdirectories), or -z (zero free space). Example: sdelete64.exe -p 3 -s -q C:\Users\.
• Shred/dd abuse — Linux Auditd: execve syscall where a0 (argv[0]) = /usr/bin/shred with arguments -u (unlink after) or -n (overwrite passes). For dd: CommandLine contains if=/dev/urandom or if=/dev/zero with of= pointing to a real file path.
• Mass file rename/overwrite patterns — EDR or Sysmon: A single process performing FileRename or FileWrite operations on more than 100 files within 60 seconds — characteristic of automated wiper behavior.
• Raw disk access — Windows Sysmon Event ID 9 (RawAccessRead): Device field referencing \\.\PhysicalDrive0 or \\.\GLOBALROOT\Device\HarddiskVolume from a non-system process — a strong indicator of a wiper attempting low-level disk access.
• Cloud mass deletion — AWS CloudTrail: eventName = DeleteObject with requestParameters.bucketName in rapid succession from a single userIdentity.arn, or TerminateInstances called against multiple instance IDs in a single API call.
• Cloud mass deletion — Azure Activity Log: operationName = Microsoft.Compute/virtualMachines/delete appearing more than 3 times within 10 minutes from the same caller identity.
• Suspicious parent-child process relationships — Sysmon/4688: wscript.exe, mshta.exe, powershell.exe, or cmd.exe spawning sdelete.exe, format.com, or cipher.exe /w:. The /w flag on cipher.exe overwrites free space and is rarely used legitimately in an automated context.
• PowerShell destruction commands — Event ID 4104 (Script Block Logging): Script block content matching patterns like [System.IO.File]::WriteAllBytes in a loop, Remove-Item -Recurse -Force targeting broad paths like C:\Users\ or D:\, or Get-ChildItem | ForEach-Object { $_ | Set-Content -Value ([byte[]]...) }.
• ESXi VM mass deletion — hostd.log: Log entries containing Destroy_Task or vim.VirtualMachine.destroy for multiple VMs within a short time window, especially outside of change windows.

Detection Logic

Rule 1 (Broad — High Sensitivity): Mass File Write or Rename by Single Process
IF process_event.file_operations_count > 100 AND process_event.operation IN ["FileWrite", "FileRename", "FileDelete"] AND process_event.timespan_seconds < 60 AND NOT process_event.image IN ["antivirus.exe", "backup_agent.exe", "windows_update.exe"] THEN alert HIGH

This catches any process performing bulk destructive file operations at wiper speed. Expect moderate false positive volume from legitimate backup software, AV scanning, and large file copy jobs — baseline your environment's normal thresholds before deploying. The NOT exclusion list will need tuning per environment.

Rule 2 (Moderate Precision): Known Secure Deletion Tool Execution
IF process_creation.image ENDSWITH "sdelete.exe" OR process_creation.image ENDSWITH "sdelete64.exe" OR (process_creation.image ENDSWITH "cipher.exe" AND process_creation.commandline CONTAINS "/w") OR (process_creation.image ENDSWITH "shred" AND process_creation.commandline CONTAINS "-u") THEN alert HIGH

Targets known secure-wipe utilities by name and flag. SDelete and shred with -u are rarely used in normal enterprise operations. Cipher /w has some legitimate use by IT admins for free-space wiping — correlate with user role and scheduled change windows.

Rule 3 (High Precision): SDelete File Extension Artifacts in Object Access Logs
IF windows_security.event_id IN [4656, 4663, 4658] AND windows_security.object_name ENDSWITH ".AAA" OR windows_security.object_name ENDSWITH ".ZZZ" THEN alert HIGH

These specific file extensions are generated exclusively by SDelete's internal rename-before-overwrite workflow and have virtually no legitimate occurrence in enterprise file systems. This rule has very low false positive rate and high confidence — treat any match as requiring immediate investigation.

Rule 4 (Cloud): Mass Infrastructure Deletion by Single Identity
IF cloud_audit.event_name IN ["DeleteObject","DeleteBucket","TerminateInstances","DeleteDBInstance","DeleteSnapshot","Delete device","Microsoft.Compute/virtualMachines/delete"] AND COUNT(cloud_audit.event_name) BY cloud_audit.user_identity > 10 WITHIN 10 MINUTES AND NOT cloud_audit.user_identity IN [approved_automation_accounts] THEN alert CRITICAL

Catches automated cloud destruction campaigns where a compromised IAM role or service principal begins mass-deleting resources. Automation accounts performing scheduled teardowns will fire this rule — maintain an allowlist of approved automation service accounts and restrict the rule to non-maintenance windows.

Tuning Guidance

• Backup software (Veeam, Veritas, Commvault, Windows Backup): These agents perform high-volume file reads, writes, and renames during backup jobs that will trigger mass file operation rules. Exclude by process_image IN ["veeam*.exe", "VeeamAgent.exe", "beremote.exe", "BackupExec*.exe"] and correlate activity times with scheduled backup windows.
• Antivirus/EDR quarantine actions: Security tools rename malicious files to quarantine them, which can resemble SDelete behavior. Exclude process_image IN ["MsMpEng.exe", "SentinelAgent.exe", "csfalconservice.exe"] from file rename/delete volume rules.
• Software deployment and patching (SCCM, Intune, Ansible): Large-scale patch deployments write and delete many files simultaneously across endpoints. Exclude parent_process IN ["ccmexec.exe", "TrustedInstaller.exe", "msiexec.exe"] when the parent is a known deployment tool, or suppress during known maintenance windows.
• Developer workflows and CI/CD pipelines: Build agents routinely delete and recreate entire directory trees. Exclude by user IN [ci_service_accounts] or process_image IN ["git.exe", "npm.exe", "gradle"] on known build hosts identified by hostname or asset tag.
• Cloud infrastructure automation (Terraform destroy, CloudFormation stack deletion): Legitimate IaC teardowns will trigger cloud deletion rules. Maintain an allowlist of automation service account ARNs/SPNs and correlate with change management tickets. Add cloud_audit.user_agent CONTAINS "terraform" as a contextual tuning signal, but do not use it as a sole exclusion since attackers can spoof user-agent strings.
• IT admin use of SDelete for data sanitization: SDelete has legitimate use on decommissioned hardware. Exclude user IN [it_admin_accounts] only when correlated with a change ticket and the target host is flagged as "decommissioning" in your asset inventory — never blanket-exclude admin accounts.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event in the source log. In your SIEM, pull the original log entry (Sysmon Event ID 1, Security Event 4663, or CloudTrail event) and confirm the key fields — CommandLine, ObjectName, userIdentity — match what triggered the alert and are not a parsing artifact or duplicated event.
2. Identify the affected host and user account, and check their privilege level. Resolve the hostname in your asset inventory (CMDB or EDR console) to determine criticality — a domain controller or file server hit is immediately P1. Look up the user in Active Directory or IAM to determine if they hold admin, privileged, or service account roles.
3. Pull the full process tree and command-line history for the suspicious process. In Sysmon or your EDR (CrowdStrike Process Tree, MDE Device Timeline, SentinelOne Deep Visibility), trace from the malicious process back to its grandparent — identify the initial execution vector (phishing attachment, lateral movement, scheduled task). The full CommandLine, ParentImage, and ParentCommandLine fields are critical here.
4. Determine the scope of destruction — how many files or resources were affected and when it started. Use Sysmon Event ID 11 (FileCreate) and 4663 object access logs, or your EDR's file activity timeline, to enumerate all files written or deleted by the process. For cloud incidents, query CloudTrail or Azure Activity Logs for all Delete* events from the same identity in the preceding 24 hours.
5. Check for network connections made by the malicious process or host. Query Sysmon Event ID 3 (NetworkConnect) or firewall/NDR logs for outbound connections made by the destroying process — wiper malware with propagation features (Shamoon-style) will attempt SMB connections to adjacent hosts on port 445 immediately before or after destruction. Flag any new internal connections to hosts not previously communicating.
6. Search for lateral movement and additional compromised hosts. Using the user account and source host as pivots, query your SIEM for Event ID 4624 (logon type 3 or 10) or Sysmon network events showing the same account authenticating to other systems in the 48 hours before the alert. Check for the same malicious binary hash or process name appearing on other endpoints via EDR threat hunting.
7. Make the escalation decision: confirmed incident or false positive. Treat the event as a confirmed incident requiring immediate containment if any of the following are true: the process name or hash matches a known wiper, more than 50 files were modified/deleted, the user account has no legitimate reason to run secure deletion tools, or additional hosts show the same activity. Treat as likely benign only if the user is IT staff, a change ticket exists, and the scope is limited to a single decommissioned asset.

Response Playbook

Containment

• Isolate the affected host immediately — but keep it powered on. Use your EDR console (CrowdStrike "Network Containment", Defender for Endpoint "Isolate Device", SentinelOne "Network Quarantine") to block all network traffic while preserving the system state and volatile memory for forensics. Do not power off — RAM may contain decryption keys, active process state, or attacker tooling not yet written to disk.
• Disable the affected user account at the directory level. In Active Directory, run Disable-ADAccount -Identity [username] or use the Azure AD/Entra portal to disable the account. For cloud IAM, immediately attach a Deny * policy to the compromised IAM user or service principal, or call aws iam delete-access-key to revoke the active key pair.
• Kill the malicious process if still running. Via EDR remote response, execute a process termination targeting the identified PID. For Windows: taskkill /PID [pid] /F. For Linux: kill -9 [pid]. Note that for wiper malware this may not undo damage already done, but stops further destruction.
• Block identified C2 IPs, domains, and lateral movement paths at perimeter controls. Submit any identified external C2 addresses to your firewall/proxy block list and DNS sinkhole. Block SMB (port 445) and RDP (port 3389) outbound from the isolated host at the VLAN ACL level to prevent any remaining worm-propagation attempts if isolation is delayed.
• Revoke active cloud sessions and tokens. For AWS: call aws iam create-policy to attach a deny-all policy, rotate access keys, and invalidate any active STS session tokens. For Azure: use Revoke-AzureADUserAllRefreshToken in PowerShell or the Entra portal. For GCP: disable the service account key via gcloud iam service-accounts keys disable.
• Snapshot surviving cloud infrastructure immediately. Before any recovery action in cloud environments, take snapshots of all surviving volumes, databases, and VM disks to preserve forensic state and provide a recovery baseline: aws ec2 create-snapshot for each surviving EBS volume.

Eradication

• Remove all identified persistence mechanisms on the affected host. Check scheduled tasks (schtasks /query /fo LIST /v), registry run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and \RunOnce), WMI event subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter), and new or modified services (sc query) for entries created in the attack timeframe. Remove any that do not correspond to legitimate software.
• Locate and delete all dropped payloads and attacker tooling. Use your EDR's threat hunting capability to search for the identified binary hashes across all endpoints in your environment. On the affected host, search %TEMP%, %APPDATA%, C:\ProgramData\, and /tmp or /var/tmp on Linux for recently created executables. Delete confirmed malicious files and submit hashes to your threat intel platform.
• Reset credentials for all accounts that executed malicious activity or were present on the compromised host. This includes the directly compromised account, any local admin accounts on the affected host (attackers routinely dump LSASS), and any service accounts whose credentials were cached. Force password resets and issue new Kerberos tickets by resetting the account twice in rapid succession to invalidate existing TGTs.
• Audit all lateral movement targets for the same indicators. For every host the attacker authenticated to (identified in step 6 of the investigation), run the same persistence and payload checks. A single missed foothold will allow re-infection.
• Rotate all exposed secrets, API keys, and certificates. Any credentials or API keys present on the compromised system — in environment variables, config files, credential stores, or browser profiles — must be treated as fully compromised and rotated in their respective platforms before any recovery action begins.

Recovery

• Restore data from the most recent verified clean backup — verify integrity before use. Identify the last known-good backup predating the attack from your backup solution (Veeam, Azure Backup, AWS Backup). Confirm backup integrity by checking hash values or backup solution verification logs before restoring to production to ensure the backup itself was not tampered with during a long-dwell intrusion.
• Re-image the affected host if confidence in full eradication is not absolute. For any host that ran confirmed wiper malware, re-imaging from a known-good golden image is safer than attempting to clean in place. Reconnect the re-imaged host to the network only after verifying no persistence mechanisms remain and a full AV/EDR scan returns clean.
• Re-enable the affected user account only after confirming no persistence remains and completing a credential reset. Have the user log in from a clean device first, and monitor their account activity closely for the following 72 hours using your UEBA platform or manual SIEM queries for anomalous logon times, locations, or accessed resources.
• Monitor the previously affected host, user account, and any lateral movement targets for 72 hours post-remediation. Create a temporary, higher-sensitivity detection rule scoped to these specific assets with lowered thresholds — any recurrence of file deletion or destruction activity should be treated as re-infection until proven otherwise.
• Document the full incident timeline and conduct a lessons-learned review within 5 business days. Capture the initial access vector, dwell time, detection gap, and total data loss in your case management system (ServiceNow, JIRA, TheHive). Present findings to stakeholders including backup coverage gaps and detection timing. Update your runbooks and detection rules with any new IOCs, process names, or behavioral patterns observed during this incident.