Default Passwords Destroyed 30 Energy Sites in One Night: What the Poland Attack Teaches Us About OT Detection
What Happened on December 29, 2025
On the morning of December 29, 2025 — during winter conditions, days before New Year’s Eve — coordinated destructive cyber activity struck at least thirty wind and solar farms, a combined heat-and-power (CHP) plant supplying heat to nearly half a million people, and an unrelated manufacturing company across Poland. The attackers did not deploy a single zero-day vulnerability. They used default passwords.
By the time the attack concluded, remote terminal units (RTUs) at renewable generation sites had been permanently damaged — some requiring physical replacement or factory reprogramming. Human-machine interface (HMI) data had been wiped. Serial device servers had been reconfigured to unreachable IP addresses. At the manufacturing facility, a PowerShell-based wiper had overwritten engineering and business files across the domain. At the CHP plant, the same wiper was detected and blocked by endpoint protection — the one site where defence held.
The attack did not stop electricity generation. It did not destabilise the Polish power system. But it severed communication between distributed generation sites and their distribution system operators (DSOs). Operators lost view. They lost control. And restoration took weeks — firmware corruption does not resolve with a reboot.
This was the first confirmed instance of the Sandworm threat group — linked to Russian military intelligence (GRU Unit 74455) — deploying destructive malware against the critical infrastructure of a NATO member state. It landed nearly ten years to the day after the same group’s BlackEnergy attack cut power to 230,000 customers in Ukraine: the first cyberattack in history to cause a blackout.
How the Attack Unfolded
The attack chain is worth examining closely, because at nearly every stage, the activity would have been invisible to a signature-based detection system. There was no novel malware on the OT devices. There were no custom ICS protocol exploits. There was simply an attacker moving laterally with legitimate credentials across a poorly segmented network.
Step one: the VPN. Initial access came through FortiGate appliances serving as VPN concentrators and firewalls — exposed to the internet, authenticated by username and password only, with no multi-factor authentication configured. One set of credentials, shared across multiple locations, opened access to dozens of facilities.
Step two: the domain. From the VPN, the attacker pivoted into the Windows enterprise environment. At the CHP plant, this phase had been underway since March 2025 — months of quiet reconnaissance, Active Directory privilege escalation, credential dumping, and domain controller compromise. By December, the attacker controlled the Group Policy Objects (GPOs) used to push configurations to every machine in the domain.
Step three: the wipers. The attacker placed DynoWiper on a compromised domain controller and configured a GPO to propagate and execute it across all domain machines. DynoWiper — a native Windows binary — recursively scans drives and overwrites files with pseudorandom data before deleting them. The manufacturing facility received a PowerShell variant called LazyWiper, distributed through the same GPO mechanism.
Step four: the OT devices. This is where the attack shifted from IT compromise to physical damage. The attackers accessed three categories of industrial devices — all through default manufacturer credentials that had never been changed since installation:
- Hitachi Energy RTU560 controllers: accessed through default web credentials. The attackers uploaded modified firmware, causing permanent damage. Some units required physical replacement.
- Mikronika RTUs and HMI interfaces: RTUs accessed through default root SSH credentials and hit with destructive filesystem commands. HMIs accessed through default local administrator credentials via RDP and SMB, then wiped by DynoWiper.
- Moxa NPort 6xxx serial device servers: accessed through default web credentials, factory-reset, then reconfigured with an unreachable IP address — online but unreachable, complicating recovery.
The common thread was not exotic malware. It was reachable management surfaces, default credentials, and insufficient hardening. The attacker did not need to write custom Modbus or DNP3 payloads. The management interfaces were already wide open.
Why Signature-Based Detection Was Structurally Blind
This attack exposes a hard truth about OT threat detection: signatures only catch what has been seen before. When an attacker uses legitimate credentials to access legitimate management interfaces and execute legitimate firmware upload commands, there is no signature to match.
Consider each stage. The VPN login used a valid username and password — no brute force, no exploit. A signature-based IDS would see an authenticated session, indistinguishable from a legitimate remote maintenance connection. The lateral movement through Active Directory used built-in Windows tools — RDP, SMB, Impacket — the same tools administrators use every day. The firmware upload to the RTU560 used the device’s own web interface with the manufacturer’s default password. From the network’s perspective, this was a standard HTTPS session to a known management port. The wiper deployment via GPO used the domain’s own software distribution mechanism — Group Policy is how organisations deploy patches and install software. The attacker used it exactly as designed, just with a different payload.
At every stage, the activity looked legitimate because the attacker had obtained legitimate access. This is the fundamental limitation of threat-based detection in OT environments: it assumes the threat will look like something already catalogued. But the most damaging attacks look like normal operations, performed by the wrong person at the wrong time.
What Would Have Made the Difference
If signature-based detection is structurally blind to credential-based attacks, what actually works? Three layers of defence operate independently of known threat signatures.
Behavioural baselining at the network layer. A monitoring platform that learns normal device behaviour — which devices talk to which others, on which protocols, at which times, with which command patterns — would have surfaced multiple anomalies. A Hitachi RTU560 that has never received a firmware update suddenly accepting one. A Moxa NPort that has never been reconfigured suddenly undergoing a factory reset and IP reassignment. These are not signature matches. They are deviations from the learned normal — detectable without knowing anything about DynoWiper or Sandworm.
Protocol-level visibility into industrial traffic. The renewable sites communicated with DSO SCADA systems through serial links using DNP3.0 or IEC 101. While the attacker operated through IP-based management interfaces, the downstream effect — loss of telemetry, unexpected protocol behaviour at the RTU — would have been visible to a sensor that understands these protocols natively. A DNP3 poll that stops arriving. An IEC 104 interrogation that returns unexpected values. These are not events a general-purpose IDS can interpret.
Firmware and configuration integrity monitoring. The most destructive act in this attack was the firmware corruption on the RTU560 controllers. A detection system that maintains cryptographic hashes of device firmware and alerts on any unauthorised change would have caught this at the moment of upload — before the device rebooted into a corrupted state. This is integrity verification, not signature detection. It does not require knowing what the attacker’s firmware contains, only that it is not what the asset owner authorised.
None of these approaches depends on prior knowledge of the threat. They depend on knowing what normal looks like — and detecting when normal changes.
The Distributed Generation Blind Spot
There is a structural lesson here that extends beyond any single attack. Poland’s installed renewable energy capacity exceeds 30 GW. The facilities attacked represented approximately 1.2 GW — nearly 5% of the country’s energy capacity, concentrated across dozens of small, distributed sites with essentially the same architecture: the same VPN appliances, the same RTU models, the same remote-access procedures, the same default credentials.
This is the distributed generation paradox. Wind, solar, and battery storage sites are individually small — often dismissed as too fragmented to be attractive targets. But they are operationally identical, remotely managed, and rarely visited by physical security teams. When one set of VPN credentials opens thirty sites, the attack surface is not fragmented. It is concentrated.
As one detailed technical analysis of the incident concluded: if distributed generation is operationally connected faster than it is architecturally governed, the attack surface scales faster than resilience. Every new renewable site that comes online with the same default credentials, the same unsegmented VPN, and the same absent MFA policy adds to the attack surface without adding detection coverage. The grid grows. The blind spots grow faster.
The IEC 62443 zone-and-conduit model becomes more than a compliance checkbox here. Properly applied, it would have segmented enterprise IT from the OT domain, required individual accounts with MFA for remote access, mandated credential rotation, and enforced site-specific authorisation. Default credentials would have been removed during commissioning — as the standard requires. The Poland attack did not defeat IEC 62443. It walked through gaps where the standard had not been applied.
The Poland energy sector attack is not a story about sophisticated malware defeating sophisticated defences. It is a story about default passwords, shared credentials, and architectural shortcuts — the kind of gaps that exist in thousands of industrial environments today. The attackers did not need to be technically elegant. They needed to be patient. And the defences they encountered were looking for the wrong thing.
Maigadi is the OT/ICS network detection and response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.
Maigadi Networks provides passive, signature-less network detection and response for OT/ICS environments. Our platform learns your network’s normal behaviour and surfaces the deviations that matter — without relying on known threat signatures, without mandatory cloud connectivity, and without disrupting industrial operations.