MCP malevoli e passkey espongono agenti AI e identità passwordless

🛡️ Executive Summary

• GhostSplice divide un’istruzione malevola tra più canali MCP, inducendo coding agent a ricomporla ed esfiltrare chiavi SSH, file .env e codice.
• Pass-the-Passkey riutilizza assertion WebAuthn esposte da Windows per impersonare utenti Entra anche in presenza di MFA resistente al phishing.
• Pass-ta-key recupera le chiavi private delle passkey sincronizzate Google, mentre Windows Hello può firmare nuove assertion da una sessione già compromessa.

Due filoni di ricerca mostrano che agenti AI e autenticazione passwordless possono essere compromessi senza violare direttamente i meccanismi crittografici su cui si basano. GhostSplice sfrutta il modo in cui i coding agent combinano descrizioni, risultati e altri contenuti provenienti dai server MCP: un’istruzione che verrebbe rifiutata se presentata interamente può essere frammentata in parti apparentemente innocue e ricostruita dal modello, fino all’esfiltrazione di chiavi SSH, file .env e codice proprietario. Sul fronte delle identità, tre ricerche indipendenti colpiscono invece i livelli che circondano WebAuthn, Google Password Manager, Microsoft Entra ID e Windows Hello for Business, dimostrando che passkey sincronizzate e device-bound restano forti sul piano crittografico ma dipendono dalla sicurezza dell’endpoint, del browser e dell’implementazione cloud.

GhostSplice divide l’attacco tra più canali MCP

ASSET Research Group definisce GhostSplice una tecnica di cross-channel trust fragmentation: il server MCP malevolo evita deliberatamente di inviare al modello una singola istruzione esplicitamente pericolosa e la distribuisce invece tra più elementi che l’agente utilizza normalmente. Nella ricerca originale di ASSET Research Group il primo frammento può essere nascosto nella descrizione di un tool, il secondo nel risultato restituito da un altro strumento e, nelle implementazioni che lo supportano, un terzo può arrivare attraverso il meccanismo di sampling. Considerati separatamente, i frammenti sembrano semplici istruzioni operative; quando finiscono nello stesso contesto del modello, però, diventano una sequenza completa. Il problema amplia il rischio già emerso con il tool poisoning nei server MCP aziendali e con le vulnerabilità Ruflo che espongono agenti MCP e ambienti VMware: il server non deve necessariamente contenere un comando malevolo chiaramente riconoscibile, perché può affidare al modello il compito di assemblare la semantica dell’attacco.

Un falso controllo di integrità può sottrarre chiavi SSH e file .env

Il proof-of-concept utilizza un tool chiamato integrity_checker che dichiara di effettuare verifiche hash server-side e accetta quattro campi apparentemente innocui, alpha, beta, gamma e delta. Un secondo tool restituisce successivamente la mappatura necessaria: inserire nei quattro campi il contenuto della chiave privata SSH, del codice proprietario, di un database clienti e del file .env. Nessuno dei due frammenti contiene isolatamente l’intera richiesta di esfiltrazione. Il coding agent li legge però nello stesso contesto e può interpretare l’operazione come la normale compilazione di un modulo, trasferendo i dati sensibili al server controllato dall’attaccante.

Il repository pubblico di GhostSplice contiene implementazioni a due e tre canali, log delle prove e progetti sintetici con credenziali canary. È una variante più elusiva della prompt injection tradizionale già osservata quando un agente OpenAI raggiungeva Hugging Face mentre Azure DevOps MCP esponeva informazioni e nelle iniezioni capaci di trasformare repository GitHub in vettori contro gli agenti.

La frammentazione quasi raddoppia la compliance media dei modelli

Nei test controllati di ASSET, la richiesta esplicita e non frammentata ha ottenuto in media una compliance del 42% su undici modelli sottoposti alla comparazione, mentre la stessa finalità divisa in due frammenti è salita all’82%. Alcuni modelli che avevano rifiutato sistematicamente l’istruzione diretta — tra cui GPT-4o, Gemini 2.0 Flash e Llama 3.3 70B nella configurazione testata — sono arrivati al 100% con il payload diviso. I ricercatori mostrano inoltre che il comportamento cambia in modo significativo in base all’harness, cioè al software che circonda il modello e decide come descrizioni, risultati e chiamate tool vengono presentati nel contesto.

