Immagine illustrativa generata con AI
Google Workspace, l’attacco può iniziare da OAuth e non dalla posta
Scopri come gli attacchi a Google Workspace iniziano da token OAuth, non dalla posta, e i rischi legati a agenti AI e privilegi eccessivi.
Testo generato da intelligenza artificiale, pubblicato senza revisione umana. Trasparenza IA
La nuova catena: prima il token, poi Gmail
Un’analisi pubblicata il 14 agosto 2026 sostiene che le violazioni associate a Vercel e Composio possano essere ricondotte a uno stesso schema: l’accesso a Google Workspace non parte necessariamente dalla casella email, ma da un token OAuth compromesso o da un’integrazione autorizzata.
La distinzione modifica il modello tradizionale dell’account takeover. In passato, la sequenza più comune prevedeva un messaggio di phishing, il furto delle credenziali, l’accesso a Gmail e Drive e infine il movimento laterale verso altri servizi. In questo scenario, invece, l’attaccante può entrare nell’ambiente attraverso un’applicazione collegata e raggiungere la posta soltanto in un secondo momento.
La posta elettronica rimane quindi centrale, ma non sempre come punto d’ingresso. Una volta raggiunta, può diventare un moltiplicatore dell’incidente: contiene spesso link per il reset delle password, magic link, credenziali archiviate nelle conversazioni e riferimenti ad applicazioni interne.
L’analisi è firmata da Rajan Kapoor, VP Security di Material Security, che è anche l’azienda promotrice della pubblicazione. I dettagli tecnici sugli incidenti di Vercel e Composio non sono stati resi noti: non risultano identificativi CVE, campagne attribuite o gruppi di minaccia associati.
Perché OAuth può sopravvivere al reset della password
Un token OAuth consente a un’applicazione di operare per conto dell’utente sulla base di autorizzazioni definite negli scope. Se il token viene sottratto, l’attaccante può utilizzarlo per accedere alle risorse consentite senza dover necessariamente conoscere la password.
Questo crea un problema operativo per i team di sicurezza. Un reset della password può non essere sufficiente a interrompere l’accesso, perché il token può continuare a essere valido. Secondo l’analisi, alcuni token possono inoltre non avere una scadenza evidente ed essere difficili da individuare se l’organizzazione controlla soltanto login, password e attività dell’utente.
Il rischio cresce quando il token appartiene a un’applicazione di terze parti. La compromissione del fornitore o dell’integrazione può trasformarsi in un attacco alla supply chain, con un accesso apparentemente legittimo all’ambiente aziendale.
La sequenza ipotizzata è articolata:
- un token OAuth viene compromesso;
- l’attaccante utilizza gli scope concessi dall’applicazione;
- Gmail e Drive diventano accessibili;
- l’account viene preso di mira senza un iniziale furto della password;
- i contenuti della posta e dei documenti vengono sfruttati per raggiungere altri sistemi;
- i dati vengono raccolti o trasferiti verso terze parti.
L’aspetto più difficile da rilevare è la legittimità formale dell’accesso. L’applicazione può essere autorizzata, il token può essere valido e l’utente può non vedere alcun segnale evidente nel proprio account.
Gli agenti AI trasformano i privilegi in azioni automatiche
La stessa dinamica può verificarsi anche senza un token rubato. Gli utenti collegano sempre più spesso agenti AI a Google Workspace tramite OAuth, concedendo loro la possibilità di leggere email, cercare documenti in Drive e operare per conto di persone reali.
Un agente può quindi avere accesso a dati e servizi sulla base degli scope assegnati. Il problema non riguarda soltanto un comportamento malevolo o una prompt injection. Un sistema può funzionare come previsto, ma disporre di privilegi sproporzionati rispetto all’attività richiesta.
Un agente incaricato di recuperare informazioni da una casella potrebbe, per esempio, avere anche la possibilità di consultare conversazioni contenenti credenziali o documenti presenti in drive condivisi. Se incontra istruzioni ambigue, contenuti manipolati o una catena decisionale non prevista dagli sviluppatori, può utilizzare quelle informazioni per svolgere azioni successive.
La catena può includere:
- lettura di messaggi o cartelle oltre il perimetro necessario;
- individuazione di credenziali, dati personali o informazioni riservate;
- apertura di link e invio di richieste verso altri servizi;
- passaggio da un’applicazione all’altra;
- trasferimento dei dati a una terza parte.
In questo caso non è indispensabile che un aggressore controlli direttamente l’agente. Il rischio nasce dall’interazione tra autorizzazioni troppo ampie, contenuti presenti nell’ambiente e capacità del sistema di eseguire azioni automaticamente.
Un operatore umano con gli stessi privilegi può applicare policy interne e buon senso prima di utilizzare un’informazione. Un agente, invece, tende a eseguire il compito sulla base delle istruzioni e degli accessi disponibili. Il token OAuth attribuito a una persona e quello assegnato a un sistema automatizzato possono quindi esporre privilegi simili, ma con modalità operative molto diverse.
Gmail e Drive diventano punti di espansione
In questo modello, Gmail e Drive non sono soltanto depositi di informazioni. Diventano infrastrutture per il movimento laterale.
Un messaggio può contenere il collegamento per reimpostare una password. Un documento può includere una chiave di accesso, una procedura operativa o un riferimento a un servizio interno. Un drive condiviso può esporre dati a un numero di utenti e applicazioni superiore a quello previsto.
La conseguenza è che una compromissione apparentemente limitata può allargarsi rapidamente. L’accesso a un’applicazione autorizzata permette di leggere i contenuti; quei contenuti possono poi fornire i mezzi per raggiungere ulteriori account e sistemi.
L’impatto potenziale comprende email, documenti aziendali, credenziali, informazioni personali identificabili e dati custoditi da applicazioni collegate. L’automazione può aumentare velocità e scala delle operazioni, soprattutto quando gli strumenti AI aiutano a individuare informazioni utili e a combinarle tra più servizi.
La fonte non assegna una classificazione formale di gravità e non fornisce indicatori di compromissione da cercare. Non sono inoltre indicate versioni software coinvolte, prodotti specifici vulnerabili o scadenze di remediation. Il caso riguarda il modello di accesso e di controllo, non una falla identificata con CVE.
Come ridurre il rischio in un ambiente Workspace
La difesa non dovrebbe concentrarsi soltanto sul filtro antiphishing o sulla protezione dell’account utente. Il primo intervento consiste nel censire applicazioni, token OAuth e scope realmente concessi, verificando anche il comportamento delle integrazioni nel tempo.
Non basta sapere che un’applicazione è autorizzata. Occorre osservare quali dati legge, con quale frequenza, da quali utenti e se le sue attività cambiano rispetto al comportamento atteso. Un accesso anomalo può indicare sia l’uso di un token rubato sia un agente legittimo che sta operando oltre il proprio compito.
Sono necessari anche controlli sui dati:
- individuare email contenenti credenziali, PII e link di recupero;
- verificare l’accessibilità dei drive condivisi;
- ridurre gli scope OAuth non indispensabili;
- applicare il privilegio minimo a utenti, app e agenti automatizzati;
- controllare variazioni improvvise nelle attività delle integrazioni.
La posta richiede una protezione specifica. Oltre a bloccare phishing, payload evasivi e attacchi attacker-in-the-middle, è utile impedire che una casella compromessa diventi automaticamente un archivio operativo per l’attaccante. I contenuti più sensibili possono essere oscurati o sottoposti a una verifica step-up prima dell’accesso.
La stessa regola deve valere per gli agenti AI. Un sistema autorizzato a cercare informazioni nella posta non dovrebbe poter recuperare senza ulteriori controlli credenziali, link di reset o dati che non servono alla sua attività.
La visibilità deve infine unire eventi di email, OAuth, Drive e account. Monitorare questi elementi separatamente lascia scoperti i passaggi tra applicazioni, proprio quelli che consentono a un token legittimo o compromesso di trasformare un accesso iniziale in esfiltrazione e movimento laterale.
Fonti
Questo articolo è una rielaborazione originale basata sulle fonti seguenti.