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.

https://www.ictsecuritymagazine.com/industrial-cyber-security/apn-privata-la-rete-che-nessuno-sorvegliava-e-che-ha-portato-lattaccante-dentro-una-centrale-di-cogenerazione/

La firma elettronica qualificata belga è rimasta esposta per mesi a causa di un’estensione browser con oltre due milioni di utenti, sviluppata da una società iscritta nella Trusted List europea come prestatore qualificato. Qualsiasi sito web poteva leggere i dati della carta d’identità elettronica dell’utente quando inserita nel lettore, indurlo a digitare il PIN in una finestra dal testo controllato dall’attaccante per poi ricavarlo in chiaro, e, sulle installazioni Windows, eseguire codice sulla sua macchina anche senza carta inserita. Le vulnerabilità, ora corrette, sono state presentate al DEF CON e mettono in discussione non tanto la qualificazione eIDAS in sé, quanto l’ampiezza del perimetro che essa certifica.

Che cosa è successo

Il software che fa da ponte fra il browser e la carta d’identità belga, e che produce con essa firme elettroniche qualificate, si è rivelato pilotabile da qualunque pagina web. Il gruppo di ricerca di Bay Area Labs, società fondata da James Arnott, ha reso pubblici il 7 agosto 2026, in concomitanza con l’intervento al DEF CON di Las Vegas, i dettagli tecnici di una serie di vulnerabilità nel sistema di firma Connective, sviluppato dall’omonima società belga e oggi in capo a Nitro Software Belgium, nell’analisi tecnica originale.

Il sistema si compone di due elementi: un’estensione per browser, distribuita per i principali browser (Chrome, Edge, Firefox e Safari), e un componente nativo installato sul sistema operativo, disponibile per Windows e macOS, che dialoga direttamente con i lettori di smart card collegati alla macchina. L’estensione funge da semplice canale di inoltro fra le pagine web e il componente nativo, che a sua volta esegue le operazioni sulla carta: lettura dei dati, verifica del PIN, calcolo della firma.

Sulla diffusione conviene essere precisi, perché il dato circola in forma imprecisa. I ricercatori parlano di oltre due milioni di utenti attivi settimanali, cifra che dichiarano di avere verificato direttamente sulle schede pubbliche dell’estensione, le sole due che espongono un conteggio: Chrome Web Store e vetrina Edge. Il dato ricorrente di otto delle dieci maggiori banche belghe e oltre sessanta amministrazioni pubbliche compare invece, con questa esatta formulazione, nel comunicato del 10 novembre 2021 con cui Nitro annunciò l’acquisizione di Connective, dove si riferisce alla base clienti complessiva della società in Europa, oltre mille clienti fra mid-market, imprese e amministrazioni, non specificamente all’estensione. Il gruppo di ricerca lo riprende dichiarando espressamente di non poterne verificare l’estensione al componente vulnerabile.

Una precisazione di trasparenza, dichiarata dagli stessi autori: la ricerca è nata come banco di prova di una piattaforma commerciale di analisi automatizzata delle estensioni e dei relativi componenti nativi, che la società offre sul mercato.

L’errore di progettazione: nessuna nozione di origine

Il difetto strutturale è tanto elementare quanto devastante. L’estensione non trasmetteva al componente nativo l’origine della richiesta, cioè il dominio della pagina che stava chiedendo un’operazione. Il programma installato sul computer, in altre parole, non aveva alcun modo di sapere con quale sito stesse parlando.

Esisteva formalmente un meccanismo di autorizzazione: un token di attivazione firmato con RSA a 2048 bit, rilasciato ai siti partner per abilitare l’uso del sistema sulla macchina dell’utente. Decodificandolo, i ricercatori hanno però constatato che il token conteneva soltanto un identificativo privo di funzione osservabile, una scadenza e una maschera di bit relativa alle operazioni abilitate. Nessun vincolo all’origine. Un token ottenuto da un servizio legittimo poteva quindi essere riutilizzato da qualunque altra pagina, iframe o annuncio pubblicitario, ottenendo lo stesso livello di accesso. I ricercatori riferiscono di averli reperiti da Doccle, la piattaforma documentale usata in Belgio per la ricezione di fatture e documenti, con tutte le operazioni abilitate e validità di ventiquattro ore.

