No Malware Required: How a Forgotten Router Let Attackers Stop a Polish Power Plant

On 29 December 2025, between roughly half past five and ten in the morning, someone reached into the control system of a combined heat and power (CHP) plant in Poland, switched its Siemens controllers to STOP, and shut down a steam turbine and the water-treatment system that feeds it. On the way out they corrupted a controller so badly it would not reboot, and factory-reset the firewall, destroying its logs.

The plant supplies heat to about 50,000 residents. They never lost it; operators recovered fast enough. But what makes this one worth studying is not the damage. It is the method. CERT Polska, which spent more than three months reconstructing the intrusion and published its findings in August 2026, found no malware anywhere. Every step used the ordinary, supported features of the devices involved. And the way in, through a misconfigured private cellular network, is something the Polish national CSIRT believes it is the first to have seen used in a real attack.

At a glance

• Target: a Polish CHP plant serving ~50,000 residents; the second of two plants hit in a December 2025 campaign
• Date of impact: 29 December 2025; disclosed by CERT Polska on 8 August 2026
• Entry point: an internet-exposed FortiGate VPN at a wind farm, then a pivot across a shared private cellular network (APN) into the plant
• Key weakness: the private APN allowed any device to talk to any other device (no client isolation)
• Impact: Siemens S7-300/1200/1500 PLCs set to STOP and locked; turbine and water treatment halted; Moxa serial servers and switches reset; a WAGO controller bricked; firewall logs wiped
• Malware used: none. Living-off-the-land with the devices' own protocols and functions
• Attribution: none for this specific incident; a separate 29 December attack was linked (medium confidence, by ESET) to Sandworm

The path in: a wind farm, a SIM router, and a flat cellular network

The attack didn't start at the power plant. It started at a wind farm that the same operator ran.

One week from an exposed VPN to a stopped turbine

The wind farm had a FortiGate doing firewall and VPN duty, exposed to the internet and, critically, allowing VPN accounts without multi-factor authentication. The attacker had admin rights on it and most likely used that to get VPN credentials that reached across the operator's network segments.

From there the intrusion crossed into something most people have never had to think about: a private APN. An APN (Access Point Name) is a dedicated slice of a mobile carrier's network that an organisation uses to connect field equipment over cellular links, a common pattern for distributed infrastructure like substations, wind turbines and remote plants. The plant's Teltonika RUTX50 cellular router sat on this APN. According to CERT Polska, nothing had been required to secure the router's management interface.

The fatal detail was the APN's configuration: it allowed any device on it to communicate with any other device. There was no client isolation. So a foothold at the wind farm could reach the CHP plant's router over the carrier's private network, and SSH-tunnel straight toward the plant's OT. Investigators found repeated successful SSH logins to the router but could not determine how the password, which had been changed from default during deployment, was obtained.

CERT Polska's assessment is blunt and worth quoting directly: to its knowledge, this is "the first instance of this attack vector being observed in a real-world cyberattack." And when it surveyed Polish organisations using private APNs, it found the same permissive, any-to-any setup was common, and believes it is widespread in other countries too.

Inside the plant: patient, then sudden

Once on the APN, the attacker found a WAGO PFC200 industrial controller with its web admin interface exposed and running default credentials. That was the doorway into the plant's OT network. From there, the operation was unhurried.

Patient, then sudden

For about a week, the attacker mapped the network, with port scans that started at the SCADA system's own address. On 25 December they connected to three Siemens PLCs over the S7 protocol, the native Siemens control protocol, almost certainly scouting for what came next.

What came next was the morning of 29 December. In a window of a few hours:

• The Siemens S7-300, S7-1200 and S7-1500 controllers running the turbine and water treatment were switched to STOP and password-protected, so operators couldn't change their state or logic. The turbine and water treatment stopped; cogeneration was interrupted.
• Seven Moxa serial device servers and three switches were factory-reset, given new passwords, and assigned unreachable addresses like 127.0.0.1. CERT judged this was automated.

Then, roughly half an hour after the last action inside the plant, the attacker destroyed the way back:

• The Teltonika router was factory-reset, its password changed, and it too was handed 127.0.0.1.
• The FortiGate was factory-reset, which wiped its logs.
• The WAGO controller's partition table was corrupted, so it would not boot and yielded no useful logs even after a factory reset.

CERT Polska describes this as the first attack on Poland's energy sector with a purely destructive objective. Not espionage, not extortion. Just: stop the plant and make it hard to understand how.

Why "no malware" is the scary part

It's tempting to read "no malware" as reassuring. It's the opposite.

