APN privata: la rete che nessuno sorvegliava e che ha portato l’attaccante dentro una centrale di cogenerazione

CERT Polska ha pubblicato l’8 agosto 2026 il rapporto integrativo sugli attacchi al settore energetico polacco del dicembre 2025. Emerge un secondo impianto colpito, mai reso noto prima, e soprattutto un vettore di accesso alla rete OT che, per quanto risulta al CERT, non era mai stato osservato in un attacco reale: una APN privata, cioè la rete cellulare dedicata che il distributore di energia usa per il telecontrollo dei propri impianti.

Un guasto che non era un guasto

Il 29 dicembre 2025, verso le sette del mattino, i sistemi di controllo industriale di una centrale di cogenerazione che serve circa 50.000 residenti sono stati colpiti. Si sono fermati una turbina a vapore e l’impianto di trattamento delle acque di processo, con conseguente interruzione del ciclo di cogenerazione. La reazione rapida del personale ha contenuto il fermo a un intervallo breve, senza alcuna interruzione della fornitura di calore o di energia elettrica agli utenti finali.

Era in corso un’attività di manutenzione. L’esercente ha quindi ipotizzato in prima battuta un errore degli ingegneri dell’appaltatore e ha segnalato l’evento a titolo puramente informativo. CERT Polska, che in quelle ore stava già trattando altri eventi analoghi nel settore, ha però aperto la gestione dell’incidente muovendo dall’ipotesi di un attacco informatico. L’analisi ha confermato l’ipotesi, e ha ricondotto l’accesso iniziale a un percorso che nessuno stava sorvegliando: una APN privata.

Il punto merita di essere sottolineato, perché è quello che il CERT stesso mette in evidenza: senza una segnalazione trasmessa per un semplice malfunzionamento inspiegato, l’episodio non sarebbe stato ricondotto alla campagna. La cultura della notifica non riguarda soltanto gli incidenti confermati.

L’indagine è durata oltre tre mesi. Per questo l’episodio non compariva nel rapporto iniziale del 30 gennaio 2026, dedicato agli attacchi coordinati contro più di trenta impianti eolici e fotovoltaici, un’azienda privata del settore manifatturiero e una grande centrale di cogenerazione che fornisce calore a quasi mezzo milione di utenti. L’impianto di cui si parla qui è un secondo, più piccolo sito di cogenerazione, colpito in parallelo. Il rapporto integrativo è stato presentato da Marcin Dudek, responsabile di CERT Polska, al DEF CON di Las Vegas, ed è accompagnato da un comunicato ufficiale del team.

L’indagine a ritroso: un PLC come postazione dell’attaccante

L’analisi dei log ha permesso di individuare il dispositivo dal quale l’attaccante aveva operato: un controllore WAGO PFC200 dotato di modem cellulare integrato. Un’anomalia in sé, perché gli attacchi contro reti industriali condotti direttamente a partire da un PLC non rientrano fra gli scenari abitualmente osservati negli ambienti OT.

Il dispositivo, però, era stato danneggiato. Nonostante l’esame forense in laboratorio, che ha richiesto la dissaldatura del chip di memoria, non è stato possibile recuperare alcun dato. L’indagine è quindi proceduta per ipotesi successive, lavorando a ritroso dagli effetti osservati verso il punto di compromissione iniziale.

La prima ipotesi, quella di un’esposizione accidentale del controllore su Internet, è stata scartata analizzando la presenza di dispositivi di quel tipo nello spazio di indirizzamento polacco nel periodo rilevante. È emerso invece che il controllore comunicava con i sistemi di un operatore di distribuzione, il DSO, tramite una SIM attestata su una rete privata di trasmissione dati gestita dallo stesso DSO. Una APN privata, appunto.

