Back to Intelligence

Polish CHP Plant Breach via Private Cellular Network: OT Defense, Detection, and Remediation Guide

SA
Security Arsenal Team
August 12, 2026
14 min read

Attackers breached a Polish combined heat and power (CHP) plant — one supplying heat to roughly 50,000 residents — by traversing the private cellular network the local grid operator uses to reach remote equipment. Once inside, they shut down a steam turbine and disabled the process-water treatment system. Recovery operations began at approximately 7:30 a.m. while the intruders were still active inside the network — a detail that should make every incident responder pause. Customers ultimately lost neither heat nor power, but that outcome was driven by operator response, not by the strength of the perimeter. The perimeter failed.

This incident matters far beyond Poland. Private LTE/5G networks and cellular-based remote access have become the default connectivity model for distributed energy resources, substations, water facilities, and remote terminal units (RTUs) across Europe and North America. The assumption baked into most of these deployments — "it's a private APN, so it's trusted" — is exactly the assumption this intrusion just killed. If you operate, integrate, or defend any environment where cellular modems bridge external networks to control systems, treat this as a direct warning shot against your architecture.


Technical Analysis

The Attack Surface: Private Cellular as an OT Backdoor

The defining characteristic of this intrusion is the ingress vector. Grid operators commonly deploy cellular connectivity (private APNs over carrier LTE, or increasingly dedicated private LTE/5G) to reach geographically dispersed assets: substations, CHP plants, DER sites, pumping stations. The typical architecture looks like this:

  1. Industrial cellular gateway/router (e.g., Sierra Wireless, Teltonika, Cradlepoint, Advantech, Moxa-class devices) sits at the remote site with a SIM provisioned on the operator's private APN.
  2. That gateway bridges the cellular WAN to the local OT LAN — PLCs, RTUs, protection relays, turbine controllers, and often the engineering workstation.
  3. Back at the central side, a concentrator or VPN headend aggregates hundreds or thousands of these remote connections into the SCADA master / control center.

The fatal design pattern in most deployments is flat trust: anything that arrives over the private cellular network is treated as internal, trusted traffic. There is frequently no firewall between the cellular gateway and the control LAN, no per-device authentication beyond the SIM itself, and no monitoring of what flows across that link. Compromise the cellular core, an APN peer, a misconfigured gateway, a SIM provisioning portal, or any other site sharing the APN — and you inherit trusted L2/L3 reachability into every control network on that network.

What the Attackers Reached

Based on what was taken offline, the intruders achieved access to — at minimum:

  • Steam turbine control layer: Issuing a turbine trip/shutdown implies interaction with the turbine control system (TCS) or the distributed control system (DCS) governing it. This is not casual access; it requires either valid protocol access (IEC 61850, Modbus/TCP, DNP3, or vendor-proprietary protocols) or control of an HMI/engineering workstation.
  • Process-water treatment system: Chemical dosing, demineralization, and condensate polishing systems are typically PLC-controlled and reachable from the same OT LAN. Taking this down alongside the turbine suggests the attackers had broad lateral reach within the control network, not a single-device foothold.

Critically, the attackers remained active in the network during recovery operations. That is a scenario every OT IR plan must account for: restoring operations on a hostile network. Bringing a turbine back online while an adversary retains control-layer access risks repeated trips, unsafe operating states, and physical equipment damage (overspeed, thermal stress, water chemistry excursions damaging boiler tubes).

Exploitation Status

  • Confirmed active exploitation in the wild against operational critical infrastructure.
  • No CVE has been publicly associated with this incident at the time of writing — this is an architectural and access-path compromise, not (based on current reporting) a single patched product flaw. Do not wait for a CVE to act.
  • No CISA KEV entry exists for this campaign; however, CISA and ENISA have repeatedly warned about cellular/remote-access pathways into OT environments.

Why This Pattern Is Spreading

Since 2024 and accelerating through 2025–2026, we've seen sustained targeting of European energy infrastructure linked to the broader geopolitical conflict environment, including Sandworm-associated activity against Ukrainian and allied-nation energy sectors. Whether or not attribution lands on a state actor here, the technique is now proven and replicable: private cellular/remote-access networks are the soft underbelly of distributed OT. Expect copycat intrusion attempts against water, district heating, and mid-tier energy operators that assumed "private" meant "protected."


Detection & Response

Sigma Rules

The following rules target observable behaviors associated with this intrusion pattern: unauthorized remote access tooling on OT hosts, suspicious interactive sessions on HMI/engineering workstations, and service manipulation consistent with disrupting control processes. They assume you are collecting endpoint telemetry from Windows-based HMI/engineering workstations and forwarding OT firewall/EDR logs — if you aren't, that gap is your first remediation item.