Da qui discende la prima conseguenza: qualsiasi sito, o qualsiasi frame incorporato in un sito, poteva leggere silenziosamente i dati della carta d’identità elettronica e della carta di pagamento Maestro, storicamente co-marchiata Bancontact in Belgio, inserite nel lettore, senza consenso né consapevolezza dell’utente. Va ricordato che dal 1° luglio 2023 in Europa non vengono più emesse nuove carte Maestro, sostituite alla scadenza da Debit Mastercard o Visa Debit: le carte con quel circuito ancora in circolazione resteranno operative al più fino al 2027.

Il PIN restituito alla pagina, con la chiave per decifrarlo

La seconda conseguenza riguarda il PIN. Il comando di verifica accettava dalla pagina web il titolo e il testo della finestra di dialogo nativa mostrata all’utente. La finestra era in tutto identica a quella di un’applicazione legittima e non indicava il dominio richiedente: nessun elemento consentiva a chi la vedeva di distinguere una richiesta autentica da una fraudolenta. Il phishing del PIN diventava così un’operazione banale.

Il punto più grave, però, riguarda ciò che accadeva dopo l’inserimento. Il componente nativo restituiva alla pagina un token relativo al PIN che, all’analisi, si è rivelato contenere sia il testo cifrato sia la chiave AES a 128 bit necessaria a decifrarlo, con un vettore di inizializzazione fisso codificato nel binario. Il PIN, in sostanza, era ricavabile in chiaro dal token stesso. Ottenuto una volta il PIN, un attaccante poteva generare autonomamente nuovi token e utilizzare la carta ogni volta che questa si trovava inserita nel lettore.

È il passaggio che rende l’incidente sistemico. La carta non lascia mai il lettore e le chiavi non lasciano mai il chip, ma il possesso del PIN unito alla capacità di inviare comandi alla carta equivale, sul piano pratico, ad avere la carta in mano, con un raggio d’azione più ampio, perché l’attacco funziona da un iframe e non richiede che la vittima visiti volontariamente un sito ostile.

L’esecuzione di codice: un parametro di troppo

Il risultato che gli stessi ricercatori considerano il più grave riguarda però un’altra strada, indipendente dalla presenza della carta nel lettore, come sottolinea anche la ricostruzione di SecurityWeek. Questa seconda catena sfrutta il meccanismo di caricamento delle librerie dinamiche di Microsoft e riguarda quindi le installazioni su Windows, non quelle su macOS.

Il comando che restituisce l’elenco dei lettori accettava dalla pagina web un parametro con il percorso della libreria da caricare, ammettendo anche percorsi relativi. L’unico vincolo era la presenza della sequenza .dll nel percorso. Poiché il browser segnala e ostacola il download diretto di file con quell’estensione, i ricercatori hanno aggirato il controllo con un file polyglot il cui nome contiene la sequenza in posizione interna, mascherato da normale documento. Trovandosi il software installato sotto la cartella dei dati applicativi dell’utente, bastava risalire con un percorso relativo fino alla cartella dei download per fare caricare ed eseguire la libreria.

L’esito è l’esecuzione di codice a livello utente, con uscita dalla sandbox del browser, senza che alla vittima sia richiesta alcuna azione consapevolmente rischiosa: dal suo punto di vista si scarica un documento e si visita una pagina. I ricercatori segnalano inoltre che nulla impediva, in linea teorica, una propagazione a catena, sottraendo i token di sessione e recapitando il collegamento ad altri utenti dell’estensione.

