What Is a Wiper? Destructive Malware Disguised as Ransomware

Ransomware and wipers can look identical in the first minutes of an incident. Both leave scrambled files and an ominous note demanding payment. The difference only becomes clear later, when the victim pays or tries to recover and discovers there was never any way to get the data back. The note was theater. The destruction was the whole point.

A wiper is malware whose purpose is to destroy. It corrupts files, overwrites disks, or wrecks the structures a computer needs to boot, and it does so with no built-in path to recovery. When a wiper wears a ransom note, the note is misdirection, designed to slow the response and hide the attacker's real goal.

Ransomware wants to be paid; a wiper does not

The distinction is about intent, and intent shows up in the code. Ransomware is a business. To collect payment, the operator has to keep a credible promise that paying restores the files, which means holding a decryption key and running working decryption. That recoverability is a feature the criminal needs.

A wiper has no such constraint. It does not need to keep a key, because it never intends to give anything back. So a wiper can:

Overwrite files with random or fixed data, destroying content in place.
Encrypt files with a key that is discarded immediately or generated so that no key ever leaves the machine.
Corrupt the master boot record and partition tables so the system cannot start at all.
Delete or overwrite the raw sectors of a disk, wiping structure as well as content.

On MITRE ATT&CK these behaviors map to Data Destruction (T1485) and Disk Wipe (T1561). A wiper that fakes encryption is sometimes called a pseudo-ransomware, because the encryption is real but the recovery is a lie.

A ransom note is not proof of ransomware

Treating every ransom note as a recoverable ransomware event can waste the critical early hours. In a wiper incident, those hours are better spent isolating systems and starting recovery from backups than negotiating with an attacker who has no key to sell. Confirm recoverability before you build your response around paying.

Why attackers destroy instead of extort

If there is no payday, why run a wiper at all? The motives are different from ordinary crime.

Sabotage and disruption. The goal is to take an organization offline, destroy operational capacity, or send a message. The damage itself is the objective.

Geopolitical conflict. Destructive malware has repeatedly appeared around state tensions, aimed at government, infrastructure, and industry to degrade an adversary's ability to function. Here the wiper is a weapon, not a scam.

Covering tracks. An attacker who has already achieved their goal, espionage, theft, or something else, may wipe systems on the way out to destroy forensic evidence and delay attribution.

Hacktivism. Ideologically motivated actors sometimes wipe to punish a target rather than profit from it.

Because the payoff is destruction rather than money, the usual deterrents and negotiation paths do not apply. That changes how you have to defend.

How wipers destroy, ranked by damage

Technique	What it targets	Recovery difficulty without backups
File overwrite	Individual files and documents	High; overwritten data is generally unrecoverable
Fake encryption	Files, with a key that is gone or never stored	Very high; no valid key exists
Master boot record corruption	The code and tables needed to boot	Moderate for structure, but data may follow
Raw disk or sector wipe	The entire disk layout and contents	Very high; both structure and data destroyed

The pattern across the table is the same. The more of the disk's structure a wiper destroys, the less any on-disk recovery tool can help, and the more everything depends on a copy that lives somewhere the wiper could not reach.

Delivery is the same as any other malware

Wipers do not arrive by magic. They are delivered and spread the same ways other intrusions are: phishing, stolen or weak credentials, exploited internet-facing services, supply-chain tampering, and lateral movement once inside. Frequently the wiper is the final stage of an intrusion that began quietly weeks earlier.

The file that carries the payload is usually one of a small set of abused formats: a script, an archive, a malicious installer, a signed-but-tampered binary. Our File-Format Abuse Atlas catalogues those delivery formats and how to detect them, which is where you can break the chain before the destructive stage ever runs.

Once the operator has access, spreading a wiper across a network uses the same lateral-movement tradecraft as ransomware, which is why segmentation and credential hygiene matter as much for destruction as for extortion. The crews that deploy destructive malware, and the state-aligned groups that favor it, are tracked in our Threat Groups directory, so you can map a wiper campaign to the actor behind it.