YAML
---
title: Remote Access Tool Execution on OT HMI or Engineering Workstation
id: 3f7a2c91-4d8e-4b1a-9c5f-2e6d8a1b4c7d
status: experimental
description: Detects execution of common remote access tools on hosts identified as OT HMI or engineering workstations. Attackers who reach OT via cellular or remote-access networks frequently deploy RMM tooling to persist and operate interactively, as seen in the Polish CHP plant intrusion.
references:
  - https://attack.mitre.org/techniques/T1219/
  - https://thehackernews.com/2026/08/hackers-breach-polish-power-plant.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.command_and_control
  - attack.t1219
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\anydesk.exe'
      - '\teamviewer.exe'
      - '\teamviewer_service.exe'
      - '\screenconnect.exe'
      - '\rustdesk.exe'
      - '\ammyy.exe'
      - '\ngrok.exe'
      - '\tightvnc.exe'
      - '\ultravnc.exe'
      - '\splashtop.exe'
  filter_approved_paths:
    Image|startswith:
      - 'C:\Program Files\TeamViewer\'
      - 'C:\Program Files (x86)\TeamViewer\'
  condition: selection_img and not filter_approved_paths
falsepositives:
  - Approved vendor remote maintenance sessions (restrict by approved install path and maintenance window)
  - Legitimate RMM deployed by the integrator — inventory it, then alert on everything else
level: high
---
title: Suspicious Service Stop or Disable Targeting Control and Monitoring Processes
id: 8b1e4d62-7c3f-4a29-b8e1-5f9d2c6a3e8b
status: experimental
description: Detects command-line attempts to stop, disable, or kill services and processes consistent with disruption of control-system software, historians, or water treatment processes. The Polish CHP attackers shut down a turbine and process-water treatment — disruption at the host level often precedes or accompanies control-layer manipulation.
references:
  - https://attack.mitre.org/techniques/T1489/
  - https://attack.mitre.org/techniques/T1562/001/
  - https://thehackernews.com/2026/08/hackers-breach-polish-power-plant.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.impact
  - attack.t1489
  - attack.t1562.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\sc.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\taskkill.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'stop '
      - 'disable'
      - 'taskkill /f'
      - 'Stop-Service'
      - 'Stop-Process'
  filter_ops_tools:
    CommandLine|contains:
      - 'spooler'
      - 'windows update'
      - 'wuauserv'
  condition: selection and not filter_ops_tools
falsepositives:
  - Maintenance-window service restarts by automation tools (SCCM, Ansible, patching systems)
  - Tune with a list of authorized administrative accounts and jump hosts
level: high
---
title: Interactive Logon to OT Workstation Outside Maintenance Window
id: 5c9d3f17-2a8b-4e61-a7c3-9d1f4b8e2a6c
status: experimental
description: Detects interactive or remote interactive logons (Type 2, 10) on OT HMI/engineering workstation hosts by accounts other than authorized operator and maintenance service accounts. Intruders who persist inside the network during recovery operations — as in the Polish CHP incident — will generate interactive session artifacts.
references:
  - https://attack.mitre.org/techniques/T1078/
  - https://attack.mitre.org/techniques/T1021/001/
  - https://thehackernews.com/2026/08/hackers-breach-polish-power-plant.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.initial_access
  - attack.t1078
  - attack.lateral_movement
logsource:
  category: authentication
  product: windows
detection:
  selection:
    LogonType:
      - 2
      - 10
  filter_authorized_users:
    UserName|endswith:
      - '$'
      - 'svc_scada'
      - 'svc_hmi_operator'
  filter_authorized_sources:
    IpAddress|startswith:
      - '10.10.5.'   # Replace with your jump host / operations VLAN range
  condition: selection and not filter_authorized_users and not filter_authorized_sources
falsepositives:
  - New integrator field technicians not yet in the authorized account list
  - Emergency operations — investigate, then update allowlists
level: high

Tuning note: The authorized-account and authorized-source filters in rule three are the difference between a high-fidelity alert and noise that gets disabled. Build those lists from your actual operations roster and jump-host infrastructure before deploying.

KQL — Microsoft Sentinel / Defender Hunt

This hunt targets the network layer: unexpected inbound sessions from cellular gateway address space to OT assets, and control-protocol traffic outside baseline. It assumes you are ingesting OT firewall or industrial DPI sensor logs via CEF/Syslog into Sentinel (the CommonSecurityLog/Syslog tables) and have Defender or EDR coverage on HMI hosts.

