Exploit generati dall'IA contro i PLC Siemens S7: dentro l'allerta AA26-231A

Nelle notti del 26 e 27 luglio 2026, oltre trenta sistemi idrici e di trattamento acque reflue in Minnesota sono stati sondati e manipolati nello stesso fine settimana, e l'impianto di trattamento di una città è stato temporaneamente messo fuori servizio. Tre settimane dopo, cinque agenzie federali statunitensi — NSA, CISA, FBI, Department of Energy ed EPA — hanno pubblicato un advisory congiunto che ne indica l'acceleratore: gli attaccanti ora usano l'IA per scrivere il codice dell'exploit contro i controllori logici programmabili Siemens S7 esposti su internet. L'advisory, AA26-231A, non usa mezzi termini. "Non è un rischio teorico — è una minaccia attiva."

Vale la pena fermarsi su quella frase, perché il settore ha passato due anni a chiedersi se l'IA avrebbe mai prodotto un exploit funzionante contro un bersaglio reale. Il dibattito è chiuso. È successo, e contro la classe di dispositivi più difficile da difendere e meno capace di difendersi: un controllore industriale che regola la pressione in una condotta di acqua potabile.

Cosa dice davvero l'advisory AA26-231A

Togliamo l'etichetta "AI-powered" su cui si è appoggiata la copertura di cronaca e leggiamo cosa hanno documentato le agenzie. Gli attaccanti stanno generando tool Python su misura che dialogano con i PLC Siemens S7 tramite la libreria open-source python-snap7 e la sottostante snap7.dll. Gli script comunicano su S7comm, il protocollo nativo Siemens, e sono confezionati per sembrare software legittimo di monitoraggio OT. Una volta connessi, leggono e scrivono memoria del PLC, dati di configurazione e programmi di logica ladder — il codice di controllo che decide se una pompa parte o una valvola apre.

I modelli colpiti coprono quasi l'intero parco installato: S7-200, S7-300 (le CPU 314/315/317), S7-400, la linea S7-1200 (dalla 1211C alla 1217C) e la serie S7-1500 — compresi i controllori di sicurezza F-series, il cui unico compito è impedire che un processo raggiunga uno stato pericoloso. I settori bersaglio includono acqua e acque reflue, energia, manifatturiero critico, chimico, agroalimentare e strutture commerciali.

La sintesi delle agenzie è la parte che chi difende dovrebbe citare al proprio board:

La combinazione di vulnerabilità note, librerie di sfruttamento accessibili e sviluppo assistito dall'IA crea uno scenario d'attacco ad alta probabilità contro installazioni di PLC inadeguatamente protette.

Leggetela come un'equazione. Nessuno dei tre ingredienti è nuovo. python-snap7 è su GitHub da anni. Le debolezze di S7comm hanno un decennio. Ciò che è cambiato è il terzo termine — il costo di trasformare i primi due in un tool funzionante e specifico per il bersaglio è crollato quasi a zero.

Perché Siemens S7 è il bersaglio perfetto per un'IA che scrive exploit

C'è un motivo per cui i modelli hanno convergito su questo protocollo, e non è la sofisticazione. È l'opposto.

Il classico S7comm — il dialetto parlato dalle famiglie S7-300 e S7-400 che ancora fanno girare gran parte delle infrastrutture idriche ed energetiche del mondo — non ha alcun concetto di utente o di sessione. Non c'è nulla contro cui autenticarsi. Raggiungere il dispositivo sulla porta TCP 102 (ISO-TSAP) è l'autorizzazione. Se riesci a instradare un pacchetto verso di lui, puoi impartirgli comandi. Le linee più recenti S7-1200 e S7-1500 hanno aggiunto livelli di protezione d'accesso e TLS opzionale, ma sul campo vengono spesso installate al livello di default con la comunicazione legacy PUT/GET abilitata per retrocompatibilità, il che riapre la stessa porta.

Aggiungiamo l'esposizione. I dati pubblici di Shodan mostrano ancora nell'ordine di 74.000 dispositivi ICS direttamente raggiungibili da internet, molti con credenziali di default o assenti. Gli attaccanti non devono nemmeno cercarli: l'advisory nota l'attività di ricognizione tramite servizi commerciali di scansione come Censys e ZoomEye, che hanno già indicizzato la porta 102 per loro.

Per un modello linguistico a cui si chiede di "scrivere un tool Python che legge e scrive logica ladder su un Siemens S7-300 via S7comm", questo è vicino al compito offensivo più facile immaginabile:

