At half past five in the morning on 29 December someone logged into the SCADA of a Polish combined heat and power plant and switched the controllers to STOP mode. The steam turbine stopped and so did the water treatment system. The plant supplies heat to some 50,000 residents. The intruder had not arrived over the internet, nor through the plant's corporate network: they had arrived through the distribution operator's private mobile network, crossing over from a wind farm whose only link to the plant was the mobile network they both connected through.
CERT Polska published its analysis on 8 August, after more than three months of investigation. It is worth reading in full, but one sentence matters most here: the attack was made possible, among other factors, by "a misconfiguration that allowed arbitrary devices within the private APN network to communicate with one another". And the kicker: that same configuration was, according to CERT itself, commonly found in Poland and is likely to be widespread in other countries too. Some context: this is the second facility hit in those days. The December 2025 campaign reached some thirty wind and solar installations and one large combined heat and power plant; this report is about the small one.
What happened, in order
The chain starts somewhere that is not the plant. At a wind farm there was a FortiGate acting as firewall and VPN concentrator, exposed to the internet, with accounts that had no multi-factor authentication. The attacker obtained VPN credentials with administrative privileges and got in. So far, nothing you would not find in any incident response report.
The interesting part is what came next. Inside that network there was an industrial Teltonika RUTX50 cellular router, the kind you install for connectivity where fibre does not reach, or as a backup link. The attacker reached its SSH service and tunnelled through it. That tunnel did not lead to the internet: it led to the distribution system operator's private APN — the utility that runs the local electricity distribution grid, not the mobile carrier — the mobile network that utility buys from a carrier to connect its equipment across the area.
From 18 December onwards they scanned that network. They found a WAGO PFC200 controller with its web administration interface reachable and default administrator credentials. That was the way into the plant's OT network. By 25 December they were making successful S7 connections to the Siemens controllers. On the 29th at 5:30 a.m. came the destructive phase: SCADA, PLCs from the S7-300, S7-1200 and S7-1500 families switched to STOP and password-protected, and seven Moxa serial device servers and three switches factory-reset, given new passwords and unreachable IP addresses. At around 7:30 a.m. the plant began recovering while the attacker was still inside. Customers lost neither heat nor electricity.
A note of honesty before moving on: the coverage uses two names, but they are not two groups. BleepingComputer calls the group behind the December campaign Electrum and SecurityWeek associates it with Sandworm; MITRE ATT&CK lists Electrum as one of the aliases of Sandworm Team. As for this second intrusion, the one at the small plant, neither the report nor the coverage names an actor. And for our purposes it does not matter: the path would have been the same with any name attached to it.
"Private" tells you who pays the bill, not who can reach you
An APN is, technically, the name that tells the mobile network which exit a SIM's traffic should be routed to. The public APN takes you to the internet. A private APN takes you to a different exit, usually with private addressing and, if you have contracted it, a link into your corporate network. That is all it means.
Note what it does not mean. It does not mean the network is yours. It does not mean you are alone in it. And above all, two devices connected to that same APN can see each other until something stops them. That something is a separate setting — on the carrier's side, and partly on the router's own firewall — and in the Polish case it was set the convenient way: everyone reachable from everyone. Two very different properties travel under the word "private" — I am not on the internet and nobody else can reach me — and the invoice only guarantees you the first one.
The corridor that runs out of the router cabinet
When somebody audits a 4G router, what they look at is the outward-facing side: that the admin interface is not published to the internet, that the password is not the one on the sticker, that the firmware is current. All of that is right and should be done. But here the Teltonika was reached from the site's own network, after the firewall fell. Its SSH service was available to anyone already inside, which is precisely the situation in which nobody checks it.
That is the shift in perspective this incident asks for. A cellular router in a warehouse, a wastewater treatment plant or a shop is also a route into another network, and it is almost never drawn as one. It looks a lot like the problem of exposed BMCs and IPMIs, those computers inside the computer that almost nobody has in an inventory; the difference being that what sits on the other side here is not your server, but somebody else's estate. It is a neighbour you have signed nothing with, the same problem we looked at with shared hosting, with the access network in between.
Your network neighbour is on no supplier questionnaire
Third-party questionnaires ask about suppliers: who provides your software, who administers your servers, who has remote access. And they are useful. But there is no trace in the report of any commercial relationship between the wind farm and the plant: they are separate facilities and, as the coverage puts it, neither of them runs the network that linked them. The only thing they shared was transport, contracted separately with the same operator. That gets ticked in no box, and it still put them in the same network domain.
If you are working through supply-chain obligations — we wrote about this a few weeks ago in connection with the Spanish law transposing NIS2 — this is a question that does not come in the template and has to be added by hand: who do I share an access network with, and what separates me from them? It is a topology question that ends up in a compliance document.
On the way out, they took the logs
The last link in the chain is the one that gave us most to think about. The attacker corrupted the partition table of the WAGO they had used as a gateway, so the device could not read it, and left the FortiGate and the Teltonika factory-reset. In other words: the three devices that told the story went silent, on the same way out.
An edge device keeping its own logs and nothing else is fine as long as the device is healthy. The moment somebody with admin rights decides to wipe it, that log ceases to exist with two commands and there is nothing to restore, because there never was a copy. A log that only lives on the device that can be compromised lasts exactly as long as the device does. Shipping syslog from routers and firewalls somewhere the attacker does not control is the difference between being able to reconstruct an intrusion and publishing a statement containing the word "allegedly".
This is not only about power plants
It is easy to read this story as a critical-infrastructure matter and turn the page. But private APNs are in a great many places that are not a power plant: the 4G backup link at a branch office, the SIMs in a warehouse's cameras, the datalogger at a small solar plant, the EV chargers in a car park, fleet telemetry, the card terminals in seasonal shops. Almost none of those companies has ever seen the configuration of the APN their cards sit in, and almost all of them assume they are alone in it.
And there is a nuance that hits close to home, because we see it when designing multi-site networks: the mobile backup link is bought with availability in mind. The conversation with the carrier is about coverage, throughput and how long failover takes. The question of who else is in that APN never comes up, because it is not an availability question. It is the same asymmetry we described in our post on SD-WAN: you buy it for what it does when the primary link goes down, and you overlook the plane it is administered through.
What to ask the carrier, and get it in writing
- →Is my APN dedicated or shared? If it is shared, with what kind of customers. They need not give you names, but the answer "well, there are others on it" already changes the design.
- →Is device isolation enabled? Get it in writing, with whatever name they use for it: client isolation, device-to-device blocking, inter-SIM filtering. And whether it ships enabled or has to be requested.
- →What routes exist between the APN and my fixed network? There is often a permanent tunnel back to headquarters that nobody remembers requesting, and that turns anything arriving through the APN into internal traffic.
- →Which management services listen on the mobile interface? Not the fibre WAN: the mobile one. SSH, Telnet, the router's web UI, the vendor agent. What is closed to the internet may well be open to the APN.
- →What logs does the carrier keep for that APN, for how long, and how are they requested? Asking on the day of the incident is too late. If your edge devices end up factory-reset, those logs are all that is left.
And the test, worth more than all five answers together: take a SIM from your APN, put it in a laptop and see what answers from there. A sweep of the range with nmap -sn and an attempt to connect to the usual management ports tells you in twenty minutes what an email thread with your account manager will not tell you in a fortnight. If from that SIM you can reach devices that are not yours, you have your answer. If you can reach devices that are yours but that you believed were isolated, you also have it. A serious warning: do the discovery and stop there. Do not try credentials against devices that are not yours and do not touch anything on them; at that point it stops being a design test and becomes a crime. Whatever turns up, put it to the carrier in writing.
Before asking them to isolate everything on Friday
Device isolation is not free, and saying so is part of giving honest advice. There are designs that depend precisely on two devices in the APN talking to each other: a small site that reaches another without going through headquarters, an engineer who gets into the cabinets from their own SIM, a telemetry relay built years ago by someone who has since left. If the carrier enables isolation on a Friday afternoon because you asked for it after reading a news story, on Monday you will have an outage nobody can explain.
The order that works for us is the opposite: first find out what talks to what today — that comes out of the SIM test and from looking at the traffic, not from asking — then write the short list of conversations that must keep existing, and only then request isolation with those exceptions. It is slower, and it is the only way to keep it from turning into a rollback. And in parallel, the cheap part: remove the management services that are not needed from the mobile interface and change the default credentials, which is what would have broken the chain at the WAGO in Poland.
The question that puts this in order
What makes this case uncomfortable is not the technique, which is simple, but that the piece which failed was administered by neither victim. You can have your firewall current, your inventory done and your segmentation drawn, and still have an open path through a network that does not appear on your diagram because it belongs to somebody else. There is one question almost nobody has answered in writing: "through which paths that I do not administer can my devices be reached, and who else is on them?". If nobody in your organisation can answer that today, that is the first task, and it costs no money: it costs an afternoon and a SIM.
Sources: follow-up report on the 29 December 2025 energy sector incident, the first observed case of access to an OT network through a private APN, the misconfiguration that allowed arbitrary devices in the APN to communicate, and how commonly that configuration was found in Poland and elsewhere — "Follow-Up Report of the December 2025 Energy Sector Incident", CERT Polska (8 August 2026). Attack chain, FortiGate without multi-factor authentication, Teltonika RUTX50 router, WAGO PFC200 controller with default credentials, Siemens S7-300/1200/1500 PLC families, Moxa serial device servers, the time of SCADA access and the recovery with the attacker still inside — The Hacker News, BleepingComputer and Help Net Security. Corruption of the WAGO partition table, the scope of the late-December campaign and attribution to Sandworm — SecurityWeek; BleepingComputer attributes the campaign to a group it calls Electrum, and we have not found an explicit, settled attribution for this second intrusion in the coverage. We took no part in this investigation and have audited none of the facilities mentioned: everything above comes from the public report and its coverage. Header image: "Radio tower, Japan; May 2016 (02)", photo by acopbc (Wikimedia Commons, CC0), cropped.
Who else is on your SIMs' network?
We are a carrier with our own network, and when we design networks and communications or build multi-site SD-WAN, the mobile backup link comes in with the same questions as everything else: how it is administered, who can reach it, and what is written down when something goes wrong. That is the boring part of Zero Trust: treating the transport as untrusted even when the invoice says "private". We are not resellers for any particular vendor; if your current design is fine, we will tell you that too.
Talk to everyWAN