A wiper attack has no decryptor and no negotiation: every minute it runs, data is permanently destroyed, so the response is a race to stop the spread and rebuild from backups the attacker could not reach. Wipers overwrite files, disk structures or firmware, and some are built to look like ransomware: MITRE ATT&CK describes WhisperGate as a multi-stage wiper "designed to look like ransomware", and NotPetya as malware whose main purpose was to destroy data and disk structures. Destruction can also come without malware, when an attacker with a stolen administrator account issues remote wipe commands through a device management platform. This playbook template gives [Organisation] a response for destructive attacks on endpoints, servers, virtualisation, cloud and device management. It assumes you have read the Wiper Malware Guide for background and covers what to do on the day.
How to use this template
- Adopt it alongside the ransomware playbook, not inside it. The first decision in section 3 is whether the event is a wiper, because evidence, communication and recovery priorities differ. See the Ransomware Response and Recovery Guide.
- Attach three lists before you need them: the critical services restoration order, the backup inventory with which copies are offline or immutable, and the out-of-band contact sheet.
- Keep decision points explicit. Each "Decision" line names who decides and on what evidence.
- Replace every [placeholder] and exercise the playbook at least yearly with a scenario where the primary identity provider and email are gone.
1. Scope and triggers
1.1 This playbook applies to any event where [Organisation] data, disks, firmware, virtual machines, cloud resources or managed devices are being, or have been, deliberately destroyed or made unrecoverable, whether by wiper malware, by abuse of legitimate administration tools, or by malware posing as ransomware.
1.2 Techniques to record in the case:
| Behaviour | ATT&CK | What responders see |
|---|---|---|
| Files overwritten or deleted | T1485 Data Destruction | Files replaced with junk, zero length or random data; mass deletions on shares |
| Disk content or raw volumes overwritten | T1561.001 Disk Content Wipe | Raw disk writes by unexpected processes; unreadable volumes |
| Master boot record or partition table destroyed | T1561.002 Disk Structure Wipe | Hosts fail to boot after a forced reboot |
| Shadow copies, backups and recovery deleted | T1490 Inhibit System Recovery | vssadmin or wbadmin deletions, backup jobs deleted, recovery partitions removed |
| Forced reboot to trigger damage | T1529 System Shutdown/Reboot | Many hosts reboot at once |
| Wiper pushed at scale | T1484.001 Group Policy Modification, T1072 Software Deployment Tools | New GPO or deployment job running the same binary everywhere |
| Fake ransom note with no real recovery path | T1485 Data Destruction (record as wiper) | Note with no unique victim ID, payment route that cannot work, or encryption keys discarded |
1.3 Triggers: many hosts failing to boot together; mass file modification alerts from EDR or file integrity monitoring; backup or snapshot deletion; a burst of device wipe, retire or delete actions in the device management audit log; destructive commands against hypervisors or cloud resources; a ransom note that the threat intelligence team cannot tie to a working extortion operation.
2. Roles and contacts
| Role | Named lead | Responsibilities |
|---|---|---|
| Incident lead | [Name, phone] | Declares the incident, owns the decision log and restoration order |
| Executive sponsor | [Name] | Approves network shutdowns and business continuity activation |
| Infrastructure and backup lead | [Name] | Protects backups first, then runs restoration |
| Identity administrator | [Name] | Removes attacker admin access, uses break-glass accounts |
| Forensics lead or retained firm | [Retainer reference] | Collects samples, memory and logs before rebuild |
| Business continuity manager | [Name] | Manual workarounds while systems are rebuilt |
| Legal, privacy and communications | [Names] | Regulators, customers, media, law enforcement |
2.1 Assume email, chat and the identity provider may be unavailable or watched. CISA's #StopRansomware Guide advises out-of-band methods such as phone calls so attackers do not learn they have been detected. See the Out-of-Band Communications for Incident Response Guide.
3. Detection and triage
3.1 Protect the backups first. Before anything else, disconnect or lock backup repositories, revoke the backup console sessions of any account in use by the attacker and confirm offline or immutable copies exist. The attacker will try to destroy recovery before or during the wipe.
3.2 Wiper or ransomware?
| Signal | Points to wiper | Points to ransomware |
|---|---|---|
| Disk and boot state | MBR or partition table destroyed, hosts unbootable | Hosts boot, files encrypted with a consistent extension |
| File content | Overwritten with fixed or random bytes, truncated | Encrypted, recoverable in principle |
| Note | Missing, generic, or no working contact or victim ID | Unique victim ID and a working negotiation portal |
| Data theft | Often none, or a "hack and leak" claim | Usually exfiltration before encryption |
| Context | Geopolitical or hacktivist claim, targeting of a sector or country | Financially motivated affiliate |
3.3 Decision (incident lead on advice from forensics and threat intelligence): classify as wiper, ransomware or unknown. Treat unknown as wiper for containment speed: there is no reason to wait for a negotiation that may never be possible.
3.4 Find the delivery mechanism. Wipers spread through what administrators use: Group Policy, software deployment and RMM tools, hypervisor management, and device management platforms. Check the audit logs of each for jobs, scripts or bulk actions started in the last [72] hours.
3.5 Capture evidence that will not survive the rebuild: a sample of the wiper binary, memory from one or two affected but still running hosts, EDR telemetry, and logs from domain controllers, deployment tools and cloud control planes. CISA's guide prefers keeping devices running and disconnecting them from the network, because powering down destroys memory artefacts.
4. Containment
4.1 Cut the propagation path. Disable or unlink the GPO, stop and delete deployment jobs, suspend the RMM or device management actions, and if spread continues, isolate at the switch or network segment level.
4.2 Remove the attacker's administration. Disable compromised admin accounts, revoke sessions, remove new privileged role assignments (T1098.003 Additional Cloud Roles) and new admin accounts. Use break-glass accounts if the normal admin path is compromised. See the Break-Glass Account Guide.
4.3 Device management wipes. In Microsoft Intune, Multi Admin Approval can require a second administrator to approve device wipe, retire and delete actions and script deployment. If it is not already on, enable it during the incident for device actions and scripts, after confirming at least two trusted administrators exist. The Stryker cyberattack reportedly used a hijacked administrator account and Intune remote wipe against tens of thousands of devices, with no wiper malware on the endpoints.
4.4 Decision (executive sponsor): shut down the network or segments. Choose a wider shutdown when destruction is still spreading and the delivery path is not yet found; choose targeted isolation when the path is cut and confirmed.
5. Eradication
5.1 Remove every persistence and delivery item found: GPOs, scheduled tasks, services, deployment packages, scripts in device management and RMM, and accounts the attacker created.
5.2 Find the initial access point (often an edge device, stolen administrator credential or third-party access) and close it before restoring anything. Restoring into an environment the attacker still controls invites a second wipe.
5.3 Rotate privileged credentials, including service accounts and API credentials with rights over deployment, backup and device management platforms. CISA's checklist sequences password resets after the environment is cleaned and rebuilt, so the attacker cannot capture new credentials.
6. Recovery
6.1 Restore in the predefined order: identity (domain controllers or identity provider), core network and DNS, backup infrastructure, then critical business services and their dependencies.
6.2 Rebuild, do not clean. Wiped hosts are rebuilt from gold images or infrastructure as code; restore data, not system state, from backups taken before the attacker's first activity.
6.3 Verify backups before use. NCSC advises scanning backups for malware and only connecting them to known clean devices. Restore into an isolated recovery segment and add only verified clean systems to it.
6.4 Track restored services against the business continuity plan and record recovery point and recovery time achieved for each.
7. Communication and notification
| Audience | Owner | When |
|---|---|---|
| Staff | Communications | Within [2] hours, by out-of-band channel: what not to use, how to work manually |
| National CSIRT and law enforcement | Incident lead | At declaration; wiper attacks may be state linked and others may be targeted (UK: report.ncsc.gov.uk) |
| Sector regulator (NIS, DORA or sector rules) | Compliance lead | Within the applicable incident reporting deadline |
| Data protection regulator | Privacy lead | Loss of availability of personal data can be a personal data breach; assess and notify where required |
| Customers and partners | Account owners | Service impact and expected restoration; never promise dates you cannot meet |
| Insurer | Finance | At declaration, before engaging paid responders if the policy requires it |
8. Post-incident review
8.1 Record the timeline: initial access, first destructive action, detection, propagation stopped, first critical service restored, full recovery.
8.2 Root cause questions: Could one administrator wipe the fleet without a second approval? Were backups reachable with domain or cloud admin credentials? Was there an offline copy? Did the restoration order match business priorities?
8.3 Metrics: time from first destructive action to propagation stopped; percentage of hosts and data recovered; recovery time per critical service against target; percentage of critical data with an offline or immutable copy tested in the last [90] days; number of destructive admin actions protected by multi-party approval.
8.4 Share indicators with your national CSIRT or sector ISAC, as CISA recommends.
Implementation guidance
- Make backups survive an admin compromise. NCSC recommends recent offline backups, multiple copies in different locations and settings that stop older versions being deleted. Separate backup identities from the production directory. See the Backup Security and Immutable Backup Guide and the Backup Identity Isolation Guide.
- Put two-person rules on destructive actions: device wipe and retire, bulk deletion in cloud consoles, backup policy changes and hypervisor datastore deletion.
- Treat automation identities as destruction paths. Service principals and API tokens with device management or backup rights can wipe as effectively as a human admin. Review them quarterly.
- Size by organisation. A small organisation may restore from cloud backups and reimage laptops through the vendor; its priority is an offline copy and a phone tree. A large organisation needs an isolated recovery environment, rehearsed identity rebuilds and a restoration order agreed with the business.
| Playbook section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Backups protected and tested | PR.DS-11 | CP-9 | A.8.13 |
| 3. Detection and triage | RS.AN-03 | IR-4, SI-4 | A.5.25 |
| Evidence handling | RS.AN-06 | IR-4 | A.5.28 |
| 4. and 5. Containment and eradication | RS.MI-01, RS.MI-02 | IR-4 | A.5.26 |
| 6. Recovery | RC.RP-02, RC.RP-03, RC.RP-05 | CP-10 | A.5.30 |
| 7. Communication | RS.CO-02, RC.CO-03 | IR-6 | A.5.26 |
References: NIST: SP 800-61 Rev. 3 Incident Response Recommendations · NIST: SP 1800-26 Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events · CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide · NCSC: Mitigating malware and ransomware attacks · Microsoft: Use Multi Admin Approval in Intune · MITRE ATT&CK: T1561 Disk Wipe · MITRE ATT&CK: WhisperGate
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Wiper Malware Guide · Data Integrity Protection Against Destructive Attacks Guide · Ransomware Response and Recovery Guide · Microsoft Intune Guide