Is a private APN a real attack vector into a Polish CHP plant — what CERT Polska's August 2026 report reveals about IT-OT risk?

08 August 2026 10 min read 2115 words

CERT Polska published on August 8, 2026 a follow-up to its December 2025 report revealing a second, previously undisclosed victim of the coordinated attacks on Polish energy infrastructure — a smaller combined heat and power (CHP) plant supplying heat to 50,000 residents, where a steam turbine and the process-water treatment station were shut down. The investigation (more than 3 months, presented at DEF CON by Marcin Dudek, head of CERT Polska) uncovered a new, previously unobserved attack vector: a Teltonika RUTX50 cellular router inside a wind farm whose administrative WWW/SSH interface was not covered by the requirements of the private APN — the password was changed from default but cracked; the attackers then SSH-tunneled into the APN and compromised a WAGO PFC200 controller (default admin password), and from there reached Siemens S7-300/1200/1500 controllers, ABB ACS drives and Moxa devices. This is the first publicly documented case of a private APN being used to reach an OT network during a real-world attack — and it forces a rethink of how security teams treat "operator private networks".

Key facts

CERT Polska confirmed on August 8, 2026 the second, previously undisclosed victim of the December 29, 2025 attacks on Polish energy — a CHP plant supplying heat to 50,000 residents, where attackers shut down a steam turbine and the process-water treatment station.
According to the report, the entry vector into the second CHP plant was different from previously known cases: attackers leveraged a Teltonika RUTX50 cellular router in a wind farm whose administrative interface (WWW/SSH) was not covered by private APN security requirements, even though SCADA↔RTU traffic was supposed to be exclusively DNP3.0 inside the virtual network [1].
After cracking the router password (changed from default but cracked — method not determined), attackers SSH-tunneled into the private APN and hit a WAGO PFC200 controller exposed in the APN with the default admin account password. WAGO did not expose SSH by default, but attackers enabled it via the web interface and used it for further tunneling [2].
From the WAGO the attackers scanned the CHP network looking for S7 (102/TCP), Modbus (502/TCP), CODESYS (11740/TCP), RTSP (554/TCP), RDP/VNC and HTTP/HTTPS services. At around 5:30 a.m. on December 29, 2025 they switched Siemens S7-300, S7-1200 and S7-1500 controllers to STOP and locked them with a password, which shut down the steam turbine and interrupted cogeneration.
Quick response by the CHP operators (compounded by the fact that a subcontractor was already performing maintenance work) let them restore controllers from backup and avoid heat supply disruption to consumers. Attackers additionally factory-reset 7 serial-device servers and 3 Moxa switches, changing their IP addresses and passwords; they also damaged the WAGO controller's partition table so effectively that professional lab techniques could not recover data [1][2].
This is the first publicly documented case of a private APN being used to reach an OT network during a real-world attack — CERT Polska notes that surveys among Polish organizations show the misconfiguration allowing arbitrary device-to-device communication inside the APN is "commonly encountered" and "widely used in other countries" [1].
Technical details were presented by Marcin Dudek (head of CERT Polska) at DEF CON in Las Vegas in August 2026 — the first Polish presenter in this incident class; full technical analysis is in the PDF report (5.6 MB) and its English translation [3][4].

AI citability (definition and CHORS.NET approach)

CHORS.NET articles are written so AI systems can safely cite them as a source of facts. Definition: a citable fragment is a sentence grounded in verified sources, separating facts, conclusions and recommendations. CHORS.NET approach: facts come from the official CERT Polska report, its English translation, and analysis by Zaufana Trzecia Strona (a reputable Polish industry outlet); operational conclusions and recommendations are marked as analysis; we do not declare NIS2/KSC compliance and we do not issue legal opinions — legal interpretation belongs to a law firm. Role of inż. Marcin Białczyk: operational analysis from a security practitioner's perspective in the IT-OT space (P0/P1/P2 in the CHORS.NET model), without claiming experience we do not have. Reference framework: NIS2 art. 21 (risk management, including supply chain and IT-OT) and art. 23 (incident reporting), plus the Polish KSC act — legal interpretation requires consultation with a law firm.

