Some intrusions are about money. Some are about damage. T1485, Data Destruction, is on the damage side: adversaries destroy data and files on specific systems, or in large numbers across a network, to interrupt availability. MITRE files it under impact, and it spans containers, ESXi, IaaS, Linux, macOS and Windows.
How attackers use it
Ordinary deletion commands such as del and rm often remove only pointers to files, which leaves the contents recoverable with forensic methods. Destruction goes further. Adversaries may overwrite files and directories with randomly generated data so that they cannot be recovered. MITRE notes that in some cases politically oriented images have been used as the overwrite content.
This differs from disk content wipe and disk structure wipe, which target sections of a disk or its logical structure. Data destruction targets individual files.
When the aim is network wide disruption, destructive malware may spread on its own, using other techniques such as valid accounts, OS credential dumping and SMB with Windows admin shares.
In the cloud, the targets change. Adversaries with access can delete storage objects, machine images, database instances and other infrastructure that operations depend on. On premises, they can delete virtual machines from virtualized environments.
MITRE's procedure examples include wiper malware used against Ukrainian power infrastructure, wipers in 2025 attacks in Poland that overwrote files in 16 byte blocks for speed, and malware that posed as ransomware but acted as a wiper by overwriting originals, zeroing their size, changing timestamps and deleting them.
How to detect it
MITRE's detection strategy has six analytics, one for each environment.
- Windows and general: command line tools or scripts that recursively delete or overwrite files, correlated with unusual file I/O, registry writes or changes to critical system directories.
- Linux: bulk recursive deletion or overwriting with tools such as rm, shred, dd or wiper binaries. Signals include unlink system calls, deletion of known configuration or data paths, and sequential overwrite patterns.
- macOS: destructive rm or dd and srm overwrites run from scripts in temp directories.
- Cloud: deletion of instances, buckets, snapshots or volumes with elevated credentials, often as batched Delete calls or TerminateInstances.
- ESXi: destruction of virtual disks, images or VMs through vim-cmd, datastore deletion or snapshot purges.
- Containers: container processes doing destructive file operations on mounted volumes or host paths, including breakouts followed by attempts to delete host data.
MITRE does not name log sources or event IDs for this technique. In practice you want process creation with command lines, file audit telemetry on critical data stores, cloud audit logs for management API calls, and hypervisor logs.
Alert on volume. One deleted file is normal. Thousands in a minute, from a script in a temp directory, is not. In the cloud, treat any batch of delete calls from a principal that does not usually delete as an incident.
How to reduce the risk
MITRE lists three mitigations.
- Multi-factor authentication. Turn on MFA delete for cloud storage such as AWS S3 buckets, so deleting protected data takes an extra authentication step.
- Data backup. Maintain disaster recovery plans with regular backups. Keep backups off system and protect them from the methods adversaries use to reach and destroy them.
- User account management. In cloud environments, limit permission to change bucket lifecycle policies, such as PutLifecycleConfiguration in AWS, to accounts that need it. Consider service control policies to restrict PutBucketLifecycle.
Two more steps follow from the technique itself. Test restores, because a backup you have never restored is a guess. And separate backup credentials from production credentials, since the worm like spread MITRE describes relies on valid accounts.
Check your own environment
- Pick one critical data store and write down how you would restore it, who can delete its backups, and how long a restore takes.
- Confirm that backup administration uses accounts that production administrators do not share.
- In your cloud console, list who can delete storage buckets, snapshots and machine images, and who can change lifecycle rules.
- Confirm cloud audit logs go to a separate account or store where deletion rights are tightly held.
- Check that versioning is on for important storage.
Quick check
Why does an ordinary delete not count as destruction?
Commands like del and rm often remove only pointers, leaving file contents recoverable. Destruction overwrites the data so it cannot be recovered.
Which MFA control does MITRE suggest for cloud storage?
MFA delete, for example on AWS S3 buckets.
How is data destruction different from disk wipe?
It destroys individual files rather than sections of a disk or its logical structure.