There was no implant to find because none was needed. Switching a PLC to STOP, setting a controller password, factory-resetting a switch, these are legitimate functions. The attacker didn't exploit a vulnerability in the Siemens controllers; they used the controllers the way an engineer would, just destructively. This is living off the land taken into the physical world, and it defeats the defences most OT shops actually have:

• Signature-based tools see nothing. There's no payload, no known-bad hash, no C2 beacon to match.
• The actions look like maintenance. In fact, the plant's operators first logged the interruption as a probable contractor error, because maintenance was underway. CERT Polska only opened an incident because it already knew of similar events elsewhere. Without that outside knowledge, this might have been written off entirely.
• The evidence is deliberately destroyed. Wiping the firewall and bricking the controller weren't vandalism; they were anti-forensics.

The one lucky break was mundane: the Teltonika router's logs survived because the RutOS version it ran (earlier than 7.07) kept its event database through a factory reset. That is a big part of how the path was reconstructed at all.

This is a configuration story, not a CVE story

There is no patch for this attack, because there is no single vulnerability. Every door the attacker walked through was a door someone left unlocked:

• A VPN exposed to the internet without MFA.
• A private APN with no client isolation, so one compromised site could reach another.
• A router management interface that no one was required to secure.
• An industrial controller on default credentials with its admin panel reachable.

Each one is a decision, or a non-decision, rather than a flaw. That's what makes it generalise. The specific brands here, Fortinet, Teltonika, WAGO, Siemens, Moxa, are not the point; swap in any vendor's equivalents and the same chain works. The private-APN finding in particular should worry anyone running distributed OT over cellular. The FBI and EPA flagged private APNs as recently as 30 July 2026 as an isolation architecture for reaching water-sector OT over cellular; CERT Polska has now shown how a flat one becomes a highway.

What to do

If you run OT over a private cellular network

• Turn on client isolation / device-to-device filtering on the APN. This is the finding. Devices on the APN should not be able to reach each other freely; treat the APN as untrusted from the OT side, and segment and restrict what can cross it.
• Ask your carrier exactly how your APN is configured. "Private" does not mean "isolated."

For every OT environment

• Get management interfaces off the open internet and off any flat network. VPN concentrators, cellular routers, PLC web panels, serial servers: if it's reachable, it's a target.
• Enforce MFA on every remote-access path, and kill accounts that are exempt. An internet-facing VPN without MFA is how this started.
• Change default credentials on everything, controllers included. A WAGO PFC200 on default creds was the actual entry into the plant.
• Baseline and alert on OT-native behaviour, not just malware. An S7 connection to a PLC from an unexpected host, a controller going to STOP outside a maintenance window, a mode or password change, these are the real signals. Deploy OT-aware monitoring (an ICS network monitor or protocol-aware IDS) that understands S7, Modbus and the like.
• Protect your evidence. Forward device and firewall logs off-box to a SIEM in real time, so a factory reset can't erase the story. Assume capable attackers will try to wipe local logs.

A starting point for an OT detection rule, to adapt to your monitoring stack:

title:  PLC mode change or S7 session from an unexpected source
logic:  ot network / ics protocol monitor
        WHERE protocol = "S7comm"
          AND ( function IN ("PLC-STOP","PLC-START","password-set")
                OR src_host NOT IN <engineering_workstation_allowlist> )
level:  high
note:   Correlate with a change-control / maintenance window.
        A STOP or password-set outside one is an incident, not noise.

For leadership

Treat the fact that the heat stayed on as luck, not resilience. The operators recovered quickly, but the attacker had a week inside before acting and left with the plant stopped and its forensics damaged. The question to ask is not "do we have antivirus on OT," it's "would we even notice a connection to a controller, and could we reconstruct it afterward?"

The takeaway

The most unsettling attacks aren't the ones with clever malware. They're the ones that don't need any. This crew walked in through an exposed VPN, crossed a cellular network that let every device talk to every other, logged into a controller with its factory password, watched for a week, and then used the plant's own equipment to shut it down and cover their tracks.

None of that required a zero-day. It required someone, somewhere, to have left the settings on default. The fix is equally unglamorous and equally overdue: isolate the networks, kill the default credentials, put MFA on remote access, and watch the control protocols themselves. The plant got its turbine back. The lesson is for everyone who hasn't been hit yet.

This article reflects public information as of 18 August 2026.

Sources

• The Hacker News: Hackers breach Polish power plant controls via private cellular network and shut turbine
• Security Affairs: Hackers cross from IT to OT through a private APN in Poland
• CERT Polska: Incident follow-up report, energy sector (2025)
• SC Media: Attackers breach Polish CHP plant using private APN and Fortinet device
• BleepingComputer: Hackers breached a small Polish energy plant via private APN