- Why Are Wipers the Weapon of Choice in OT Attacks?
- The Four-Phase Playbook Used by Wiper Malware
- What Do Real-World Wiper Attacks in OT Environments Look Like?
- Why Does Every Wiper Attack Start with a File Crossing a Trust Boundary?
- The Latest Wiper Attack on Venezuela’s Energy Sector
- Wiper Samples and Indicators Referenced in This Analysis
- Stop Wiper Attacks Before They Execute
In our previous blog, we analyzed major ICS and OT cyberattacks from 2024 through early 2026. One pattern stood out: wipers have become the weapon of choice for state-sponsored actors targeting operational technology environments. Six separate wiper campaigns impacted industrial sectors in 2024–2025, including power grids, water systems, healthcare, and manufacturing around the world.
This article examines that trend in detail. It explains why wipers are effective in OT environments, reviews three real-world incidents, and identifies the consistent attack pattern behind them. While writing this post, another example emerged. A newly reported threat, Lotus Wiper, targeted Venezuela’s energy sector. That case is included in the final section.
Why Are Wipers the Weapon of Choice in OT Attacks?
Wipers are designed to destroy data, which makes them fundamentally different from ransomware. Because they do not enable extortion, they are not a useful tool for threat actors driven purely by financial gain. Instead, they are highly effective for actors whose objective is to cause disruption or damage, particularly when aiming to translate cyber operations into real-world impact while maintaining a high degree of anonymity. For this reason, wipers are commonly associated with state-sponsored activity.
In traditional IT environments, wipers primarily destroy files. While this can be highly disruptive, the impact is often recoverable if reliable backups are in place. However, the situation is different in OT and ICS environments. Systems such as SCADA servers, engineering workstations, and HMI displays do not merely store data. They actively control and monitor physical processes. When the data on these systems is destroyed, operators lose visibility and control over operations, effectively becoming blind to what is happening on the ground.
This is where wipers become particularly dangerous. They can bridge the gap between cyberattacks and physical consequences. Because of this capability, state-sponsored actors frequently leverage wipers. Their use is often observed in regions experiencing armed conflict or heightened geopolitical tensions, where disruption is the primary objective.
The Four-Phase Playbook Used by Wiper Malware
Every wiper analyzed, regardless of language, platform, or sophistication, follows the same basic pattern. Understanding these phases is a practical starting point for defending against wiper attacks.
Phase 1: Initialization
The wiper prepares its corruption payload, typically generating pseudo-random data using a common random number generator. Random data makes forensic recovery more difficult than overwriting with zeroes.

Phase 2: Discovery
The wiper maps everything it can destroy by enumerating drives, volumes, directories, and files.

Phase 3: Destruction
The wiper opens each file, removes protection attributes, and overwrites it with random data. Some also delete files afterward. Others target the Master Boot Record (MBR) or Master File Table (MFT), making the entire disk unreadable.

Phase 4: Anti-Recovery
A forced reboot locks in the damage. The wiper escalates privileges, acquires shutdown rights, and restarts the system. When, and if, it comes back up, there is nothing left to restore.

