The Most Dangerous Part of the Attack Happened Months Before Anyone Noticed

On 29 December 2025, with Poland already in the grip of snowstorms and sub-zero temperatures just before the New Year, a coordinated cyberattack hit more than 30 wind and solar farms and a combined heat and power plant supplying heating to nearly half a million people. Prime Minister Donald Tusk described it afterwards as an act of Russian sabotage with one clear objective: to cause a blackout in the middle of winter. 

By the time the attack began, the group behind it had been quietly inside the CHP plant for months. 

That detail, documented in the technical analysis published by CERT Polska in January 2026, is the part of this story that deserves the most attention. The destructive phase on 29 December was not an opportunistic smash-and-grab. It was the culmination of a sustained, patient infiltration during which the attackers harvested operational data, escalated privileges, and thoroughly mapped the plant’s systems to know exactly where to strike. When they finally triggered the wiper malware, the software was built not to extort but to permanently obliterate data, corrupt firmware, and brick industrial devices; it was blocked by endpoint detection software at the last moment. At the renewable energy substations across Poland, there was no such last-minute defence. RTU controllers, protection relays and HMI computers were taken offline one by one; firmware was corrupted, system files deleted, and operators across the country lost remote visibility and control of facilities they had managed without interruption for years. Electricity kept generating, but the ability to monitor, adjust or respond from outside the fence was gone. 

CERT Polska attributed the attacks to the clusters Static Tundra, Berserk Bear, and Ghost Blizzard, which it assessed as linked to Russia’s FSB. Dragos and ESET, in separate analyses, attributed the activity with moderate confidence to Sandworm, the GRU-linked group responsible for attacks on Ukrainian power infrastructure since 2015. The exact attribution matters less than the technical reality it points to: a sophisticated, well-resourced actor with demonstrated knowledge of industrial control systems, months of undisturbed access to critical infrastructure, and the capability to cause physical consequences at scale. 

CISA issued a global alert in February 2026, amplifying the CERT Polska report. The entry point at every affected site was consistent: internet-facing FortiGate VPN devices configured without multi-factor authentication and credentials reused across more than 30 locations. The attackers did not need to do anything particularly clever once they were in. The architecture in place, common across many distributed OT environments, created an opening that could be exploited with little sophistication. 

The Access Problem That Keeps Appearing 

IBM’s X-Force Threat Intelligence Index 2026 records manufacturing as the most attacked industry globally for the fifth consecutive year, accounting for 27.7% of all cyberattacks. The average cost of a breach in the industrial sector rose 18% year-on-year in 2024 to reach $5.56 million, per IBM’s Cost of a Data Breach Report 2024. The average time to identify a breach in an OT environment is 199 days. In Poland, the attackers were present for considerably longer than that before they were detected. 

Across OT incidents, the pattern in how attackers gain and maintain access is consistent. They enter through remote connectivity infrastructure, typically via vendor- or third-party-access pathways established for legitimate operational reasons but lacking the controls needed to make them auditable or containable. They move laterally over weeks or months, working through privilege escalation and credential reuse. In environments where IT and OT networks are not properly segmented, that movement eventually reaches operational technology. The damage, when it comes, is a function not only of the attacker’s sophistication but also of the degree of freedom of movement the environment unwittingly granted them. 

Addressing this does not require the kind of lengthy, disruptive security overhaul that OT operators rightly worry about. None of it is straightforward to implement in environments where uptime is non-negotiable, assets are decades old, and security teams are often working with limited resources. The controls that would have changed the outcome in Poland are specific and well understood. Every privileged remote session into an OT environment should require explicit approval from the OT team before it opens, and every action within that session should be logged to a tamper-proof record. Credential reuse across sites is common in distributed OT environments partly because systematic rotation at scale, without disrupting continuous operations, is genuinely difficult, but it is also the single most exploitable condition for lateral reach, and vaulting credentials centrally is the most direct way to close that exposure. The IT/OT boundary should be enforced at the network level rather than assumed, so that a compromised enterprise account cannot traverse into operational infrastructure without crossing a monitored checkpoint. And when something goes wrong, the organisation needs the ability to terminate all external access simultaneously, suspend individual accounts, and keep internal production running. At the same time, the threat is isolated, not facing a choice between containment and continuity. 

None of this is theoretical. The Polish CHP plant had endpoint protection that stopped the wiper at the final moment. If the organisation had also had visibility into months of lateral movement through its privileged accounts, the attack would not have reached that point. The access management architecture that underpins that kind of visibility is the same architecture that NIS2 now requires across essential entities in Europe: documented access controls, multi-factor authentication, supply chain governance and tested incident handling processes, with management bodies personally accountable for failures and fines reaching up to €10 million or 2% of global annual turnover. 

Building Resilience Before You Need It 

There is a tendency in OT security to treat resilience as something to consider only after prevention has failed. The Poland incident makes a strong case against that framing. The attackers were inside long before the destructive phase. Prevention, in the sense of keeping them out entirely, had already failed by the time anyone knew there was a problem. What determined the outcome was whether the organisation had the controls in place to detect lateral movement, limit the damage, and recover quickly; on that front, the picture was mixed. The wiper was caught; the renewable substations were not. 

Organisations that take the Poland case seriously will be asking two questions. First, do they have genuine visibility into who holds privileged access to their OT environment, what those accounts can reach, and whether any of that access is currently anomalous? Second, if something were already in the network today, what controls exist to detect it, contain it and respond without taking down the systems the business depends on? 

The attacker in Poland operated undetected for months. The practical question that follows is not whether something similar could happen elsewhere. It is whether the controls exist to make it matter less when it does.