MITRE ATT&CK T1561 Disk Wipe: Detecting and Limiting Damage

Disk wiping destroys the data and boot structures that every recovery plan assumes will still be there, and in 2026 it no longer needs custom malware: a hijacked administrator account in a device management console can wipe a fleet with a built-in command. MITRE ATT&CK tracks this as T1561 Disk Wipe, an Impact (TA0040) technique with two sub-techniques, T1561.001 Disk Content Wipe and T1561.002 Disk Structure Wipe, on Linux, macOS, network devices and Windows. This guide is for detection engineers, endpoint and device management owners and incident responders. It covers how wiping works at the technique level, the cases ATT&CK records, MITRE's three detection strategies, and the controls that limit how far a wipe can spread. The step-by-step response is in the Wiper Attack Response Playbook, which this page links to rather than repeats.

Key takeaways

• Two targets, one goal. Content wipe overwrites data so it cannot be recovered through the storage interface; structure wipe destroys the boot record or partition table so the system cannot start. Many wipers do both.
• Scale comes from identity, not malware. ATT&CK notes wiping malware may spread using Valid Accounts, OS Credential Dumping and SMB/Windows Admin Shares. In the 2026 Stryker attack, VOID MANTICORE used legitimate remote wipe commands from Microsoft Intune.
• Raw disk access is the tell. MITRE's analytics centre on processes opening \\.\PhysicalDrive devices on Windows, writes to block devices on Linux, destructive diskutil calls on macOS and erase or format on network devices.
• The only ATT&CK mitigation is backup. M1053 Data Backup is the single mitigation listed in v20. Everything that limits blast radius beforehand, such as approval for destructive admin actions, is an NHI Mgmt Group recommendation layered on top.
• Plan for machines that will not boot. A structure wipe turns file restore into bare-metal rebuild. Recovery time depends on reimaging capacity, not just on backup copies.

What the technique covers

ATT&CK v20 (T1561 version 1.2) describes adversaries wiping or corrupting raw disk data on specific systems or in large numbers across a network to interrupt availability. With direct write access, they may overwrite portions of disk data or disk structures such as the master boot record (MBR).

Neighbouring techniques draw the boundaries. Deleting or overwriting files through the file system is T1485 Data Destruction. Reading raw volumes to bypass file controls is T1006 Direct Volume Access. Deleting backups and recovery data is T1490 Inhibit System Recovery, and the reboot that makes a structure wipe take effect is T1529 System Shutdown/Reboot.

How adversaries use it: real cases

From the ATT&CK v20 procedure examples, with the research ATT&CK cites, plus one NHI Mgmt Group breach analysis:

Remote wipe through management platforms

• Stryker (March 2026), VOID MANTICORE (G1055): ATT&CK records that the group used a disk wiping utility on victim servers and also used legitimate remote disk wiping commands. Our Stryker Cyberattack 2026 analysis describes a compromised administrator account used to create a new Global Administrator, then Intune's remote wipe command issued to enrolled devices between about 05:00 and 08:00 UTC on 11 March 2026. Reporting cited there puts the figure near 80,000 devices; the attacker's larger claims are unverified. No wiper malware was reported on endpoints. The US Justice Department describes Handala as a persona operated by Iran's Ministry of Intelligence and Security. See the Handala and Void Manticore Threat Actor Profile Guide.

Wiper malware

• Shamoon (S0140) with RawDisk (S0364): overwrote the MBR and partitions using RawDisk, which ATT&CK describes as a legitimate commercial driver that allows direct modification of disk data, in some cases from user-mode processes (Palo Alto Networks and Unit 42, 2016 and 2018).
• HermeticWiper (S0697): corrupts partitions, damages the MBR and overwrites the Master File Table of all physical drives (SentinelOne and CrowdStrike, February 2022).
• WhisperGate (S0689): overwrote the MBR with a malicious bootloader and overwrote disk sectors at periodic offsets; ATT&CK attributes its use in Ukraine to Ember Bear (G1003).
• CaddyWiper (S0693): destroys partition information including MBR, GPT and partition entries (ESET and Cisco Talos, March 2022).
• Sandworm Team (G0034): used the BlackEnergy KillDisk component to corrupt the MBR (US-CERT, 2016). In December 2025, ESET attributed DynoWiper, used against a Polish energy company, to Sandworm with medium confidence; it overwrote files and forced a reboot. See the Sandworm Threat Actor Profile.
• HomeLand Justice (C0038): a ZeroCleare variant wiped disk drives on targeted hosts in Albania (CISA, September 2022).

Living off the land and ransomware

• APT28 Nearest Neighbor Campaign (C0051): used the native cipher.exe (S1205) to overwrite deleted data, removing traces rather than causing outage (Volexity).
• Diskpart (S9002): ATT&CK notes it can delete partitions or remove all partitions from a disk; ShrinkLocker (S1178) used it to format partitions.
• BlackCat (S1068): can wipe VM snapshots (Microsoft and Sophos, 2022), and The Gentlemen ransomware wrote 64 MB chunks to exhaust free space and overwrite deleted content (Check Point Research, April 2026). Here wiping supports extortion by blocking recovery.

What to detect and where

ATT&CK v20 has three detection strategies with near-identical platform analytics. The table condenses them.

The management plane is a platform too

