Advisory AA26-231A: minaccia attiva sui PLC Siemens S7, script di attacco generati con AI

Cosa dice l'advisory

Il 19 agosto 2026 National Security Agency, CISA, FBI, Department of Energy ed Environmental Protection Agency hanno pubblicato l'advisory congiunto AA26-231A su una minaccia attiva contro i PLC Siemens S7 Series esposti su internet o insufficientemente segmentati.

Il testo è esplicito su un punto: "This is not a theoretical risk, it is an active threat." Non è un bollettino di vulnerabilità, è la descrizione di attività in corso.

Ed è altrettanto esplicito su un secondo punto, che vale la pena leggere prima di tutto il resto: l'attività di targeting sui PLC è più ampia dei soli Siemens. La parte Siemens-specifica va intesa come un sottoinsieme di un fenomeno più vasto, e le agenzie chiedono a tutti i proprietari di PLC, di qualsiasi marca, di applicare le mitigazioni pertinenti.

I modelli oggetto di targeting attivo:

• S7-200 Series, tutte le varianti CPU
• S7-300 Series, tutte le varianti CPU incluse 314, 315, 317
• S7-400 Series, tutte le varianti CPU
• S7-1200 Series, CPU 1211C, 1212C, 1214C, 1215C, 1217C
• S7-1500 Series, tutte le varianti CPU, inclusi i controllori di safety serie F

I settori più colpiti negli Stati Uniti sono critical manufacturing, energia, acqua e acque reflue, chimico, alimentare e agricoltura, strutture commerciali, con esposizione potenziale anche della base industriale della difesa. La sovrapposizione con il tessuto industriale italiano è quasi totale.

Come funziona la catena

L'advisory descrive un flusso semplice e per questo efficace.

Ricognizione tramite servizi di scansione internet. Gli attori usano piattaforme come Censys e ZoomEye (T1596.005) per trovare PLC S7 esposti con software non aggiornato o mal protetti. Nessuna scansione propria, nessun rumore: interrogano un database già pronto.

Sviluppo di exploit assistito da AI. Gli attori generano script con l'aiuto dell'AI a partire da informazioni pubbliche sui PLC S7, iterando rapidamente sul codice (T1587.004, T1588.007). L'advisory qualifica questo passaggio come evoluzione delle capacità degli attori, perché riduce drasticamente competenza tecnica e tempo necessari a produrre tool ICS funzionanti, e permette di adattarsi in fretta alle contromisure difensive.

Credenziali insicure. Molti dispositivi esposti hanno autenticazione non configurata o configurata al minimo (T1694). Non è che l'autenticazione non esista: non è stata accesa.

Script Python su snap7. Gli script generati incorporano la libreria snap7.dll / python-snap7 presa da repository pubblici (T0834) e ottengono accesso in lettura e scrittura a memoria, dati di configurazione e programmi in logica ladder tramite protocollo S7comm, porta TCP 102.

Mascheramento da tool di monitoraggio. Gli script sono deliberatamente costruiti per somigliare a soluzioni legittime di monitoraggio OT ed eludere i team di sicurezza (T0849).

Lettura e scrittura sui data block (T0893, T0821), per ricognizione, test delle capacità o pre-posizionamento.

La valutazione delle agenzie sull'ultimo punto è la parte che dovrebbe interessare più di ogni altra chi gestisce un impianto: si tratta con buona probabilità di ricognizione persistente finalizzata a preparare effetti operativi su infrastrutture critiche. L'accesso in lettura serve a capire l'ambiente, per poi posizionarsi in vista di future operazioni di scrittura.

Nessun CVE nuovo, e questa è la notizia

L'advisory non nomina un solo CVE. Siemens, interpellata dalla stampa, ha dichiarato di non aver rilevato né livelli di attacco crescenti né vulnerabilità sconosciute nei propri prodotti ICS: gli attacchi sfruttano configurazioni errate già note.

Entrambe le affermazioni sono compatibili, e insieme dicono la cosa importante. Gli ingredienti erano tutti già sul tavolo: python-snap7 è pubblico da anni, i PLC su internet sono un problema documentato, la password protection dei PLC esiste da sempre e spesso non viene attivata. Quello che è cambiato è il costo di ingresso. Scrivere un tool che interroga e scrive su un S7-300 richiedeva competenze di automazione industriale; oggi non più.

È lo stesso meccanismo descritto parlando di AI, dal payload all'APT: l'AI non crea vulnerabilità inedite, allarga la platea di chi può sfruttare quelle esistenti. Il che cambia il profilo di rischio anche per chi si considerava troppo piccolo per interessare a un attore statale.

Cosa cercare: le detection opportunity

Questa è la sezione più utile dell'advisory, perché uno script mascherato da tool di monitoraggio genera traffico che assomiglia a traffico legittimo. Non lo distingue la firma, lo distingue il contesto. Le agenzie indicano cinque famiglie di anomalie da cacciare:

