In a disclosure that should alarm every operator of critical infrastructure, attackers breached a small Polish combined heat-and-power (CHP) plant — a facility supplying heat to roughly 50,000 residents — by riding a private APN (Access Point Name) directly into the plant's Operational Technology (OT) network. The intrusion, which occurred last year and was publicly reported this week, is a textbook demonstration of a failure mode I've seen repeatedly in OT assessments: cellular connectivity provisioned for vendor maintenance or telemetry that quietly becomes an unmanaged, unmonitored backdoor into the control environment.
This was not a zero-day. No exotic exploit chain was required. The attackers leveraged a legitimate remote access mechanism — a private APN provisioned over a mobile carrier network — that bypassed the plant's perimeter defenses entirely because it never traversed them. For defenders, the lesson is stark: if you can't inventory it, you can't defend it, and cellular modems attached to OT assets are among the least-inventoried devices in industrial environments.
This post breaks down the attack path, explains why private APNs are a growing intrusion vector into ICS/OT environments, and provides concrete detection logic, hunt queries, and hardening steps you can apply immediately.
Technical Analysis
What a Private APN Is — and Why Attackers Love It
An APN defines the network path a cellular device uses to connect to packet data services. A private APN is a carrier-provisioned, logically segregated network that routes a subscriber's SIM-equipped devices into a dedicated IP space — often directly integrated with the customer's corporate or OT network via MPLS, IPsec, or direct carrier peering. Utilities and industrial operators commonly use private APNs for:
- Remote telemetry from RTUs, PLCs, and metering equipment
- Vendor maintenance access to remote or unmanned sites
- Backup WAN connectivity for substations and plants
The security problem is structural. Private APN traffic never crosses the enterprise firewall, IDS, or web proxy stack. It enters the OT network through a cellular router or gateway — frequently a device installed by a third-party integrator, managed by the carrier, and forgotten by the security team. If the APN relies on weak authentication (SIM possession only, default router credentials, no mutual TLS), anyone who obtains or clones SIM credentials, compromises the carrier-side integration, or gains access to the APN management plane can route straight into OT.
The Attack Chain in the Polish Incident
Based on the reporting around this breach, the intrusion path followed a pattern consistent with cellular remote-access abuse:
- Initial access via the private APN — The attackers gained connectivity to the APN serving the plant's OT environment, whether through compromised SIM/credentials, a carrier integration weakness, or an exposed cellular gateway.
- Direct OT network presence — Because the APN terminated inside or adjacent to the control network, the attackers landed on OT segments without crossing any monitored perimeter control.
- Access to operational systems — The plant's heat-and-power control environment — supporting heat delivery to ~50,000 residents — was exposed to an actor with network-level access to industrial devices.
The defensive takeaway: the "perimeter" for this plant included a carrier network segment that almost certainly had no IDS coverage, no NetFlow collection, no asset inventory, and no SOC visibility. Traditional detections tuned to north-south traffic at the IT/OT boundary (e.g., Purdue Level 3.5 DMZ monitoring) would see nothing.
Exploitation Status
This is a confirmed real-world intrusion, not a theoretical attack path. No CVE is associated with the breach — it is an architectural and credential/access-control failure, which makes it harder to patch and more dependent on detection and segmentation discipline. Similar cellular-borne access paths have been documented in water, energy, and pipeline incidents over the past several years, and adversaries targeting European energy infrastructure amid the ongoing geopolitical conflict have strong incentive to exploit exactly these paths.
Detection & Response
The core detection philosophy: you cannot monitor the carrier's network, but you can monitor everything on your side of the cellular gateway — the WWAN interfaces, the cellular router's management plane, authentication into OT assets from unexpected source ranges, and any process or interface state that indicates a cellular path is active on a host that shouldn't have one.
Sigma Rules
---
title: Cellular WWAN Interface Activation on OT or Server Host
tid: 3f9c1a7e-2b84-4d51-9c6a-8e7f2a1b4c90
status: experimental
description: Detects use of rasdial or network shell commands to establish or query cellular/PPP dial-up connections on hosts, which may indicate an unauthorized cellular path into an OT network segment as seen in the Polish energy plant intrusion.
references:
- https://www.bleepingcomputer.com/news/security/hackers-breached-a-small-polish-energy-plant-via-private-apn-last-year/
- https://attack.mitre.org/techniques/T1133/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.persistence
- attack.t1133
- attack.command_and_control
logsource:
category: process_creation
product: windows
detection:
selection_rasdial:
Image|endswith:
- '\rasdial.exe'
- '\rasphone.exe'
selection_netsh_wwan:
Image|endswith: '\netsh.exe'
CommandLine|contains:
- 'wwan'
- 'mbn connect'
- 'ras set'
condition: 1 of selection_*
falsepositives:
- Field engineering laptops with legitimate WWAN connectivity
- Legitimate cellular failover administration
level: high
---
title: New Network Interface Configuration via Netsh or PowerShell on OT Host
tid: 8b2d4e61-9f3a-4c72-b5d8-1a6e9c3f7d25
status: experimental
description: Detects modification of network interface or routing configuration that could be used to bridge a cellular/APN connection into an OT segment, a technique consistent with cellular remote-access abuse in ICS environments.
references:
- https://www.bleepingcomputer.com/news/security/hackers-breached-a-small-polish-energy-plant-via-private-apn-last-year/
- https://attack.mitre.org/techniques/T1090/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.command_and_control
- attack.t1090
logsource:
category: process_creation
product: windows
detection:
selection_netsh:
Image|endswith: '\netsh.exe'
CommandLine|contains:
- 'interface set interface'
- 'routing ip nat'
- 'interface ipv4 add route'
- 'interface ipv4 set address'
selection_ps:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
CommandLine|contains:
- 'New-NetIPAddress'
- 'New-NetRoute'
- 'Enable-NetAdapter'
- 'Set-NetConnectionProfile'
condition: 1 of selection_*
falsepositives:
- Network administrators performing documented change work
- Automated provisioning scripts during maintenance windows
level: medium
---
title: Interactive Remote Logon to OT Asset from Non-Baseline Source
tid: c5a1f8d3-6e29-4b87-a3f1-9d2c5e8b4a67
status: experimental
description: Detects RDP or network logons to servers and HMI/engineering workstations from accounts or source addresses outside an approved baseline. Tune the approved source list to your documented jump-host and vendor VPN ranges to catch sessions originating from APN-terminated address space.
references:
- https://www.bleepingcomputer.com/news/security/hackers-breached-a-small-polish-energy-plant-via-private-apn-last-year/
- https://attack.mitre.org/techniques/T1021/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.lateral_movement
- attack.t1021.001
logsource:
product: windows
service: security
detection:
selection_logon:
EventID: 4624
LogonType:
- 3
- 10
filter_approved_sources:
IpAddress|startswith:
- '10.10.20.'
- '192.168.50.'
filter_local:
IpAddress: '-'
condition: selection_logon and not 1 of filter_*
falsepositives:
- New vendor access arrangements not yet added to the baseline
- DHCP renumbering of approved management subnets
level: high
A note on tuning: the third rule's value depends entirely on maintaining an accurate allowlist of approved management source ranges (jump hosts, vendor VPN pools, the OT DMZ). In the Polish scenario, sessions arriving from APN-assigned address space — which would never appear in that baseline — would fire immediately. If you don't have that baseline documented, build it this week; it's the single highest-return detection investment for OT remote access.
KQL (Microsoft Sentinel / Defender)
The following hunt queries assume OT Windows hosts and engineering workstations are onboarded to Defender for Endpoint, and that firewall/syslog from the cellular router or OT boundary is ingested via CEF/Syslog.
// Hunt 1: Interactive logons to OT assets from non-baseline source ranges
// Replace the approved prefix list with your jump-host / vendor VPN / OT DMZ ranges
let ApprovedSources = dynamic(["10.10.20.", "192.168.50."]);
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4624 and LogonType in (3, 10)
| where IpAddress != "-"
| where not (IpAddress has_any (ApprovedSources))
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), LogonCount=count(), DistinctAccounts=dset(Account)
by Computer, IpAddress
| order by LastSeen desc;
// Hunt 2: Cellular/dial-up connection tooling executed on any onboarded host
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where FileName in~ ("rasdial.exe", "rasphone.exe")
or (FileName =~ "netsh.exe" and ProcessCommandLine has_any ("wwan", "mbn connect", "ras set"))
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc;
// Hunt 3: Inbound sessions from cellular/carrier NAT ranges hitting OT assets via CEF firewall logs
// Tune destination zone/device list to your OT segment
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor in ("Fortinet", "Palo Alto Networks", "Cisco", "Check Point", "Juniper") or DeviceProduct has "firewall"
| where DestinationIP startswith "10.50." // OT segment placeholder - replace
| where SourceIP startswith_any ("100.64.", "10.200.", "172.30.") // carrier-grade NAT / APN pools - replace with your carrier ranges
| summarize SessionCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by SessionCount desc;
// Hunt 4: SSH/RDP brute force or anomalous auth against cellular routers from syslog
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_any ("authentication failure", "Failed password", "login failed")
| where Computer has_any ("cell", "gw", "rtu", "modem") // tune to your cellular gateway hostnames
| summarize FailCount=count(), DistinctSources=dset(HostIP) by Computer
| where FailCount > 20
| order by FailCount desc;
Velociraptor VQL
Use this artifact to sweep OT Windows hosts and engineering workstations for evidence of cellular/dial-up connection activity and active remote sessions — valuable both proactively and during an IR sweep when you suspect an APN-borne intrusion.
-- Hunt for cellular/dial-up tooling, active remote sessions, and unexpected listeners on OT hosts
-- Deploy as a multi-artifact collection across the OT Windows fleet
LET dialup_procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)rasdial|rasphone|netsh'
AND CommandLine =~ '(?i)wwan|mbn|ras |dial'
LET remote_conns = SELECT Pid, Name, Path, Connection.LocalIP as LocalIP,
Connection.LocalPort as LocalPort,
Connection.RemoteIP as RemoteIP,
Connection.RemotePort as RemotePort,
Connection.Status as Status
FROM netstat()
WHERE (LocalPort in (22, 3389, 5900, 502, 44818) AND Status =~ 'LISTEN')
OR (RemotePort in (3389, 22) AND Status =~ 'ESTAB')
SELECT * FROM dialup_procs
UNION ALL
SELECT * FROM remote_conns
Remediation / Audit Script
The following Bash script audits Linux-based OT gateways, cellular routers running embedded Linux, and engineering stations for active WWAN interfaces, unexpected PPP devices, ModemManager state, and listener exposure. Run it via your configuration management tooling or manually during the inventory exercise described in the Remediation section.
#!/bin/bash
# audit_cellular_paths.sh - Audit for cellular/WWAN interfaces and remote-access
# exposure on Linux OT gateways and engineering hosts.
# Run as root. Review output; do NOT auto-remediate on production OT systems.
OUT="/var/log/cellular_audit_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a "$OUT") 2>&1
echo "=== [1] WWAN / PPP interfaces present ==="
ip -brief link | grep -Ei 'wwan|ppp|usb[0-9]|cdc' || echo "None found"
echo "=== [2] ModemManager detected modems ==="
if command -v mmcli >/dev/null 2>&1; then
mmcli -L
else
echo "mmcli not installed"
fi
echo "=== [3] Active PPP / dial-up processes ==="
ps aux | grep -E '[p]ppd|[w]vdial|[q]micli|[m]bimcli' || echo "None found"
echo "=== [4] Listening services exposed on all interfaces ==="
ss -tulnp | grep -E ':(22|23|80|443|502|3389|5900|44818|20000)\b' || echo "No high-risk listeners"
echo "=== [5] Routes via cellular interfaces (possible APN termination) ==="
ip route show | grep -Ei 'wwan|ppp' || echo "No cellular routes"
echo "=== [6] Recent SSH auth failures (possible brute force on gateway) ==="
journalctl -u ssh --since "7 days ago" 2>/dev/null | grep -c "Failed password" || echo "0"
echo "=== [7] Crontab/systemd persistence referencing modem bring-up ==="
grep -rEi 'pppd|wvdial|mmcli|qmi' /etc/cron* /etc/systemd/system/ 2>/dev/null || echo "None found"
echo "=== Audit complete: $OUT ==="
Remediation
There is no patch for an architectural blind spot. Closing this class of exposure requires an inventory-and-control program, executed in order:
1. Build a complete cellular inventory (this week). Identify every SIM-equipped device, cellular router, and private APN contract touching your environment. Pull records from your carrier(s), procurement, and OT integrators — do not rely on network scanning alone, since cellular gateways may be inactive until a failover event. Every device found gets an owner, a documented business purpose, and a risk decision: keep, replace, or decommission.
2. Terminate APN traffic outside the OT zone — never inside it. Private APN sessions must land on a hardened DMZ or OT access broker, not directly on control segments. Enforce mutual authentication (certificates, not SIM possession alone), IPsec or TLS from the gateway to a concentrator you control, and default-deny ACLs permitting only the specific flows the use case requires. Work with your carrier to disable APN features you don't use (device-to-device communication within the APN is a common default that enables lateral movement between field sites).
3. Instrument the ingress point. Since you cannot monitor the carrier side, log everything at your termination point: full NetFlow/packet metadata from the APN concentrator, authentication logs from the cellular router, and session records from any jump host or remote access broker downstream. Forward it all to the SIEM and baseline it — the KQL Hunt 3 above is your starting point. An APN path with no logging is an APN path you must assume is compromised.
4. Enforce least-privilege remote access for OT. Vendor and maintenance access through cellular paths should require MFA where feasible, time-bound approval, session recording, and jump-host brokering — never persistent direct connectivity to PLCs, RTUs, or HMIs. Align this with IEC 62443 zone-and-conduit requirements and NIST CSF 2.0's identity and access controls.
5. Test the path before an adversary does. Commission an adversary-emulation exercise that specifically includes cellular remote access as an initial-access vector. Most OT penetration tests scope out the carrier path entirely — which is precisely why attackers use it. Include SIM credential compromise and rogue-gateway scenarios in your next tabletop and technical assessment.
6. Plan for the hostile scenario. Given that this intrusion targeted heat delivery to 50,000 residents during a period of sustained attacks on European energy infrastructure, ensure your IR runbooks cover OT containment: safe operational states, manual fallback procedures for heat/power delivery, carrier emergency contacts for SIM revocation, and pre-coordinated communications with national CERTs (CERT Polska published guidance relevant to this incident — see the source reporting at BleepingComputer).
The Polish plant breach is a warning shot, not an anomaly. Any utility, manufacturer, or facility operator with a cellular path into OT that isn't inventoried, segmented, and monitored is running the same exposure — and the adversaries targeting energy infrastructure already know it.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.