The following section applies this playbook to real-world incidents.
What Do Real-World Wiper Attacks in OT Environments Look Like?
DynoWiper — Poland’s Power Grid
Actor: Sandworm/ELECTRUM (GRU)
Target: Poland, energy sector (distributed energy resources)
Delivery: Windows executable (PE binary) delivered through a compromised network
In December 2025, Sandworm, the GRU’s most capable ICS-focused unit, targeted Poland’s electric infrastructure with DynoWiper. According to Dragos, this was the first coordinated cyberattack targeting distributed energy resources (DER) at scale.
Approximately 30 sites were affected, including combined heat and power plants, wind farms, and solar dispatch systems. Unlike previous attacks that focused on centralized power stations, this operation targeted smaller, distributed facilities that are expanding rapidly in modern energy markets. These environments are also typically less defended.
The attack could have affected up to 500,000 residents. Poland’s Prime Minister stated that the transmission grid was not at risk, but the attackers reached OT systems and permanently disabled some equipment. DynoWiper followed the four-phase playbook precisely: pseudo-random payload generation, drive enumeration, file overwriting, and forced reboot. It executed as a compiled binary designed for systematic destruction.
PathWiper — Ukraine’s Critical Infrastructure
Actor: Russia-nexus (unspecified unit)
Target: Ukraine, critical infrastructure (multiple sectors)
Delivery: VBScript dropper paired with an executable
PathWiper was deployed against Ukrainian critical infrastructure by a Russia-nexus actor as part of an ongoing wartime cyber campaign. While DynoWiper targeted a specific sector, PathWiper targeted critical infrastructure more broadly, affecting multiple essential services during active conflict.
What sets it apart is the thoroughness of destruction. PathWiper does not just overwrite files. It destroys local storage at the volume level. In an active war, wiping the systems that manage essential services has consequences that extend beyond data loss.
The same four phases apply, but PathWiper pushes the destruction phase further than most. By targeting volume-level storage rather than individual files, it ensures that even partial forensic recovery is effectively impossible. The intent is total erasure, not just of data, but of the system’s ability to function.
LazyWiper — Poland’s Manufacturing Sector
Actor: Sandworm/ELECTRUM (GRU)
Target: Poland, manufacturing
Delivery: PowerShell script pushed via Group Policy Objects (GPO)
LazyWiper was not a separate campaign. It struck on the same day as DynoWiper, December 29, 2025, as part of the same coordinated operation. However, it targeted a manufacturing company, and CERT Polska assessed it as opportunistic. The attackers identified an exposed entry point and used it.
That entry point was a Fortinet device whose configuration had been stolen and published on a criminal forum. The attackers used the leaked credentials to establish persistent access, moved laterally to domain administrator privileges, and pushed LazyWiper to every machine via GPO. Unlike DynoWiper’s compiled binary, LazyWiper is a PowerShell script. It disables Defender, uses built-in Windows management tools to map all drives, renames files to random four-character names, and overwrites them with pseudo-random data.
One detail makes this case especially notable. CERT Polska assessed that parts of the file-overwriting code were likely generated by a large language model, indicating AI-assisted malware development in the wild. If defenders assume wipers will always appear as traditional compiled malware, LazyWiper highlights the need to account for script-based and dynamically generated threats.
Why Does Every Wiper Attack Start with a File Crossing a Trust Boundary?
Every incident in this blog, and every incident in the previous threat landscape report, shares one constant: a file crossed a trust boundary. Different formats and delivery methods, but the same pattern.
- DynoWiper: Windows executable delivered through a compromised network
- PathWiper: VBScript dropper paired with an executable
- LazyWiper: PowerShell script pushed via GPO
OPSWAT’s Adaptive Sandbox inspects every file at each trust boundary before it reaches the engineering workstation, before it interacts with the SCADA system, and before it crosses from IT into OT. It does not rely on observing destructive behavior. Instead, it identifies malicious capabilities in a controlled environment before the file is trusted.
If you operate in energy, water, manufacturing, healthcare, or government, then wipers are part of your threat model, whether explicitly accounted for or not.
Wipers will evolve with new languages, delivery methods, and targets, but the pattern remains consistent. A file must arrive, reach a system, and execute. This has remained true from Stuxnet in 2010 to DynoWiper in 2025. Inspecting the file before it crosses the boundary is a control that applies across wipers, actors, and sectors.
The Latest Wiper Attack on Venezuela’s Energy Sector
As this article was being finalized, on April 21, Kaspersky GReAT reported a previously unknown wiper, Lotus Wiper, targeting Venezuela’s energy and utilities sector.
The attack is methodical. Two batch scripts isolate the machine first by disabling services, terminating network interfaces, and logging off sessions. They then wipe disk volumes, overwrite folders, and fill remaining storage space. Only after these steps does the final payload execute.
The wiper is disguised as a legitimate enterprise software component, delivered in encrypted form and decrypted at runtime. Once active, the system becomes unbootable, with no recoverable data. There is no ransom demand and no indication of data exfiltration for financial gain. Like the other wipers discussed in this article, Lotus Wiper is designed for destruction.
The same pattern appears again in real time. A file crosses a trust boundary, executes, and destroys everything it can reach. File-level inspection before the payload decrypts represents the earliest opportunity for interception.

Wiper Samples and Indicators Referenced in This Analysis
Wiper | Type | Target | Actor | Hash / Indicator |
DynoWiper | Windows PE | Poland, Energy | Sandworm/ELECTRUM (GRU) | 835b0d87ed2d49899ab6f9479cddb8b4e03f5aeb2365c50a51f9088dcede68d5 |
PathWiper | Windows PE | Ukraine, Critical Infrastructure | Russia-nexus | 7c792a2b005b240d30a6e22ef98b991744856f9ab55c74df220f32fe0d00b6b3 |
LazyWiper | PowerShell | Poland, Manufacturing | Sandworm/ELECTRUM (GRU) | 033cb31c081ff4292f82e528f5cb78a503816462daba8cc18a6c4531009602c2 |
Lotus Wiper | Windows PE | Venezuela, Energy & Utilities | Unknown (geopolitically motivated) | 111ea3f5c4a4239a3f5f08de5f243e9d01da9d021fc393e277c1e6cadc27d327 |
Stop Wiper Attacks Before They Execute
Wiper attacks follow a consistent pattern across environments, sectors, and threat actors. Regardless of how they are delivered or what language they use, they depend on the same sequence: a file crosses a trust boundary, executes, and destroys system data.
This consistency creates a clear defensive opportunity. Identifying and analyzing files before they are trusted remains one of the most effective ways to stop wipers before they can cause damage.
MetaDefender Aether applies a layered approach to this problem. It combines real-time reputation analysis, advanced sandboxing, and behavioral correlation to detect unknown and evasive threats before execution. Its emulation-based analysis exposes hidden payloads, unpacks multi-stage malware, and identifies indicators of compromise without relying on signatures.
For organizations operating critical infrastructure, this approach enables earlier detection at the point where attacks begin, before disruption reaches OT systems. To understand how this applies to your environment, contact an OPSWAT expert to discuss MetaDefender Aether.
