Attacchi con l’IA: cosa cambia e cosa continua a proteggere

Dal 2025 è documentato che chi attacca non usa più i modelli linguistici soltanto per e-mail di phishing estremamente credibili, ma fa eseguire loro anche attacchi da prendere decisamente sul serio. Per la gestione di siti web e server, però, questo cambia meno di quanto suggeriscano molti titoli — in un punto, tuttavia, cambia parecchio: la velocità.

Cosa è documentato

Nel novembre 2025 Anthropic, l’azienda che sviluppa il modello linguistico Claude, ha descritto la prima campagna di attacchi documentata eseguita in gran parte da un’IA. Un gruppo sostenuto da uno Stato ha attaccato circa 30 organizzazioni, tra cui aziende tecnologiche, istituti finanziari e autorità pubbliche. Secondo l’analisi di Anthropic, l’IA ha svolto dall’80 al 90 per cento del lavoro, mentre le persone prendevano decisioni solo occasionalmente. In un piccolo numero di casi l’intrusione è effettivamente riuscita.¹

Quasi un anno dopo non si tratta più di un caso isolato. Il rapporto di Anthropic del settembre 2026 descrive intrusioni portate a termine nel giro di ore e singoli autori che prendevano di mira decine di obiettivi in parallelo. Un caso riguarda direttamente i siti web: un singolo autore ha sviluppato con l’aiuto dell’IA un attacco a una vulnerabilità fino ad allora sconosciuta, che interessa la reinstallazione di WordPress. In questo modo è riuscito a creare un account amministratore senza credenziali valide — con successo su almeno quattro siti web. Inoltre ha manipolato i backup di una vittima in modo che un ripristino gli avrebbe subito restituito l’accesso al sistema.²

Nel maggio 2026 il Threat Intelligence Group di Google ha individuato per la prima volta un exploit zero-day che, secondo la sua valutazione, era stato sviluppato con l’IA: un aggiramento dell’autenticazione a due fattori in un diffuso strumento open source per l’amministrazione di sistemi via browser, destinato a un attacco su larga scala. Questo codice d’attacco è stato intercettato ancora in fase di pianificazione, prima di essere impiegato. Ciò che Google descrive in questi due rapporti è un’autonomia in singole fasi — agenti che trovano le falle da soli e malware che prosegue autonomamente su un dispositivo già compromesso —, non un attacco completo che più nessuno guida.^{3, 4}

La stessa capacità, però, è a disposizione anche di chi difende. Nel 2025 Big Sleep, l’agente IA di Google, ha scoperto nel database SQLite una falla critica che, secondo Google, era nota solo agli aggressori. Questo però serve solo a chi poi installa davvero la correzione.⁵

Cosa cambia: velocità e quantità

Un attacco è fatto di molti piccoli passi: individuare i servizi, riconoscerne le versioni, cercare una falla adatta, modificare il codice d’attacco, analizzare le risposte, proseguire. Finora per la maggior parte di questi servivano persone con esperienza e tempo. Un modello linguistico ne sbriga molti in pochi secondi, giorno e notte e contro molti obiettivi contemporaneamente.

Lo si vede più chiaramente nel tempo che intercorre tra la divulgazione di una falla e il suo sfruttamento. Mandiant, la divisione di incident response di Google, ha misurato per il 2018 e il 2019 una media di 63 giorni, per il 2023 soltanto cinque. Nel rapporto M-Trends 2026 il valore medio stimato è di meno sette giorni: lo sfruttamento avviene regolarmente prima ancora che esista una patch. La tendenza è iniziata prima dell’IA, ma l’IA la accelera.^{6, 7}

Il Bundesamt für Sicherheit in der Informationstechnik (BSI), l’ufficio federale tedesco per la sicurezza informatica, constata nel giugno 2026 che con l’IA, partendo da una patch pubblicata, si può ricavare nel giro di minuti o di ore come deve essere fatto un attacco. La sua conclusione: le organizzazioni devono essere in grado di esaminare e valutare le vulnerabilità e, se necessario, installare le patch nel giro di minuti o al massimo di poche ore. Pochi giorni, secondo il BSI, non sono un tempo di reazione adeguato.⁸

Il secondo cambiamento riguarda la scelta degli obiettivi. Se un attacco richiede meno lavoro, diventano interessanti anche obiettivi finora troppo piccoli — è esattamente lo spostamento che descrive Anthropic. L’idea che un piccolo sito web non interessi agli aggressori è sempre stata azzardata. Oggi è semplicemente sbagliata: gli attacchi automatizzati non scelgono necessariamente in base all’importanza, ma in base alla raggiungibilità.²

Cosa non cambia: perché gli attacchi riescono