Vale la pena anticipare un elemento metodologico, perché torna due volte nella ricostruzione e ha un peso non secondario: alcuni degli anelli della catena non sono stati ricavati dai sistemi delle vittime, ma dai log dell’operatore di rete mobile, correlati con quelli disponibili in centrale. Senza quella collaborazione, buona parte del percorso sarebbe rimasta indimostrabile.

Dal parco eolico all’APN privata: il primo anello

Per capire come l’attaccante sia arrivato lì occorre tornare agli attacchi contro i parchi eolici, che avevano interessato oltre trenta punti di connessione alla rete, cioè i punti in cui un impianto di produzione rinnovabile si collega alla rete di distribuzione e al suo operatore.

Ogni sottostazione compromessa ospitava un dispositivo FortiGate con funzione di concentratore VPN e firewall. In tutti i casi l’interfaccia VPN era raggiungibile da Internet e consentiva l’autenticazione con account definiti localmente nella configurazione del dispositivo, senza autenticazione a più fattori. Pur in presenza di segmentazione in VLAN, l’attaccante disponeva di privilegi amministrativi sul dispositivo, verosimilmente usati per ottenere le credenziali di un account VPN con visibilità su tutti i segmenti.

Le sottostazioni impiegano inoltre router cellulari come canale di comunicazione di riserva o, in alcuni casi, primario. Sono dotati di SIM che danno accesso all’APN privata del distributore, la quale consente il dialogo fra il sistema SCADA del DSO e l’unità terminale remota installata in sottostazione.

Qui si colloca lo scarto fra i requisiti formali e la superficie di attacco reale. I distributori impongono che tutta la comunicazione fra la propria rete e l’RTU avvenga su protocollo seriale, nella fattispecie DNP3.0, e nel sito compromesso il requisito era rispettato. Nessun requisito era però stato definito riguardo alla gestione dell’interfaccia amministrativa del router cellulare. Il router installato, un Teltonika RUTX50, presentava quindi due interfacce fisiche: un collegamento seriale RS485 verso l’RTU e una porta Ethernet attestata su una VLAN governata dal firewall centrale, già compromesso.Il modello espone per impostazione predefinita un’interfaccia web di amministrazione e un servizio SSH sull’interfaccia LAN. La password predefinita era stata cambiata, come il dispositivo impone al primo accesso, dall’azienda che aveva realizzato l’installazione, e non è stato possibile stabilire come l’attaccante ne sia venuto in possesso, né se sia stata sfruttata una vulnerabilità del dispositivo. Un elemento fortunato per gli investigatori: nelle versioni di RutOS precedenti alla 7.07 il database degli eventi sopravvive al ripristino di fabbrica, e dall’archivio SQLite recuperato dalla memoria persistente è stato possibile ricostruire le tracce degli accessi al pannello web e via SSH, ripetuti nel corso di dicembre.

Incrociando quelle tracce con i log dell’operatore di rete mobile, il CERT ritiene molto probabile che l’attaccante abbia usato il servizio SSH del router per aprire un tunnel verso l’APN privata.

Dentro l’APN privata: il secondo anello

A partire dal 18 dicembre 2025 l’APN privata è stata scandagliata ripetutamente alla ricerca di servizi VNC e HTTP e dei protocolli industriali S7 e Modbus. È il momento in cui una rete nata per trasportare telecontrollo diventa terreno di ricognizione.

Fra i dispositivi individuati c’era il controllore WAGO PFC200. Esponeva la propria interfaccia web di amministrazione sull’interfaccia WAN, raggiungibile dall’APN privata, e manteneva le credenziali predefinite dell’account “admin”. SSH, invece, non era attivo sulla WAN nella configurazione di fabbrica. Dai log dell’operatore mobile risulta che l’attaccante ha raggiunto prima l’interfaccia web e poi il servizio SSH, il che indica che quest’ultimo sia stato abilitato proprio attraverso il pannello di amministrazione. La correlazione dei timestamp fra i log raccolti nell’APN e quelli della rete locale della centrale porta il CERT a ritenere molto probabile un secondo tunnel SSH, questa volta verso la rete OT dell’impianto.