How to defend and stay resilient

You cannot assume prevention will hold every time, so the defensive center of gravity shifts from stopping the malware to surviving it. Resilience is the goal.

Keep backups isolated and offline. A backup reachable from the production network can be wiped in the same run. Follow a layered rule: multiple copies, on different media, with at least one copy offline or immutable and out of the network's reach.
Make at least one copy immutable. Write-once or object-lock storage means an attacker with full network access still cannot overwrite the backup within its retention window.
Test restores, treat every backup as unproven until you recover from it. An untested backup is a hope. Rehearse full recovery on a schedule so that when a wiper hits, the restore is a known procedure, not an experiment.
Segment the network. Limiting how far an attacker can move constrains how many systems a wiper can reach in a single deployment.
Harden identity and access. Phishing-resistant authentication, least privilege, and tight control of administrative credentials remove the access a wiper needs to spread widely.
Have a rehearsed incident plan. Know in advance how to isolate systems, who decides, and how recovery is sequenced. In a wiper event, speed and clarity in the first hour shape the whole outcome.

Prove the restore before you need it

The measure of a backup is not whether it exists but whether you have restored from it recently and timed how long a full recovery takes. Run a real restore drill, record the recovery time, and fix whatever breaks. That rehearsal is what turns a wiper from a disaster into an outage.

Wipers strip away the transactional logic that makes ransomware negotiable. There is no key, no deal, and no undo. That makes them frightening, but it also clarifies the defense. You cannot buy your way out, so you build so that destruction on the production side is survivable: isolated immutable backups, a segmented network, and a recovery plan you have actually practiced. Get that right and a wiper becomes a bad day rather than an extinction event.

A worked example: the timed detonation

Walking through how a destructive campaign typically unfolds shows why the visible destruction is the last act rather than the first, and why the defensive opportunities all sit earlier.

An operator gains an initial foothold, often weeks before anyone sees damage. The entry point is unremarkable: a phished credential, an exposed remote service, or a compromised vendor connection. From that foothold the operator moves quietly. They harvest more credentials, map the network, and locate the systems that matter, including domain controllers, file servers, and the backup infrastructure. None of this looks destructive, so it can pass as ordinary administrative traffic if no one is watching for the pattern.

Then the operator prepares the payload for scale. A common approach is to stage the wiper on a central management system and push it to many machines at once, using the same software-distribution channels a legitimate administrator would use. Sometimes the payload is set to trigger at a chosen time so that many systems detonate together, maximising disruption and minimising the window for anyone to react. If backups are reachable from the network, the operator deletes or corrupts them first, so that when the wipe fires there is nothing to restore from.

When it fires, the destruction is fast and often simultaneous across the estate. Files are overwritten, boot records are corrupted, and machines go dark. A ransom note may appear to misdirect the response. From the defender's chair the event feels sudden, but it was the visible end of a chain that had been running quietly for a long time.

The walkthrough carries a clear lesson. By the time the wipe is visible, the decisions that determine the outcome have already been made: whether the intrusion was detected during the quiet phase, whether the network was segmented enough to limit spread, and whether at least one backup lived somewhere the operator could not reach. The destructive stage is loud, and every control that matters acts before it.

How to detect a wiper before it fires

Because the destructive stage is brief and final, useful detection targets the intrusion that precedes it and the preparation just before detonation. The concrete signals cluster in a few areas.

Signals during the quiet intrusion phase:

Credential-harvesting behaviour, such as access to the memory of the local security authority process or to credential stores, followed by reuse of those credentials elsewhere.
Reconnaissance patterns: broad scanning of internal hosts, enumeration of shares, and queries against directory services from an account that does not normally do this.
Lateral movement using administrative protocols to hosts the source account rarely touches.
New or modified scheduled tasks and services on multiple machines, which points to staging for mass execution.