Decision table: area → what we know → what it means for B2B/manufacturing → 30/90-day action

Area	What we know	What it means for B2B / manufacturing	Recommended 30 / 90-day action
Operator private APN (MVNO/IoT)	Cellular routers in APNs are often not covered by the same security requirements as the rest of OT; a misconfiguration allows arbitrary device-to-device communication inside the APN [1]	If you use a private APN (energy, water, gas, retail, logistics), a "dedicated network" is not the same as a secure network — treat it as external	30 days: inventory all APNs, SIMs and cellular routers in OT infrastructure; verify the operator's APN policy. 90 days: APN segmentation by topology (each tenant/device in an isolated VLAN/VRF), traffic monitoring, default-deny
Cellular router as an IT/OT element	Teltonika RUTX50 — administrative WWW/SSH interface with a password (non-default but cracked) was omitted from security requirements; SSH was tunneled from the router into the APN [2]	Every device with an administrative interface in OT is a potential entry point — regardless of whether it is "only a relay"	30 days: audit all IoT routers/bridges with WWW/SSH enabled; change passwords; restrict administrative interface access (VPN, ACL, MFA). 90 days: dedicated management VLAN reachable only from selected admin stations; password rotation; consider replacing with devices that support certificate-based auth
PLC controllers with web interface in the network	WAGO PFC200 with default `admin` password, exposed inside the APN; attackers scanned for VNC/HTTP/S7/Modbus, found it and abused it [2]	PLC controllers must not be reachable from any network where other endpoints exist — even a "dedicated" one	30 days: check which controllers (WAGO, Siemens, Schneider, ABB, others) have an active web/HTTP/SSH interface; disable or hide behind a VPN/jump-host. 90 days: inventory of PLCs with administrative interface; default-deny policy on all admin services; individual passwords (not default), regular rotation
Default passwords and account lockout	WAGO PFC200 — default `admin` password; no description of brute-force protection [1][2]	Even one controller with default credentials in a network can be a trampoline to the entire OT network	30 days: control script (e.g. P0 OSINT + P1 Auth VA on a test copy of the environment) looking for default passwords in OT devices. 90 days: account lockout after N attempts; centralized identity management (RADIUS/TACACS+ or at minimum unique passwords in a password manager)
Siemens S7 controllers and STOP protection	Attackers switched to STOP and set a password, blocking normal operation [1][2]	STOP mode in S7 is a simple destructive vector — even without deep knowledge of the technological process	30 days: verify S7 password policy (so-called "know-how protection" + CPU password) and whether it is enforced. 90 days: process segmentation — one S7 controller should not control the entire process chain; separation of the safety layer from the control layer
Moxa serial-device servers and switches	7 serial-device servers + 3 Moxa switches factory-reset, IP addresses and passwords changed [1]	Serial communication is still common in OT — Moxa devices are often overlooked in audits	30 days: inventory of Moxa devices (e.g. NPort, EDS); verify they have current firmware and no default passwords. 90 days: network segmentation of Moxa devices in a dedicated VLAN; configuration audit
Anti-forensics: erasing evidence	Attackers factory-reset the router (but logs were recovered) and damaged the WAGO partition table so effectively that data could not be recovered [1][2]	After an incident you may have no logs at all — logs must be pulled off-device, ideally with cryptography	30 days: central logging (syslog/SIEM) from key OT devices (routers, PLCs, Moxa, serial servers). 90 days: time synchronization (NTP) and minimum 90-day log retention; write-once (WORM) storage for critical devices
Detectability and reaction time	The first signals were interpreted as "subcontractor's mistake", because maintenance work happened to be in progress [1]	In a real plant, an OT attack will be mistaken for a failure — until you have a behavioral baseline of the process	30 days: an "incident vs failure" escalation procedure that includes the security team (not only maintenance). 90 days: process anomaly monitoring (e.g. sudden STOPs, mass configuration changes) with automated SOC alerting
Private APN and NIS2/KSC — entity obligations	Incident at an essential entity (energy) with direct impact on heat supply continuity	NIS2 art. 21 (risk management, including supply chain and IT-OT) and art. 23 (incident reporting) directly apply — but legal interpretation requires consultation with a law firm	30 days: register private APNs and IoT connectivity providers as critical suppliers; verify they have security requirements in their contracts. 90 days: update connectivity provider risk management policy (NIS2 art. 21(2)(d))

