In Polen leidde een cyberaanval op een warmtekrachtcentrale tot het uitschakelen van een stoomturbine en het proces-waterbehandelingssysteem. Wat dit incident extra schrijnend maakt, is de route: de aanvallers bereikten de industriële besturing via een Private APN (een apart cellulair datanetwerk) dat de netbeheerder gebruikt om remote apparatuur te bereiken.
CERT Polska deelde de details op 8 augustus, na een onderzoek dat meer dan drie maanden duurde. Hoewel de schade groot leek, vielen de gevolgen voor de omgeving mee: volgens de rapportage verloren klanten geen warmte of elektriciteit, en de centrale begon rond 7:30 ’s ochtends met herstel terwijl de indringers nog actief waren in het netwerk.
Wat er gebeurde bij de Poolse warmtekrachtcentrale
De centrale levert warmte aan ongeveer 50.000 inwoners. De destructieve acties speelden zich af in een tijdvak dat later werd vastgesteld: de aanvaller(s) waren ongeveer van 5:30 tot 10:10 uur actief in het OT-netwerk, met herstel startend rond 7:30. Binnen die periode kwamen besturingscomponenten in een stopstand terecht en werd de processtroom onderbroken.
Volgens de betrokken partijen werden meerdere controllerfamilies voor besturing geraakt. Daarbij ging het om systemen die via gangbare industriële protocollen communiceren, en de rapportage benadrukt dat de stappen leunden op normale, ondersteunde functies van de aanwezige apparatuur.
De sleutelrol van Private APN in de aanval
Het incident liep niet alleen via “een internetverbinding” of een klassiek extern VPN-pad. De doorslaggevende factor was een Private APN die werd beheerd door de distributiesysteemoperator. Met dat APN kon de netbeheerder remote apparatuur bereiken, maar de configuratie liet ook toe dat willekeurige apparaten binnen dat APN met elkaar communiceerden.
Door die instelwijze konden aanvallers pivoten: vanuit een gecompromitteerd netwerksegment van een windpark konden ze overstappen naar een controlleromgeving bij de warmtekrachtcentrale. CERT Polska noemt dit, voor zover bekend, de eerste observatie van deze specifieke aanvalsvector in een echte cyberaanval.
Waarom er geen “één patch” was
Onderzoekers konden niet vaststellen welke specifieke kwetsbaarheid aan de basis stond van de initiële toegang. Er werd geen CVE als eenduidige oorzaak vastgesteld en er kon niet worden bepaald of een kwetsbaarheid in een Teltonika-router daadwerkelijk werd misbruikt. Dat betekent in de praktijk: geen simpele “patch en klaar”-oplossing, maar vooral hardening, segmentatie en accountbeheer.
De rapportage vermeldt dat de industriële controller die via het Private APN bereikbaar was (een WAGO-controller) nog default beheerdersreferenties accepteerde. Tegelijkertijd was het Private APN ingesteld op client-to-client verkeer, wat laterale beweging vergemakkelijkte.
Concreet: van scanning naar beheerinterface naar OT
De onderzoekers beschrijven een verloop waarin de aanvaller(s) eerst toegang bleken te krijgen tot het APN-landschap en daarna gericht zochten naar beheerdersinterfaces. Vanaf 18 december werd het Private APN gescand en werd een WAGO PFC200-controller gevonden die zijn webbeheerinterface blootstelde met default admin credentials.
Daarna suggereert het patroon van SSH-activiteit dat de aanvaller(s) die beheerinterface mogelijk inschakelden en vervolgens via de WAGO-toegang de route naar het OT-netwerk vervolgden. Vervolgens werd ook verkenning uitgevoerd richting Siemens PLC’s via het S7-protocol. CERT ziet die fase als voorbereidende reconnaissance voor de latere, verstorende handelingen.
Wat de onderzoekers opmerkten over apparaat- en netwerkconfiguratie
Een belangrijk punt is dat de aanwezigheid van goed functionerende industriële protocollen niet betekent dat het beheerweggetje veilig is. De vereiste datacommunicatie voor een remote terminal unit moest via DNP3.0 lopen. Dat onderdeel klopte, maar er golden geen vergelijkbare eisen voor de managementinterface van de cellulair verbonden router.
In de beschrijving zat de managementinterface op een tweede netwerkpoort, gekoppeld aan een VLAN dat via de Ethernet-infrastructuur achter een gecompromitteerde firewall liep. Met andere woorden: de route voor data was functioneel, maar de beheerroute liet ruimte voor misbruik.
Verder stelde CERT dat organisaties in Polen die Private APN’s inzetten vaak een permissieve configuratie hanteren: elk apparaat kan elk ander apparaat bereiken. Als aanvallers binnen die permissieve “vriendelijke” zone komen, groeit de impact.
Wat maakte de aanval destructief?
De destructieve handelingen in het OT-gedeelte leunden niet op het plaatsen van malware, zo meldt de rapportage. De aanvaller(s) maakten gebruik van bestaande mogelijkheden binnen de gebruikte componenten en protocollen.
Zo werden controllers in stopmodus gezet en werden aanvullende onderdelen in een fabrieksreset-achtige toestand gebracht. De tijdsvolgorde wijst er volgens CERT op dat dit geautomatiseerd verliep. Op apparaatniveau werden onder meer switches en seriële device servers omgezet met gewijzigde wachtwoorden en onbereikbare IP-adressen (waaronder het bekende 127.0.0.1 om ze effectief “weg te zetten”).
Ook aan de zijde van de toegang tot de “binnenkomende route” werd ingegrepen: de WAGO-controller bleek later niet meer te kunnen opstarten door corrupte partitiegegevens, waardoor bruikbare logging achterbleef. Vervolgens factory-resette de aanvaller ook de Teltonika-router en resette men de FortiGate, met als gevolg dat logs verloren gingen.
Lessen voor OT-organisaties: Private APN hardening
CERT Polska doet een reeks aanbevelingen die vooral draaien om het beperken van de aanvalsvlakken rond cellulaire toegang tot OT. Hieronder staan de meest relevante maatregelen uit het rapport in logische volgorde.
1) Audit de Private APN-configuratie
Begin met het controleren of client-to-client verkeer echt nodig is. CERT raadt aan om client isolation aan te zetten zodat apparaten binnen het Private APN elkaar niet zomaar kunnen benaderen.
2) Behandel het APN als niet-vertrouwd
De kernles is dat een Private APN niet automatisch “veilig” is. CERT adviseert om het APN vanaf de OT-kant te behandelen als een onbetrouwde zone, met strikte segmentatie en beperkingen op verkeer.
3) Beperk en verwijder managementtoegang
Daarnaast is het advies om verkeer en beheerfuncties te beperken: verwijder onnodige beheerdiensten van interfaces die via het APN bereikbaar zijn. Daarmee verklein je de kans dat een indringer met één extra stap direct bij beheer terechtkomt.
4) Pak default credentials aan
Omdat in dit incident een controllerbeheerinterface met default admin-credentials bereikbaar was, is wachtwoordhygiëne cruciaal. CERT benoemt ook het aanpassen van standaardaccounts en het verwijderen van situaties waarin apparatuur “out-of-the-box” nog met bekende gegevens te beheren is.
Extra waarschuwing: de eerste stap zat niet per se in een CVE
De rapportage benadrukt dat de oorzaak niet met één bekende kwetsbaarheid te herleiden was. Dat is een belangrijke boodschap voor beveiligings- en OT-teams: ook wanneer er geen directe CVE-patch is, kun je door configuratiefouten en accountbeheer wél degelijk ernstig risico lopen.
Als je denkt aan vergelijkbare uitdagingen tussen AI en operationele omgevingen, dan zie je hetzelfde patroon: het grootste gevaar zit vaak in hoe systemen onderling praten en hoe toegang wordt ingericht. Over dat bredere spanningsveld kun je ook lezen in onze artikelen over AI-aanvallen, Metabase 0-day en backdoors, waar de nadruk ligt op toegangspaden en verborgen mogelijkheden in systemen.
Praktische checklist om de route te breken
Om de kans op laterale beweging via Private APN te verkleinen, kun je de onderstaande checklist gebruiken als startpunt voor een technische review.
- Segmentatie: scheid OT-systemen strikt van elke zone waar een indringer (mogelijk) toegang kan krijgen.
- Client isolation: zet client-to-client verkeer binnen het APN uit waar dat niet strikt noodzakelijk is.
- Toegangsbeheer: beperk managementinterfaces; laat alleen noodzakelijke beheerprotocollen toe.
- Accounthygiëne: vervang default credentials en controleer administratieve rechten op alle relevante apparaten.
- Monitoring: let op scanning- en tunneling-patronen; koppel logging aan detectieprocedures voor vroege signalen.
- Inrichtingsbeleid: behandel Private APN als onbetrouwbaar vanaf de OT-zijde, ook als het door de netbeheerder wordt beheerd.
Conclusie
Het incident bij de Poolse warmtekrachtcentrale laat zien dat een Private APN een reële brug kan vormen tussen “remote bereikbaarheid” en daadwerkelijke OT-impact. De aanval draaide niet om één grote exploit, maar om een combinatie van permissieve netwerkinstellingen, beheertoegang via web/SSH, en default credentials op een controller die via het APN bereikbaar was.
Wie Private APN’s gebruikt om industriële omgevingen te bereiken, doet er goed aan om de configuratie te herzien, client isolation te activeren en managementtoegang vanaf OT-zijde streng te beperken. Zo voorkom je dat een aanvaller die ergens anders binnenkomt, moeiteloos kan doorstappen richting kritieke processen.
Gerelateerd: als je geïnteresseerd bent in hoe aanvallers via beheer- of toegangspaden verder komen binnen industriële of remote omgevingen, bekijk dan ook Private APN-pivot: hackers zetten Poolse energie op stop.
Bron: https://thehackernews.com/2026/08/hackers-breach-polish-power-plant.html