Signals of imminent or active destruction:

Deletion or disabling of backups, shadow copies, and snapshots, a near-universal precursor to destructive and extortion attacks alike.
Stopping of backup, database, and security services across many hosts in a short window.
A single management or distribution system pushing an unknown binary to a large number of endpoints.
A burst of raw disk writes, boot-record modification, or mass file overwrites, which is the wipe itself and the last possible moment to isolate.
Many endpoints going offline together, especially outside a maintenance window.

The backup deletion is the alarm

Across destructive and extortion incidents, one action recurs just before the payoff: the attacker deletes shadow copies, snapshots, and reachable backups so recovery is impossible. Treat any unexpected mass deletion or disabling of backups as a high-severity signal that the destructive stage is close, and wire an alert to it. It is one of the most reliable early warnings you can instrument.

Wiper compared with ransomware and other destructive events

The terms around destructive malware overlap, and the differences change how you respond. Placing them side by side makes the decision points clear.

Event type	Attacker goal	Is recovery by paying possible	Where the defense sits
Ransomware	Extortion payment	Sometimes, a key may exist	Prevention plus tested backups
Wiper	Destruction or disruption	No, there is no key	Resilience: isolated immutable backups
Pseudo-ransomware	Destruction disguised as extortion	No, the note is a decoy	Same as wiper, confirm recoverability early
Ransomware with data theft	Payment plus leverage from stolen data	Partly, but data is already copied	Backups plus assuming the data is exposed
Accidental mass deletion	None, it is an error	Depends on backups	Backups and change control

The table highlights the single most important early question in an incident: does a key exist and is recovery by any means other than backups actually possible. Ransomware and wipers can look identical at first, so confirming recoverability, rather than assuming it, is what keeps a response from being built around a payment that can never restore anything.

Common misconceptions

Several assumptions about wipers lead teams to prepare for the wrong thing.

"A ransom note means we can pay to recover." Not necessarily. A wiper can display a convincing note while holding no key at all. The note is often theatre meant to slow you down. Confirm that decryption is genuinely possible before you treat payment as an option.

"Our backups protect us." Only if they survive the attack. A backup that is online and reachable from the compromised network can be deleted or wiped in the same operation. Survivability comes from isolation and immutability, not from the backup merely existing.

"Wipers are only a problem for governments and critical infrastructure." Destructive malware has hit ordinary organisations as collateral, as opportunistic sabotage, and as cover for other intrusions. Any organisation that an attacker wants to disrupt, or whose forensic evidence an attacker wants to destroy, is a candidate.

"Encryption on our files means it was ransomware." Encryption is a means, not a motive. A wiper can encrypt files with a key it immediately discards, producing the same visible result as ransomware with none of the recoverability. The observable encryption tells you nothing about whether a key exists.

"If we detect the wipe, we can stop it." Once the destructive stage fires, it is fast and often simultaneous across many machines. Detection at that moment limits spread at best. The intrusion phase before it is where detection actually changes the outcome.

How the technique evolved

Destructive malware is not new, and its shape has tracked attacker motives more than technology. Early destructive code was often crude and sometimes accidental, damage from malware that was buggy rather than deliberately ruinous. Over time, destruction became a deliberate instrument. State-aligned operations adopted wipers as a way to degrade an adversary's capacity without seeking payment, and the pseudo-ransomware pattern emerged, where a destructive payload wears an extortion costume to muddy attribution and delay response.

Two developments stand out. First, wipers learned to target the boot process and raw disk structures, so that recovery had to contend with unbootable machines rather than only lost files. Second, destructive operators adopted the same tradecraft as extortion crews: quiet initial access, credential theft, lateral movement, and centralised mass deployment through legitimate management tools. The convergence means the early stages of a destructive campaign look the same as the early stages of a ransomware campaign, which is useful, because the detection and segmentation that catch one catch the other. The constant across every era is that destruction is the final act of an intrusion, and the intrusion is where it can be stopped.

Designing backups that actually survive

Because resilience is the real defense, it pays to be specific about what makes a backup survive a destructive attack, since most backup setups are built for accidental loss rather than a live adversary. An attacker with administrative reach behaves nothing like a failed disk.

The widely used baseline is a layered copy rule: keep several copies of important data, store them on more than one type of media, and hold at least one copy off site. For destructive threats, two extra properties matter more than the count of copies. One copy must be offline or otherwise unreachable from the production network, so that an attacker with full domain access still cannot touch it. And one copy must be immutable within its retention window, using write-once or object-lock storage, so that even an account with delete rights cannot overwrite it before the window expires. A recovery goal of zero uncertainty comes from being able to say, with evidence, that at least one good copy exists beyond the attacker's reach at all times.

Isolation and immutability address the two moves attackers make against backups. Isolation defeats the attacker who tries to reach the backup system over the network and delete it. Immutability defeats the attacker who has valid credentials to the backup platform itself and tries to shorten retention or overwrite the stored data. A setup that has only one of the two can still be defeated by the move it does not cover, which is why serious designs insist on both.

Retention length is its own control. Destructive operators often sit in a network for weeks, so a backup window that only reaches back a few days can mean every retained copy already includes the attacker's staging. Retention long enough to predate the intrusion gives you a clean point to restore from, rather than restoring the compromise along with the data.

Recovery order is part of the plan

Restoring a wiped estate is a sequence, not a single button. Rebuilding identity and directory services usually has to come before application and file servers, and clients come after that, or restored systems reauthenticate into a broken environment. Decide and rehearse the order in advance, including how you validate that a restored system is clean before it rejoins the network, so the recovery does not reintroduce the intrusion it is meant to undo.

The measure of all of this is a timed, recent restore drill. A backup you have never restored is an assumption, and a wiper incident is the worst moment to discover the assumption was wrong. Rehearse a full recovery, record how long it takes, fix what breaks, and you convert destruction from a catastrophe into a scheduled outage.

Frequently asked questions

What is the difference between a wiper and ransomware?

Intent, and whether recovery by paying is possible. Ransomware keeps a way to restore files because the operator wants to be paid. A wiper aims only to destroy, so it keeps no key and offers no real path back, even when it displays a ransom note as a decoy.

Why would an attacker destroy data instead of demanding money?

Because the goal is something other than direct profit: sabotage, disruption during a conflict, punishment of a target, or destroying forensic evidence on the way out of another intrusion. When the payoff is damage rather than money, extortion mechanics do not apply.

Can data destroyed by a wiper be recovered?

Generally not from the affected disk. Overwritten files, corrupted boot structures, and raw sector wipes leave little for on-disk recovery tools. Recovery depends almost entirely on a copy stored somewhere the wiper could not reach, which is why isolated, immutable backups are the core defense.

How do I tell a wiper from ransomware during an incident?

Do not assume from the note. Confirm whether working decryption and a valid key actually exist before building a response around payment. Independent analysis of the sample, and testing whether any files can genuinely be decrypted, is what separates a recoverable event from a destructive one.

Are backups enough to survive a wiper?

Only if they are isolated and immutable. Attackers routinely delete reachable backups and snapshots before detonating, so a backup on the production network can be destroyed with everything else. At least one copy must be offline or write-once and out of the network's reach, and you must have tested restoring from it.

Do wipers spread by themselves?

Not usually as their defining trait. A wiper is typically deployed across a network by an operator who already has access, using the same lateral-movement and mass-distribution methods as ransomware. Some destructive payloads include spreading logic, but the common pattern is a human-operated push from a central system.

What is the first thing to do if a wiper is detonating?

Isolate to limit spread, since the destruction is fast and often simultaneous. Disconnect affected segments, protect and verify your offline backups, and begin the rehearsed recovery procedure. Time spent negotiating with an attacker who has no key to sell is time not spent restoring.