Vale la pena registrare, sul piano del metodo, che gli autori dichiarano di avere individuato le vulnerabilità con l’ausilio di modelli linguistici di grandi dimensioni impiegati nella loro piattaforma di analisi, indicando espressamente le versioni di Claude Opus utilizzate, pur sostenendo nello stesso passaggio che nessuna delle scoperte richiedeva strumenti di quel tipo, ma soltanto ingegneri di sicurezza competenti che guardassero il codice.

Firma elettronica qualificata: dall’identità alla sottoscrizione con valore legale

La chiave di non ripudio della carta belga produce firme elettroniche qualificate ai sensi del regolamento eIDAS, giuridicamente equiparate alla sottoscrizione autografa e destinate a un ruolo ancora più centrale con l’identità digitale europea. L’equiparazione discende dall’articolo 25, paragrafo 2 del regolamento, e nell’ordinamento italiano trova riscontro nell’articolo 20 del Codice dell’amministrazione digitale, che al documento sottoscritto con firma qualificata attribuisce l’efficacia probatoria dell’articolo 2702 del codice civile. La conseguenza pratica, evidenziata dai ricercatori, è che chi subisce una firma falsificata si trova nella posizione processuale più scomoda: è lui a dover attivare la contestazione e a doverne sostenere l’onere.

I ricercatori osservano inoltre che i file presenti sul chip, firmati dal Registro nazionale, contengono nome completo, numero di registro nazionale e indirizzo. Un attaccante non otteneva dunque soltanto dati anagrafici, ma una copia attestata dallo Stato di quei dati, unita alla capacità di firmare documenti con valore legale pieno.

Ne discende un effetto a cascata sull’intero ecosistema. Il gruppo riporta di avere dimostrato l’acquisizione di un account sul portale governativo CSAM.be, che si autentica tramite eID. Sul provider di identità itsme, utilizzato in Belgio per l’accesso a home banking, dichiarazione dei redditi e servizi previdenziali, i ricercatori descrivono uno scenario di takeover basato sulla combinazione fra creazione dell’account tramite firma con eID e procedure di blocco e riattivazione documentate dal provider stesso, precisando però di non averlo verificato sperimentalmente.

Il punto editorialmente più significativo è un altro: né itsme né CSAM.be presentavano difetti nei rispettivi software. Lo schema di identificazione elettronica belga di cui itsme fa parte è notificato ai sensi di eIDAS con livello di garanzia “elevato”, il più alto previsto, come risulta dalla notifica pubblicata nella Gazzetta ufficiale dell’Unione europea nel dicembre 2019; la stessa società che gestisce itsme è a sua volta prestatore qualificato di servizi fiduciari. La loro esposizione derivava dalla fiducia riposta in un componente a monte. Va detto, per completezza, che lo scenario descritto per itsme poggia anche su due elementi delle procedure del provider, che gli stessi ricercatori discutono criticamente: il blocco di un account non richiede alcuna autenticazione, e un account non attivo può essere riattivato tramite firma con eID associandolo a un nuovo numero di telefono.

Centoquarantasei giorni, nessun CVE, duecento dollari

La gestione della segnalazione merita di essere ricostruita, perché è la parte che interroga più direttamente il quadro regolatorio.

Un primo intervento correttivo è stato rilasciato l’8 maggio 2026, introducendo una verifica dell’origine tramite un server remoto. Era una correzione parziale: non toccava l’esecuzione di codice né la restituzione del token del PIN alla pagina, limitandosi a restringere l’insieme dei siti in grado di sfruttarli. Il 19 maggio il fornitore ha chiesto di posticipare la divulgazione per consentire l’aggiornamento delle installazioni presso i clienti in locale; nello stesso giorno i ricercatori hanno segnalato l’incompletezza della correzione, indicando le modifiche necessarie.

La correzione completa è arrivata il 1° giugno, con la disabilitazione del comando che consentiva il caricamento di librerie arbitrarie e con lo spostamento della gestione del token del PIN all’interno dell’estensione, sostituendo il dato sensibile con un identificativo casuale. L’applicazione effettiva dei controlli sull’origine è stata completata il 22 luglio; l’ultimo aggiornamento dell’estensione pubblicato sul Chrome Web Store risale al 29 luglio. I ricercatori quantificano in centoquarantasei giorni l’intervallo fra la prima segnalazione e la correzione, senza rendere pubblica la data della segnalazione iniziale. Non risultano assegnati identificativi CVE. Al ricercatore è stata offerta una ricompensa di duecento dollari.