KQL — Microsoft Sentinel / Defender
// Hunt: Anomalous sessions originating from private cellular/remote-access segments into OT assets
// Tune the source ranges to your cellular APN gateway subnets and the destination ports to your control protocols.
let CellularGwSubnets = dynamic(["10.60.0.0/16", "100.64.0.0/10"]); // REPLACE with your private APN / LTE gateway ranges
let OtAssetSubnets = dynamic(["10.20.0.0/16"]);                       // REPLACE with your OT control LAN ranges
let ControlPorts = dynamic([502, 20000, 102, 44818, 47808, 2404]);    // Modbus, DNP3, S7, EtherNet/IP, BACnet, IEC-104
let Lookback = 7d;
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where ipv4_is_in_any_range(SourceIP, CellularGwSubnets)
| where ipv4_is_in_any_range(DestinationIP, OtAssetSubnets)
| summarize SessionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            Ports = make_set(DestinationPort), Protocols = make_set(ApplicationProtocol)
    by SourceIP, DestinationIP, DeviceAction
| where array_length(Ports) > 3 or Ports has_any (ControlPorts)
| project FirstSeen, LastSeen, SourceIP, DestinationIP, SessionCount, Ports, Protocols, DeviceAction
| order by SessionCount desc;

// Correlation: new processes spawned on HMI/OT hosts within 10 minutes of an inbound remote session
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where RemotePort in (3389, 5900, 22, 5938) // RDP, VNC, SSH, TeamViewer
| summarize by DeviceName, RemoteIP, bin(TimeGenerated, 10m)
| join kind=inner (
    DeviceProcessEvents
    | where TimeGenerated > ago(Lookback)
    | where InitiatingProcessFileName in~ ("rdpclip.exe", "explorer.exe", "svchost.exe", "winlogon.exe")
    | where FileName !in~ ("conhost.exe", "dwm.exe", "sihost.exe", "taskhostw.exe")
    | summarize by DeviceName, FileName, ProcessCommandLine, bin(TimeGenerated, 10m)
) on DeviceName, TimeGenerated
| project DeviceName, RemoteIP, FileName, ProcessCommandLine, TimeGenerated;

Deploy the first query as a scheduled analytic rule with entity mapping on SourceIP — a single cellular gateway that suddenly fans out to many OT destinations or speaks control protocols it never previously used is your earliest-warning indicator of this exact attack pattern.

Velociraptor VQL Hunt

For endpoint forensics on HMI/engineering workstations, hunt for unauthorized remote access tooling and recently-created executables outside sanctioned install paths:

VQL — Velociraptor
-- Hunt: Unauthorized remote access tools and recently dropped executables on OT Windows hosts
-- Scope this to your HMI / engineering workstation collections.
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime,
       timestamp(epoch=CreateTime) AS ProcessStartUTC
FROM pslist()
WHERE Exe =~ '(?i)(anydesk|teamviewer|screenconnect|rustdesk|ammyy|ngrok|vnc|splashtop|logmein)'
   OR CommandLine =~ '(?i)(anydesk|teamviewer|rustdesk|screenconnect)'

-- Companion artifact: executables created in user-writable paths in the last 14 days
SELECT FullPath, Size, Mtime, Created
FROM glob(globs=[
  'C:/Users/*/AppData/**/*.exe',
  'C:/ProgramData/**/*.exe',
  'C:/Windows/Temp/**/*.exe'
])
WHERE Created > now() - (14 * 24 * 60 * 60)
  AND FullPath !~ '(?i)(Microsoft|Google|Mozilla|TeamViewer\\\\Update)'
ORDER BY Created DESC

Any hit on the first query in an OT collection is a paging event, full stop. On the second query, validate hits against your approved software manifest — OT hosts should have near-zero executable churn, which makes this hunt high-signal in that environment even though it would be noise on corporate endpoints.

Containment Script — Harden the Remote Access Path

This Bash script audits and hardens a Linux-based industrial cellular gateway (the typical OT edge device) and verifies that the OT LAN is not broadly reachable. Adapt paths/commands to your gateway vendor's CLI where applicable.

Bash / Shell
#!/bin/bash
# Security Arsenal - Cellular Gateway / OT Edge Hardening Audit
# Run on each remote-site gateway or via your fleet management tooling.
set -euo pipefail

echo "=== [1] Identify listening services on the gateway ==="
# Any unexpected listener (telnet, unauthenticated web UI, dropbear on WAN) is a finding
ss -tulpen | awk 'NR==1 || /LISTEN/'

echo "=== [2] Verify WAN-side management interfaces are DISABLED ==="
# Flag any management service bound to 0.0.0.0 or the cellular/WAN interface
ss -tulpen | grep -E ':(23|80|443|8080|7547)\b' && \
  echo "[!] FINDING: Management service exposed - restrict to LAN or disable" || \
  echo "[OK] No obvious management listeners"