• Comportamento S7comm anomalo: connessioni da host che non sono workstation di engineering, pattern insoliti di accesso ai data block, operazioni di scrittura fuori dalle finestre di change.
• Indicatori di ricognizione: scansione sequenziale di IP sulla porta 102, tentativi di connessione ripetuti con parametri variabili, enumerazione delle proprietà della CPU.
• Artefatti dei tool: uso di snap7.dll fuori dalle workstation di engineering approvate, script Python con funzionalità S7comm, installazioni di software di monitoraggio non autorizzate.
• Anomalie temporali: attività S7comm fuori orario, pattern di connessione coerenti con uno script automatico più che con un operatore umano, modifiche di configurazione senza work order o ticket di change corrispondente.
• Anomalie geografiche: connessioni da paesi o range IP non associati a fornitori o integratori.

Il filo comune è che nessuna di queste è rilevabile senza una baseline del traffico OT. Sapere che una scrittura su data block è anomala richiede sapere com'è fatta una giornata normale su quella rete.

Le mitigazioni, in ordine di ritorno

L'advisory elenca sette gruppi di azioni di hardening. In sintesi, con i dettagli che contano:

1. Inventario immediato dei PLC S7: verificare le versioni firmware contro la gold copy di backup, identificare i sistemi raggiungibili direttamente o indirettamente da reti non fidate, mappare tutte le workstation con TIA Portal, STEP 7 o accesso di programmazione S7.
2. Patch: firmware alle versioni più recenti, priorità ai controllori internet-facing o in DMZ, aggiornare anche TIA Portal e STEP 7, consultare gli advisory Siemens ProductCERT, testare in ambiente di sviluppo prima della produzione.
3. Segmentazione: audit delle regole firewall alla ricerca di servizi S7comm esposti, blocco totale della porta TCP 102 sui firewall perimetrali, architettura DMZ tra OT e IT, gateway unidirezionali per le connessioni verso l'historian, verifica che non esista routing non autorizzato tra rete aziendale e industriale.
4. Controlli di accesso: allowlist MAC/IP sui PLC per limitare l'accesso TIA Portal/STEP 7 alle sole postazioni autorizzate, password protection attiva su tutti gli S7, protection level configurati (protezione in scrittura o in lettura/scrittura), rimozione delle community string SNMP di default, application allowlisting sulle workstation di engineering, MFA su ogni accesso remoto OT.
5. Logging e monitoraggio: IDS ICS-aware, monitoraggio di tutto il traffico S7comm su porta 102 fuori dalle finestre di manutenzione, alert sulle operazioni PUT/GET non autorizzate (in particolare scritture su data block e aree di configurazione), log di tutte le connessioni TIA Portal/STEP 7 con timestamp e IP sorgente, baseline del comportamento legittimo e alert sulle deviazioni, monitoraggio dei processi Python che importano snap7.dll.
6. Hardening specifico S7: disabilitare i web server se non serviti operativamente, disabilitare i protocolli non usati (Modbus TCP, PROFINET se non necessari), limitare le sessioni S7comm simultanee tramite le connection resource, attivare complete restart protection e know-how protection dove disponibili, verificare le modifiche alla logica ladder in modalità online e offline.
7. Siemens: coinvolgere il supporto tecnico per indicazioni specifiche per modello CPU e versione firmware, verificare la compatibilità delle patch con l'ambiente e le integrazioni di terze parti.

Un avvertimento che l'advisory ripete due volte merita attenzione particolare: queste mitigazioni sono particolarmente importanti per chi lavora con service provider o system integrator che hanno accesso remoto ai PLC, perché l'asset owner può semplicemente non sapere di essere esposto. Le agenzie chiedono di condividere l'advisory con quei soggetti e pretendere l'implementazione.

Nota per i lettori italiani: le indicazioni di incident reporting nell'advisory sono rivolte a CISA, FBI e DOE. In Italia il canale è quello di ACN e CSIRT Italia, con le tempistiche di notifica previste da NIS2 per i soggetti in perimetro.

Le tre verifiche da chiudere questa settimana

• Cercare la porta 102 esposta dall'esterno, non sul foglio Excel della segmentazione. Includere gli accessi remoti dei fornitori e i router 4G installati per un intervento e mai rimossi.
• Contare i PLC S7 realmente presenti: modello, firmware, chi ci parla. Se il numero non coincide con l'inventario ufficiale, il problema precede l'advisory.
• Chiedersi se una scrittura S7comm da un host nuovo genererebbe un alert. Se la risposta è no, l'advisory descrive uno scenario che non sareste in grado di vedere.

La risorsa

L'advisory completo, con le mappature MITRE ATT&CK for ICS e D3FEND in appendice, è disponibile qui:

• Defending Against an Active Threat to Siemens S7 Series PLCs, PDF ufficiale (AA26-231A)
• Pagina CISA dell'advisory

L'angolo MON5

Le detection opportunity dell'advisory descrivono, punto per punto, quello che si vede solo osservando il traffico OT in continuo: connessioni S7comm da host inattesi, scritture su data block fuori finestra, pattern di scansione sulla porta 102, attività fuori orario con la firma temporale di uno script e non di un operatore.

MON5 fa NDR passivo fuori banda sui protocolli industriali nativi, Siemens S7 incluso, con anomaly detection sulla baseline operativa. È l'approccio che risponde alla richiesta del punto 5 delle mitigazioni senza toccare i PLC: nessun agent, nessun polling attivo, nessuna sessione S7comm aggiuntiva su controllori che ne hanno un numero limitato.

Il punto di partenza però resta l'inventario, non lo strumento. Un assessment OT chiude in poche settimane le tre verifiche elencate sopra, senza fermare la produzione.