Wiper Malware Guide: Destructive Attacks, Resilience and Recovery

Wiper malware is built to destroy data, disks or firmware so that systems cannot be used or recovered, and many wipers pose as ransomware to slow the response. Wipers are mostly used by state-linked groups during geopolitical conflict, but the damage spreads to anyone connected to the target, as NotPetya showed in 2017. Recent attacks have also used legitimate admin tools, such as device management consoles, to wipe devices without any custom malware. This guide covers how wiper attacks work, where they show up, how to detect the preparation stage, and how to harden and plan recovery. It is written for security operations, infrastructure, OT and resilience teams; for malware families in general see the Malware Guide.

Key takeaways

• A ransom note does not mean ransomware. NotPetya and WhisperGate showed ransom notes, but their purpose was destruction and the data was never recoverable by paying.
• The intrusion comes before the wipe. In Albania, Iranian actors were inside for about 14 months before deploying a wiper, so detection of access, credential theft and lateral movement is the realistic window.
• Admin tools are the most dangerous wipers. Domain controllers, Group Policy, software deployment and device management platforms can push destruction to every device at once; protect them as tier zero.
• Recovery is the control that decides the outcome. Offline or immutable backups, tested rebuild procedures and spare hardware or firmware images determine whether a wiper causes days or months of disruption.
• OT and network devices are targets too. AcidRain wiped satellite modems and the December 2025 Polish energy attack damaged RTUs and controller firmware.

How the attack works

A wiper attack is a full intrusion with a destructive final step. The wiper itself is usually simple; the preparation is what makes it effective.

1. Access: exploitation of internet-facing systems (T1190 Exploit Public-Facing Application), VPNs and remote services (T1133 External Remote Services), or a compromised software supplier.
2. Privilege and spread: credential dumping (T1003 OS Credential Dumping) and movement over SMB admin shares and WMI (T1021.002, T1047), or abuse of central tools such as Group Policy (T1484.001 Group Policy Modification) and software deployment platforms (T1072 Software Deployment Tools).
3. Recovery sabotage: deleting shadow copies, backup catalogues and recovery partitions (T1490 Inhibit System Recovery), and targeting backup servers directly.
4. Destruction: overwriting files (T1485 Data Destruction), wiping raw disk content or structures such as the master boot record (T1561.001 Disk Content Wipe, T1561.002 Disk Structure Wipe), corrupting firmware (T1495 Firmware Corruption), then forcing a reboot (T1529 System Shutdown/Reboot) so the damage takes effect.

Wiper types defenders should recognise

Where it shows up

• Sandworm and Russia's war on Ukraine: ATT&CK attributes NotPetya to Sandworm Team (G0034), linked to GRU unit 74455. The UK government judged on 15 February 2018 that the Russian military was responsible, with Ukrainian financial, energy and government sectors the primary targets and costs across Europe of hundreds of millions of pounds. HermeticWiper (from early 2022, Ukraine, Latvia and Lithuania), WhisperGate and CaddyWiper followed around the 2022 invasion. See the Sandworm Threat Actor Profile.
• Satellite and telecoms: on 24 February 2022 an attacker used a misconfigured VPN appliance to reach the KA-SAT management segment and sent legitimate management commands that overwrote modem flash. Viasat reported tens of thousands of modems knocked offline and nearly 30,000 replacements shipped. ATT&CK lists the AcidRain wiper (S1125) and its overlap with Sandworm's VPNFilter.
• Iranian operations: Shamoon (S0140) was first used in 2012 by a group calling itself the Cutting Sword of Justice, with new versions in 2016 and 2018. In 2022, actors calling themselves HomeLand Justice disrupted the Albanian government using an encryptor and a disk wiper that abused the EldoS rwdsk.sys driver (CISA AA22-264A). Agrius (G1030) has used DEADWOOD, Apostle and MultiLayer Wiper.
• Energy and OT in 2025: CERT Polska reported destructive attacks on 29 December 2025 against more than 30 wind and solar farm grid connection points, a combined heat and power plant and a manufacturer. RTUs and controller firmware were damaged at renewable sites, cutting remote control though not production, and the CHP plant's EDR blocked the wiper. CERT Polska noted infrastructure overlap with the cluster tracked as Berserk Bear, Ghost Blizzard and Dragonfly.
• Admin platform abuse: in the Stryker cyberattack one hijacked admin account used Microsoft Intune to wipe tens of thousands of devices. The Amazon Q Developer extension compromise shipped data-wiping instructions to an AI coding agent.

Impact

Detection

By the time disks are being overwritten, detection is too late to save those hosts, but early alerts can stop the spread. Focus on the preparation stage and on destructive commands from admin tools.

Metrics

• Restore readiness: percentage of tier-one systems restored successfully in the last quarter's test, and measured time to restore against the recovery time objective.
• Backup isolation: percentage of critical data with an offline or immutable copy that production admin accounts cannot delete.
• Mass action protection: number of admin platforms (device management, deployment, hypervisor, cloud) with second-person approval on destructive actions.
• Preparation detection coverage: share of the staging signals above with a tested alert.
• Golden image currency: age of the clean build images and firmware images held offline.

Prevention and hardening