echo "=== [3] Audit firewall rules between cellular WAN and OT LAN ==="
# The default policy toward the OT LAN must be DENY with explicit allow rules only
iptables -L FORWARD -n -v --line-numbers
iptables -P FORWARD | grep -q DROP && echo "[OK] FORWARD default DROP" || \
  echo "[!] FINDING: FORWARD default policy is not DROP"

echo "=== [4] Check for unexpected established sessions FROM WAN side ==="
# Long-lived or unexpected sessions inbound from the carrier/APN core are anomalous
conntrack -L 2>/dev/null | grep ESTABLISHED | grep -v "dport=1194" || \
  echo "[OK] No unexpected established sessions (adjust VPN dport filter to yours)"

echo "=== [5] Verify SIM/IPsec or WireGuard tunnel is the ONLY permitted ingress ==="
# Confirm no plaintext management paths bypass the VPN concentrator
ipsec status 2>/dev/null || wg show 2>/dev/null || \
  echo "[!] FINDING: No IPsec/WireGuard tunnel detected on this gateway"

echo "=== [6] Check for non-standard local accounts and SSH keys ==="
awk -F: '$3 >= 1000 && $7 !~ /nologin|false/ {print $1}' /etc/passwd
find /home /root -name authorized_keys -exec ls -la {} \; 2>/dev/null

echo "=== [7] Firmware/version check ==="
cat /etc/os-release 2>/dev/null | head -3
uname -a
echo "=== Audit complete. Forward output to the SOC for review. ==="

Remediation

There is no patch for this incident because there is no single product flaw — the fix is architectural. Prioritize in this order:

Immediate (24–72 hours)

  1. Inventory every cellular-connected remote site. You cannot defend what you haven't mapped. Enumerate gateways, SIMs, APN assignments, and which OT assets sit behind each gateway.
  2. Deny-by-default between cellular WAN and OT LAN. If your industrial gateways forward all traffic from the cellular network to the control LAN, insert explicit firewall policy: only the SCADA master's IPs, only required control-protocol ports, nothing else. Management interfaces must never be reachable from the WAN side.
  3. Hunt for persistence now. Run the Sigma/KQL/VQL content above. Assume, as in this incident, that an intruder who got in may still be there. Check for unauthorized RMM tools, rogue accounts on gateways and HMI hosts, and new authorized_keys files.
  4. Rotate credentials and certificates on cellular gateways, VPN concentrators, engineering workstations, and any account that has authenticated across the remote-access network in the last 90 days.

Short-term (2–6 weeks)

  1. Deploy monitoring on the cellular-to-OT boundary. Mirror gateway traffic to an industrial DPI sensor (Dragos, Nozomi, Claroty-class) or at minimum a Zeek/Suricata sensor with ICS protocol dissectors (Modbus, DNP3, S7, IEC-104). Baseline which sites talk which protocols; alert on deviation.
  2. Enforce mutual authentication on remote access. Replace "SIM = identity" with device certificates, IPsec/WireGuard with strong mutual auth, and MFA on any interactive path into OT. A SIM provisioned on a private APN is an address, not an identity.
  3. Segment the OT LAN internally. The attackers hit both the turbine and the water treatment system — flat OT networks let one foothold become multi-system impact. Put the TCS/DCS, water treatment PLCs, and historian into separate zones with conduits between them per IEC 62443.

Strategic (90 days+)

  1. Exercise the "recovery under active intrusion" scenario. Your IR plan almost certainly assumes a clean environment for restoration. This incident proves otherwise. Tabletop the decision tree: do you rebuild from known-good backups before re-energizing? How do you verify control-integrity of PLC logic and setpoints before returning a turbine to service? Who has authority to delay recovery while adversary eviction is incomplete?
  2. Contract and carrier review. If a grid operator or third party owns the cellular network that reaches your equipment, you need contractual visibility into their security monitoring, SIM provisioning controls, and breach notification SLAs. Their compromise is your compromise.
  3. Adopt IEC 62443 / NIST CSF 2.0 zoning as the target architecture, and map your cellular remote-access design against CISA's guidance on securing remote access to OT. Private APNs are a transport mechanism, not a security control.

The Operator's Bottom Line

Fifty thousand residents kept their heat because plant operators responded well, not because the architecture held. The intruders were inside during recovery — that's the part of this story you should carry into your next architecture review. Any path that lets a remote network touch your control layer is part of your attack surface, no matter how "private" the carrier tells you it is. Monitor it, authenticate it, segment it, and assume it's already being probed.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.