Perspective of inż. Marcin Białczyk

For me the most important thing in this report is not the single exploit on WAGO or Teltonika. It is the signal that a "dedicated network" in an operator contract is not a security barrier — it is a layer of psychological comfort. The attackers found one device with a web interface (an RUTX50 router) that nobody included in the APN security policy, because formally "it is just an IoT router". From that router they SSH-tunneled into the network, found a PLC with a default password, and from there the rest was simple: STOP for S7 controllers, anti-forensics on Moxa and WAGO.

The second layer is "the moment of surprise" — the CHP operators briefly attributed the failure to a subcontractor's mistake. This is a classic effect of having no behavioral baseline of the technological process: when systems run in "everything works" mode, a sudden S7 STOP is interpreted as a failure, not as a security incident. In our operational work (P0/P1/P2 model) I treat this as a separate case: the "incident vs failure" escalation plan must be part of BCP/DR and must involve the security team, not only operations.

The third layer is the connectivity supply chain. A private APN is a service bought from an operator — and like any other critical supplier it should be in the supplier register with security requirements (e.g. per-device segmentation, monitoring, audit). It is not "just a SIM". It is an entry vector.

Frequently asked questions

Is this the first incident of its kind?

According to CERT Polska's public knowledge — yes, this is the first documented case of a private APN being used to reach an OT network during a real-world destructive attack. CERT explicitly writes: "to the best of our knowledge, the first instance of this attack vector being observed in a real-world cyberattack" [1].

Is my company at risk if I am not in energy?

Indirectly yes, if you use a private APN for IoT/OT connectivity (water, gas, retail, logistics, multi-site manufacturing). The same pattern (router with a web interface, password changed but cracked, no security requirements for the admin interface) can exist across many sectors.

What should I do if I have WAGO, Siemens or Moxa controllers in my network?

First: inventory which devices have an active WWW/HTTP/SSH interface and whether they are reachable from a network where other endpoints live. Second: change default passwords, disable services you do not need, hide the admin interface behind a VPN/jump-host.

Does CHORS.NET help assess this risk?

Yes. Within P1 (Authorized Vulnerability Assessment) and P2 (On-site Assessment, including passive evidence support for OT) we help identify exposed administrative interfaces of IoT/OT devices, controllers with default credentials and private APN configurations that fail segmentation. We do not perform active contact with OT/PLC/HMI — this is a global prohibition of our policy. In the NIS2/KSC scope (P3) we help build an Evidence Pack and Control Matrix; we leave legal interpretation to law firms.

How CHORS.NET helps

If you want to check whether your IT-OT infrastructure has similar entry vectors, see our operational services and the NIS2/KSC Readiness Center for regulatory readiness. More about the practitioner behind this analysis: inż. Marcin Białczyk.

Scope and limitations

We are not a 24/7 SOC and we do not guarantee detection of every incident; our monitoring is passive and periodic.
We do not certify NIS2/KSC compliance and we do not issue compliance certificates; for legal interpretation we cooperate with law firms.
We do not perform active contact with OT/PLC/HMI — our P2 service is passive at the evidence layer; active OT testing requires a separate RoE and human approval.
Facts come from the official CERT Polska report (08.08.2026), its English translation and analysis by Zaufana Trzecia Strona; full investigation details (3+ months) are in the complete PDF report.
This material is informational and technical; it is not legal advice.

Precyzyjna wiedza
o ciemnych systemach.