M1053 Data Backup: Data Backup as an ATT&CK Mitigation for Destructive Techniques

Backups are the only ATT&CK mitigation listed for disk wiping and defacement, yet attackers routinely reach and destroy them with the same administrator and service account credentials used to manage them. MITRE ATT&CK mitigation M1053 Data Backup does not prevent a destructive technique from running; it limits the impact by making restoration possible. This guide maps M1053 to the ten Impact techniques it mitigates in ATT&CK v20, shows which backup properties counter each one, explains how attackers defeat backups through T1490 Inhibit System Recovery and stolen backup identities, and sets out implementation priorities and metrics. It is written for detection engineers, backup and infrastructure owners and security architects who need to show that backup coverage is real.

Key takeaways

• Ten techniques, all in the Impact tactic. In ATT&CK v20, M1053 mitigates T1485 Data Destruction, T1485.001 Lifecycle-Triggered Deletion, T1486 Data Encrypted for Impact, T1490 Inhibit System Recovery, T1491 Defacement (and .001, .002) and T1561 Disk Wipe (and .001, .002).
• For two technique families M1053 stands alone. ATT&CK lists no other mitigation for T1561 Disk Wipe or T1491 Defacement, or their sub-techniques, so recovery capability is the whole ATT&CK-listed defence there.
• "Off system and protected" is the core requirement. ATT&CK's usage text repeatedly says backups must be stored off system and protected from the methods adversaries use to destroy them.
• Backup identities are the attack path. Backup consoles, service accounts and cloud keys that can delete, shorten retention or change lifecycle rules are the route to defeating M1053; treat them as tier 0.
• Only a tested restore counts. Measure restore success and time against recovery objectives, not job completion rates.

What M1053 is in ATT&CK terms

ATT&CK defines M1053 Data Backup as taking and securely storing backups of data from end-user systems and critical servers, with hardened backup systems, secure storage and isolation from the corporate network so backups survive an active incident. Its implementation guidance names regular scheduling (daily incremental and weekly full backups for critical systems as an example), immutable write-once-read-many storage, encryption of backups, offsite or cloud storage, and regular restore testing.

The per-technique usage text adds three specifics: implement IT disaster recovery plans with regular backups; enable versioning on cloud storage objects and copy backups to other accounts or regions to isolate them from the original copies; and on ESXi servers, take regular disk images and virtual machine snapshots with copies stored off system. The D3FEND ontology records that comprehensive IT disaster recovery planning is outside D3FEND's current scope, so there is no D3FEND countermeasure mapped to M1053.

This page covers M1053 from the ATT&CK point of view. For backup architecture, immutability options and vendor-neutral design, see the Backup Security and Immutable Backup Guide.

Techniques M1053 mitigates

All ten non-revoked techniques linked to M1053 in ATT&CK v20 (enterprise-attack 20.0), with the backup property that matters most and the other mitigations ATT&CK lists.

Technique detail and detections are in the MITRE ATT&CK T1486 Data Encrypted for Impact and the T1490 Inhibit System Recovery Defensive Guide.

Priority order

1. T1490 first: it is the technique that defeats M1053 for every other row. If an attacker can delete shadow copies, backup catalogues, snapshots or cloud backups, the rest of this table fails.
2. T1486: the most frequent destructive outcome; it drives recovery time objectives.
3. T1485.001 and cloud T1485: fast, API-driven and often missed by on-premises backup programmes.
4. T1561 and T1491: lower frequency, but M1053 is the only listed mitigation, so image-level and content backups must exist.

How attackers defeat M1053

ATT&CK's T1490 entry lists native Windows tools adversaries use to remove recovery options: vssadmin.exe and WMI to delete volume shadow copies, wbadmin.exe to delete the Windows backup catalog, bcdedit.exe to turn off automatic recovery, and REAgentC.exe to disable the Windows Recovery Environment. It also notes adversaries may disable recovery notifications and then corrupt backups. Local recovery features on the compromised host are therefore convenience copies, not M1053 coverage.

In cloud environments, T1485.001 describes an adversary with permission to change lifecycle configuration applying a rule that deletes every object in a bucket. The Codefinger S3 ransomware campaign combined both cloud patterns: stolen long-lived access keys with read and write permissions were used to re-encrypt objects with attacker-held keys, and lifecycle rules were set to delete the files within seven days. Recovery depended on a separate, protected copy.

Control-plane destruction does not need malware at all. In the Stryker Intune wiper attack, a compromised administrator account issued remote wipe commands to tens of thousands of devices. The lesson for M1053 is that rebuild capability (golden images, configuration backups, device re-enrolment) must survive an identity-plane compromise.

Protecting backup identities

