MITRE ATT&CK T1485 Data Destruction: Detecting and Limiting Damage

Data destruction leaves nothing to negotiate over: once files, buckets, clusters or virtual machines are overwritten or deleted, recovery depends entirely on what the attacker could not reach. MITRE ATT&CK T1485 Data Destruction covers adversaries destroying data and files on specific systems or across a network to interrupt availability, often overwriting them so forensic recovery is impossible. In ATT&CK v20 it belongs to the Impact tactic (TA0040) and applies to Windows, Linux, macOS, ESXi, IaaS and containers, with one sub-technique, T1485.001 Lifecycle-Triggered Deletion, covered on its own page. This guide covers how destruction appears across endpoints, hypervisors, cloud and Kubernetes, the v20 detection strategy and its six platform analytics, the three ATT&CK mitigations, and the identity controls that decide how far one compromised account can reach. It is for detection engineers, SOC leads, cloud and platform owners and recovery planners. The tactic-wide view is in the ATT&CK Impact Tactic Guide, and wiper malware families are covered in the Wiper Malware Guide; this page stays on the technique.

Key takeaways

• Malware is optional. ATT&CK v20 lists ShinyHunters calling the DeleteBucket API and LAPSUS$ deleting systems and resources on premises and in the cloud; the reported Stryker incident used a device management console's own wipe command.
• Overwrite, then delete. Wipers such as CaddyWiper, HermeticWiper, Shamoon and DynoWiper overwrite content before or instead of deleting it, so file deletion events alone under-report the damage.
• Six platforms, six signals. v20 detection strategy DET0146 has analytics for Windows, Linux, macOS, IaaS, ESXi and containers, each with different log sources.
• Three mitigations, all about recovery and rights. M1053 Data Backup, M1032 Multi-factor Authentication (MFA delete) and M1018 User Account Management (limit who can change lifecycle policies).
• Identities set the blast radius. A global administrator, a cloud access key with Delete permissions, a CI token or a privileged Kubernetes service account decides whether one system or the whole estate is destroyed.

How the technique works

ATT&CK describes destruction that makes data irrecoverable by overwriting files on local and remote drives. Ordinary deletion commands only remove pointers, so adversaries overwrite with random data, and in some cases politically motivated images. Destructive malware may spread worm-like using T1078 Valid Accounts, T1003 OS Credential Dumping and T1021.002 SMB/Windows Admin Shares. In the cloud, adversaries delete storage objects, machine images, database instances and other infrastructure; on premises they may delete virtual machines.

How adversaries use it: cases

Two incidents where the lesson is the customer-side control

• Management console as the weapon: in the Stryker Cyberattack 2026, reporting cited on the NHI Mgmt Group breach page says attackers compromised an administrator account, created a new Global Administrator and used Intune remote wipe against nearly 80,000 devices in about three hours on 11 March 2026. Stryker stated no ransomware or malware was deployed. The controls that matter are no standing top-tier roles, alerts on new privileged role assignments, multi-admin approval for bulk destructive actions and tightly scoped device management roles. See the Handala and Void Manticore Threat Actor Profile Guide.
• Cloud keys and lifecycle rules: in the Codefinger S3 Ransomware 2025 case, stolen long-term AWS keys were used to re-encrypt objects and then schedule their deletion within seven days through the S3 lifecycle API. Lifecycle-driven deletion is T1485.001; the recommended controls are temporary credentials instead of long-term keys, scoped S3 permissions, versioned and protected backups, and alerts on bulk overwrites and lifecycle changes.

Supply chain worms show the developer angle: the Shai-Hulud entry above destroyed home directories on developer machines. See the Shai-Hulud npm Worm Guide.

What to detect and where

ATT&CK v20 maps DET0146 Detection of Data Destruction Across Platforms via Mass Overwrite and Deletion Patterns. Its analytics and named log sources:

Making the signals actionable

• Rate, not event: alert on deletions or overwrites per process or per principal per minute against a baseline. A wiper or a scripted mass delete produces a curve no normal workload does.
• Cloud fan-out: one principal calling Delete or Terminate across many resources, regions or accounts in a short window; any lifecycle configuration change that adds an expiration rule on a production bucket; disabling of versioning.
• Management plane actions: bulk wipe, retire or delete actions in endpoint management, and new top-tier role assignments shortly before them. See the Microsoft 365 Ransomware and Mass Deletion Playbook.
• Kubernetes: new privileged DaemonSets or pods mounting host paths, created by an identity that does not normally deploy to that cluster.
• Precursors: recovery inhibition and defence tampering usually come first and are covered in the T1490 Inhibit System Recovery Defensive Guide.