• Il protocollo è documentato e stabile.
• Una libreria matura (python-snap7) lo incapsula già.
• Non c'è logica di autenticazione da battere — niente fuzzing, niente memory corruption, nessun primitivo d'exploit da sviluppare.
• Migliaia di bersagli vivi e indirizzabili sono pre-indicizzati da terze parti.

L'IA qui non sta scoprendo uno zero-day. Sta facendo qualcosa di più corrosivo: rimuove l'ultima barriera rimasta — la conoscenza OT specialistica e le ore di scripting — che teneva un attaccante di medio livello lontano da un sistema di controllo. Questo è il contenuto reale di AA26-231A.

Da Aliquippa al Minnesota: lo schema che l'IA ha appena accelerato

Non è la prima volta che un gruppo allineato all'Iran entra in un'utility idrica statunitense attraverso un PLC. Nel novembre 2023 la persona CyberAv3ngers, attribuita al Cyber Electronic Command dell'IRGC, ha compromesso almeno 75 PLC Unitronics Vision esposti su internet negli USA, in Israele, nel Regno Unito e in Irlanda. Uno di questi regolava una stazione di rilancio della Municipal Water Authority di Aliquippa, Pennsylvania. L'intero "exploit" era la password di default di fabbrica del dispositivo. CISA lo ha documentato nell'advisory AA23-335A.

L'ondata del Minnesota 2026 — oltre 30 sistemi in un solo weekend, di nuovo con sospetto coinvolgimento di CyberAv3ngers — è lo stesso copione con lo sforzo rimosso. Nel 2023, colpire 75 dispositivi in quattro paesi era una campagna manuale. Nel 2026, generare uno script per famiglia Siemens e puntarlo su un export di Censys è il lavoro di un pomeriggio. Il divario tra queste due operazioni è esattamente il divario che un assistente IA colma.

	Aliquippa, nov 2023	Minnesota, lug 2026
Bersaglio	PLC Unitronics Vision	PLC Siemens S7
Ingresso	Password di default di fabbrica	Esposizione internet + credenziali deboli/default
Strumenti	Manuali, hands-on-keyboard	Script python-snap7 generati dall'IA
Scala	~75 dispositivi, una campagna	30+ sistemi in un weekend
Camuffamento	Nessuno	Confezionati come tool di "monitoraggio" OT

Cosa cambia davvero il "generato dall'IA"

È tentante liquidarlo come marketing — le agenzie che mettono "IA" in un titolo. È una lettura sbagliata, e i dettagli operativi mostrano perché.

Primo, la soglia di competenza crolla. Scrivere un client S7comm corretto che manipola la logica ladder senza mandare in blocco la CPU richiedeva qualcuno che capisse sia il protocollo sia il processo. Un modello che ha ingerito la documentazione di python-snap7 e qualche thread di forum produce quel tool su richiesta, e itera quando restituisce un errore.

Secondo, il tool è modellato per mimetizzarsi. L'advisory segnala espressamente che gli script si spacciano per software legittimo di monitoraggio OT. Un tecnico che vede un processo eseguire python-snap7 e interrogare i PLC vede esattamente ciò che sembra un historian o un poller SCADA reale. La lettura/scrittura malevola si confonde con quella legittima.

Terzo, e più importante per chi difende: niente di tutto questo è patchabile secondo il tuo calendario. Non puoi riavviare il PLC di un impianto di trattamento acque un martedì per installare una correzione. Molti dispositivi colpiti sono anni oltre l'ultimo aggiornamento firmware e non ne riceveranno mai un altro. La prima raccomandazione dell'advisory non è "aggiorna" — è "assicurati che i controllori non siano accessibili da internet". Quando la mitigazione principale è "staccalo dalla cosa a cui non avrebbe mai dovuto essere collegato", stai gestendo un'esposizione di progetto, non un bug software.

Remediation

Trattate AA26-231A come un mandato di caccia e hardening, non come un ticket di patch. Il PDF completo dell'advisory è la fonte autorevole; il runbook qui sotto ne è la distillazione operativa.

1. Sono esposto? Inventariate ogni S7-200/300/400/1200/1500 nel parco — compresi i controllori di sicurezza F-series. Da un host di engineering, verificate quali rispondono su TCP/102:

nmap -Pn -p 102 --open <sottorete-ot>/24

Poi verificate se qualcuno di quegli indirizzi è raggiungibile da fuori il confine OT. Cercate la vostra impronta esterna su Shodan/Censys con port:102 e i vostri range IP/ASN. Ogni riscontro è un incidente, non una finding.

2. Patch — lo stato corretto esatto. Qui non c'è un singolo fix CVE; la "patch" è una postura di configurazione e firmware:

• Aggiornate il firmware S7-1200/1500 all'ultima release e impostate il livello di protezione d'accesso su "Full protection" (nessun accesso anonimo).
• Disabilitate la comunicazione legacy PUT/GET su S7-1200/1500 salvo che un'applicazione specifica la richieda.
• Impostate una password PLC robusta e la protezione del progetto TIA Portal; ritirate ogni dispositivo ancora ai default di fabbrica.
• Per S7-300/400, che non possono imporre autenticazione, considerate l'hardening firmware insufficiente da solo e passate direttamente all'isolamento.

3. Non puoi patchare ora? — controlli compensativi.

• Rimuovete la porta 102 da ogni percorso esposto a internet. Nessun S7comm deve mai attraversare il perimetro.
• Imponete un confine di segmentazione hardware o firewall; consentite S7comm solo da workstation di engineering nominate, tramite ACL allow-list esplicite.
• Distribuite un data diode o gateway unidirezionale per ogni monitoraggio che debba passare da OT a IT.
• Limitate chi può raggiungere la VLAN di engineering; eliminate le reti flat dove un HMI compromesso può parlare con ogni controllore.

4. Caccia alla compromissione — segnali e ATT&CK for ICS. Il lato scrittura di S7comm è dove vive il danno. Cercatelo sul filo e nei log di engineering:

• Nuove sessioni TCP/102 da host che non sono stazioni di engineering designate — mappa su T0883 (Internet Accessible Device) e T0812 (Default Credentials).
• Function code S7comm di scrittura / program download verso controllori fuori da una finestra di change — T0843 (Program Download) e T0836 (Modify Parameter).
• Messaggi di comando STOP-CPU emessi fuori dalla manutenzione — T0855 (Unauthorized Command Message), precursore di T0814 (Denial of Service).
• Connessioni in ingresso da range di scanner Censys/ZoomEye noti che colpiscono la porta 102.
• Un processo che si chiama o si comporta come software di monitoraggio OT ma proviene da un host o utente inatteso — la firma del "tool camuffato".

5. Bonifica + verifica. Se trovate scritture non autorizzate: catturate la logica ladder corrente, confrontatela byte per byte con la vostra baseline di engineering nota-buona, e ri-scaricate il programma verificato dal controllo di versione — non fidatevi mai della copia sul dispositivo. Ruotate ogni credenziale di PLC e di stazione di engineering. Poi confermate la pulizia dopo la ri-segmentazione, verificando che non resti alcun percorso esterno verso la porta 102 e che nei nuovi log di sessione S7comm compaiano solo host in allow-list.

La rete è l'unico posto dove lo vedrai

Ecco la verità scomoda che AA26-231A impone: non puoi mettere un agente su un S7-300. Non esiste un EDR per un controllore del 2009. Il dispositivo parla un protocollo senza login, non può essere patchato secondo i tuoi tempi, e il traffico malevolo è modellato per sembrare il traffico di monitoraggio che ti aspetti. L'unica superficie dove una scrittura non autorizzata alla logica ladder, un comando STOP-CPU o una scansione a tappeto sulla porta 102 diventano visibili mentre accadono è la rete stessa.

È esattamente il caso per cui è stata costruita l'AI Traffic Analysis di Zero Hunt. Un modello di deep learning proprietario con quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco e fingerprinting applicativo — gira localmente sulla GPU dell'appliance a 2,7+ Gbit/s, senza alcun callback verso il cloud. Legge le anomalie di protocollo OT/ICS in modo comportamentale: un comando di scrittura S7comm da un host che non ha mai parlato S7comm prima, un program download fuori da una finestra di change, la firma di fan-out di uno script che spazza la porta 102 su una sottorete. Segnala la manipolazione mentre attraversa il filo — non nel digest del SIEM della mattina dopo, quando una pompa ha già girato a secco.

Il complemento è trovare l'esposizione prima che lo faccia l'IA dell'avversario. Lo swarm generativo a 10 agenti di Zero Hunt con le campagne change-triggered tratta un PLC appena esposto su internet come un innesco: un nuovo asset sul perimetro lancia una campagna completa di validazione entro l'ora, e gli agenti Recon ed Exploit dimostrano quali dei tuoi controllori S7 sono davvero raggiungibili e con credenziali di default — lo stesso ragionamento che esegue il modello dell'attaccante, eseguito prima dalla tua parte, con ogni finding firmata ECDSA per la catena di evidenze che gli operatori idrici ed energetici oggi devono produrre per EPA, AWIA e NIS2. L'attaccante ha automatizzato la scrittura dell'exploit. L'unica risposta durevole è automatizzare il vedere e il validare — in modo continuo, sull'unica superficie da cui un PLC non può nascondersi.