Colpisce ciò che manca in questi rapporti: nuove tecniche di attacco. Anthropic scrive esplicitamente che nessuna delle operazioni descritte si basava su una tecnica mai vista prima da chi difende. Si tratta delle solite porte d’ingresso — credenziali rubate, dispositivi non aggiornati al perimetro della rete, servizi raggiungibili apertamente, codice di database iniettato (SQL injection), phishing. Mandiant giunge alla stessa conclusione per il 2025: la grande maggioranza delle intrusioni riuscite continua a derivare da errori umani e sistemici di base, non dall’IA in sé.^{2, 7}

Per i siti web un dato è particolarmente eloquente: secondo VulnCheck, nel primo semestre 2026 i sistemi di gestione dei contenuti rappresentavano un terzo di tutte le vulnerabilità che VulnCheck ha inserito per la prima volta nel suo elenco di falle sfruttate attivamente. Ogni estensione installata ma non utilizzata amplia la superficie d’attacco senza apportare nulla.⁹

Ne deriva il messaggio centrale di questo articolo: contro gli attacchi con l’IA non serve necessariamente un nuovo tipo di protezione. Aiuta ciò che ha sempre aiutato. Solo che oggi la sicurezza va ripensata: senza lacune, automatizzata e monitorata con costanza.

Più livelli anziché una soluzione miracolosa

Purtroppo non possiamo indicare qui un’unica misura che, una volta attuata, risolva tutti i problemi e renda sicuri tutti i sistemi. Puntiamo quindi su un modello a livelli: ogni livello intercetta una parte, e ognuno parte dal presupposto che quello precedente abbia fallito. È così che gestiamo i siti web e le applicazioni che ospitiamo per i nostri clienti, e anche i nostri. Nelle sezioni seguenti entriamo nel dettaglio di questi livelli.

L’«edge»: web application firewall e CrowdSec

Ogni richiesta a uno dei nostri servizi web raggiungibili pubblicamente passa prima attraverso un web application firewall (WAF): ModSecurity con l’OWASP Core Rule Set, una raccolta di regole curata in comune (da una comunità globale) contro gli schemi di attacco più diffusi — codice di database iniettato, script estranei, accessi a file al di fuori dell’area consentita. Le regole riconoscono schemi, non la singola vulnerabilità concreta. Per questo fermano anche una parte degli attacchi a vulnerabilità per le quali non esiste ancora una patch. Così guadagniamo tempo di cui non sapevamo nemmeno che avremmo avuto bisogno.

Accanto al WAF, CrowdSec analizza i log e riconosce comportamenti anziché singole richieste: chi cerca sistematicamente interfacce di amministrazione, prova una password dopo l’altra o sonda i server alla ricerca di falle note. Questi indirizzi vengono bloccati prima di raggiungere il sito web. A ciò si aggiunge la rete: chi utilizza CrowdSec condivide gli attacchi rilevati e riceve in cambio una lista di blocco gestita in comune. Un indirizzo che attacca altrove può così essere già bloccato da noi prima ancora di inviare la prima richiesta.

Contro l’automazione questo funziona particolarmente bene, perché l’automazione lascia tracce. Chi invia migliaia di richieste in poco tempo genera uno schema — indipendentemente dal fatto che dietro ci sia una persona con uno script o un modello linguistico.

Sul server: solo ciò che serve

L’accesso SSH ai nostri server non è possibile con password, né come «root», né con utenti qualsiasi. È possibile solo con una chiave crittografica e solo per i pochi utenti, definiti in modo fisso, che sono autorizzati ad accedere; gli indirizzi che si sono già distinti altrove per attacchi vengono scartati dal firewall ancora prima. E il firewall, per principio, non lascia entrare proprio nulla: è aperto solo ciò che serve davvero. Gestiamo gli accessi in modo centralizzato, e chi non ne fa più parte li perde su tutti i server. Tutto questo è predisposto come Infrastructure as Code (IaC) e configurato allo stesso modo su ogni server, mai a mano.

Contro i tentativi di indovinare le password — uno dei primi compiti che si possono delegare a una macchina — non aiuta quindi una password migliore, ma nessuna password.

Nel container: meno privilegi possibile

Le applicazioni stesse girano ciascuna isolata in container, e ogni container ha solo i privilegi di cui ha bisogno per funzionare: il file system è in sola lettura, tranne le directory in cui devono trovarsi i dati. Il container non gira per principio mai con privilegi di root, ha un limite fisso di memoria di lavoro e si trova in una propria rete, separata dai container di altri clienti. Chi sfrutta una falla nell’applicazione non può sovrascrivere il codice del programma e non ha nemmeno una possibilità diretta di comunicare con i container di altri clienti e di comprometterli.

Altrettanto importante è ciò che nel container non c’è proprio. Gli strumenti che servono per la build ma non per il funzionamento lì non hanno nulla da fare. Nel settembre 2026 la sola rimozione del gestore di pacchetti e dei suoi programmi ausiliari dall’immagine del nostro sito web ha eliminato 38 segnalazioni di gravità critica e alta dello scanner di vulnerabilità. Per non parlare del fatto che l’assenza di strumenti ostacola o addirittura impedisce i tentativi di compromissione. Perché ciò che non è disponibile non può essere sfruttato.

In esercizio: sapere anziché presumere

Un server non è sicuro solo perché lo era al momento della configurazione. Ogni notte uno scanner (Trivy) controlla i pacchetti installati su tutti i server e tutte le immagini container in esecuzione alla ricerca di vulnerabilità note. Gli aggiornamenti di sicurezza dei server si installano automaticamente ogni giorno; se uno resta in sospeso per più di un ciclo, scatta un avviso del monitoraggio.

Così, nel settembre 2026, abbiamo portato l’immagine del nostro sito web da 5 vulnerabilità critiche e 51 alte a zero — un dato misurato, non stimato.

Resta comunque una finestra temporale: tra la pubblicazione di una falla e l’aggiornamento successivo, e a maggior ragione prima. Nessun processo di aggiornamento può chiuderla del tutto. Gli altri livelli servono proprio a questa finestra — il WAF, che riconosce gli schemi di attacco senza conoscere la falla, e i privilegi ridotti al minimo, che limitano ciò che un attacco riuscito può provocare.

Per l’emergenza: backup che un aggressore non può cancellare

Chi ha preso il controllo di un server spesso tenta subito dopo di cancellare o modificare i backup; il caso WordPress descritto sopra mostra come avviene. I nostri backup sono cifrati, si trovano su un altro server e vengono scritti in modalità «append-only»: un server sottoposto a backup può aggiungere nuovi salvataggi, ma non cancellare né sovrascrivere quelli esistenti. Le versioni precedenti restano così conservate, anche se un aggressore controlla completamente quel server.

Questo da solo non basta: bisogna anche sapere quale versione è pulita. Per questo i log dell’edge, dei server e delle applicazioni confluiscono su un server dedicato; mostrano da quando qualcuno era dentro. E il ripristino l’abbiamo provato. Backup che non vengono mai davvero validati fino in fondo sono più una speranza che una protezione.

Una protezione che colpisce le persone sbagliate

Ognuno di questi livelli può colpire anche visitatori reali. Nell’agosto 2026 il livello di protezione all’edge ha escluso dal nostro sito web singoli visitatori, ogni volta per un giorno intero. La causa era un unico file mancante: mancava la piccola icona nella scheda del browser (favicon), quindi ogni visualizzazione di pagina generava un messaggio di errore, ossia restituiva un 404, e una regola predefinita interpretava come attacco un numero sufficiente di errori 404 in un determinato intervallo di tempo. Nel frattempo questa regola è stata adattata in modo che qualche 404 sporadico non porti più direttamente al blocco di un visitatore innocente.

Nella stessa settimana la prima analisi ha mostrato chi visita effettivamente i siti web che gestiamo. Una lista di blocco fornita di serie respingeva praticamente tutte le richieste dei servizi di IA — in un solo giorno circa 370 da client che si presentavano come ChatGPT su richiesta di una persona: non un crawler che raccoglie contenuti, ma un servizio che voleva leggere una di queste pagine per dare una risposta. Per un’azienda che vuole rendere visibili i propri clienti nelle risposte dell’IA, era decisamente la protezione sbagliata. Da allora decidiamo noi, per ogni sito web, se i servizi di IA possono leggerlo: per niente, solo su richiesta di una persona o completamente (crawler inclusi).

Nessuno dei due casi è una nota a margine. Una protezione che tiene fuori i visitatori reali è controproducente e prima o poi viene disattivata del tutto, per non perdere altri clienti. Non è questo lo scopo. E bloccare indiscriminatamente tutto ciò che sembra una macchina non è una strategia di sicurezza, ma una decisione contro la propria visibilità e reperibilità.

Cosa potete verificare voi stessi

Con le domande seguenti si può valutare se i propri sistemi sono ben impostati. Ogni domanda a cui non si riesce a rispondere subito o con vera precisione indica che c’è bisogno di intervenire.

• Che cosa è raggiungibile dall’esterno? Interfacce di amministrazione usate principalmente all’interno, banche dati e altri accessi tramite password non vanno esposti apertamente su Internet.
• Come vi accorgete che uno dei vostri sistemi presenta una vulnerabilità di sicurezza?
• Quanto velocemente un aggiornamento di sicurezza arriva davvero sui vostri sistemi — e come sapete che è arrivato?
• Davanti all’applicazione c’è qualcosa che riconosce gli schemi di attacco e interviene prima che venga raggiunta l’applicazione stessa?
• Con quali privilegi gira l’applicazione, e ne ha davvero bisogno?
• Esiste un backup che nemmeno chi ha pieni diritti sul server può cancellare? Quando è stato fatto l’ultimo ripristino da quel backup?
• Chi viene allertato quando qualcosa non quadra — e chi decide cosa succede dopo?

L’IA ha reso gli attacchi più veloci ed economici, non inarrestabili. Ciò che aiuta a contrastarli è lo stesso di prima. Deve solo essere attuato e monitorato senza lacune.