Il controllore WAGO aveva connettività sia verso i sistemi SCADA sia verso i segmenti che ospitano i dispositivi industriali responsabili dei processi operativi chiave dell’impianto.

Una settimana di ricognizione

Fra il 18 e il 25 dicembre l’attaccante ha esplorato la rete della centrale. I primi tentativi, diretti all’interfaccia web del dispositivo che svolge insieme funzione di firewall e di gateway VPN, raggiungibile dalla LAN, sono falliti: sono stati provati i nomi utente “admin”, “user” e un nome associato all’azienda responsabile dell’installazione dei sistemi di telecontrollo negli impianti rinnovabili, e la sequenza è stata ripetuta tre giorni dopo, sempre senza esito.

Il 21 dicembre, una domenica, otto giorni prima dell’attacco, è avvenuta la scansione della rete interna. Fra i servizi bersaglio compaiono S7 sulla porta 102, Modbus sulla 502, CODESYS sulla 11740 e RTSP sulla 554, quest’ultimo riconducibile alla videosorveglianza, accanto a RDP, VNC e ai servizi web in HTTP e HTTPS. Un dettaglio significativo: in una delle sottoreti la scansione è cominciata proprio dall’indirizzo assegnato al sistema SCADA, il che suggerisce che i bersagli di maggior valore fossero già stati individuati in una fase precedente. In un’altra sottorete, invece, la scansione ha seguito un andamento più consueto, interrogando l’intero intervallo di indirizzi.

Il giorno seguente, 22 dicembre, i log di traffico registrano connessioni verso porte di servizi di desktop remoto su due host: con ogni probabilità tentativi manuali di individuare credenziali valide, dei quali non risulta alcun esito positivo.

Il 25 dicembre l’attaccante ha stabilito connessioni riuscite verso tre PLC Siemens tramite protocollo S7. Lo scopo non è stato determinato con certezza; la spiegazione più plausibile è una ricognizione dei controllori in preparazione delle azioni successive.

Le ore dell’attacco

Il 29 dicembre l’attività all’interno della rete della centrale si è svolta fra le 5:30 e le 10:10 circa. Le operazioni di ripristino avviate dall’esercente intorno alle 7:30 sono quindi cominciate mentre l’attaccante era ancora presente in rete.

La sequenza distruttiva ha preso avvio dall’interfaccia web del server SCADA, per passare a un PLC Siemens S7-300 e poi, con lo stesso schema, a un S7-1200 e a un S7-1500, con ulteriori interazioni con l’interfaccia SCADA lungo tutto il periodo. Secondo quanto riferito dal personale, i controllori sono stati portati in modalità STOP e protetti con una password che impediva sia il cambio di stato operativo sia la modifica della logica di controllo. Da qui l’arresto della turbina e del trattamento acque. Il ripristino è avvenuto riportando i dispositivi alle impostazioni di fabbrica e ricaricando i backup della logica: soluzione efficace sui tempi di fermo, ma che ha comportato la perdita dei log presenti sui controllori, non più recuperabili, come confermato da Siemens ProductCERT.

L’attaccante ha inoltre modificato la configurazione di sette device server seriali e tre switch di rete Moxa, con lo stesso schema già osservato negli impianti rinnovabili: ripristino di fabbrica, cambio della password di accesso e assegnazione di indirizzi IP non raggiungibili, ad esempio 127.0.0.1, così da rendere i dispositivi inaccessibili e allungare i tempi di recupero. La cadenza delle richieste HTTP indica con elevata affidabilità che l’operazione fosse automatizzata.

Sono state osservate connessioni verso le interfacce di amministrazione di due azionamenti a frequenza variabile ABB della serie ACS, senza che sia stato possibile determinare quali azioni siano state compiute. I tentativi verso azionamenti Schneider Electric ATV6xx sono invece falliti, molto probabilmente per una ricognizione incompleta: l’attaccante ha bussato alla porta 80, mentre le interfacce erano in ascolto altrove.

