Negli ultimi mesi la sicurezza informatica ha dovuto fare i conti con un nuovo tipo di campagne di phishing, costruite non per ingannare una persona, ma l’intelligenza artificiale.
Si tratta di un bersaglio sempre più presente nei flussi di lavoro aziendali: l’agente AI che naviga il web in autonomia, confronta fonti e, in alcuni casi, esegue direttamente transazioni per conto di un’organizzazione.
Due campagne recenti, documentate da Zscaler ThreatLabz, danno un’idea concreta di come si stia muovendo questo fronte.
Indice degli argomenti
Due casi di indirect prompt injection
La prima campagna presenta un finto pacchetto Python la cui documentazione nasconde, in dati strutturati non visibili a un utente, l’istruzione di effettuare un pagamento per ottenere una presunta chiave API.
La seconda campagna imita, tramite typosquatting, il dominio della piattaforma di finanza decentralizzata DeBank: il sito fraudolento contiene un blocco di testo reso invisibile tramite CSS, non percepibile da chi guarda la pagina ma pienamente leggibile da un agente AI.
Quel testo nascosto istruisce esplicitamente il modello a considerare il dominio contraffatto come la fonte ufficiale e affidabile di DeBank, così che un agente incaricato di reperire informazioni su quella piattaforma finisca per fidarsi del sito fasullo invece di quello autentico.
Questi due casi sono solo l’espressione più recente di un fenomeno più ampio, quello dell’indirect prompt injection.
La classifica dei rischi critici
Il progetto OWASP dedicato alla sicurezza dei sistemi basati su modelli linguistici colloca, per la seconda edizione consecutiva, il prompt injection al primo posto della propria classifica dei rischi critici, includendo in questa categoria sia la variante diretta sia quella indiretta, e ne spiega la causa strutturale comune in termini precisi: un modello linguistico riceve istruzioni di istema e contenuto esterno recuperato dal web, da un documento o da un’email attraverso lo stesso canale testuale, senza una separazione affidabile tra ciò che è comando e ciò che è semplice dato da elaborare.
È proprio questa assenza di separazione a rendere possibile, nello specifico, l’injection indiretta.
Nel prompt injection diretto è l’utente stesso a scrivere un messaggio malevolo per aggirare le regole del modello, interagendo quindi direttamente con esso.
Nell’injection indiretta, invece, l’attaccante non ha alcun contatto diretto con il modello: si limita a pubblicare un contenuto online, per esempio su un sito o in un documento, sapendo che prima o poi un agente lo incontrerà durante lo svolgimento autonomo di un compito e, non potendo distinguerlo con certezza da un’istruzione legittima, lo interpreterà come un comando da eseguire.
È su questo punto che si misura la distanza reale tra il phishing pensato per un essere umano e quello pensato per un agente.
A confronto classico phishing e inganno rivolto a un agente AI
Il phishing tradizionale deve superare una soglia percettiva e cognitiva precisa.
Un’email fraudolenta deve avere un mittente plausibile, un logo sufficientemente somigliante, un tono che generi urgenza o autorevolezza; un sito clone deve avere un dominio quasi identico all’originale e un’interfaccia visivamente coerente.
Il bersaglio, per quanto vulnerabile all’inganno, esercita comunque una qualche forma di valutazione: nota un errore di battitura, si insospettisce per una richiesta insolita, verifica il mittente.
L’intero impianto difensivo costruito negli ultimi vent’anni, dalla formazione anti-phishing ai filtri email basati su reputazione del dominio, si fonda sull’idea che esista un momento di scelta umana da correggere o rinforzare.
I tre piani che ampliano la superficie di attacco per l’agente AI
L’inganno rivolto a un agente elimina buona parte di questo impianto di riferimento, e lo fa su tre piani distinti.
Il primo riguarda il canale di esposizione. Il phishing classico arriva quasi sempre in modo diretto e mirato, l’injection indiretta, al contrario, si presenta come un’esposizione passiva e incidentale: un agente che esegue una ricerca tecnica legittima può incappare nel contenuto malevolo semplicemente nel corso del proprio lavoro ordinario, senza che nessuno gliel’abbia inviato.
Questo rende la superficie di attacco enormemente più estesa, perché qualunque pagina indicizzata sul web diventa un potenziale vettore.
Secondo piano: la natura del contenuto ingannevole
Il secondo piano riguarda la natura del contenuto ingannevole. Mentre un sito di phishing destinato ad umani deve investire risorse nella credibilità visiva, un sito costruito per ingannare un agente può affidarsi interamente a elementi invisibili all’occhio, ma leggibili da un parser: testo nascosto, dati strutturati in formato schema.org o JSON-LD normalmente destinati ai motori di ricerca, stringhe codificate in caratteri Unicode a larghezza zero.
Una ricerca di Unit 42, la divisione di threat intelligence di Palo Alto Networks, ha catalogato queste tecniche, distinguendo i metodi di occultamento del payload da quelli pensati per eludere i filtri di sicurezza, come istruzioni formulate in più lingue o frammentate su più attributi HTML per non essere riconosciute da un pattern matching semplice.
Il repertorio individuato mostra un livello di standardizzazione che va oltre la sperimentazione isolata: sono tecniche già catalogate, documentate e replicabili, al punto che Zscaler segnala l’esistenza di una decina di repository pubblici collegati a varianti delle stesse campagne.
Terzo piano: il meccanismo di fiducia
Il terzo piano riguarda il meccanismo di fiducia. Un utente umano normalmente si fida meno di un mittente sconosciuto, di un dominio mai visitato, di una richiesta che esce dagli schemi consueti.
Un agente, salvo controlli espliciti implementati dagli sviluppatori, tende a trattare come attendibile qualunque contenuto rientri nel proprio contesto operativo nel momento in cui esegue un compito.
Indirect prompt injection, una sfida cyber di lungo periodo
Anche i produttori dei principali modelli AI riconoscono la natura strutturale di questo problema.
OpenAI, descrivendo il lavoro di irrobustimento del proprio browser agentico ChatGPT Atlas, definisce il prompt injection una sfida di sicurezza di lungo periodo, paragonabile per certi versi al phishing tradizionale, nel senso che nessuno dei due fenomeni viene eliminato una volta per tutte, ma richiede un contenimento continuo attraverso livelli di difesa progressivi.
La differenza è che al phishing destinato alle persone sono stati dedicati decenni di formazione, normative e strumenti di verifica costruiti attorno al comportamento umano. Invece le difese equivalenti per gli agenti sono ancora in fase di definizione.
Misure operative per mitigare l’Indirect prompt injection
Per le organizzazioni che hanno già integrato agenti, con accesso a strumenti di pagamento o di approvvigionamento, questa differenza di natura richiede misure operative specifiche, distinte da quelle pensate per il phishing tradizionale.
Per esempio, la conferma umana obbligatoria sopra una soglia di importo rappresenta una prima barriera. Ma va accompagnata da un limite aggregato calcolato su un intervallo temporale definito, perché un limite fissato sulla singola transazione può essere aggirato tramite pagamenti multipli di importo ridotto.
Le eventuali whitelist di domini o fornitori verificati per le azioni sensibili dovrebbero basarsi su un elenco gestito e aggiornato centralmente, non sulla valutazione dell’agente stesso circa l’affidabilità di un dominio incontrato durante la navigazione, proprio perché quella valutazione è il punto debole sfruttato dall’attacco.
La separazione dei permessi tra lo strumento di navigazione e quello di autorizzazione dei pagamenti, spesso indicata come sandboxing, evita che lo stesso contesto operativo dell’agente disponga simultaneamente della capacità di leggere contenuti web non verificati e di autorizzare un trasferimento di fondi.
Una sanificazione preventiva del contenuto prima che raggiunga il modello, con rimozione di tag nascosti e normalizzazione dei caratteri Unicode anomali, riduce ulteriormente la superficie disponibile per l’injection, pur senza eliminarla del tutto.
Un sistema di log dettagliato, capace di ricostruire quale contenuto specifico ha portato l’agente a una determinata decisione, resta infine essenziale per l’analisi forense successiva a un eventuale incidente, in un contesto in cui la ricostruzione della causa non può più basarsi sull’interrogare un dipendente su cosa lo ha convinto a cliccare.
La responsabilità difensiva
Se il vettore d’attacco risiede nel contenuto stesso della rete e non più in un messaggio mirato verso una persona, una parte rilevante della responsabilità difensiva si sposta necessariamente verso chi progetta e addestra i modelli e gli agenti, un ambito sul quale i team di sicurezza aziendale hanno oggi una capacità di intervento diretto ancora limitata rispetto agli strumenti consolidati per contrastare il phishing rivolto agli esseri umani.
Partecipa alla community