Va detto, per completezza, che il fornitore disponeva di un canale dedicato alle segnalazioni di sicurezza, ha risposto, non ha subordinato il dialogo alla firma di accordi di riservatezza e ha infine corretto i difetti. Non ha invece dato riscontro alla richiesta di commento avanzata dalla stampa specializzata. La pubblicazione è avvenuta con il benestare del Centre for Cybersecurity Belgium, nell’ambito della clausola di esenzione da responsabilità penale, a determinate condizioni, prevista dal quadro nazionale belga per la divulgazione coordinata: benestare che gli autori dichiarano di non avere ritenuto strettamente necessario. Contestualmente all’articolo tecnico, gli autori dichiarano di avere reso pubblico anche il codice di sfruttamento delle vulnerabilità: un elemento da tenere presente per le installazioni in locale che non avessero completato l’aggiornamento.

Alla data del 10 agosto 2026 non risultano dichiarazioni pubbliche del fornitore, del provider itsme, dell’amministrazione responsabile del portale CSAM.be o del Centre for Cybersecurity Belgium sulla vicenda.

La domanda che riguarda anche noi

Qui la vicenda va letta con precisione, perché è facile trarne la conclusione sbagliata. Nitro Software Belgium figura effettivamente nella Trusted List europea come prestatore qualificato, ma il servizio iscritto è un servizio qualificato di validazione delle firme elettroniche qualificate, come risulta dalla stessa documentazione di conformità della società e dal certificato eIDAS LSTI che ne attesta la conformità. L’estensione e il componente nativo, cioè esattamente il software che dialoga con la carta e raccoglie il PIN, non rientrano nel perimetro qualificato e non costituiscono oggetto degli audit periodici di conformità che il regolamento impone ai prestatori qualificati, condotti da organismi di valutazione accreditati con cadenza almeno biennale ai sensi dell’articolo 20, paragrafo 1, del regolamento 910/2014.

Il dettaglio più istruttivo sta proprio dentro quel certificato. Il documento in vigore, numero 980, è stato emesso il 5 giugno 2025 sulla base di una valutazione di conformità del 17 marzo 2025, ha validità fino al 4 giugno 2027 e fissa al 16 marzo 2027 la successiva valutazione. Dichiara la conformità al regolamento (UE) 2024/1183, cioè alla versione riformata di eIDAS, e cita fra le norme applicate la EN 319 401 nella versione 3.1.1, che incorpora i requisiti di cibersicurezza della direttiva NIS2, in particolare quelli dell’articolo 21. Il quadro è completato dal regolamento di esecuzione (UE) 2025/1942 sui servizi di validazione qualificati e dal regolamento di esecuzione (UE) 2025/2162 sull’accreditamento degli organismi di valutazione.

In altre parole: il prestatore è stato valutato, di recente e su uno standard che già assorbe gli obblighi di gestione del rischio della NIS2. Il software che raccoglieva il PIN degli utenti non era però l’oggetto di quella valutazione.

Il problema, dunque, non è che l’audit abbia mancato il bersaglio: è che il bersaglio non era nel poligono. La fiducia che il marchio di qualificazione genera sul mercato è più ampia del perimetro che la qualificazione certifica, e nel mezzo resta il client, cioè il punto in cui l’utente incontra materialmente la propria identità digitale. Vale la pena aggiungere che il fornitore dichiarava sul proprio sito, in una versione archiviata risalente al 2022, di sottoporre il software a test di penetrazione annuali: un impegno volontario, non un obbligo regolamentare, e questo è precisamente il punto.

