Ho ricevuto un messaggio su Signal il mese scorso da un collega di un SOC che stava osservando un pattern di traffico insolito. Sembravano chiamate API ChatGPT legittime, ma provenivano da una macchina appartenente a un CFO che si trovava in quel momento su una spiaggia a Maui. Il CFO aveva cliccato su un link in un'e-mail apparentemente innocua di "ottimizzazione dello spazio di lavoro" tre giorni prima. Quando abbiamo analizzato i log, un agente autonomo viveva già nell'ambiente, leggendo silenziosamente le e-mail ed esfiltrando dati da fogli di calcolo verso un indirizzo esterno. Questo scenario non è più un esercizio teorico per i red team.
I ricercatori di sicurezza di Zenity Labs hanno recentemente divulgato una vulnerabilità negli OpenAI ChatGPT Workspace Agents che permetteva esattamente questo tipo di infiltrazione silenziosa. Denominata AgentForger, la falla consentiva a un utente malintenzionato di creare un link di phishing che, se cliccato, creava e distribuiva automaticamente un agente AI malevolo all'interno dell'organizzazione della vittima. Questo agente fungeva da insider persistente e autonomo con accesso agli strumenti aziendali integrati della vittima. Sebbene OpenAI abbia corretto la vulnerabilità l'8 giugno 2026, l'incidente offre uno sguardo allarmante su come la prossima generazione di ingegneria sociale si stia spostando oltre il furto di credenziali verso il dirottamento architettonico.
Al suo nucleo tecnico, AgentForger è una vulnerabilità di tipo cross-site request forgery (CSRF). L'exploit prendeva di mira il ChatGPT Agent Builder, uno spazio di lavoro visivo progettato per consentire agli utenti di creare workflow AI multi-step. Dietro le quinte, lo strumento Builder accettava il suo stato iniziale tramite parametri URL. Zenity Labs ha scoperto che il parametro initial_assistant_prompt non era solo un campo di testo segnaposto. Al caricamento della pagina, l'applicazione inviava ed eseguiva automaticamente qualsiasi testo contenuto in quel parametro.
Dal punto di vista del rischio, questo ha trasformato uno strumento di configurazione standard in un motore di esecuzione di codice remoto per istruzioni AI. Un attaccante poteva costruire un URL seguendo un pattern specifico: chatgpt.com/agents/studio/new?template_name=[template]&initial_assistant_prompt=[malicious instructions]. Se un utente loggato cliccava su questo link, il browser apriva l'Agent Builder nella sua sessione autenticata e iniziava immediatamente a seguire i comandi dell'attaccante. La vittima poteva vedere un breve lampo della schermata del Builder, ma il lavoro pesante avveniva istantaneamente e senza ulteriore consenso.
Per rendere l'attacco efficace, il prompt malevolo doveva fare di più che porre una semplice domanda. I ricercatori hanno scoperto che il payload poteva essere progettato per automatizzare l'intero processo di configurazione di un agente ad alto privilegio. Una volta che la vittima cliccava sul link, il prompt incorporato istruiva il Builder a selezionare un template "chief-of-staff". Questo template è particolarmente pericoloso perché è progettato per avere un accesso ad ampio raggio alla vita professionale di un utente.
Il payload dell'attaccante eseguiva quindi una sequenza di tre passaggi per garantire che l'agente rimanesse furtivo e funzionale. Innanzitutto, collegava ogni connettore disponibile al nuovo agente. Questi connettori collegano ChatGPT ad applicazioni mission-critical come Outlook, Gmail, Slack e Google Drive. In secondo luogo, il payload modificava le impostazioni di approvazione per questi connettori in "Non chiedere mai". Questo passaggio è il punto di cedimento architettonico. Per progettazione, queste integrazioni dovrebbero richiedere il permesso dell'utente prima di intraprendere azioni, ma l'exploit AgentForger permetteva all'attaccante di disabilitare quel controllo di sicurezza a livello programmatico.
Infine, l'agente veniva programmato per essere eseguito ogni ora. Questo ha trasformato l'esecuzione di uno script una tantum in un operatore persistente. In termini proattivi, il clic originale ha funzionato come l'installazione di una backdoor. La pianificazione manteneva la backdoor aperta e le app collegate fornivano all'attaccante sia un canale di comando e controllo sia una fonte di dati sensibili.
Affinché l'attacco AgentForger avesse successo, la vittima doveva soddisfare una serie specifica di criteri. L'attaccante non poteva semplicemente colpire un utente internet casuale; aveva bisogno di un punto d'appoggio in un ambiente aziendale che utilizzasse attivamente le funzionalità enterprise di ChatGPT.
| Requisito | Descrizione |
|---|---|
| Sessione Attiva | La vittima deve essere loggata in un account ChatGPT al momento del clic. |
| Accesso al Workspace | L'account della vittima deve avere accesso al set di funzionalità Workspace Agents di OpenAI. |
| Connettori Esistenti | La vittima deve aver precedentemente autorizzato almeno un connettore aziendale (es. Slack o Outlook). |
La presenza di un connettore esistente è la chiave per l'autonomia dell'agente. Se un utente aveva già collegato il proprio account Gmail a ChatGPT per legittimi motivi di produttività, l'agente contraffatto ereditava quella fiducia. Il modello AI non aveva bisogno di chiedere una password; utilizzava semplicemente il token di autenticazione esistente per leggere, scrivere ed eliminare messaggi per conto della vittima.
Una volta che l'agente è attivo, l'attaccante non ha più bisogno che la vittima interagisca con ChatGPT o che mantenga aperta la scheda del browser. L'agente risiede sull'infrastruttura di OpenAI, non sulla macchina locale della vittima. Durante ogni esecuzione pianificata, l'agente rogue può essere programmato per controllare la posta in arrivo della vittima alla ricerca di e-mail con un oggetto specifico, come "TASK". L'attaccante invia un'e-mail alla vittima, l'agente la legge, esegue l'azione richiesta all'interno dell'organizzazione e poi invia i risultati all'attaccante via e-mail.
Guardando al panorama delle minacce, ciò crea una terrificante opportunità di movimento laterale e ricognizione. Un agente contraffatto potrebbe passare settimane a scansionare un Google Drive aziendale alla ricerca di documenti etichettati come "riservato" o "password". Potrebbe monitorare i canali Slack per chiavi API sensibili o diagrammi architettonici. Poiché il traffico sembra provenire da un servizio AI legittimo e autorizzato, molti strumenti di sicurezza di rete tradizionali tratterebbero l'attività come normali operazioni aziendali.
Inoltre, l'agente rogue può essere utilizzato per lanciare attacchi di phishing interni. Un dipendente è molto più propenso a cliccare su un link inviato tramite Microsoft Teams da un collega fidato rispetto a un'e-mail sospetta da un indirizzo esterno. L'agente contraffatto può impersonare la vittima, inviando link malevoli ad altri dipendenti per raccogliere credenziali o diffondere ulteriormente l'infezione AgentForger nell'azienda. Questo trasforma l'agente AI in un cavallo di Troia digitale che opera all'interno del perimetro di fiducia dell'azienda.
OpenAI ha intrapreso il passo proattivo di deprecare interamente il prodotto Agent Builder, a partire dal 30 novembre 2026. Gli utenti sono invitati a migrare verso l'SDK degli Agenti, progettato con un controllo più granulare e meno vulnerabilità web legacy come il CSRF. Tuttavia, l'incidente AgentForger serve come caso di studio forense sul motivo per cui non possiamo trattare le piattaforme AI come separate dai normali principi di sicurezza web.
La vulnerabilità non è un fallimento della logica dell'AI o una prompt injection in senso tradizionale. È un fallimento della gestione dello stato dell'applicazione. Quando analizzo APT complessi, vedo spesso che le violazioni più devastanti coinvolgono questi tipi di errori di implementazione semplici e trascurati. La piattaforma ha confidato nel fatto che l'utente avesse intenzionalmente avviato la creazione dell'agente semplicemente perché la richiesta proveniva da una sessione valida.
Siamo attualmente in un periodo in cui server di modelli self-hosted e framework di agenti vengono distribuiti a un ritmo rapido. Molti di questi sistemi sono configurati in modo errato o si affidano a porte prevedibili, rendendoli bersagli sfruttabili. Zenity Labs ha recentemente notato che l'infrastruttura AI esposta sta diventando un backend comodo e negabile per operazioni di AI offensiva. AgentForger è solo un esempio di come gli attaccanti stiano spostando la loro attenzione dall'attaccare il modello AI all'attaccare l'infrastruttura che lo ospita.
Al di là delle patch, le organizzazioni devono riconoscere che le integrazioni AI rappresentano una nuova classe di shadow IT. Se un dipendente collega la propria e-mail aziendale a un servizio AI di terze parti, sta essenzialmente estendendo la superficie di attacco dell'azienda all'infrastruttura di quel fornitore. In caso di una violazione come AgentForger, la sicurezza dell'intera organizzazione dipende dalle impostazioni di autorizzazione di un singolo utente.
Per costruire una postura più resiliente, i team di sicurezza dovrebbero considerare i seguenti passaggi:
AgentForger è stato un campanello d'allarme. Ha dimostrato che, man mano che diamo all'AI maggiore autonomia per agire per nostro conto, stiamo anche fornendo agli attaccanti strumenti più potenti per sovvertire la nostra fiducia. L'obiettivo della sicurezza non è smettere di usare questi strumenti, ma garantire che i nostri assistenti digitali non diventino i nostri insider più pericolosi.
Dichiarazione di non responsabilità: Questo articolo è solo a scopo informativo ed educativo. Non costituisce consulenza legale o di cybersicurezza professionale. Le organizzazioni dovrebbero condurre le proprie valutazioni del rischio indipendenti e consultare professionisti della sicurezza prima di implementare modifiche architettoniche.



La nostra soluzione di archiviazione e-mail crittografata end-to-end fornisce i mezzi più potenti per lo scambio sicuro dei dati, garantendo la sicurezza e la privacy dei tuoi dati.
/ Creare un account gratuito