DynoWiper and Sandworm: Wiper Malware Against Decentralised Energy Plants
On 29 December 2025 the Russia-aligned Sandworm group attacked a Polish energy company with a previously unknown wiper that ESET calls DynoWiper. The attack was meant to destroy data, not steal it. It failed. This article explains what DynoWiper does technically, why decentralised energy plants are an exposed attack surface and what you as an energy utility should do now.
DynoWiper is a destructive wiper malware that the Russia-aligned Sandworm group used against a Polish energy company in late December 2025. ESET detects it as Win32/KillFiles.NMO and attributes it to Sandworm with medium confidence. On 29 December 2025 the attackers deployed three samples to a shared directory in the victim's domain. The malware overwrites files with a 16-byte random buffer, works on removable and fixed drives and forces a reboot. According to reports, two combined heat and power plants and a renewable energy management system were affected, with around 500,000 customers potentially threatened. The attack failed because an EDR/XDR product blocked execution. For European utilities this is a test run for their own duties under NIS2, national critical infrastructure law and sector security catalogues. The priorities are clear: comprehensive EDR/XDR, strict separation of IT and OT, immutable offline backups and a reporting process within 24 hours. Wipers target availability, not confidentiality, so classic data protection alone is not enough.
What happened: the failed attack on Poland
In late December 2025 Sandworm attacked a Polish energy company with a new wiper malware. The goal was destruction, not theft and not ransom. The attack failed because an EDR/XDR product blocked execution. That is the core of the story, and it is unusually well documented.
The date is no coincidence. The 29th of December 2025 fell almost on the tenth anniversary of the 2015 Sandworm attack on Ukraine's power grid, which left around 230,000 people without electricity for four to six hours. Ten years later the same group is targeting an EU country.
According to reports, the attackers hit two combined heat and power plants and a renewable energy management system that bundles wind and solar assets. Around 500,000 customers were potentially affected. Poland's Prime Minister Donald Tusk said the attacks had been prepared by groups directly linked to Russian services.
What DynoWiper does technically
DynoWiper is a pure destroyer. The malware overwrites files and forces a reboot to render systems inoperable. ESET detects it as Win32/KillFiles.NMO. No encryption, no ransom note, no recovery for payment.
How does it overwrite? With a 16-byte random buffer. Files up to 16 bytes are fully overwritten, larger files partially. That is enough to ruin them. The malware works its way across removable and fixed drives and then forces a reboot. What is notable is where it stayed: in the IT network. ESET observed no targeted manipulation of the operational technology, meaning the control and automation systems.
ESET makes the attribution to Sandworm with medium confidence, not certainty. It rests on overlaps in code and tradecraft with the ZOV wiper, which the group deployed against a Ukrainian bank in November 2025. Attribution in the cyber domain stays a matter of probability, not a fingerprint.
Who is behind Sandworm
Sandworm is considered a unit of Russia's military intelligence service GRU. The group carries several names, depending on the analysis house: APT44, Seashell Blizzard, UAC-0113. For a decade it has stood for sabotage against critical infrastructure.
- 2015 and 2016: attacks on Ukraine's power grid with BlackEnergy and Industroyer, the first time malware demonstrably caused a power outage.
- 2025: more than ten incidents with destructive malware, almost all in Ukraine, including the wipers ZEROLOT, Sting and ZOV.
- The stated pattern, per ESET: weaken the adversary's economy rather than steal data. Energy, logistics and the grain sector were in focus.
The jump from Ukraine to Poland is the genuinely new part. It shifts the threat out of the immediate war zone into an EU and NATO member state. Anyone operating energy plants in Europe should take that shift seriously. The attackers and their tools are the same ones that have run against Ukraine for years. This is no longer an abstract danger.
Why decentralised energy plants are exposed
The energy transition spreads generation across thousands of smaller plants. Solar parks, wind farms, battery storage, virtual power plants. That is good for the climate and bad for the attack surface. Because many of these operators have no professional IT security.
Virtual power plants bundle many decentralised assets into one controllable unit and count as digital energy services. A single compromised management system can therefore reach many downstream plants. That is precisely where the DynoWiper attack aimed, at a management system, not at a generating block.
Remote maintenance, cloud connectivity and shared directories are the price of digitalisation. They create paths for lateral movement, the shift from one hijacked system to the next. How quickly automation turns into an attack chain is also clear from the growing attack surface of agentic AI. And how much the supply chain itself becomes a risk is shown by the debate around Chinese PV inverters as a security risk.
The European perspective: NIS2 and the security catalogues
For European energy utilities the Polish case is a test run for their own duties. The legal framework is there, it just has to take effect. NIS2 and national critical infrastructure law tighten the requirements across Europe, and in the energy sector the IT security catalogue and the Network Code on Cybersecurity implement them.
What does the framework demand in concrete terms? Operators must run systematic risk management and deploy intrusion detection systems. Security incidents usually have to be reported within 24 hours. National cyber agencies address the risks of renewable and decentralised plants explicitly in their energy-sector guidance. Anyone who takes the duties from NIS2 and the critical infrastructure umbrella law and the IT security catalogue under Section 5c EnWG seriously already has most of what stopped DynoWiper on the list. For grid operators the requirements of the Network Code on Cybersecurity come on top.
The difference between Poland and a possible case in Germany does not lie in the law. It lies in the implementation. A catalogue on paper stops no wiper. A deployed EDR/XDR product does.
Challenges and risks
The DynoWiper case is a warning, not a reason for alarmism. It failed at standard protection, not by luck. Still, the honest look at the downside is worth it.
One point is easy to miss. DynoWiper stayed in the IT network this time. That was luck within limits, not a law of nature. If IT and OT are not cleanly separated, the path from an office machine to the control of a plant is shorter than many would like. That is where the next section starts.
What energy utilities should do now
The failed attack delivers a clear list of priorities. It follows the four phases a wiper moves through, and the control that stops each phase. No new framework, just consistent execution of the known.
-
Separate IT and OT strictly
Split the networks for office IT and operational technology, with controlled crossings instead of open connections. DynoWiper stayed harmless only because it did not reach the control systems. Segmentation turns that coincidence into a rule.
-
Harden shares, limit rights
The attackers used a shared directory in the domain to distribute the samples. Least privilege means every account and service gets only the rights it actually needs. Open write shares for everyone are a distribution path, not a convenience.
-
Roll out EDR/XDR comprehensively
This is exactly the technology that stopped DynoWiper. Endpoint detection and response spots suspicious behaviour and blocks execution before the malware takes effect. Coverage is what counts: a gap in the rollout is the door the wiper looks for.
-
Keep immutable offline backups
Against a wiper the backup is the last line of defence. But it only helps if it is offline or immutable, otherwise the malware overwrites the backup too. That includes regular restore tests, not just creating the copy.
The four measures have long been in NIS2 and the IT security catalogue. The Polish case only shows that they really work when it counts. Decentralised plants and service providers belong in the plan too, not just your own data centre.
Further reading
Frequently asked questions
DynoWiper is a destructive wiper malware that ESET discovered in late December 2025 after an attack on a Polish energy company. ESET detects it as Win32/KillFiles.NMO. The malware overwrites files with a 16-byte random buffer, works on removable and fixed drives and forces a reboot to render systems inoperable. It does not steal data, it destroys it.
Sandworm is considered a unit of Russia's military intelligence service GRU and carries other names such as APT44, Seashell Blizzard and UAC-0113. The group has been known for a decade for sabotage against critical infrastructure, including the attacks on Ukraine's power grid in 2015 and 2016. ESET attributes DynoWiper to Sandworm with medium confidence.
No. On 29 December 2025 three DynoWiper samples were deployed to a shared directory in the victim's domain. An installed EDR/XDR product blocked execution, so no disruption occurred. According to reports, two combined heat and power plants and a renewable energy management system were affected, with around 500,000 customers potentially threatened.
Wiper malware is software that irreversibly deletes or overwrites data rather than stealing or encrypting it. Unlike ransomware it demands no ransom and offers no recovery. Its goal is availability: systems should fail. That is why the main defences against wipers are immutable offline backups and fast threat detection.
The case shows that destructive malware is no longer only a Ukrainian wartime scenario but hits the decentralised energy supply of an EU neighbour. European utilities are covered by NIS2, national critical infrastructure law and sector security catalogues. In practice that means comprehensive EDR/XDR, strict separation of IT and OT, immutable backups and a 24-hour reporting process.