On December 29, 2025, a Sunday between Christmas and New Year’s, a coordinated cyberattack simultaneously struck over 30 wind and photovoltaic farms, a large combined heat and power (CHP) plant serving nearly 500,000 heat recipients, and a private manufacturing facility. The attackers did not demand a ransom. They deployed destructive software — the wipers DynoWiper and LazyWiper — whose sole purpose was to permanently destroy data and damage control systems. The CERT Polska report published in late January 2026, supplemented by analyses from ESET and Dragos, allows us to reconstruct the full anatomy of this incident.
This was not a typical ransomware attack that paralyzes IT systems while waiting for a cryptocurrency transfer. It was an intelligence operation culminating in an act of sabotage — nine months of infiltration converted into a single coordinated act of destruction aimed at the critical infrastructure of a NATO member state. Dragos described this incident as the first major coordinated attack targeting distributed energy resources at scale in history.
What did the attack timeline look like — from infiltration to detonation?
The attack that culminated on December 29, 2025 began at least nine months earlier. According to the CERT Polska report, the first traces of infiltration date back to March 2025. At that time, the attackers gained access to the CHP plant’s IT infrastructure and initiated a reconnaissance phase that lasted until the moment of detonation.
During the March–July 2025 period, the attackers collected sensitive operational information: OT system modernization documentation, SCADA network diagrams, and control device configurations. Simultaneously, they escalated privileges within the Active Directory environment, obtaining accounts with full administrative access. This phase proceeded silently — no destruction, no revealing their presence, with precise mapping of targets.
In the autumn of 2025, the infiltration expanded to additional facilities — wind and photovoltaic farms. Shared VPN credentials across locations meant that compromising a single set of login data opened access to dozens of additional facilities. The attackers automated IP address scanning and leveraged standardized FortiGate device configurations to propagate access.
On the morning of December 29 — a Sunday when staffing levels were minimal — the automated sabotage plan was launched. The attackers connected to domain controllers at individual locations, placed archives containing destructive software, and distributed them via the Group Policy Objects (GPO) mechanism. Simultaneously, in a separate attack vector, they proceeded to directly manipulate OT devices — RTU controllers, serial port servers, and HMI interfaces.
| Date | Event |
|---|---|
| March 2025 | Beginning of CHP plant IT infrastructure infiltration |
| March–July 2025 | Reconnaissance: OT documentation, SCADA diagrams, AD privilege escalation |
| Autumn 2025 | Propagation to renewable energy farms via shared VPN credentials |
| December 29, 2025, morning | Simultaneous wiper detonation across multiple locations |
| December 29–30, 2025 | EDR blocks DynoWiper at the CHP plant; RTU damage at farms |
| January 14, 2026 | Prime Minister Tusk informs government leaders about the attack |
| January 15, 2026 | Official statement from the Polish government |
| January 28–31, 2026 | Publication of technical reports: CERT Polska, ESET, Dragos |
| February 10, 2026 | CISA issues warning to U.S. critical infrastructure |
The choice of date was deliberate. The Sunday holiday break meant minimal staffing, extended response times, and limited system oversight. Exactly the same tactic had been used in the past — the BlackEnergy attack on the Ukrainian power grid in December 2015 also took place just before the holidays.
📚 Read the complete guide: OT/ICS Security: Bezpieczeństwo systemów OT/ICS - różnice z IT, zagrożenia, praktyki
How did the attackers gain access to the infrastructure — entry vectors?
In all three incidents — the CHP plant, renewable energy farms, and manufacturing facility — the entry vector was FortiGate devices configured as VPN concentrators and firewalls, exposed directly to the internet. Three critical weaknesses enabled the attackers to gain full access.
The first and most serious: the absence of multi-factor authentication (MFA). Logging into the VPN required only a username and password — no additional token, authenticator app, or certificate. In an environment where VPN devices serve as the sole gateway to critical infrastructure, the lack of MFA is a fundamental oversight that eliminates one of the most effective defense layers against credential theft.
The second weakness: shared credentials across locations. The same accounts and passwords were used across multiple farms simultaneously — a common practice in the energy industry, where a single integrator manages dozens of distributed facilities. Compromising a single set of credentials provided immediate access to all locations using the same login data. The attackers did not need to conduct separate reconnaissance for each facility.
The third weakness: after gaining access to FortiGate with administrative privileges, the attackers could browse and manipulate all VLANs configured on the device. The lack of granular segmentation meant that administrative access to the firewall equaled access to the entire network infrastructure of the location — both IT and OT.
These three elements — no MFA, shared passwords, full access from FortiGate — combined with automated IP scanning, allowed the attackers to propagate access to over 30 facilities in a relatively short time. Standardized DER (distributed energy resources) device configurations further facilitated automation — each subsequent facility looked identical to the previous one.
Key takeaway: Entry vectors — critical weaknesses
- FortiGate VPN exposed to the internet without MFA — the only authentication was a username and password
- Shared credentials across locations — one stolen set = access to dozens of facilities
- FortiGate administrative privileges = access to all VLANs (IT and OT)
- Standardized DER configurations — automation of attack propagation
- No network segmentation between IT and OT at the facility level
What is DynoWiper and how does the destruction mechanism work?
DynoWiper — detected by ESET as Win32/KillFiles.NMO — is destructive software used primarily in the attack on the CHP plant. Technical analysis published by ESET and Elastic Security Labs reveals a simple but effective data destruction mechanism.
DynoWiper distribution proceeded through Group Policy Objects (GPO) from a compromised Windows domain controller. The attackers placed an archive containing the wiper on the domain controller, then configured the group policy to automatically propagate and execute the destructive code on all machines in the domain. This is an elegant method — it uses a trusted infrastructure management mechanism to deliver the destructive payload without the need for direct interaction with each workstation.
DynoWiper itself is characterized by several significant technical properties. The program has no persistence mechanism — it does not install permanently, does not modify the registry, and does not create scheduled tasks. It does not communicate with external command-and-control (C2) infrastructure. It makes no attempt to hide its activity. It is a single-use tool — it launches, destroys, and terminates.
The data destruction mechanism relies on the Mersenne Twister pseudorandom number generator (MT19937). DynoWiper recursively scans drives marked as DRIVE_FIXED and DRIVE_REMOVABLE, skipping system directories: system32, windows, program files, temp, boot, perflogs, and appdata. For each file found, the program first removes protection attributes, then opens the file for reading and writing. The file header is overwritten with 16 bytes of pseudorandom data generated by the Mersenne Twister. For files exceeding a minimum threshold, the wiper generates up to 4,096 random offsets within the file and overwrites each with a 16-byte sequence of pseudorandom data.
This technique is deliberately chosen. Overwriting the file header destroys format metadata — the operating system and applications are unable to recognize the file type or interpret its contents. The additional overwriting of random fragments makes it impossible to recover even partial content using forensic tools. At the same time, this technique is faster than fully overwriting the entire file — which allows more files to be destroyed in less time. This is a trade-off between destruction thoroughness and propagation speed, typical of operations where simultaneously striking multiple targets is paramount.
At the CHP plant, DynoWiper was detected and blocked by ESET PROTECT (EDR/XDR) software at the moment of attempted execution. This was a critical defensive success — endpoint detection and response proved to be the last line of defense that prevented the full destruction of the IT systems of a CHP plant serving half a million people.
How does LazyWiper differ from DynoWiper?
In the attack on the manufacturing facility, a different destructive tool was used — LazyWiper. While the objective was identical (permanent data destruction), the implementation technique differed significantly.
LazyWiper is based on PowerShell — the native scripting environment of the Windows operating system. This is a “living off the land” (LoTL) approach — instead of delivering a separate executable file, the attackers leveraged a tool already present in every Windows environment. PowerShell scripts are harder to detect by traditional signature-based antivirus solutions because PowerShell itself is a trusted component of the operating system.
Like DynoWiper, LazyWiper was distributed through Group Policy Objects from a compromised domain controller. The operational pattern was therefore identical — privilege escalation in Active Directory, domain controller takeover, distribution of the destructive payload via GPO. The difference lay solely in the payload form: a compiled executable (DynoWiper) versus a PowerShell script (LazyWiper).
The impact on the manufacturing facility was severe — dozens of workstations and servers were permanently damaged at the software level. Recovery required reinstalling operating systems and restoring data from backups. Unlike the CHP plant, where EDR blocked the wiper, at the manufacturing facility the destruction proceeded as the attackers intended.
The use of two different destructive tools within a single coordinated operation is an operational signal. It points to the modularity of the attackers’ toolkit — the ability to adapt the payload to the specifics of the target environment. It may also suggest that individual phases or targets of the operation were handled by different sub-teams within the same group, each with their own tooling preferences.
What OT and ICS systems were attacked — and how?
The attack on industrial control systems (OT/ICS) at wind and photovoltaic farms represents the most concerning element of the December incident. While the destruction of IT systems — workstations and servers — is serious but reversible through backup restoration, damage to OT devices may require physical hardware replacement.
CERT Polska and Dragos identified three groups of ICS devices that fell victim to the attack — each attacked in a different manner, but in all cases exploiting default manufacturer credentials.
Hitachi Energy RTU560 devices (Remote Terminal Units) — controllers used for remote monitoring and control of energy facilities. The attackers gained access through default credentials that had never been changed since installation. After gaining access, they uploaded modified firmware, leading to permanent device damage — some RTUs required physical replacement or reprogramming by the manufacturer’s service team.
Moxa NPort 6xxx serial port servers — devices converting serial communication (RS-232/485) to Ethernet, critical for integrating legacy OT devices with modern IP networks. The attackers exploited an enabled web interface with default login credentials. The attack pattern was particularly destructive: factory reset, password change to a new value (preventing the operator from regaining access), and then setting the device’s IP address to an unreachable one — for example, 127.0.0.1 (loopback). This effectively “bricked” the device — it was not physically destroyed but became unreachable and non-functional without manual hardware-level intervention.
RTU controllers and HMI interfaces from Mikronika — a Polish manufacturer of energy automation equipment. Here too, the entry vector was default credentials. The attackers destroyed data on HMI (Human-Machine Interface) panels — operator screens used for process visualization and control.
The consequences of the attack on the OT layer included loss of view — operators lost the ability to monitor the status of devices at renewable energy farms. Loss of control — remote manipulation of operating parameters became impossible. Physical overwriting of communication server disks. Permanent firmware damage on some RTU devices (bricking). Destruction of data on HMI interfaces.
Key takeaway: Attacked OT/ICS devices
- Hitachi Energy RTU560: access via default passwords → modified firmware upload → permanent damage
- Moxa NPort 6xxx: default passwords → factory reset → IP changed to 127.0.0.1 → device unreachable
- Mikronika RTU/HMI: default passwords → destruction of operator data
- Common denominator: default manufacturer credentials never changed after installation
- Result: loss of view and control between the operator and facilities
Why is the attack on distributed energy resources (DER) a precedent?
In its analysis published in late January 2026, Dragos described the December incident as the “first major coordinated attack targeting distributed energy resources at scale.” This characterization is not rhetorical exaggeration.
Previous attacks on energy infrastructure — BlackEnergy (Ukraine 2015), Industroyer/CrashOverride (Ukraine 2016), Triton/TRISIS (Saudi Arabia 2017) — targeted single, large facilities: power plants, transmission stations, petrochemical plants. The attack on Poland changed the paradigm — the targets were dozens of small, distributed renewable energy generation facilities.
This shift has fundamental implications for energy sector security. Distributed energy resources — wind farms, photovoltaic installations, small hydroelectric plants — represent a growing share of the energy mix. In Poland, installed renewable energy capacity has exceeded 30 GW, and the total capacity of the attacked facilities is estimated at approximately 1.2 GW — representing nearly 5% of the country’s energy capacity.
DER facilities have a specific security profile that makes them particularly vulnerable to attacks. They are physically dispersed — a wind farm in Pomerania and a photovoltaic farm in Lubusz are managed by the same operator but separated by hundreds of kilometers. Management is conducted remotely via VPN — physical service visits are rare and expensive. Configurations are standardized — each subsequent facility is a clone of the previous one, meaning that a vulnerability found in one facility applies to all.
Cybersecurity budgets in the DER sector are disproportionately low relative to the value of the managed assets. A 50 MW wind farm represents an investment on the order of PLN 200–300 million, but its cyber protection is often limited to a firewall at the internet boundary and default passwords in controllers. This disproportion between the value of the protected asset and the level of protection is exactly what the attackers exploited in December.
The precedent also lies in scalability — the techniques used to attack 30 farms can just as easily attack 300 or 3,000 facilities if they share common management infrastructure. As the energy transition progresses and the share of DER in the mix grows, the attack surface expands proportionally — and the December incident showed that attackers have learned to exploit it.
Who is behind the attack — and why is the attribution divergent?
The attribution of the December attack is unusually complex — three independent analytical teams reached convergent but not identical conclusions.
CERT Polska — as the national computer emergency response team and author of the official report — attributed the attack to the Static Tundra activity cluster (Cisco Talos classification). The same group is known by many other names depending on the research firm: Berserk Bear (CrowdStrike), Ghost Blizzard (Microsoft), DYMALLOY (Dragos), Dragonfly (Symantec), Blue Kraken, Crouching Yeti. The U.S. Department of Justice linked this group to Russia’s Federal Security Service (FSB) — specifically Center 16, the unit responsible for cyber operations against critical infrastructure.
ESET — a Slovak security firm that independently conducted analysis of the incident — attributed it with “medium confidence” to the Sandworm group (APT44 / Seashell Blizzard). ESET based its assessment on technical analysis of DynoWiper, pointing to close TTP (tactics, techniques, and procedures) links with the earlier ZOV wiper, used by Sandworm in Ukraine. Sandworm is linked to the GRU — Russian military intelligence, specifically Unit 74455.
Dragos — specializing in OT security — attributed the attack with “medium confidence” to the ELECTRUM group, which exhibits technical and operational overlap with Sandworm. However, Dragos noted that ELECTRUM and Sandworm are not fully interchangeable — not all Sandworm activity can be attributed to ELECTRUM and vice versa.
The divergence is significant: CERT Polska points to the FSB (Center 16), while ESET and Dragos point to the GRU (Sandworm/ELECTRUM). These are two different intelligence services of the Russian Federation — the FSB is responsible for counterintelligence and internal security, the GRU for military intelligence. Both have documented histories of cyber operations against critical infrastructure, but their operational structures, toolsets, and strategic objectives differ. The divergence in attribution does not mean that any of the teams is wrong — it may indicate cooperation between units, shared tools, or simply limitations of analytical methods.
Regardless of whether the FSB or GRU is behind the attack, one thing is indisputable: the December incident is a state-sponsored operation carried out by Russian intelligence services. Prime Minister Donald Tusk, when informing about the attack in mid-January 2026, stated that the collected data points to the involvement of groups linked to Russian security services.
What is the significance of the attack falling on the tenth anniversary of BlackEnergy?
December 2025 marks exactly ten years since the first cyberattack in history to cause a blackout — the BlackEnergy attack on the Ukrainian power grid on December 23, 2015. This temporal coincidence may not be accidental and has deep implications for threat assessment.
BlackEnergy/Sandworm in 2015 cut power to 230,000 customers in the Ivano-Frankivsk region for several hours — the first time a cyberattack caused a physical interruption of energy supply. In 2016, the same actor, using the Industroyer/CrashOverride malware, attacked the Ukrainian power grid again, this time with a more advanced tool capable of directly manipulating industrial protocols (IEC 101, IEC 104, OPC DA).
Since 2022 — the full-scale invasion of Ukraine — Sandworm has radically escalated the use of destructive software. ESET documented over 19 different wiper families used by this group: from HermeticWiper and CaddyWiper (February–March 2022), through SwiftSlicer and NikoWiper (2023), ZEROLOT and Sting (2024–2025), to DynoWiper (December 2025). All of these attacks were aimed at Ukraine.
The DynoWiper used in Poland broke through this boundary — it is the first confirmed instance where Sandworm (or a related group) used destructive malware against the critical infrastructure of a NATO country. ESET identified a technical link between DynoWiper and the earlier ZOV wiper (used in Ukraine), suggesting an evolution of the toolkit rather than the creation of an entirely new arsenal.
For security professionals, this context is crucial. Sandworm/Static Tundra is not a group that carries out single attacks and disappears. It is an actor with a decade-long history of operations against the energy sector, systematically developing its capabilities and gradually expanding the geography of its attacks. The transition from Ukraine to Poland — a NATO country and key Ukrainian ally — is a logical next step in this escalation.
How did endpoint defense prevent catastrophe at the CHP plant?
One of the most significant technical takeaways from the December incident concerns the effectiveness of endpoint defense. At the CHP plant — the most critical target of the attack — DynoWiper was detected and blocked by ESET PROTECT, an EDR/XDR (Endpoint Detection and Response / Extended Detection and Response) class solution.
The detection mechanism triggered at the moment of attempted wiper execution — before the program could begin data destruction. This is a critical difference because DynoWiper is designed to operate quickly and irreversibly. Once file overwriting begins, there is nothing left to “block” — the data is destroyed. The effectiveness of EDR in this case resulted from detection at the execution stage, not at the delivery or installation stage.
At the renewable energy farms, endpoint defense was insufficient or absent — the destruction of IT systems proceeded according to the attackers’ plan. This asymmetry in protection levels between the CHP plant and the farms is symptomatic of the entire sector. Large energy facilities — power plants, CHP plants — typically have more robust defenses, dedicated security teams, and budgets for advanced protection tools. Distributed DER facilities — wind farms, PV installations — are treated as “less critical” and proportionally less well protected.
The December incident provides hard evidence that EDR/XDR constitutes one of the most effective defense layers against destructive attacks. Where it was deployed and properly configured — it worked. Where it was absent — the attack succeeded. This is not a subtle correlation — it is a direct cause-and-effect relationship confirmed under conditions of a real state-sponsored attack.
It is worth emphasizing that EDR does not replace other defense layers — MFA, segmentation, credential management. Had these layers been properly implemented, the attackers would likely never have reached the stage where EDR needed to intervene. Defense in depth is not an abstract postulate — the December attack showed exactly what happens when individual layers fail, and what happens when one of them holds.
What technical conclusions emerge from the official reports by CERT Polska, ESET, and Dragos?
Three independent reports published in January and February 2026 provide complementary perspectives on the December incident — each with different technical depth and analytical focus.
The CERT Polska report (published on cert.pl in both Polish and English versions) is the most comprehensive source on the course of the operation. It contains the full timeline — from March 2025 to the December 29 detonation. It documents entry vectors (FortiGate VPN), propagation mechanisms (GPO), destruction tools (DynoWiper, LazyWiper), and the attack on the OT layer (Hitachi, Moxa, Mikronika). CERT Polska is the only source that discloses details about LazyWiper and the attack on the manufacturing facility. Attribution: Static Tundra / FSB Center 16.
The ESET report (WeLiveSecurity) focuses on the technical analysis of DynoWiper. ESET provided the detection name (Win32/KillFiles.NMO), detailed analysis of the destruction mechanism (Mersenne Twister PRNG, header and random offset overwriting), the link to the earlier ZOV wiper, and attribution to Sandworm. Key information from the ESET report: it was their EDR software (ESET PROTECT) that blocked DynoWiper at the CHP plant. Attribution: Sandworm / GRU with medium confidence.
The Dragos report provides the OT/ICS perspective. Dragos is the only one to analyze the attack on distributed energy resources in detail from an industrial systems security perspective. It introduces the concept of DER (distributed energy resources) as a new target category and identifies the precedent-setting nature of the incident. Dragos uses its own nomenclature — the ELECTRUM group — and notes that it is not fully interchangeable with Sandworm. Attribution: ELECTRUM with medium confidence.
CISA (U.S. Cybersecurity and Infrastructure Security Agency) on February 10, 2026 issued an alert titled “Poland Energy Sector Cyber Incident Highlights OT and ICS Security Gaps” — directed at U.S. critical infrastructure operators. The CISA alert specifically identifies three gaps: default ICS credentials, lack of MFA on VPN, and lack of IT/OT segmentation. This signals that the December attack on Poland is being treated by the United States as a globally significant threat — if these techniques worked in Poland, they can work in any country with similar infrastructure weaknesses.
What does the technical defense maturity map look like for DynoWiper-type attacks?
The table below synthesizes the technical conclusions from the December incident into an organizational resilience assessment model for destructive attacks. It is based on the specific vectors and techniques used on December 29, 2025.
| Defense layer | Insufficient | Baseline | Hardened | Advanced |
|---|---|---|---|---|
| VPN authentication | Static password, no MFA | Token-based MFA (TOTP) | MFA with client certificate + geofencing | ZTNA (Zero Trust Network Access), contextual access, no persistent VPN |
| AD/GPO management | No GPO change monitoring, shared admin accounts | Alerts on GPO changes, admin accounts with password rotation | Tiered AD model, PAW (Privileged Access Workstation), GPO monitoring in SIEM | Full AD tier model, JIT access, GPO logs in SOC with behavioral correlation |
| Endpoint protection (IT) | Signature-based antivirus or none | AV + basic behavioral detection | EDR with automatic isolation, SIEM integration | XDR with IT/OT correlation, threat hunting, automated playbooks |
| OT/ICS protection | Default passwords, no monitoring, flat network | Passwords changed, basic IT/OT firewall | Dedicated OT monitoring (e.g., Dragos, Claroty, Nozomi), zone segmentation | OT microsegmentation, OT SOC, anomaly detection on industrial protocols |
| Backup and recovery | Online backup, no testing, no wiper plan | 3-2-1, testing once/year, BCP plan for ransomware | 3-2-1-1 with immutable storage, quarterly testing, BCP plan for wiper | Air-gapped backup, RTO/RPO testing for full destruction scenario, war games |
| Forensic readiness | No log retention, no procedures | 30-day logs, basic IR procedures | 90+ day logs, forensic firm retainer, tabletop exercises | Full DFIR pipeline, EDR with historical telemetry, threat intelligence integration |
The December attack showed that the “insufficient” column represents the state in which most of the attacked facilities found themselves. EDR in the “hardened” column saved the CHP plant. The goal should be to reach at least the “hardened” level in all layers — not as an aspiration but as an operational requirement for any organization managing energy infrastructure.
Frequently asked questions
Is DynoWiper linked to earlier Sandworm wipers?
Yes. ESET identified close technical links (TTP — tactics, techniques, and procedures) between DynoWiper and the ZOV wiper previously used by Sandworm in Ukraine. Both tools share a similar architecture: no persistence, no C2, distribution via GPO, single-use destruction execution. However, DynoWiper uses the Mersenne Twister PRNG to generate overwriting data, a technique not present in ZOV.
Why did the attackers use two different wipers — DynoWiper and LazyWiper?
The use of two tools points to the modularity of the attackers’ toolkit. DynoWiper (a compiled executable) was used at the CHP plant, while LazyWiper (a PowerShell script) was used at the manufacturing facility. The difference in payload form may result from adaptation to the specifics of the target environment or from the fact that individual targets were handled by different operational sub-teams.
Can the attacked OT devices (RTU, HMI) be repaired, or do they require replacement?
It depends on the degree of damage. Moxa NPort devices whose IP addresses were changed to unreachable values can be restored through manual hardware-level reconfiguration (reset via console port). Hitachi RTU560 devices whose firmware was overwritten may require reprogramming by the manufacturer’s service team or physical replacement. CERT Polska classified some devices as “permanently damaged” (bricked).
What energy capacity did the attacked facilities represent?
The total installed capacity of the attacked wind and photovoltaic farms is estimated at approximately 1.2 GW, representing nearly 5% of Poland’s energy capacity. This is a value comparable to the capacity of a large conventional power plant.
Did CISA issue a warning after the Polish attack?
Yes. On February 10, 2026, CISA published an alert titled “Poland Energy Sector Cyber Incident Highlights OT and ICS Security Gaps,” directed at U.S. critical infrastructure operators. The alert identified three critical gaps: default ICS credentials, lack of MFA on VPN, and lack of IT/OT segmentation.
What signatures and IOCs (Indicators of Compromise) were published?
ESET published the detection name: Win32/KillFiles.NMO (DynoWiper). Elastic Security Labs published a detailed technical analysis with file hashes and YARA detection rules. CERT Polska released a complete set of IOCs in the technical report available on cert.pl. Recommendation for SOC teams: update rule databases with the published IOCs and implement GPO change monitoring as an additional early warning signal.
Why was Sunday, December 29 specifically chosen?
The attack timing is deliberate and stems from three factors: minimal staffing during the holiday period (extended response times), peak heating season (maximizing potential impact of heat supply disruption), and historical precedent — APT groups attacking energy infrastructure have repeatedly chosen the holiday period, including the BlackEnergy attack on Ukraine (December 23, 2015).