La sequenza completa

La catena ricostruita dal CERT si articola in undici passaggi.

1. Accesso al dispositivo perimetrale del parco eolico e connessione VPN remota.
2. Individuazione del router cellulare Teltonika RUTX50 all’interno della rete del parco.
3. Accesso all’interfaccia web di amministrazione del router e successivo login al servizio SSH.
4. Uso di SSH per stabilire un tunnel verso l’APN privata.
5. Scansione dell’APN privata.
6. Individuazione del controllore WAGO PFC200 che espone l’interfaccia web di amministrazione sulla WAN.
7. Uso delle credenziali predefinite per ottenere accesso amministrativo all’interfaccia web.
8. Abilitazione del servizio SSH sull’interfaccia WAN del WAGO.
9. Uso di SSH per stabilire un tunnel verso la rete OT della centrale.
10. Ricognizione della rete OT nell’arco di una settimana.
11. Azioni distruttive, con arresto della turbina a vapore e del trattamento delle acque di processo.

La cancellazione delle tracce

La fase finale è quella che più caratterizza l’operazione. Dopo poco meno di cinque ore, e dopo un ultimo accesso all’interfaccia SCADA verosimilmente per valutare l’effetto ottenuto, l’attaccante ha danneggiato il controllore WAGO usato come varco, corrompendone la tabella delle partizioni. Il tentativo di ripristino di fabbrica condotto dall’esercente non ha riparato la tabella, il dispositivo è rimasto non avviabile e nessun log utile è stato recuperato.

L’operazione è poi proseguita nell’ambiente del parco eolico. Circa trenta minuti dopo l’ultima attività nella centrale, il router Teltonika è stato riportato alle impostazioni di fabbrica, con cambio della password amministrativa e assegnazione dell’indirizzo 127.0.0.1, verosimilmente per ostacolarne la riconfigurazione. Come ultima azione osservata, anche il FortiGate che era servito da punto di ingresso iniziale è stato riportato alle impostazioni di fabbrica: data la configurazione e il modello del dispositivo, l’operazione ha comportato la perdita dei log.

Una nota sull’attribuzione

Il rapporto integrativo non contiene elementi di attribuzione, e non ne aggiunge rispetto al quadro noto. Vale però la pena ricordare che su quel quadro non c’è consenso.

Nel rapporto di gennaio CERT Polska aveva ricondotto la campagna a un cluster tracciato come Static Tundra da Cisco, Berserk Bear da CrowdStrike, Ghost Blizzard da Microsoft e Dragonfly da Symantec, sulla base di un elevato grado di sovrapposizione nell’infrastruttura utilizzata, inclusi server VPS e router compromessi, negli schemi di traffico e nelle caratteristiche dell’infrastruttura di anonimizzazione. Si tratterebbe della prima attività distruttiva descritta pubblicamente per quel cluster, storicamente orientato a ricognizione e spionaggio.

Le società di sicurezza sono arrivate altrove, e per vie diverse fra loro. ESET, che ha analizzato il wiper impiegato nella campagna e lo ha denominato DynoWiper, attribuisce l’attività a Sandworm con confidenza media, sulla base del malware e delle tattiche, tecniche e procedure osservate, che ricalcano da vicino quelle di un precedente episodio ucraino legato al wiper ZOV. Dragos, con confidenza moderata, ha indicato invece un gruppo che traccia come Electrum, che descrive come collegato a Sandworm ma non sempre coincidente con esso. La distinzione non è nominalistica: sono due perimetri di attore diversi, e vanno tenuti separati.

Gli investigatori polacchi, dal canto loro, hanno ritenuto le somiglianze fra il codice del wiper polacco e quello dei wiper già ricondotti a Sandworm troppo deboli per sostenere l’attribuzione, definendole di carattere generale, e hanno concluso di non poter determinare in modo conclusivo il coinvolgimento di quel gruppo. Parte della stampa specializzata continua nondimeno a presentare Sandworm come attore accertato, anche nella copertura del rapporto integrativo: allo stato, l’attribuzione resta contesa.