File integrity monitoring and canary files in high-value shares give early, low-noise signals of overwrite activity. For CloudTrail specifics see How to Investigate CloudTrail for a Compromised Access Key.

Mitigations

AWS storage protections compared

Equivalent controls exist in other clouds and backup platforms; the principle is the same: a copy the production identities cannot delete. See the Backup Security and Immutable Backup Guide, the Amazon S3 Security Guide and M1053 Data Backup.

Where identity fits

Destruction at scale needs rights at scale. In most cloud and management plane cases the adversary did not need exploits, only an identity allowed to delete. Recommended controls:

• Separate destroy rights from run rights: workload roles, CI tokens and service principals should read and write data but not delete buckets, snapshots, clusters or backup vaults.
• No long-term cloud keys with Delete permissions: replace them with temporary credentials and scope them to named resources.
• Just-in-time top-tier roles: no standing global administrator or device management wipe rights; alert on every new assignment.
• Multi-admin approval: for bulk wipes, deletes and backup policy changes where the platform supports it.
• Backup identities apart: backup administration in a separate account or tenant with its own credentials. See the Backup Identity Isolation Guide.

Rolling out protection and detection

1. Rank data stores by recovery impact: list the buckets, databases, file shares, VM datastores and clusters whose loss stops the business.
2. Find who can destroy them: enumerate every human and non-human principal with Delete, Terminate, lifecycle, wipe or datastore rights on each; remove what is not needed.
3. Protect a copy: enable immutable recovery points for the top tier first, testing Object Lock in governance mode before committing to compliance mode.
4. Deploy detection in audit: rate-based deletion rules per platform and cloud fan-out rules, measured for two to four weeks against normal clean-up jobs.
5. Move to alert and automated containment: for the highest-confidence rules, disable the principal or isolate the host automatically, with an approved break-glass path.
6. Rollback: detection and permission changes are reversible from saved policy versions; compliance-mode retention is not, which is why it comes after the governance-mode test.

How to test

• Restore drill: restore a top-tier data store from the immutable copy into an isolated account and time it.
• Immutability check: with a test principal, attempt to delete a locked test object version and confirm the denial and the log entry.
• Endpoint rate rule: delete a folder of generated test files on a lab host and confirm the rule fires on rate.
• Cloud rule: in a sandbox account, add an expiration lifecycle rule to a test bucket and delete test snapshots, then confirm both alerts.
• Management plane: confirm a wipe action against a single test device generates an alert and, where configured, requires a second approver.

Measuring it

• Immutable coverage: percentage of top-tier data stores with an immutable, separately administered recovery point.
• Destroy-capable principals: count of identities with Delete, Terminate, lifecycle or wipe rights on top-tier stores, trending down.
• Long-term keys with Delete rights: target zero.
• Restore time: measured recovery time for the last drill against the target.
• Detection latency: time from the start of a test mass deletion to alert, per platform.

Common failure patterns

• Backups in the blast radius: the same administrator or cloud account can delete production and its backups, as Storm-0501's destruction of backup files shows.
• Deletion events only: overwrite-style wipers change content without deleting, so rules keyed on delete events miss them.
• Clean-up jobs as cover: broad exclusions for routine deletion jobs hide an adversary using the same identity.
• Standing management console rights: one compromised administrator can issue fleet-wide destructive commands with no second check.
• Lifecycle rules unmonitored: an expiration rule looks like housekeeping and deletes everything on schedule.

Framework mapping

Practitioner checklist

• Rank data stores by recovery impact and list every principal that can destroy each one.
• Keep an immutable, separately administered recovery point for every top-tier store.
• Remove Delete, Terminate, lifecycle and wipe rights from workload identities and long-term keys.
• Make top-tier and device management roles just-in-time, with alerts on assignment.
• Require multi-admin approval for bulk wipes and deletes where the platform offers it.
• Alert on deletion and overwrite rates per platform, and on cloud Delete or Terminate fan-out.
• Alert on lifecycle expiration rules and versioning changes on production buckets.
• Run restore drills on a schedule and record the measured recovery time.

Standards and references

• MITRE ATT&CK: T1485 Data Destruction
• MITRE ATT&CK: T1485.001 Lifecycle-Triggered Deletion
• AWS: Locking objects with Object Lock
• AWS: Configuring MFA delete
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ATT&CK Impact Tactic Guide · Wiper Attack Response Playbook · Cloud Ransomware Guide · Backup Identity Isolation Guide · MITRE ATT&CK T1486 Data Encrypted for Impact