• Protect tier zero: domain controllers, identity providers, device management, software deployment, hypervisor and backup consoles should be administered only from privileged access workstations with phishing-resistant MFA. See the Living off the Land Guide.
• Require a second admin for mass destruction: Intune Multi Admin Approval can hold device wipe, retire and delete, script deployment, app deployment and RBAC changes until a different administrator approves, and it also applies to app-only Graph calls. Equivalent approval controls exist in many backup and cloud platforms; turn them on.
• Isolate backups: the NCSC advises offline copies, multiple copies in different locations, protection of previous versions from deletion, and administration of backups from privileged access workstations with MFA on a separate device. See the Backup Security and Immutable Backup Guide.
• Segment and limit spread: CISA's joint advisory on Ukraine-targeting wipers recommends segmentation with restrictive ACLs, management interfaces on restricted VLANs, unique service accounts without interactive logon rights, and staggered deployment of updates.
• Close the access paths: patch internet-facing systems using the CISA KEV catalog for priority, never expose management interfaces to the internet, and remove default credentials on VPNs and OT gateways.
• Keep rebuild material offline: operating system and application media, licences, network diagrams, configuration backups and firmware images, as CISA's advisory lists for recovery planning.

Implementation sequence

1. Business impact analysis (weeks 1 to 4): rank systems by the cost of total loss and set recovery time and point objectives that assume every host is wiped at once.
2. Backup isolation (weeks 2 to 10): create an offline or immutable copy for tier-one data, with separate credentials. Test by attempting deletion with a production admin account; it must fail.
3. Admin approval controls (weeks 4 to 8): enable Multi Admin Approval or equivalent on device management and deployment tools, starting with wipe and script actions. Pilot with one approver group, confirm approvers are reachable out of hours, and keep a documented break-glass procedure; roll back by removing the access policy if it blocks critical work.
4. Detection (months 2 to 4): deploy staging and recovery-sabotage alerts in report-only mode, tune, then page on them.
5. Full rebuild exercise (months 4 to 6): rebuild an identity tier, a business application and, where relevant, an OT cell from offline media in an isolated environment, and record real times. See the Identity Recovery Guide.

Small organisations should prioritise an offline backup, MFA on every admin console and a written rebuild order. Large and critical infrastructure organisations add clean-room recovery, spare OT devices and firmware, and exercises with suppliers. See the Cloud Recovery and Clean Room Guide.

Responding to a wiper attack

1. Find the common vector: CISA advises looking for what affected hosts share, such as a central application, file share, privileged account, network segment or DNS server.
2. Stop the spread: isolate with ACLs, null-route malicious addresses, disable suspect accounts and pause software deployment and device management jobs.
3. Reset credentials: be ready to reset all passwords and Kerberos tickets, including krbtgt to remove golden tickets.
4. Preserve evidence: collect off-host logs and images of surviving hosts before rebuilding.
5. Recover in order: identity first, then core infrastructure, then business systems, verifying backup integrity before restore (NIST CSF 2.0 RC.RP-03).
6. Report: to the NCSC in the UK, or CISA and the FBI in the US.

See the OT Incident Response Guide for plants and grid assets.

Lessons from incidents

• One admin account can be enough: the Stryker attack needed no custom malware once a device management admin account was hijacked.
• Management planes are targets: KA-SAT was damaged through its own management segment, reached through a misconfigured VPN appliance.
• Long dwell time is normal: the Albania attackers read email for about a year before the wipe.
• EDR still helps at the end: in Poland, EDR blocked the wiper at the CHP plant while unmonitored field devices were damaged.
• Collateral victims are real: NotPetya's main victims outside Ukraine were never the intended targets.

Framework mapping

Practitioner checklist

• Hold an offline or immutable copy of tier-one data that production admin accounts cannot delete, and test that.
• Keep golden images, firmware images, licences and network diagrams offline.
• Enable second-admin approval for wipe, delete, script and deployment actions on device management and deployment platforms.
• Administer tier-zero systems only from privileged access workstations with phishing-resistant MFA.
• Alert on shadow copy deletion, backup catalogue changes, Group Policy edits and bulk wipe commands.
• Remove internet exposure of management interfaces and default credentials on VPNs and OT gateways.
• Set recovery objectives that assume every endpoint is wiped at the same time.
• Run a full rebuild exercise from offline media at least once a year and record real times.
• Keep the incident response plan and contact list offline.

Standards and references

• CISA and FBI: Destructive Malware Targeting Organizations in Ukraine (AA22-057A)
• CISA and FBI: Iranian State Actors Conduct Cyber Operations Against the Government of Albania (AA22-264A)
• NCSC: Mitigating malware and ransomware attacks
• CERT Polska: Energy sector incident report 2025
• Microsoft Learn: Use Multi Admin Approval in Intune
• Viasat: KA-SAT Network cyber attack overview
• MITRE ATT&CK: Disk Wipe (T1561)
• UK Government: Foreign Office Minister condemns Russia for NotPetya attacks

Related NHI Mgmt Group resources: Malware Guide · Ransomware Response and Recovery Guide · Cyber Recovery Vault Guide · OT Security Guide · Threat Actor Groups Guide