Poland's Energy Sector Attack, Part Two: When the Path Into OT Is a Private Cellular Network
By Patrick Miller
A second Polish combined heat and power plant was hit the same morning as the December 2025 attacks. CERT Polska's follow-up report describes something no one had seen in the wild, an attacker pivoting into an operational technology network across a shared private cellular network (a private APN). It explains how the chain worked, why the weak link sat on infrastructure the plant did not control, and what every operator relying on a private APN should check now.
Overview
When we wrote about the 29 December 2025 attacks on Poland's energy sector, we figured we had the full picture. More than 30 wind and solar farms, a large combined heat and power (CHP) plant, and a manufacturing facility had all been hit in a coordinated destructive operation that CERT Polska compared to deliberate arson. On 8 August 2026, CERT Polska published a follow-up report that adds a facility we didn’t know about, and a technique the operational technology (OT) security community has never seen used in the wild.
A second, smaller CHP plant, one that supplies heat to roughly 50,000 residents, was attacked the same morning. It was left out of the original report because the analysis took more than three months. The way the attacker got in was something no one had a playbook for. In CERT Polska's own words, gaining access to the plant's OT network through a private cellular network was "the first instance of this attack vector being observed in a real-world cyberattack."
This should get your attention. It wasn’t another substation full of default passwords. It was a shared piece of telecom infrastructure, sitting between a utility and dozens of generation sites, that was turned into a bridge from one company's wind farm into another company's turbine controls.
A Quick Recap, for Context
If you have not read Part One, here is the short version. In late December 2025, attackers exploited internet-facing FortiGate virtual private network (VPN) devices that lacked multi-factor authentication, moved into the networks behind them, and set out to destroy rather than extort. At the renewable sites they corrupted controller firmware, deleted files on protection relays and remote terminal units (RTUs), and factory-reset serial device servers, cutting operators off from their own generation. The large CHP plant in that first report supplied heat to nearly half a million customers, which puts the scale of the second plant, at roughly 50,000 residents, in perspective. CERT Polska tied the infrastructure to Russian state-aligned activity clusters, and later third-party analyses from Truesec, ESET, Midnight Blue, and others debated the exact attribution and dissected the wiper and the equipment-bricking techniques.
The follow-up report does not revisit any of that. It follows the one thread the first report left hanging. How did the attacker get from a wind farm into a completely separate heat and power plant? The answer runs through a network most operators don’t usually think of as part of their attack surface.
The Plant That Almost Filed It as a Maintenance Error
At around 7:00 a.m. on 29 December, the industrial control systems at the second CHP plant came under attack. A steam turbine and the water treatment system that produces process water were shut down, interrupting the cogeneration process. Thanks to a fast response from the plant's operators, the outage was short and customers never lost heat or electricity. The attacker, it turned out, was still inside the network when recovery began. CERT Polska places the intruder's activity between roughly 5:30 and 10:10 a.m., with the operators starting to restore systems around 7:30.
Here is the detail every operator should consider. Because maintenance work happened to be underway that day, the plant initially assumed the disruption was an error made by a contractor's engineers, and reported it "for informational purposes only." It was not flagged as an attack. CERT Polska opened a real investigation anyway, on the strength of pattern recognition alone, because they were already aware of similar events elsewhere. That instinct is the only reason this incident was ever understood as a cyberattack.
Investigators worked backward, from the observed damage toward the point of entry. They eventually identified the device the attacker had operated from, a WAGO PFC200 programmable logic controller (PLC) with an integrated cellular modem. The device had been damaged in the attack, and even after CERT Polska desoldered its memory chip and examined it in the lab, no data could be recovered. The reconstruction that follows was assembled from logs elsewhere in the chain, but not from the pivot device itself.
The Path In: A Private Cellular Network Nobody Was Guarding
To understand how the attacker reached the CHP plant, you need to go back to the wind farms from the first report, and to the network plumbing that connects them to their distribution system operator (DSO).
Renewable sites connect to the grid at interconnection points, and the substations commonly use cellular routers for communication with the DSO, sometimes as a backup channel and sometimes as the primary one. Those routers carry SIM cards that operate on a dedicated private data transmission network (a private APN) run by the DSO. The private APN is how the DSO's supervisory control and data acquisition (SCADA) system talks to the RTUs out at each site. It is normal, it is useful, and it is almost never treated as a security boundary.
At the compromised wind farm, the attacker (already inside from the FortiGate compromise described in Part One) found a Teltonika RUTX50 cellular router. The router had two physical interfaces. One was a serial link to the RTU, exactly as the DSO required. The other was an Ethernet connection into a virtual local area network (VLAN) managed by the central firewall the attacker had already taken over. No one had ever defined a security requirement for how that router's administrative interface should be handled. The attacker logged into it over Secure Shell (SSH) repeatedly through December, and used SSH tunneling to venture out onto the private APN itself.
And this is where a design assumption became a vulnerability. The private APN had no client isolation. Devices on it could reach each other directly. So an attacker who had compromised one site's router could scan across the shared network and reach equipment belonging to entirely different operators. Starting on 18 December, that is exactly what happened. The attacker swept the APN for virtual network computing (VNC) and hypertext transfer protocol (HTTP) services and for the industrial protocols S7 and Modbus.
On that shared network sat the second CHP plant's WAGO PFC200 controller. Its web administration interface was reachable from the APN and still carried the default credentials for the "admin" account. SSH was not exposed on that interface by default, so the attacker most likely logged in through the web interface, turned SSH on, and then tunneled through the controller into the plant's OT network. The WAGO had connectivity to both the SCADA systems and the segments running the plant's key operational processes. The path was one default password on one controller, reachable across a network no one was watching.
The Full Chain, in Order
CERT Polska lays out the successive steps:
Access to a perimeter device (the FortiGate) at a wind farm is obtained, and a remote VPN connection is established.
A Teltonika RUTX50 cellular router is identified inside the wind farm network.
The router's web administration interface is accessed, followed by login to its SSH service.
SSH is used to tunnel onto the private APN network.
The private APN is scanned.
A WAGO PFC200 controller exposing a web administration interface on its wide area network (WAN) side is found.
Default credentials are used to gain administrative access to that web interface.
SSH is enabled on the WAGO's WAN interface.
SSH is used to tunnel into the CHP plant's OT network.
Reconnaissance of the CHP plant's OT network is conducted over the course of a week.
Disruptive actions are carried out, shutting down the steam turbine and the water treatment system and interrupting cogeneration.
Inside the Plant: A Week of Quiet, Then a Morning of Damage
The reconnaissance was patient and deliberate. Between 18 and 25 December, the attacker scanned the plant's network for the services you would expect an OT-skilled adversary to want. Those included S7 on 102/TCP, Modbus on 502/TCP, CODESYS on 11740/TCP, video feeds over the real-time streaming protocol (RTSP) on 554/TCP, plus remote desktop protocol (RDP), VNC, and web interfaces. One telling detail stood out. In at least one subnet, the scanning began at the Internet Protocol (IP) address of the SCADA system itself, which suggests the attacker already knew where the crown jewels were from an earlier reconnaissance phase. Much of this activity fell on a Sunday, and on Christmas Day the attacker established connections to three Siemens PLCs over the S7 protocol, almost certainly staging for what came next.
On the morning of 29 December the attacker connected to the SCADA server's web interface and then, one after another, to a Siemens S7-300, an S7-1200, and an S7-1500. The PLCs were switched into STOP mode and locked with a password that prevented operators from changing their state or modifying the control logic. This is what took the steam turbine and the water treatment system offline. Recovery required restoring the controllers to factory settings and reloading logic backups, which shortened the outage but also erased the logs stored on the controllers. Siemens ProductCERT confirmed those logs could not be recovered.
The attacker wasn’t finished. Seven Moxa serial device servers and three Moxa switches were factory-reset, given new passwords, and assigned unreachable IP addresses such as 127.0.0.1, all to slow down recovery. The timing of the requests shows this was automated. The attacker also touched two ABB ACS variable frequency drives, and made unsuccessful attempts against Schneider Electric ATV6xx drives that failed only because they guessed the wrong port. Incomplete reconnaissance was the sole reason those drives survived.
Then came the cleanup. After roughly five hours inside the plant, ending with a look at the SCADA web interface to assess the damage, the attacker corrupted the WAGO controller's partition table, bricking the device so thoroughly that the plant's own factory reset could not revive it. About half an hour after the last activity at the CHP plant, they factory-reset the Teltonika router back at the wind farm, changed its password, and set its IP to 127.0.0.1. Finally, they restored the FortiGate to factory settings, destroying the logs that would have made the whole chain easier to see. The investigation succeeded in part because an older version of the router's operating system happened to retain its event database through a factory reset, a lucky break that won’t repeat on patched devices.
Why This One Is Different
Every element of this attack, taken alone, is something defenders already know about, whether an unpatched edge VPN, a default password, a flat network, or an OT-aware adversary. What makes the follow-up report worth reading is the connectivity issue. The private APN turned a set of independent facilities into a single, reachable neighborhood, and no one owned the responsibility for securing the street between the houses.
CERT Polska is straightforward about how common this is. The misconfiguration that allowed arbitrary devices to talk to one another across the APN was "commonly encountered in Poland" and, to the best of their knowledge, "widely used in other countries around the world." This is not a Polish problem. Private APNs are just as common outside Europe, including in North America, where the major carriers offer them and utilities rely on them for grid and metering connectivity. Any operator whose remote sites ride a carrier-managed or DSO-managed private APN should assume the same design assumption may be baked into their own environment until they have checked.
The uncomfortable part is that the weak link may sit outside your walls entirely. You can harden every device you own and still be exposed through a network you neither configure nor monitor, reached through a peer's compromised site. Shared infrastructure is a shared attack surface.
A Known Risk, Finally Exploited
It is worth separating what was actually new here from what only looked new. The path was new. The pieces along it were not.
Let’s start with the hardware. The Teltonika cellular router the attacker rode onto the private APN belongs to a product line that researchers had already pulled apart. In May 2023, OTORIO and Claroty's Team82 disclosed eight vulnerabilities in Teltonika's RUT industrial routers and their Remote Management System, flaws serious enough to allow full device takeover and, in the researchers' description, to turn the vendor's cloud platform into a single pivot point into thousands of OT networks at once. The WAGO PFC200 controller at the far end has a longer record still, with advisories from the US Cybersecurity and Infrastructure Security Agency (CISA) going back years for default credentials, unauthenticated remote access, and critical flaws in its CODESYS runtime. The attacker needed none of those specific bugs. A default "admin" password made things as easy as possible. The pieces were catalogued, published, and, in the WAGO's case, shipping with the very weakness that undid it.
The private APN is the same story. That a shared private cellular network can be a route for lateral movement, and that the devices on it need to be isolated from one another, was not a secret before December. The vendors who secure private cellular networks for utilities had been making the point for a while, and in early 2024 OneLayer warned specifically that a cellular gateway sitting on a private APN could be turned into a "trojan horse" into the networks behind it. Connectivity guidance from the GSMA had long called for isolating devices that share an APN. What CERT Polska documented was not a new weakness. It was the first time an adversary was caught wiring a well-known one into a bridge between separate companies.
It’s crucial to note that this did not take an exotic, state-only capability. It took ordinary, documented exposure that no defender had connected end to end, and an adversary with motive.
The Wider Trend
Zoom out and this stops looking like a special event. CERT Polska's 2025 annual report calls the December attacks the first time in Poland's history that coordinated, sabotage-focused attacks were carried out against the energy sector, striking both IT systems and physical industrial devices, a combination the report describes as relatively rare, and doing so during a stretch of low temperatures and snowstorms. The same report notes a broader intensification of state-linked advanced persistent threat (APT) activity across the year.
The unlocked front door was not exotic either. When CERT Polska issued its 2025 notifications, it found 240 vulnerable FortiOS or FortiProxy instances in Poland alone, alongside hundreds of other exposed or vulnerable edge and VPN appliances from Cisco, Ivanti, Citrix, and SonicWall. Exposed edge devices are a systemic condition, not one unlucky substation. And the year's record 179 ransomware cases, up from 147 in 2024, most often began with compromised VPN credentials, with investigators repeatedly slowed by poor log retention on edge devices.
The NIS2 Question, Revisited
Part One pointed out that when the attacks happened, Poland had not yet written the EU's NIS2 Directive into its own law. That’s changed. The Polish president signed the amendment to the National Cybersecurity System Act on 19 February 2026, and after a one-month grace period it entered into force on 3 April 2026, a little over three months after the attack. Covered organizations have until 3 October 2026 to register as essential or important entities and until 3 April 2027 to meet the full set of obligations. The amendment widens the national scheme far beyond its original scope, puts cybersecurity accountability on management boards, with regulators able to suspend executives for serious failures, and adds a mechanism to screen and phase out high-risk suppliers.
For an incident like this one, the key parts are supply-chain and third-party network security. Electricity distribution operators and district heating operators are both covered under NIS2's energy sector, and both are now expected to manage the risks that ride in through their suppliers and the networks they depend on. A private APN operated by a distribution operator and shared across dozens of generation sites is close to a textbook example. It is third-party infrastructure sitting inside the trust boundary of every entity attached to it, and until this report was published, few if any were treating it as something they had to secure.
The law still leaves a hard question open. When a single shared network links a wind farm operator, a distribution operator, and a heat and power plant, who (if anyone) is accountable once it becomes the route for an attack? When a private APN is delivered over a mobile carrier's network, client isolation, meaning whether devices on the network can reach one another, is configured on the carrier's side, and carriers hold their own network-security obligations as electronic communications providers under NIS2 and the EU's Electronic Communications Code. In this incident, though, CERT Polska described the private APN as managed by the distribution operator, and directed its recommendations at the entities using it, telling them to audit the configuration, enable client isolation, and treat the APN as untrusted where it sits outside their control. NIS2 tells each entity to manage its own supplier risk, but a private APN is a boundary several parties share and none usually fully controls. Deciding who carries that responsibility, in the contract and in practice, is now a compliance question and not just an engineering one.
NIS2 is also not the only compliance instrument tightening around this. The EU's Network Code on Cybersecurity for the electricity sector, Commission Delegated Regulation (EU) 2024/1366, took effect in 2024 and sets binding cybersecurity obligations across the electricity value chain, from transmission and distribution operators to the generation connected to them. It is sector-specific where NIS2 is general, and it reaches exactly the population this attack ran through. Working alongside it, the Cyber Resilience Act comes at the other end of the problem, the equipment, by requiring that connected products sold in the EU, industrial controllers and routers included, ship secure by default and stay supported with patches for years after sale. The loop is closing on both the operators who run these networks and the vendors who build the boxes that sit on them.
What to Do Now
CERT Polska's recommendations for anyone relying on a private APN are worth reading in full, but they can be distilled to a single principle. Stop treating the private APN as a trusted extension of your network. That means auditing the APN's configuration and enabling client isolation so that devices cannot reach one another unless there is a documented reason.
Treat the APN as untrusted relative to your OT, with segmentation and traffic controls at least as strong as those you apply to a corporate WAN connection.
Consider it as fully external, at internet trust level, when you have no visibility into how it is configured.
Strictly limit and allowlist-only the traffic permitted between your OT network and the device that gateways onto the APN.
Monitor that traffic for anything outside the expected profile.
Centralize and isolate logs from the gateway devices.
Minimize the open ports reachable from the APN, with no web, SSH, or Telnet administration exposed.
Change default credentials on everything connected to it.
Pull private APNs and their gateway devices into the scope of your penetration tests, red team exercises, and architecture reviews.
There is also a fundamental lesson sitting underneath the technical one, and it costs nothing to act on. This incident became knowable only because someone treated an unexplained operational disruption as worth investigating rather than writing it off as a contractor's mistake. If your reporting culture only captures confirmed incidents, the novel attacks (the ones with no known signature or immediately recognizable source or pattern) are exactly the ones you will miss. Report the anomalies you cannot explain, and give someone the job of looking for patterns across them. Even the near-misses need to be treated the same way.
If you operate distributed generation, a CHP plant, or a DSO network and you are not certain whether a private APN quietly connects your OT to sites you do not control, that uncertainty is the finding. Map those trust boundaries before an adversary does, while it is still an exercise and not an incident.