Non si tratta quindi di una classifica assoluta dei modelli: la stessa famiglia può reagire diversamente dentro Cursor, Codex CLI o altri client. Il risultato rafforza quanto emerso nelle falle degli agenti AWS, Google e Vercel e nel caso in cui Kiro eseguiva codice partendo da contenuti web avvelenati: la sicurezza dell’agente dipende almeno quanto dal runtime e dai confini tra strumenti quanto dal modello utilizzato.

I normali scanner MCP possono non vedere l’attacco

GhostSplice è stato costruito specificamente per aggirare controlli che analizzano ogni superficie singolarmente. Uno scanner statico che legge soltanto la descrizione del tool trova una funzione di verifica con parametri generici. Un sistema che osserva il risultato della scansione vede invece riferimenti a file e parametri, ma non necessariamente un ordine esplicito di esfiltrazione. Il comportamento malevolo emerge soltanto nel momento in cui il modello combina i frammenti.

ASSET distingue quindi GhostSplice dal classico tool poisoning, nel quale l’intera istruzione ostile viene nascosta in una singola descrizione MCP. La mitigazione proposta consiste nel trattare i risultati restituiti dai server come dati e non come istruzioni, impedendo che valori provenienti da un tool vengano trasferiti automaticamente negli argomenti di un altro senza una validazione indipendente. Il principio si collega alle più ampie falle Terraform MCP e n8n che espongono credenziali e accessi aziendali e al rischio già osservato nei workflow agentici dove input non attendibili raggiungono capacità privilegiate.

Le passkey vengono attaccate senza rompere FIDO2

Il secondo filone riguarda tre ricerche presentate o pubblicate nella settimana di Black Hat USA 2026. Nessuna dimostra una rottura della crittografia alla base delle passkey. Gli attacchi sfruttano invece assertion già generate, meccanismi di sincronizzazione, processi browser e chiavi Windows Hello accessibili da una sessione compromessa. SpecterOps definisce la propria famiglia di tecniche Pass-the-Passkey e mostra come vulnerabilità nell’implementazione Windows ed Entra possano permettere l’impersonificazione di utenti privilegiati pur in presenza di policy che richiedono MFA resistente al phishing. La presentazione ufficiale di SpecterOps a Black Hat 2026 descrive tre zero-day praticamente sfruttabili individuati nel percorso di autenticazione. La ricerca si inserisce nello stesso cambio di paradigma già affrontato con Pass-ta-key contro Google Password Manager e con le campagne che aggirano MFA e autenticazione passwordless in Microsoft Entra.

Windows conservava assertion WebAuthn riutilizzabili

SpecterOps ha scoperto che Windows memorizzava nei log firme WebAuthn precedentemente generate da YubiKey, leggibili in chiaro anche da utenti autenticati senza privilegi amministrativi. Il problema Windows è identificato come CVE-2026-34348, vulnerabilità di information disclosure nel Windows Event Logging Service corretta negli aggiornamenti Microsoft di luglio. La documentazione Microsoft per CVE-2026-34348 fornisce le patch per le versioni interessate. Secondo SpecterOps, le assertion recuperate potevano essere combinate con caratteristiche dell’implementazione Microsoft Entra ID per effettuare replay e impersonare account privilegiati senza estrarre la chiave privata dalla YubiKey. Il punto è fondamentale: l’autenticatore hardware continua a proteggere correttamente il segreto crittografico, ma un artefatto firmato già prodotto può diventare riutilizzabile se il relying party non lega sufficientemente challenge, sessione e autenticazione. Microsoft ha comunicato di avere applicato anche mitigazioni lato Entra e SpecterOps considera spezzata la catena completa dopo gli aggiornamenti Windows di luglio.

Golden Pass-ta-key recupera le chiavi private sincronizzate

Unit 42 affronta invece l’architettura di Google Password Manager su Chrome per Windows. Tutti gli attacchi descritti partono da malware già in esecuzione sul dispositivo della vittima e non costituiscono quindi una tecnica remota per superare una passkey senza una compromissione iniziale dell’endpoint. Nella variante più grave, Golden Pass-ta-key, il bersaglio è il Security Domain Secret, una chiave master simmetrica di 32 byte utilizzata per proteggere le passkey sincronizzate. La ricerca di Unit 42 sulla sicurezza delle autenticazioni passwordless documenta inizialmente la presenza del segreto nei log FIDO di Chrome; Google ha rimosso quella esposizione dopo la segnalazione, ma i ricercatori affermano che il valore rimane temporaneamente presente nella memoria del processo durante una nuova registrazione con il cloud authenticator. Se il malware recupera il Security Domain Secret può decrittare le chiavi private delle passkey sincronizzate e utilizzarle su un sistema controllato dall’attaccante.

