Key takeaways
- 30+ facilities were breached the same way: internet-facing FortiGate VPN portals with no MFA, using accounts stored locally on the device rather than a central identity provider.
- Credential reuse across sites turned one compromised account into a fleet-wide problem; a leaked FortiGate config at one target was functionally a leaked password list.
- A destructive function inside one wiper shows signs of LLM generation — and got the logic backwards, making the wiper slower than a naive full overwrite.
- Canary-file detection stopped the wiper twice at the CHP plant, without needing a signature for the malware family, forcing the attacker to burn around 50 minutes recompiling and retrying.
On the morning of 29 December 2025, coordinated attacks hit at least 30 wind and solar farms across Poland, alongside a combined heat and power plant supplying heat to nearly half a million people. Temperatures were dropping, snowstorms were moving across the country, and New Year’s Eve was days away. The timing of it all certainly was not a mistake. CERT Polska has published a thorough technical account of what happened, and if you want the full attack chain, malware analysis, and indicators of compromise, that is the place to start. [1] This blog post will not retell the attack but rather highlight some important lessons: how straightforward the initial access actually was, an observation about how one of the malware samples was likely built, and detection engineering that worked.
Ease of Access
CERT Polska’s attribution points to an activity cluster tracked under several names by different organisations, most notably Static Tundra, with a documented history stretching back over a decade and a consistent focus on the energy sector. [1] This is not a smash-and-grab criminal operation but likely a state-backed Russian threat actor. It is patient, well-resourced, and has a track record of getting into industrial environments and staying there.
So how exactly did they breach the perimeter? At every one of the 30 renewable energy facilities, a FortiGate device sat at the network perimeter, doing double duty as VPN and firewall. The VPN portal was reachable from the internet, which is normal enough, plenty of legitimate remote access setups work this way. What was not normal is that authentication relied on accounts statically defined inside the device’s own configuration file, with no multi-factor authentication sitting in front of them.
“Statically defined” can sound abstract, so it’s worth being precise about what it means in practice. These are local user accounts, username and password, stored directly on the FortiGate itself rather than authenticated against a central identity provider. The attacker did not need to pivot through some other compromised system to get them. They needed valid credentials for one of those accounts, and the login page was sitting on the open internet waiting for them.
Where the credentials came from differs slightly by target, which is itself informative. CERT Polska notes that credential reuse across facilities was common industry practice at the renewable energy sites, meaning a single compromised account could plausibly unlock all 30. Some of the devices had also been vulnerable to remote code execution issues at various points in their history, which is one obvious route to harvesting credentials in the first place. [1] At the manufacturing company hit on the same day, the picture is more damning still: the FortiGate’s configuration had been stolen at some point in the past and posted publicly on a forum used by criminal communities. [1] Older FortiGate firmware has a history of storing local account secrets in a weakly protected format, so a leaked configuration file is functionally equivalent to a leaked password list. CVE-2022-40684, a well-documented authentication bypass affecting FortiOS, is the kind of vulnerability that produces exactly this scenario, though CERT Polska’s report does not confirm which specific CVE was involved at this target. [2]
Once inside, the attacker had admin-level privileges on the FortiGate, which they used to obtain or fabricate VPN accounts with access spanning all internal subnets, segmentation or no segmentation. From there, the rest of the network offered remarkably little resistance. Hitachi RTU560 controllers running the substations had a built-in account literally named “Default”. [1] Mikronika RTUs, built on Linux, accepted default SSH credentials straight to a root shell. Moxa NPort serial device servers had their web interfaces wide open with factory credentials still in place. None of this required any skill beyond knowing where to look, and a simple web search for default credentials.
Consider that this is a group capable enough to have been linked to power grid attacks and malware deployments against critical infrastructure for the better part of ten years. They got into 30 separate facilities, simultaneously, using a login page with no second factor and a password that, in some cases, was sitting in a forum post. Sophistication in this incident lived in the planning, the coordination across targets, and the choice of timing. No zero-days necessary.
The fix here is not overtly complex and should lie well within the skill bounds of any team tasked with protecting these types of assets. Centralised authentication through RADIUS or LDAP rather than accounts baked into each device, mandatory MFA on any internet-facing OT ingress point, and credentials scoped to least privilege rather than blanket subnet access. ISA/IEC 62443-3-3 covers most of this directly under its identification and authentication requirements. [3] It’s not groundbreaking advice.
LLM in the Loop
Buried in CERT Polska’s malware analysis section is a detail that, as far as I can tell, hasn’t shown up in a formally attributed nation-state incident report targeting OT environments before. The attack against the manufacturing company used a PowerShell-based wiper the report names LazyWiper, which overwrites files with pseudorandom byte sequences to render them unrecoverable. Inside it, a C# function (invoked from the PowerShell script) responsible for overwriting file contents stood out from the rest of the script: different coding style, inconsistent indentation, and comments that, in CERT Polska’s words, “would likely not be written by a human developer”. [1] Their conclusion is that the function was probably generated using an LLM.
There’s a slightly comic footnote to this: The function exists because the technique of overwriting selected byte ranges rather than the whole file is, in theory, faster than a full overwrite. Whoever or whatever wrote it got the logic backwards: the way the file operations were actually implemented made it significantly slower than just overwriting everything would have been. [1] So the AI-assisted component of a nation-state wiper attack appears to have made the wiper worse at its job, not better. It’s somewhat comforting to know that even the bad guys struggle with agentic coding.
CERT Polska is appropriately cautious here, and I’ll take my lead from them. This is inferred from the code characteristics and not something confirmed as fact. If true, this pattern is indicative of the broader trend of attackers leveraging LLMs. You no longer need a malware developer on staff, the bar to entry for creating malware has been significantly lowered. (Even if the LLM inverts the logic).
The Detection That Held
At the CHP plant, the same actor had been inside the network for months before the destructive phase. Reconnaissance activity going back to March 2025, credential theft via LSASS memory dumps, a full Active Directory database extraction in July, all quietly building toward something. [1] When the wiper, a native Windows binary CERT Polska calls DynoWiper, was finally distributed across the domain via a Group Policy Object on 29 December, it began executing on more than 100 machines.
Somewhat fortunately, it didn’t get to finish. The organisation’s EDR deployment used a canary file mechanism, essentially planted files that trigger an alert the moment their contents start changing, and the wiper’s overwrite activity tripped it. Execution was halted before the damage spread further. [1]
The attacker didn’t give up. They recompiled a modified version of DynoWiper within roughly 50 minutes and tried again. CERT Polska’s table of analysed samples shows two compile timestamps around 50 minutes apart on the same day, which is about as close as you get to watching an attacker’s reaction time in real time. [1] That attempt was blocked too.
There’s more here than “a defence worked”. First, it’s a clean demonstration that detecting wiper behaviour doesn’t require predicting the specific malware family or having a signature for it in advance. Canary files work because they detect the behaviour, indiscriminate overwriting, rather than the binary. Second, GPO-based distribution, while a convenient and quiet way to push malware across a domain, leaves a trail in event logs that’s detectable if anyone is looking for it, which CERT Polska’s forensic timeline confirms they were able to reconstruct after the fact in considerable detail. Third, the roughly-50-minute recompile-and-retry tells you something about operational tempo: a good detection control doesn’t just block one attempt, it forces the attacker to burn time and resources reacting in the moment, which is exactly the kind of friction a defender wants to introduce.
Lessons Learned
Default credentials in OT environments are not a theoretical finding from a penetration test report. They were the literal mechanism that let a state-sponsored group into 30 separate facilities at once. Credential reuse across sites turns a single compromise into a fleet-wide one, which is a particularly bad trade when the alternative, centralised identity management, is neither new nor exotic technology. And detection engineering, specifically behaviour-based controls like canary files that don’t depend on knowing what the potentially LLM generated malware looks like in advance, demonstrably worked against a capable, patient, and reactive adversary under live conditions.
The CERT Polska report has the full attack chain, the IoCs, the YARA rules, and the MITRE ATT&CK mappings for both enterprise and ICS environments, and it’s worth reading in full if any of this is relevant to your own environment. [1] If any of this overlaps with the kind of thing you’d rather see firsthand, my colleague Colin Cassidy is giving a talk called ACME Windpharm at hack::soho in London, walking through lessons learned from a real windfarm security assessment. Catch it in person or live on our YouTube channel.
References
[1] CERT Polska. Energy Sector Incident Report – 29 December. 2025. https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Report_2025.pdf
[2] Cybersecurity and Infrastructure Security Agency. CVE-2022-40684. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2022-40684
[3] ISA/IEC 62443-3-3. System Security Requirements and Security Levels. Research Triangle Park: ISA. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards