For more than half a year, the incident stayed out of public view. An attack on a district heating plant supplying roughly 50,000 residents, which took place on 29 December 2025, has only now been described by CERT Polska, in a supplement to its January report on attacks on the energy sector. The analysis took the team more than three months to complete, and the attack vector used, CERT says, had not previously been observed in any known real-world incident against industrial infrastructure.
The attack in numbers
29 December 2025, around 7:00 AM — the attack on the plant’s automation systems begins
~50,000 residents rely on heat from the targeted facility
5:30 AM–10:10 AM — the attacker’s window of activity inside the OT network on the day of the attack
WAGO PFC200 with a built-in cellular modem — the device the attacker operated from
A breakdown that turned out to be an attack
The facility happened to be undergoing maintenance work at the time, so when processes stopped, staff assumed a contractor’s engineers had made an error and reported the event purely for information, without flagging it as a security incident. CERT Polska, however, already aware of similar events elsewhere in the energy sector that same day, opened the case as a suspected attack. Further log analysis confirmed the hypothesis. The team draws a clear lesson from this: operators should report not only confirmed incidents, but also unexplained malfunctions.
Starting point: a gap on the wind farms
To understand this attack, it helps to revisit the campaign CERT Polska described in its report of 30 January 2026, which hit more than 30 grid-connection substations linking renewable installations to the distribution network. At every compromised substation, a Fortigate appliance served as the firewall and VPN concentrator, with its VPN interface reachable from the internet and no multi-factor authentication in place. Gaining administrator access to that device most likely let the attacker retrieve VPN account credentials with access to every subnet on site.
Substations like these also have cellular routers fitted with a SIM card connected to a private APN run by the local distribution system operator (DSO). That private network carries traffic between the DSO’s SCADA system and the site’s RTU controller — and, per DSO requirements, only over a serial link, in this case the DNP3.0 protocol. The catch: DSOs set no requirements for how the router’s own administrative interface should be handled. At the compromised site, the Teltonika RUTX50 router in use did meet the serial-link requirement, but it also had a second, physical Ethernet interface — bridged into a VLAN managed by the central firewall that the attacker had already taken over.
How the attacker reached the heating plant
By default, the router exposes a web panel and an SSH service on its LAN interface. The default password had been changed by the integrator during deployment; CERT could not determine how the attacker obtained the new one, or whether a vulnerability in the Teltonika device was exploited instead. Forensic analysis of the device’s flash memory recovered an event database showing repeated, successful SSH logins throughout December. Cross-referencing those logs with traffic on the APN side, CERT Polska concluded the attacker most likely used SSH tunneling to reach the operator’s private network.
From 18 December onward, the attacker repeatedly scanned the private APN, probing for VNC and HTTP services as well as the industrial protocols S7 and Modbus. That’s how it found a WAGO PFC200 controller with an administrative web panel exposed on its WAN interface, still using default credentials for the “admin” account. SSH isn’t enabled on that interface by default — it was most likely turned on manually, through the web panel. That same controller had access both to SCADA systems and to network segments controlling the plant’s key technological processes, and it was through this device, again via an SSH tunnel, that the attacker crossed into the heating plant’s OT network.
A week of reconnaissance
After breaking into the heating plant’s network, the attacker didn’t move straight to disruption. Between 18 and 25 December, the activity was reconnaissance. On 18 and 21 December, the attacker tried logging into the firewall/VPN gateway’s web panel, using the accounts “admin”, “user”, and a username tied to the company that had implemented telemechanics equipment at renewable sites. Both attempts failed.
On 21 December — a Sunday, eight days before the attack — the attacker turned to scanning the internal network, probing for S7, Modbus, CODESYS and RTSP services, as well as RDP, VNC and web panels. In one subnet, the port scan started specifically from the address of the SCADA host, suggesting the attacker had already identified high-value targets during earlier reconnaissance. The next day, the attacker tried, apparently manually, to guess credentials for two hosts running remote-desktop services, without success. On 25 December, Christmas Day, the attacker connected via the S7 protocol to three Siemens PLCs. CERT Polska could not determine the exact purpose of these sessions, but reconnaissance ahead of the destructive phase is the most likely explanation.
29 December: hours of disruption
The attacker was active inside the heating plant’s network from around 5:30 AM to 10:10 AM — meaning that by the time plant staff started remediation efforts, around 7:30 AM, the attacker was still present. The sequence: a tunnel through the WAGO controller, a connection to the SCADA server’s web panel, then connections via the S7 protocol to the Siemens S7-300, S7-1200 and S7-1500 controllers in turn, interspersed with further access to the SCADA panel.
According to plant staff, the controllers were switched into STOP mode and password-protected in a way that blocked any change to their operating mode or firmware. The result: the steam turbine and the process water treatment station both stopped, interrupting the cogeneration process. Staff quickly restored the devices to factory settings and reloaded their software backups — a step that shortened the outage but also wiped the controllers’ logs. Siemens ProductCERT confirmed to CERT Polska that recovering logs after such a reset is not possible.
Moxa, ABB, Schneider Electric
That same day, the attacker also reconfigured seven Moxa serial device servers and three Moxa network switches — restoring factory settings, changing login passwords, and setting each device’s IP address to an unreachable one (such as 127.0.0.1), which delayed recovery. Based on the timing of HTTP requests sent to each device, CERT assesses this part of the attack was automated — mirroring what was seen on the renewable-energy sites in the January report. The attacker also connected to the web panels of two ABB ACS frequency converters; what was done there could not be determined. Connection attempts against Schneider Electric ATV6xx converters failed, most likely because the attacker tried the standard port 80/TCP while those devices’ web panels listened on a different port — a sign of incomplete reconnaissance.
Covering tracks
The attacker’s last action inside the heating plant’s network — after nearly five hours of activity — was another visit to the SCADA web panel, likely to assess the impact of the attack. After that, the attacker disabled the WAGO controller that had served as the gateway into the network, corrupting its storage partition table. When plant staff tried to repair the device by resetting it to factory settings, the partition table remained broken and the controller would no longer boot; CERT’s lab analysis could not recover any useful data from it.
About thirty minutes after the last activity in the heating plant’s network, the attacker also reset the Teltonika router used for the SSH tunnels to its factory settings, then changed its administrator password and set its IP address to an unreachable one, to slow down any attempt to reconfigure it. Finally, the attacker reset the Fortigate device on the wind farm that had served as the original entry point into the whole chain — on that model and configuration, the reset also wiped its logs.
Impact on consumers
Thanks to a fast response from plant staff, the incident caused only a brief stoppage of the installation. Heat supply to the roughly 50,000 residents served by the plant was not interrupted.
CERT Polska’s recommendations
CERT notes that the misconfiguration underlying this attack — allowing arbitrary connections between devices sharing a private APN — is, based on the team’s own survey of operators, a commonly encountered setup in Poland, and one the team believes is widely used elsewhere in the world too. For organisations running private-APN based solutions, CERT Polska recommends:
- Auditing the private APN’s configuration, including enabling “client isolation” between end devices on the APN; where such communication cannot be avoided, running a risk assessment covering the possibility that a device connected directly to the APN is compromised and used to reach other devices on it.
- Treating the private APN as an untrusted network relative to the OT environment. On the OT side, the APN connection should be segmented and monitored at least to the standard applied to corporate WAN links; where the organisation has no control over, or visibility into, the APN’s configuration and security controls, it should be treated as an external network with a trust level comparable to the public internet.
- Strictly limiting traffic between the OT network and the device acting as the gateway to the private APN, allowing only the connections required for defined business and technical purposes, via allowlist rules.
- Monitoring traffic between the OT network and the private APN, with particular attention to deviations from the expected communication profile.
- Centrally logging and monitoring events from the device serving as the gateway to the private APN, wherever that device supports it.
- Limiting the number of ports open on the interface reachable from the private APN to the necessary minimum, and in particular not exposing administrative services such as a web panel, SSH or Telnet on it.
- Changing default credentials on every service available on the device, especially administrative ones.
- Including private APNs, and the devices that provide access to them, in penetration tests, red-team exercises and security-architecture reviews.
Source: CERT Polska / NASK PIB, “Supplement to the Report on the 29 December 2025 Energy Sector Incident.” CERT Polska published its first report on the coordinated 29 December 2025 attacks on the energy sector on 30 January 2026.