La sincronizzazione trasforma il master secret in un asset critico

La conseguenza di Golden Pass-ta-key è più persistente della cattura di una singola sessione. Unit 42 osserva che l’implementazione analizzata non espone un meccanismo attraverso il quale l’utente possa semplicemente ruotare o revocare il Security Domain Secret dopo una compromissione. Il modello evidenzia il compromesso strutturale delle passkey sincronizzate: la possibilità di recuperare automaticamente le credenziali su più dispositivi richiede un meccanismo cloud capace di proteggere e ricostruire il materiale crittografico. È proprio quel livello a diventare un nuovo confine di sicurezza. Questo non rende le passkey equivalenti alle password né elimina la loro resistenza al phishing tradizionale, ma dimostra che la sicurezza del credential manager e dell’endpoint resta parte del modello di minaccia. Lo stesso problema dell’endpoint come ultimo confine emerge nelle campagne di device-code phishing contro Microsoft 365 e nelle operazioni in cui Kali365 e Greatness industrializzano il furto di account Microsoft.

Windows Hello può firmare senza richiedere nuovamente il PIN

La terza ricerca, pubblicata da Dirk-jan Mollema, mostra una proprietà diversa delle credenziali Windows Hello for Business. Nei sistemi moderni la chiave privata è normalmente protetta dal Trusted Platform Module e non può essere semplicemente esportata. Un processo in esecuzione all’interno della sessione dell’utente può però chiedere a Windows di utilizzare quella chiave attraverso le API crittografiche senza provocare necessariamente una nuova richiesta di PIN o biometria. Nella ricerca “Borrowing Windows Hello keys” Mollema utilizza questa capacità per generare una assertion FIDO2 valida verso Entra ID e successivamente esplora percorsi di registrazione del dispositivo e acquisizione di un Primary Refresh Token. Anche in questo scenario l’attaccante deve avere già compromesso la sessione Windows: non viene estratta la chiave TPM, ma viene abusata la capacità legittima del sistema di chiederle di firmare.

La challenge Entra diventa parte del problema

Mollema osserva inoltre che la challenge WebAuthn ottenuta da Entra può essere trasportata su un altro sistema, firmata attraverso la chiave Windows Hello della vittima e restituita per completare l’autenticazione. La challenge resta valida per alcuni minuti e, nella configurazione analizzata, non risulta vincolata in modo sufficiente alla sessione, all’utente o al tenant che l’ha originata. Questo rende possibile trasformare una sessione locale già compromessa in un’autenticazione cloud che può soddisfare anche controlli di phishing-resistant MFA. Il percorso è distinto dalla ricerca SpecterOps: Pass-the-Passkey riutilizza assertion precedentemente generate, mentre Mollema produce nuovo materiale firmato utilizzando la chiave hardware-bound già disponibile alla sessione. La differenza tecnica è importante perché mostra che non esiste una singola correzione capace di risolvere tutti i problemi. Come già evidenziato negli attacchi contro Microsoft 365 che sfruttano credenziali, sessioni e identità, l’autenticazione deve essere valutata insieme alla postura dell’endpoint e al contesto nel quale viene prodotta.

MCP e passkey spostano la sicurezza fuori dal singolo protocollo

GhostSplice e le nuove tecniche contro le passkey appartengono a domini differenti, ma mostrano lo stesso limite delle difese concentrate esclusivamente sul componente centrale. MCP può mantenere formalmente separati descrizioni e risultati dei tool, ma l’agente li ricompone all’interno dello stesso contesto semantico. FIDO2 può proteggere correttamente una chiave privata, ma Windows può conservare assertion utili al replay, un browser può temporaneamente esporre un segreto di sincronizzazione o una sessione compromessa può chiedere al TPM di produrre una nuova firma. In entrambi i casi la vulnerabilità nasce nelle interfacce tra componenti affidabili. Per gli agenti AI significa verificare server MCP, limitare strumenti e flussi tra tool e introdurre approvazioni sulle operazioni sensibili; per l’identità significa applicare gli aggiornamenti Windows, proteggere browser ed endpoint e monitorare registrazioni anomale di dispositivi e autenticazioni Windows Hello. La sicurezza non dipende quindi soltanto da un protocollo robusto, ma da come il software circostante interpreta, conserva e trasferisce ciò che quel protocollo considera attendibile.