Perché il caso non è polacco: l’APN privata come rischio di filiera

La conclusione del CERT è esplicita: per quanto risulta al team, si tratta del primo impiego osservato in un attacco reale di una APN privata come vettore di accesso a una rete OT. L’esecuzione è stata resa possibile, fra gli altri fattori, da una configurazione errata che consentiva a dispositivi arbitrari all’interno dell’APN di comunicare fra loro. Le rilevazioni condotte presso più soggetti che utilizzano soluzioni analoghe hanno mostrato che quella configurazione era di comune riscontro in Polonia, e il CERT ritiene che assetti simili siano ampiamente diffusi anche in altri Paesi. La stessa CISA ha ritenuto il caso rilevante oltre i confini nazionali, riprendendo il primo rapporto in un alert del 10 febbraio 2026 redatto con il contributo dell’ufficio CESER del Dipartimento dell’Energia statunitense e dello stesso CERT Polska.

Le raccomandazioni conclusive si possono raccogliere attorno a tre principi. Il primo: sottoporre ad audit la configurazione dell’APN privata, abilitando in particolare l’isolamento fra i client collegati, e dove la comunicazione diretta sia necessaria condurre una valutazione del rischio che consideri esplicitamente la compromissione di uno dei dispositivi attestati. Il secondo: trattare l’APN privata come rete non fidata rispetto all’ambiente OT, applicando segmentazione e controlli di traffico almeno equivalenti a quelli previsti per le connessioni WAN aziendali, e assimilandola a Internet quando l’organizzazione non ne controlla la configurazione né dispone delle informazioni per verificarne i meccanismi di sicurezza. Il terzo: ridurre al minimo la superficie esposta sui dispositivi raggiungibili dall’APN, non pubblicando interfacce web di amministrazione, SSH o Telnet, cambiando le credenziali predefinite, limitando il traffico fra rete OT e gateway a regole in allowlist, monitorando gli scostamenti dal profilo di comunicazione atteso, centralizzando i log dei gateway e includendo APN e relativi dispositivi nel perimetro di penetration test, esercitazioni red team e revisioni di architettura.

Per il lettore italiano il nodo è di governance prima ancora che tecnico, e ricalca quanto già osservato in altri comparti dove la sicurezza OT dipende da una filiera di operatori distinti. L’impianto colpito è stato raggiunto attraverso infrastrutture che non controllava: il perimetro di un altro soggetto, il parco eolico, e una APN privata gestita da un terzo, il distributore. Nessuno dei due aveva visibilità completa sulla catena, e la centrale meno di tutti. È significativo che la ricostruzione sia stata possibile solo aggiungendo un quarto attore, l’operatore di rete mobile, i cui log hanno colmato ciò che i sistemi delle vittime non potevano documentare.

Il requisito contrattuale imposto dal DSO riguardava il protocollo di comunicazione con l’RTU, non l’interfaccia amministrativa dell’apparato che quel protocollo trasportava, ed è esattamente lì che l’attaccante è passato.

È il tipo di rischio che NIS2 chiama in causa quando parla di sicurezza della catena di approvvigionamento e di rapporti fra soggetti essenziali, tema su cui l’articolo 21, comma 2, lettera d) della direttiva, recepito dall’articolo 24 del D.Lgs. 138/2024 fra le misure minime di gestione del rischio, impone una valutazione strutturata delle dipendenze esterne. Nel settore elettrico questo si traduce in una domanda operativa molto concreta: chi risponde della configurazione di una APN privata condivisa, chi ha il diritto contrattuale di verificarla e chi conserva i log necessari a ricostruire un incidente che attraversa tre organizzazioni. Nell’esperienza polacca la risposta, al momento dell’attacco, non era definita.