Google Workspace, l'attacco ora inizia da OAuth non da email

Il 16 settembre 2026, un'analisi di Material Security ridefinisce il perimetro della minaccia su Google Workspace: la catena di attacco si è spostata da email-first a OAuth-first. Il dato non è marginale. Gli OAuth token rubati sopravvivono ai reset password, non scadono e sono invisibili agli utenti. Contemporaneamente, gli agenti AI legittimi con OAuth grants autorizzati replicano strutturalmente lo stesso percorso di compromissione, rendendo impossibile distinguere la minaccia maliziosa dalla produttività accidentale.

Da email phishing a OAuth invisibile: come è cambiata la catena

La catena di attacco tradizionale su Google Workspace seguiva un percorso riconoscibile: email di phishing, furto di credenziali, accesso a Gmail e Drive, movimento laterale. Questa sequenza aveva il vantaggio della visibilità. Il security team poteva intercettare l'email malevola, rilevare il login anomalo, reagire al reset password.

La catena evoluta documenteda da Material Security elimina questi punti di contatto. L'ingresso avviene tramite OAuth token compromesso, spesso conseguenza di un supply chain attack su un fornitore terzo. Il token garantisce accesso diretto ai dati Gmail e Drive, bypassando del tutto la fase credenziale. Da lì, l'attaccante procede a account takeover e movimento laterale attraverso la stessa infrastruttura che l'organizzazione usa per la produttività.

La persistenza è architetturale, non tattica. Gli OAuth token rubati non scadono con il cambio password, non generano notifiche di accesso anomalo e non appaiono nelle dashboard di autenticazione tradizionali. Sono, per progetto, invisibili.

Il paradosso strutturale: l'agente AI legittimo come doppelgänger

Il nucleo dell'analisi di Material Security non è la tecnica di attacco in sé, ma la sovrapposizione con comportamenti legittimi. Un agente AI autorizzato con OAuth grant legge email, cerca in Drive, opera per conto di un utente reale. Il suo token ha lo stesso accesso di un token persona. Quando lo scope del permesso eccede il task richiesto, l'agente non possiede il "common sense" aziendale per riconoscerlo.

Secondo l'analista citato, "OAuth tokens granted to an AI agent carry the same access as tokens granted to a person, but the agent won't understand that it's been overpermissioned before it acts. It will simply do what it needs to do in order to execute the task". Il risultato è accesso non intenzionale a inbox o cartelle non previste, lettura di credenziali in thread email, azioni downstream che replicano punto per punto il movimento laterale di un attaccante.

Lo stesso analista evidenzia la convergenza esplicita: "The pattern I'm describing, where an OAuth grant is used to access an account, read sensitive data from email and Drive, and use that access to move past the workspace, doesn't only describe what attackers do. It increasingly describes what AI agents do, by design, every day".

La compressione temporale che rende il problema urgente

Il contesto threat intelligence corrobora la natura non solo strutturale ma anche accelerata del fenomeno. Secondo il Google Threat Intelligence Group, nel secondo trimestre 2026 attori di minaccia hanno compromesso una risorsa cloud, quindi pianificato, costruito ed eseguito una campagna di credential harvesting massivo con automazione agent-enabled in meno di 6 ore.

"In Q2 2026, GTIG observed threat actors compromise a cloud resource, then plan, build, and execute an agent-enabled mass credential harvesting campaign in under six hours." — Google Threat Intelligence Group

Questa compressione temporale non è un miglioramento marginale delle tecniche. Rappresenta uno spostamento di paradigma: la fase di pianificazione e build, tradizionalmente la più lunga e rilevabile del kill chain, è ora compressa entro una singola finestra operativa. La difesa basata su rilevamento di pattern temporali fallisce.

Il dato trova eco in ricerche di settore più ampie. Secondo il report di Filigran citato da The Hacker News, l'88% dei security leader afferma che l'intelligenza artificiale accelera la velocità degli attaccanti post-infiltrazione. Il 93% riferisce attacchi cyber con impatto business negativo negli ultimi 12 mesi nonostante difese validate.

Perché i controlli tradizionali non reggono