La conclusione dei ricercatori è netta: serve un obbligo normativo esplicito di test di sicurezza tecnicamente competenti in capo ai prestatori qualificati, perché l’assetto attuale rischia di certificare processi anziché prodotti.

È qui che la vicenda cessa di essere belga. Il modello architetturale colpito, un’estensione browser che fa da ponte verso un componente nativo con accesso al lettore di smart card, è lo stesso adottato in tutta Europa per l’interazione fra browser e carte di identità o dispositivi di firma, Italia inclusa. Nessun elemento agli atti indica che prodotti italiani siano interessati da queste specifiche vulnerabilità, e non risultano segnalazioni in tal senso. Ma la classe di difetto è generale, e i ricercatori affermano di avere individuato problematiche analoghe in altre estensioni della stessa famiglia, alcune delle quali interessano un numero elevato di istituti bancari.

Per il lettore italiano restano tre implicazioni concrete. La prima riguarda il Cyber Resilience Act: un’estensione con componente nativo ricade con ogni probabilità nella nozione di prodotto con elementi digitali, e come tale nei requisiti di sicurezza per progettazione e di gestione delle vulnerabilità, applicabili dall’11 dicembre 2027, mentre l’obbligo di segnalazione delle vulnerabilità attivamente sfruttate decorre dall’11 settembre 2026. La seconda riguarda NIS2, che colloca i prestatori di servizi fiduciari fra i soggetti dell’infrastruttura digitale dell’allegato I e qualifica quelli qualificati come soggetti essenziali a prescindere dalla dimensione. La terza riguarda DORA e la gestione del rischio derivante da terze parti: se il dato del 2021 sulla diffusione presso la maggioranza delle grandi banche belghe fosse ancora attuale, si tratterebbe di una concentrazione di rischio che nessuna delle entità coinvolte controlla direttamente, e che il regolamento chiede a ciascuna di mappare e presidiare, con un regime distinto e ulteriore per i fornitori designati come critici a livello europeo.

La qualificazione eIDAS produce fiducia. La domanda che questa ricerca lascia aperta è se quella fiducia sia oggi accompagnata da una verifica tecnica proporzionata alle conseguenze giuridiche che essa abilita, e se il suo perimetro coincida con quello che il mercato le attribuisce.

https://www.ictsecuritymagazine.com/digital-id-security/firma-elettronica-qualificata-esposta-le-falle-delleid-belga-e-il-perimetro-che-eidas-non-copre/

The image most security professionals still carry of perimeter crime is the opportunist: the actor who spots an open gate, grabs what is within reach, and flees. While that type of criminal certainly still exists, the sophisticated adversary keeping us practitioners awake at night looks nothing like them.

The adversary that matters today plans. They surveil, rehearse, and study a facility the way an engineer studies a blueprint. By the time this opponent executes a physical breach, they have already answered every operational question that would have stopped an amateur.

https://www.securitymagazine.com/articles/102479-the-crime-began-well-before-the-breach

Mixed-use properties have unique security challenges by their very nature. They typically house numerous occupants that require access to common areas and individual spaces that all need to be secured 24/7/365 — sometimes under a single roof and often across properties or campuses with multiple buildings. Add into the equation multi-tenant, mixed-use properties that combine residential and business spaces, and the logistical challenges of implementing modern security solutions increase exponentially.

The most common longstanding security and safety challenges of mixed-use properties generally fall into four categories: 1) the need to isolate private and public internal and exterior spaces; 2) manage physical credentials and access privileges; 3) prevent unauthorized access and intrusion; and 4) maintain security in common areas.

https://www.securitymagazine.com/articles/102468-modern-wireless-first-security-solutions-deliver-multiple-benefits-for-mixed-use-properties

@import url('https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,300..800;1,300..800&display=swap'); @import url('https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,300..800;1,300..800&family=Roboto:ital,wght@0,100..900;1,100..900&display=swap'); @import url('https://fonts.googleapis.com/css2?family=Handlee&display=swap'); h3 { font-weight: bold; font-size: 18px; color: #C72026; } figure { padding: 4px; margin: auto; } figcaption { color: #404144; font-size: 14px; padding: 10px; text-align: left; } .pqFull { display: block; border-width: 2px 0; border-style: solid; border-color: #404144; padding: 1.5em 0 0.5em; margin: 1.5em 0; position: relative; font-size: 20px; text-align: center; color: #0067A6; } .pqFull:before { content: '\275D'; position: absolute; top: -.10em; left: 50%; transform: translate(-50%, -50%); background: #fff; width: 4rem; height: 2rem; color: #666; text-align: center; } .pqFull:after { content: "\2013 \2003" attr(cite); display: block; text-align: center; font-size: 18px; color: #404144; }

What do you do if you’re on fire? Ask anyone that question and no matter their age you’ll more than likely get the same answer. Say it with me: STOP, DROP, and ROLL!

Very good class! That famous phrase taught to countless school children since the 1970s has drastically reduced the number of children (and adults) who are injured by fire. All thanks to national standards for fire protection.

https://www.securitymagazine.com/articles/102462-stop-drop-and-roll

Artificial intelligence (AI) is a double-edged sword. In capable hands, it sharpens decisions, accelerates transformation, and strengthens defense. In the wrong hands, or in well-intentioned hands without oversight, it scales risk faster than any organization can absorb. The capability is not the problem, the governance is. And right now, governance is losing the race.

The same models that help defenders detect threats faster also help attackers run reconnaissance, craft convincing phishing, and probe enterprise systems at machine speed. That is not a future risk. It is happening now, in production environments, often inside organizations that have not yet decided who owns AI risk on their executive team.

https://www.securitymagazine.com/articles/102464-as-ai-outpaces-regulation-trust-is-at-risk

Enterprise AI is transitioning from the “does it work” phase to the “how can we adopt it safely” phase, creating an unprecedented and complex mix of opportunities and challenges for business leaders. Most AI pilots today fail due to misalignment between leaders, departments, individuals and one often-overlooked but critical piece: their data ecosystem. Without a defined strategy, clear accountability, clean data and explainable decisions, adding AI to a flawed process only amplifies existing risks. As AI quickly moves from pilot to production, unified data and AI trust are both strategic and infrastructure imperatives for enterprises.

As AI Investment Continues, So Does Cost of Failure

KPMG projects that in 2026, business leaders will invest an average of $124M in AI, with AI agents becoming more mainstream. Recent industry studies show that 54% of banks have adopted AI in production, 46% of proof of concept projects fielded by large providers in healthcare are progressing to production and 58% of retail and CPG organizations are actively deploying AI solutions in 2026. From risk identification and quality assurance in financial services to patient care management in healthcare and supply chain optimization in retail, AI is increasingly embedded in large sectors that impact billions of people worldwide. 

https://www.securitymagazine.com/articles/102463-building-trust-in-ai-starts-with-trustworthy-data

The Belarusian creator and administrator of the Ransom Cartel ransomware was sentenced to 16 years in prison in the US.

Maksim Silnikau, 40, built the ransomware operation and recruited other individuals through cybercrime forums, according to documents presented in court.

Silnikau provided Ransom Cartel conspirators with stolen credentials and other information on compromised computers, as well as with tools to encrypt those systems.

Additionally, the court documents show, he maintained a hidden website used to manage and monitor ransomware attacks, communicate with other conspirators and with victims, and manage the distribution of funds between participants.

Between 2021 and 2023, Ransom Cartel targeted at least 18 organizations in the US and abroad, stealing victims’ data and demanding monetary payments in exchange for decryption keys or the promise not to publish the stolen information.

According to the documents presented in court, the Ransom Cartel operation was disrupted when Silnikau was arrested in 2023.

In a separate case, Silnikau was charged with participating in the distribution of Angler (a notorious exploit kit disrupted in 2016 that was widely used for the deployment of malware) and of other malware and online scams.

Together with Volodymyr Kadariya, a Belarusian and Ukrainian national, and Andrei Tarasov, a Russian national, Silnikau allegedly distributed malware and other threats through malvertising and other means between 2013 and 2022.

Silnikau was arrested in Spain and extradited to the US in 2024 from Poland. Tarasov was arrested in Germany, but was released after six months and returned to Russia. In 2024, the US posted a $2.5 million reward for information on Kadariya.

On August 5, Silnikau was sentenced to 16 years for conspiracy to commit offenses against the US, wire fraud conspiracy, and aggravated identity theft.

Related: Two Scattered Spider Hackers Sentenced to Jail in UK

Related: Alleged Scattered Spider Hacker Extradited to US

Related: Google, FBI Disrupt NetNut Residential Proxy Network Powered by Millions of Devices

Related: Microsoft and Allies Smash Shared Infrastructure of Amadey and StealC Malware

https://www.securityweek.com/belarusian-ransom-cartel-mastermind-gets-16-years-in-prison/

A constantly shifting geopolitical landscape underscores the importance of protecting U.S. national security, especially as the private sector has been elevated and increasingly relied upon to combat threats to U.S. interests in partnership with government.

For more than 28 years, Paul Abbate worked at the Federal Bureau of Investigation in a variety of roles, most recently as Deputy Director where he oversaw domestic and international investigative and intelligence operations across the entire organization. He currently serves as Senior Managing Director at FTI Consulting.

https://www.securitymagazine.com/articles/102424-the-state-of-national-security

Cisco on Wednesday rolled out patches for two dozen vulnerabilities across its products, including critical-severity bugs in Catalyst SD-WAN, IOS XE, and Secure Firewall Management Center (FMC).

For Catalyst SD-WAN, the company released five fixes, noting that the CVEs were assigned to multiple weaknesses grouped by the underlying vulnerability class.

Three of the CVEs, namely CVE-2026-20303, CVE-2026-20304, and CVE-2026-20310, have a CVSS score of 9.9 and are described as improper input validation, improper access control, and improper link resolution before file access.

The remaining two, CVE-2026-20312 and CVE-2026-20313, are high-severity flaws described as cleartext storage of sensitive information and improper validation of specified quantity in input.

IOS XE received seven fixes, and the assigned CVEs group multiple issues by their underlying vulnerability class.

Two of them, CVE-2026-20272 (CVSS score of 9.8) and CVE-2026-20267 (CVSS score of 9.0), are critical-severity command injection and improper access control defects, while the rest are high-severity flaws.

FMC received patches for CVE-2026-20079 (CVSS score of 10), a critical authentication bypass that allows remote, unauthenticated attackers to execute scripts and gain root privileges.

“An attacker could exploit this vulnerability by sending crafted HTTP requests to an affected device. A successful exploit could allow the attacker to execute a variety of scripts and commands that allow root access to the device,” Cisco notes.

The company also patched high-severity security defects in Integrated Management Controller (IMC), IOS XE, and IOS, and medium-severity bugs in IOS XE, Terminal Service (TS) Agent, Catalyst SD-WAN Manager, RoomOS, and IMC.

Of these, CVE-2026-20200 (CVSS score of 8.8) deserves special attention. It is a high-severity improper validation of user-supplied input issue in IMC that could be exploited remotely to execute arbitrary commands and gain root privileges.

While the flaw’s exploitation requires authentication, proof-of-concept (PoC) code targeting it exists, Cisco warns. The weakness affects UCS C-Series M7 and M8 Rack Servers in standalone mode.

Cisco says it is not aware of any of these vulnerabilities being exploited in the wild. Additional information can be found on the company’s security advisories page.

Related: Hackers Start Exploiting Recent JetBrains TeamCity Vulnerability

Related: Decades-Old BMC Vulnerability Exposes Thousands of Data Centers to Attacks

Related: N‑able Patches Vulnerability Exploited to Hack N-central Servers

Related: Ruby on Rails Patches Critical Vulnerability

https://www.securityweek.com/cisco-patches-critical-sd-wan-ios-xe-fmc-vulnerabilities/