TLDR

  • Umbrij, collegato a ToddyCat, punta agli account Gmail aziendali usando OAuth e sessioni browser già aperte.
  • Il punto interessante è che la password non viene necessariamente rubata: il malware cerca di ottenere un token valido.
  • Browser headless, remote debugging e app Google autorizzate diventano superfici da monitorare.
  • La difesa passa da audit delle app collegate, revoca dei token sospetti, log endpoint e controllo dei browser avviati in modalità anomala.

Perché conta ora

La password è ancora importante, ma non è più il solo premio.

In molti ambienti cloud il vero bottino è il token: un permesso già concesso, valido, leggibile dalle API, abbastanza normale da non far rumore come un login fallito alle tre di notte.

La campagna descritta da Kaspersky a fine giugno 2026, collegata al gruppo ToddyCat, è interessante proprio per questo. Il tool Umbrij non punta solo a rubare credenziali in modo classico. Prova a sfruttare una sessione Gmail già aperta nel browser, ottenere un codice OAuth e trasformarlo in accesso API alla posta aziendale.

Tradotto: l'attaccante non deve necessariamente chiederti la password.

Può cercare di convincere il tuo browser, già autenticato, a concedere un token.

Il token è una chiave silenziosa

OAuth non è una vulnerabilità. È il modo normale con cui un'applicazione chiede accesso a un account senza conoscere la password.

Il problema nasce quando quel meccanismo viene usato nel contesto sbagliato.

Un token può permettere di leggere posta, contatti, calendario, file o altre risorse. Dipende dagli scope concessi. Se il token è valido, molte difese non vedono un ladro che forza la porta. Vedono un'app autorizzata che usa un'API.

È qui che il rischio diventa meno cinematografico e più fastidioso: l'accesso sembra amministrativamente pulito.

Non c'è per forza una password digitata su un sito falso.

Non c'è per forza un secondo fattore fallito.

C'è un consenso abusato.

Come lavora Umbrij, senza magia

La dinamica descritta dai ricercatori passa da alcuni ingredienti familiari:

  • DLL sideloading per avviare il componente malevolo;
  • browser Chromium già usato dall'utente;
  • modalità headless;
  • remote debugging port;
  • sessione Google ancora valida;
  • richiesta OAuth verso un'app Google legittima;
  • codice di autorizzazione poi convertito in token.

Il pezzo più importante non è il singolo trucco tecnico. È la combinazione.

Umbrij prova a prendere il contesto dell'utente, individuare profili Chrome o Edge con account Google autenticati, avviare una copia del browser in background e pilotarla attraverso il protocollo di debugging. Da lì tenta di completare un flusso OAuth e ottenere un codice di autorizzazione.

Se funziona, la posta non viene letta aprendo la webmail come farebbe una persona.

Viene letta via API.

Perché l'email aziendale è così preziosa

Una casella Gmail aziendale non contiene solo messaggi.

Contiene:

  • reset password;
  • inviti a documenti;
  • contratti;
  • allegati;
  • chat di progetto;
  • calendari;
  • nomi di clienti e fornitori;
  • notifiche di GitHub, cloud, CRM e banca;
  • link temporanei;
  • prove di relazione tra persone.

Chi legge la posta può spesso capire come entrare altrove.

E se l'accesso avviene via API, l'attacco può diventare più ordinato, selettivo e meno visibile all'utente finale.

Non serve spaventare la vittima.

Serve restare dentro.

Cosa controllare subito

Per un account Google Workspace o Gmail usato in azienda, controlla:

  1. App di terze parti collegate all'account.
  2. Scope concessi alle app più vecchie.
  3. Applicazioni Google Workspace Migration o Sync non usate.
  4. Browser avviati con --remote-debugging-port.
  5. Browser avviati in modalità headless su endpoint utente.
  6. DLL caricate da percorsi inattesi.
  7. Task pianificati con nomi che imitano software legittimi.
  8. Accessi Gmail via API fuori dal comportamento normale.
  9. Esportazioni o letture massive di messaggi.
  10. Account che non eseguono logout da sessioni condivise o macchine promiscue.

Il controllo delle app collegate è spesso sottovalutato perché sembra burocrazia.

In realtà è il pannello dove molte chiavi restano appese.

Errori comuni

Il primo errore è pensare che MFA risolva tutto.

MFA è fondamentale, ma se l'attaccante ottiene un token da una sessione già autenticata, il problema si sposta. Non sta più cercando di indovinare la password. Sta cercando di riusare una fiducia già concessa.

Il secondo errore è ignorare il browser come processo sospetto. Siamo abituati a vedere Chrome o Edge sempre aperti. Proprio per questo, un avvio anomalo del browser può passare inosservato.

Il terzo errore è trattare OAuth come un dettaglio da sviluppatori.

OAuth è identità operativa. Se non sai quali app hanno accesso agli account, non sai chi può leggere cosa.

Difese pratiche

Per team piccoli:

  • revoca le app OAuth non necessarie;
  • controlla periodicamente myaccount.google.com/connections;
  • limita gli scope delle app autorizzate;
  • monitora avvii browser con remote debugging;
  • blocca o limita DevTools dove non servono;
  • separa profili browser personali e aziendali;
  • evita sessioni Gmail permanenti su macchine condivise;
  • usa EDR o logging endpoint per task pianificati e DLL sospette;
  • crea una procedura rapida per revocare token e sessioni;
  • considera la posta come un asset critico, non come semplice comunicazione.

Per organizzazioni più grandi, il controllo deve stare anche nell'admin console: policy OAuth, app allowlist, alert su nuove autorizzazioni e audit periodico dei token.

Il punto

La sicurezza cloud non finisce al login.

Anzi, spesso comincia dopo.

Quando un utente ha completato MFA, quando il browser è aperto, quando le app sono autorizzate, quando gli strumenti di lavoro parlano tra loro via API.

Umbrij ricorda una cosa semplice: la password è rumorosa, il token è elegante.

E gli attaccanti amano le chiavi eleganti.

FAQ

Che cosa ruba Umbrij?

L'obiettivo osservato è ottenere un codice di autorizzazione OAuth e trasformarlo in token di accesso, così da leggere risorse Google come Gmail tramite API.

Perché OAuth è rischioso?

OAuth è legittimo e utile, ma un token valido può dare accesso alle risorse senza conoscere la password dell'utente. Se il token viene ottenuto in modo abusivo, l'attaccante entra dalla porta delle integrazioni.

Disconnettersi da Gmail aiuta?

Aiuta a ridurre il rischio legato alle sessioni browser attive, ma non basta da solo. Servono anche controllo delle app autorizzate, logging, EDR e policy sui browser.

Cosa devo controllare in Google Account?

La sezione delle app e dei servizi di terze parti collegati. Applicazioni come Google Workspace Migration o Sync per Outlook vanno revocate se non sono usate davvero.

Qual è il segnale tecnico più utile?

Un browser Chromium avviato in modalità headless con remote debugging attivo su una postazione utente che non fa sviluppo o test automatizzati è un evento da guardare subito.

Fonti