8BitSecurity

Negli ultimi anni, le piattaforme di assistenti AI (come Microsoft CoPilot) sono diventate parte integrante degli ambienti enterprise, affiancando gli utenti nelle attività quotidiane e nei flussi operativi. Ma cosa accade se un attaccante riesce a sfruttare la fiducia che un utente (o un sistema) ripone in CoPilot per istruire un comportamento malevolo, travestito da funzionalità legittima? È proprio questo l’obiettivo della ricerca presentata da Tobias Diehl al DEFCON 33: “Mind the Data Voids: Hijacking CoPilot Trust to Deliver C2 Instructions with Microsoft Authority” (link).

La PoC mostra come un attaccante possa individuare “vuoti informativi” (data voids) – argomenti raramente indicizzati o poco trattati – e inserirvi contenuti malevoli che, grazie all’“autorità” percepita di Microsoft nei risultati contestuali, possono essere elevati a istruzioni operative da CoPilot. Il risultato finale è che CoPilot diventerà vettore di attacco, guidando gli utenti nell’installazione di malware sul proprio dispositivo, nella fallace convinzione che si tratti di un software legittimo.

Qualcuno sarebbe pronto a mettere in dubbio le istruzioni del proprio LLM preferito? E, soprattutto, ad immaginare che possa essere lui stesso a compromettere la sicurezza dei nostri dispositivi? Immagino di no; ecco perché questo scenario è particolarmente rilevante in un’epoca in cui gli assistenti generativi e i sistemi AI assumono ruoli sempre più centrali nel workflow aziendale, poiché la fiducia implicita nel sistema diventa il vettore d’attacco.

Nell’articolo esploreremo i concetti tecnici alla base, il modello d’attacco proposto da Diehl, e le implicazioni per difesa, performance e architetture scalabili.

Contesto tecnico

Data Voids: definizione e rischi

Il concetto di data void è stato formalizzato inizialmente nel contesto dei motori di ricerca e riguarda quei termini o query per cui esistono poche fonti affidabili o ben “posizionate”. Un attore malevolo può “riempire” quel vuoto inserendo contenuti (articoli, pagine web) ottimizzati per quella query, diventando di fatto la voce dominante.

Nel contesto dei sistemi AI che fanno uso di retrieval o contesto esterno (ad es. RAG, knowledge indexing), un data void può essere sfruttato per far sì che il modello “recuperi” la fonte malevola e la consideri contesto legittimo. Se quel contesto include istruzioni o payload nascosti, l’AI potrebbe seguirli, specialmente se il sistema di verifica è debole.

Prompt injection e retrieval-augmented generation

Due meccanismi fondamentali rendono possibile questo tipo di attacco:

1. Prompt injection – un attaccante inserisce istruzioni malevole nel contesto che il modello considera; può essere diretto (l’input dell’utente) o indiretto (contenuto recuperato da fonti esterne).
2. Retrieval-augmented generation (RAG) – molte applicazioni AI integrano modelli generativi con un livello di memoria o recupero dati da fonti esterne (documenti, archivi). Se tali fonti contengono dati compromessi, l’output può essere “avvelenato”.

In un sistema come CoPilot, l’AI non genera tutto da zero: parte del risultato è basato sul contesto, metadati, documenti collegati. Se un attaccante riesce a inserire istruzioni nascoste in quei contesti, c’è il rischio che l’AI le consideri legittime.

Modello di attacco di Diehl

Il modello presentato da Diehl si articola nelle seguenti fasi:

1. Individuazione del vuoto: scegliere un argomento tecnicamente circoscritto, poco frequentato e con scarsa copertura nei corpus usati da CoPilot per il recupero.
2. Iniezione persistente: creare contenuti (documenti, blog, pagine tecniche) che associno quel termine con istruzioni C2 (es. “come installare agenti, come contattare un dominio controllato”).
3. Pesa semantica tramite Microsoft authority: legare il tema malevolo a elementi che richiamano Microsoft (nomi di prodotti, domini, termini tecnici riconosciuti), in modo che il sistema lo consideri “compatibile” con il contesto legittimo.
4. Triggering dall’utente: l’utente chiede a CoPilot qualcosa su quell’argomento; il sistema richiama il contenuto iniettato come parte del contesto e fornisce (di fatto) una guida C2.
5. Esecuzione indiretta: l’utente segue le istruzioni, attiva un agente malevolo, stabilisce un canale C2.

Un punto cruciale: CoPilot può non validare ciascuna istruzione recuperata, se la considerano parte del “contesto accettabile”. Ciò lo rende vulnerabile a questo tipo di “autorità manipolata”.

Analisi e approfondimento tecnico

Perché questo attacco funziona (o ha una probabilità di riuscita)

• Bassa copertura tematica: quando l’argomento è poco trattato, il contenuto iniettato può dominare il contesto utilmente.
• Confidenza implicita: il sistema riconosce terminologia Microsoft e assume che il contenuto sia allineato con le linee guida.
• Mancanza di validazione passo-passo: CoPilot non è progettato per validare ogni passo di un’istruzione tecnica, bensì per renderla utile al contesto utente.
• Persistenza: una volta che il contenuto è indicizzato, può rimanere attivo per lungo tempo prima di essere corretto o rimosso.

Esempio di attacco

Immaginiamo un dominio “Contoso-AgentX” che non esiste (data void). Un attaccante crea una pagina “How to install Contoso-AgentX via Microsoft Graph” con istruzioni passo-passo (es. “registrare endpoint, autenticazione, callback”). Il documento include richiami a Microsoft 365, Graph API, registri Azure AD. Una volta indicizzato, se l’utente chiede “Come installo AgentX nel mio ambiente Microsoft?”, CoPilot può includere l’URL e le istruzioni come parte del contesto (poiché semanticalmente compatibile). L’utente segue la guida e installa un client C2 che comunica all’attaccante.

In un sistema reale, la guida potrebbe includere frammenti JSON, comandi PowerShell, endpoint URL malvagi, ecc.

Confronto con altri attacchi AI

• Data poisoning tradizionale: mira a influenzare il modello durante il training. Qui invece l’attacco agisce a livello di recupero del contesto e prompt injection, non richiede accesso al training.
• Prompt injection puro: spesso l’input utente è manipolato. Qui l’attacco “indiretto” vive fuori dal controllo dell’utente e viene richiamato come parte del sistema di contesto.
• Backdoor nei modelli: un trigger nascosto nel modello induce un comportamento; in questo caso non serve un backdoor interno, ma semplicemente il contesto manipolato.
• EchoLeak (attacco recente su CoPilot): anche se diverso nella modalità, EchoLeak è un esempio di “scope violation” dove input esterni possono far emergere dati interni del contesto aziendale. Ne abbiamo parlato QUI.

Fortunatamente, l’attacco non è efficace in tutti i contesti: se l’argomento diventa molto popolare o monitorato, il contenuto malevolo potrebbe essere “diluito” da fonti legittime. Inoltre, i sistemi AI ben progettati potrebbero includere validatori interni o filtri che rifiutano istruzioni “non verificate”.

Implicazioni di sicurezza, prestazioni e scalabilità

È facile intuire come l’attacco di trust hijacking possa avere conseguenze devastanti, soprattutto in contesti enterprise, con interi uffici compromessi, malware estremamente complessi da rilevare (perché a loro volta analizzati da altri sistemi AI), fino poi alla perdita di fiducia dell’utente verso il sistema AI.

Il problema è anche che l’aggiunta di meccanismi di validazione, scansione semantica, filtri di sicurezza impatta in termini computazionali. Ciò può tradursi in latenza addizionale quando CoPilot costruisce contesti o riconcilia fonti esterne. Occorre bilanciare sicurezza e reattività.

In ambienti con migliaia di utenti e centinaia di domini, occorre:

• Filtrare e catalogare fonti affidabili per contesto (whitelisting).
• Versionare e auditare i cambi nei corpus di conoscenza AI.
• Applicare registri di modifica (“trust pipeline”) per chi reimposta o modifica contenuti contestuali.
• Automatizzare l’analisi semantica delle nuove fonti per rilevare potenziali istruzioni sospette.

Conclusione

Questa ricerca mette in guardia su un rischio emergente e sofisticato per far sì che un assistente AI diventi veicolo di istruzioni malevole, con tutta la credibilità di Microsoft come garante. Per un utente comune riuscire a distinguere questa tipologia di attacchi può essere più che mai complesso. Per questo, proteggere la fiducia che riponiamo in sistemi come CoPilot sarà essenziale per non trasformarli in vettori di compromissione. Mettere in pratica queste difese sarà parte integrante delle architetture AI sicure del prossimo futuro.

Takeaway e best practice

• Mappare e monitorare le query a bassa copertura nei sistemi AI interni, per identificare possibili voids.
• Implementare filtri semantici che scansionino istruzioni recuperate e le confrontino con whitelist di pattern o domini approvati.
• Isolare il contesto proveniente da fonti esterne con livelli di fiducia (es. “sandboxed reading” prima dell’inserimento nel prompt).
• Loggare e auditare le fonti contestuali usate nelle risposte AI e consentire rollback.
• In ambienti enterprise, disabilitare la possibilità di recuperare fonti esterne non verificate e limitare il contesto a documenti interni controllati.