Every backup system runs on non-human identities: backup service accounts with broad read rights, agents with local administrator or root, hypervisor credentials, cloud roles that write to vaults, and API keys for SaaS backup connectors. These identities can usually also delete, shorten retention or disable jobs. NHI Mgmt Group recommends the following, which go beyond the ATT&CK text:

• Separate the backup control plane: backup consoles and vault administration in a separate account, subscription, project or domain, not joined to the production identity provider where avoidable. See the Backup Identity Isolation Guide.
• Split write from delete: the identity that writes backups should not be able to delete recovery points, reduce retention or change lifecycle rules.
• Require a second approver for destructive actions: use multi-person authorisation where the platform offers it for retention changes and deletion.
• Replace long-lived keys: use federated or short-lived credentials for cloud backup jobs and SaaS backup connectors, and rotate any remaining secrets.
• Phishing-resistant MFA for backup administrators: backup admin accounts are tier 0 and should be named, dedicated and monitored.

Implementation in phases

1. Map coverage to techniques: list critical systems and data stores, and for each record whether an off-system, immutable copy exists and whether a restore was tested in the last quarter. Include cloud object stores, SaaS data, hypervisors and identity provider configuration.
2. Close T1490 exposure: make sure at least one copy is out of reach of domain and cloud administrators of the protected environment, through WORM storage, a locked vault or an offline medium.
3. Turn on cloud immutability: enable versioning and retention locks, and copy to another account or region as ATT&CK recommends. Test in a reversible mode first, then lock (see the table below).
4. Harden backup identities: apply the identity controls above and remove backup service accounts from general administrator groups.
5. Test restores: run scheduled restores of whole systems, not just files, into an isolated network, and time them. See the Backup and Recovery Testing Checklist.
6. Roll back safely: retention locks are designed to be irreversible. Pilot with governance or unlocked modes and short retention, confirm cost and operational impact, and only then lock.

Cloud immutability settings

Providers are listed alphabetically. Each row describes the provider's own feature from its documentation as of November 2026.

Decision guidance

Small organisations get most of the value from one immutable cloud copy administered by a separate account with MFA, plus quarterly whole-system restore tests. Large organisations should add cross-region copies, golden images, multi-person authorisation and recovery environments sized for a domain-wide event.

Detection and measurement

Detection for M1053 focuses on attempts to defeat it: process creation of vssadmin, wbadmin, bcdedit and REAgentC with deletion or disable arguments; backup job failures or disabled notifications; retention reductions and deletion of recovery points in backup consoles; and cloud API events that change lifecycle rules, disable versioning or bypass governance retention. For cloud storage, the Codefinger case shows why bulk overwrites and lifecycle changes need alerts.

Framework mapping and related controls

Related ATT&CK mitigations: M1040 Behavior Prevention on Endpoint, M1018 User Account Management, M1028 Operating System Configuration and M1032 Multi-factor Authentication.

Common failure patterns

• Backups in the same identity domain: backup servers joined to the production domain, so domain admin compromise is backup admin compromise.
• Counting shadow copies and snapshots as backups: T1490 removes them first.
• Cloud data without versioning or a second account: one stolen key can overwrite or lifecycle-delete everything, as in the Codefinger campaign.
• Untested whole-system restores: file restores pass while hypervisor, identity provider and application rebuilds have never been rehearsed.
• Backup service accounts with standing delete rights: the writing identity can also purge recovery points and shorten retention.
• Silenced alerts: ATT&CK notes adversaries disable recovery notifications before corrupting backups; nobody notices the jobs stopped.

Practitioner checklist

• Map every critical system to an off-system, immutable copy and record the gaps.
• Store at least one copy outside the reach of production administrators.
• Enable cloud versioning and retention locks, with copies in another account or region.
• Image ESXi and other hypervisor workloads with copies stored off system.
• Split write and delete rights for backup identities and require a second approver for retention changes.
• Remove long-lived keys from backup jobs and connectors.
• Alert on T1490 utilities, retention changes, lifecycle changes and disabled backup notifications.
• Run timed whole-system restores into an isolated network every quarter.

Standards and references

• MITRE ATT&CK: M1053 Data Backup
• MITRE ATT&CK: T1490 Inhibit System Recovery
• CISA: #StopRansomware Guide
• NIST: SP 1800-25 Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events
• Amazon Web Services: Locking objects with Object Lock
• Google Cloud: Backup vault overview
• Microsoft Learn: Immutable vault for Azure Backup

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Backup Identity Isolation Guide · T1490 Inhibit System Recovery Defensive Guide · Backup and Recovery Testing Checklist · MITRE ATT&CK T1486 Data Encrypted for Impact