ATT&CK's analytics are host-centric, but the Stryker case shows the wipe can arrive as an authorised device action. Add these NHI Mgmt Group recommended detections for endpoint and mobile device management:

• Bulk device actions: more than a small number of wipe, retire or delete actions within minutes, from any account.
• New top-tier role assignments: creation of a Global Administrator or Intune Administrator assignment outside your privileged access workflow, followed by device actions.
• App-only device actions: wipe or delete calls through Microsoft Graph made by an application identity, which bypass interactive sign-in controls unless explicitly covered.
• Fleet-wide host signals: many devices going offline or re-enrolling at once, correlated with the console audit log.

For the event pipeline around these, see the Microsoft Intune Guide and the MITRE ATT&CK T1072 Software Deployment Tools guide, which covers wipers pushed through deployment tooling.

Limiting the blast radius

ATT&CK v20 lists one mitigation for T1561 and both sub-techniques: M1053 Data Backup, with backups stored off system and protected from the methods adversaries use to reach and destroy them. The other rows are NHI Mgmt Group recommendations.

Two details from Microsoft's Multi Admin Approval documentation matter for design. First, protection applies to delegated admin actions and to app-only calls through Microsoft Graph, but enterprise applications can be excluded from a policy, and excluded apps change protected resources without approval, so keep that list short and reviewed. Second, protecting role changes too early can deadlock role assignments; configure the other policies and verify role assignments first.

Where identity fits

Disk wipe at scale is an identity outcome. ATT&CK's description of worm-like spread names valid accounts, credential dumping and admin shares; the Stryker wipe needed only one privileged account and a console. Non-human identities widen the path: application registrations and service principals with Microsoft Graph device management permissions can issue wipes without an interactive sign-in, and deployment or backup service accounts often hold rights across every host. Inventory every human and non-human identity that can wipe, retire or reimage devices, remove standing top-tier rights, and alert when any of them acts in bulk. See the Privileged Access Workstations Guide and Recovering IAM and PAM After Ransomware or Domain Compromise.

How to test and roll out

1. Map who can wipe: list roles and application permissions that allow device wipe, retire and delete in each management platform, plus accounts with local admin or root on servers and privilege 15 on network devices.
2. Collect raw disk telemetry: Sysmon or EDR events for physical drive handles and driver loads on Windows; auditd rules for block device writes on Linux servers; unified log forwarding on macOS; TACACS+ command accounting on network devices.
3. Emulate safely: on a disposable virtual machine, an authorised tester runs a benign raw write to a spare disk and a partition change, and on a lab network device an erase of a test file. Confirm each analytic fires. Never test destructive actions on production storage.
4. Pilot approval controls: enable Multi Admin Approval for device actions with a small approver group, measure the effect on helpdesk work for two weeks, then extend to scripts, apps and role changes.
5. Rehearse rebuilds: restore and reimage a sample of devices, servers and network devices from offline sources, including a host whose boot record has been removed.
6. Roll back: access policies can be deleted if a legitimate workflow breaks; record the exception and re-create the policy rather than leaving protection off.

Metrics

• Number of identities, human and non-human, able to wipe more than 100 devices without a second approval (target: zero).
• Share of servers and endpoints sending raw disk access and driver load telemetry.
• Time to detect a bulk device action in the management console.
• Percentage of critical systems with a tested bare-metal rebuild in the last 12 months.
• Network devices with offline configuration backups and command accounting enabled.

Common failure patterns

• Treating the device management console as an IT tool, not a tier 0 system: the Stryker case shows a single console role can act as a wiper.
• Backups reachable from the domain: the account that wiped the fleet can usually reach backup servers on the same domain.
• Restore plans that assume a working OS: structure wipes need reimaging capacity at scale, including for domain controllers and hypervisors.
• Trusting legitimate drivers by default: RawDisk is a legitimate commercial driver; being legitimate does not make raw disk access expected on a given host.
• Excluding automation apps from approval policies: excluded application identities can perform protected actions with no second approver.
• No logs off the host: evidence on a wiped disk is gone; forward telemetry before the event.

Framework mapping

Practitioner checklist

• Inventory every human and non-human identity that can wipe, retire or reimage devices.
• Require second-admin approval for device wipe, retire and delete, and keep app exclusions minimal.
• Enforce phishing-resistant MFA and Conditional Access on device management administrators.
• Alert on bulk device actions and on new top-tier role assignments.
• Collect raw disk access and driver load events on Windows, and block device writes on Linux servers.
• Enable command accounting and keep offline configuration backups for network devices.
• Keep backups off system and out of reach of production administrative accounts.
• Rehearse bare-metal rebuild for hosts with a destroyed boot record.

Standards and references

• MITRE ATT&CK: Disk Wipe (T1561)
• MITRE ATT&CK: Disk Content Wipe (T1561.001)
• MITRE ATT&CK: Disk Structure Wipe (T1561.002)
• CISA: CISA Urges Endpoint Management System Hardening After Cyberattack Against US Organization
• Microsoft: Use Multi Admin Approval in Intune
• ESET Research: DynoWiper update, technical analysis and attribution
• Specops: Stryker cyber attack, what we know about the remote wipe
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Wiper Attack Response Playbook · T1490 Inhibit System Recovery Defensive Guide · ATT&CK Impact Tactic Guide · Data Integrity Protection Against Destructive Attacks Guide · Backup Identity Isolation Guide