La difesa tradizionale si articola su tre pilastri: email security per l'ingresso, autenticazione forte per le credenziali, endpoint detection per il comportamento post-compromissione. La catena OAuth-first aggira tutti e tre. Non c'è email da filtrare. Non ci sono credenziali da proteggere. Non c'è endpoint compromesso da rilevare.

L'elemento distintivo è che l'attaccante e l'agente AI legittimo condividono la stessa firma comportamentale. Entrambi attraversano: OAuth grant, accesso dati Gmail/Drive, scoperta credenziali nei contenuti, movimento laterale via password reset o magic links, persistenza. La differenza risiede unicamente nell'intenzionalità, che non è osservabile tecnicamente.

Come sottolinea l'analista di Material Security, "The same coverage that defends against the modern attack chain also defends against the modern agent risk. They're the same problem, wearing different hats". La implicazione è che la sicurezza non può più basarsi sulla distinzione tra attore malizioso e attore legittimo, ma deve spostarsi sul controllo dell'ambiente: least-privilege granulare, classificazione dei dati, visibilità cross-layer che integri email, OAuth, Drive e comportamento account in un'unica superficie di analisi.

Cosa fare adesso

• Audit degli OAuth grants attivi: identificare agenti AI e applicazioni terze con accesso a Gmail/Drive, verificando che lo scope corrisponda al task effettivo richiesto.
• Classificazione dei dati in Drive e email: mappare dove risiedono credenziali, token o informazioni sensibili che potrebbero fungere da pivot per movimento laterale.
• Visibilità cross-layer: integrare i log di OAuth grants con l'accesso ai dati e le azioni account per rilevare pattern che isolati appaiono legittimi.
• Ricalibrazione delle policy di accesso: progettare il controllo assumendo che qualsiasi agente autorizzato possa replicare il percorso di un attaccante, indipendentemente dalla sua natura.

Un problema di architettura, non di intenzione

La novità di questo scenario non è tecnica ma categoriale. Per decenni la sicurezza informatica ha costruito controlli che presumevano una distinzione netta tra insider e outsider, tra software legittimo e malware, tra errore umano e intenzionalità malevola. L'integrazione degli agenti AI nei flussi di lavoro aziendali dissolve queste categorie.

Quando un token OAuth autorizzato legge credenziali in un thread email e le utilizza per accedere a un sistema terzo, il confine tra produttività automatizzata e compromissione diventa operativamente irrilevante. La domanda non è più "chi sta attaccando?" ma "qualunque entità con questi permessi può causare questo danno?". La risposta, per gli agenti AI sovra-permessi come per gli attaccanti con token rubati, è affermativa. La sicurezza del workspace deve ricostruirsi su questa premessa.

Domande frequenti

Perché gli OAuth token rubati sopravvivono al cambio password?

Gli OAuth token sono disaccoppiati dalle credenziali utente. Una volta emessi, autorizzano l'applicazione senza richiedere ri-autenticazione. Il reset password invalida la password, non i token già distribuiti.

Gli agenti AI possono essere configurati per evitare l'accesso a dati sensibili?

Il brief non documenta meccanismi di scoping automatico. Il problema evidenziato è che gli agenti eseguono il task senza comprendere il contesto aziendale del dato, rendendo insufficiente la configurazione task-level senza controlli ambientali sui dati.

Il CVE-2025-20393 è collegato a questa minaccia?

I dati disponibili non consentono di stabilire un collegamento. La pagina NVD relativa al CVE non è risolta in dettagli specifici nel materiale estratto.

Fonti

• https://www.helpnetsecurity.com/2026/09/16/material-google-workspace-attack-chains/
• https://thehackernews.com/2026/09/attack-chains-not-just-attack-surfaces.html
• https://nvd.nist.gov/vuln/detail/cve-2025-20393
• https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai/
• https://www.bleepingcomputer.com/news/security/reliaquest-confirms-failed-data-theft-attack-after-shinyhunters-breach/
• https://nvd.nist.gov/vuln
• https://img2.helpnetsecurity.com/posts2026/Material-Google_Workspace_security_2.png

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti