ToddyCat usa Umbrij per rubare token OAuth e accedere agli account Gmail

🛡️ Executive Summary

• ToddyCat usa Umbrij per ottenere token OAuth validi e accedere agli account Gmail aziendali tramite API Google.
• La tecnica Shadow Token via Remote Debug abusa di sessioni Chromium già autenticate attraverso profili copiati e debug remoto.
• Il deployment avviene tramite DLL sideloading, task pianificati e binari legittimi, riducendo la visibilità per EPP ed EDR.

ToddyCat amplia il proprio arsenale con Umbrij, uno strumento progettato per compromettere account Gmail aziendali senza rubare direttamente password e senza richiedere nuova interazione da parte dell’utente. Il tool, documentato da Kaspersky dopo attività di threat hunting, sfrutta una tecnica denominata Shadow Token via Remote Debug per abusare del flusso OAuth 2.0 di Google attraverso browser basati su Chromium. Gli attaccanti copiano il profilo dell’utente, avviano il browser in modalità headless con una porta di debug remoto e pilotano il processo di autorizzazione fino a ottenere un codice valido, poi scambiato per un token di accesso. Con quel token possono interagire con le API di Gmail, Google Calendar, Google Drive e altri servizi, aggirando molti controlli tradizionali basati su password, MFA e anomalie di login. Umbrij mostra così l’evoluzione delle operazioni APT contro la posta cloud: non più solo furto di cookie o credenziali, ma abuso automatizzato delle stesse logiche autorizzative usate dalle applicazioni legittime.

ToddyCat evolve dal furto browser all’abuso OAuth

ToddyCat è un gruppo APT già noto per campagne mirate contro comunicazioni aziendali, dati browser e servizi email locali o cloud. Le tecniche precedenti, pur efficaci, venivano intercettate con maggiore probabilità da soluzioni EPP ed EDR, perché implicavano accesso diretto a file sensibili, dumping di dati o esecuzione di utility sospette. Umbrij nasce per superare questo limite operativo. Invece di estrarre direttamente credenziali, lo strumento sfrutta una sessione Google già attiva nel browser della vittima e forza, nel contesto di quel profilo, la concessione di un’autorizzazione OAuth a un’applicazione Google esistente.

Il risultato è un token apparentemente legittimo, ottenuto senza prompt visibili all’utente e utilizzabile via API. Questo approccio riduce la dipendenza da password e cookie riutilizzabili, migliora la persistenza dell’accesso e rende l’attività più simile al normale uso di un’integrazione autorizzata. Per un attore orientato allo spionaggio, l’accesso silenzioso a email, file e calendari aziendali offre un valore superiore rispetto alla semplice compromissione temporanea di una workstation.

Shadow Token via Remote Debug sfrutta Chromium headless

La tecnica Shadow Token via Remote Debug si basa sul controllo remoto di un browser Chromium-based in modalità headless. Umbrij individua i profili di Chrome ed Edge, copia i file necessari in una directory di backup dentro %LOCALAPPDATA% e avvia il browser con parametri come –user-data-dir, –remote-debugging-port e –headless. Poiché il profilo copiato conserva cookie, stato locale e dati di sessione, il browser opera come se fosse ancora l’utente legittimo. A quel punto il tool si connette alla porta di debugging tramite Puppeteer Sharp, libreria .NET che permette di controllare programmaticamente la pagina, eseguire JavaScript e simulare interazioni. Umbrij apre l’endpoint di autorizzazione di Google, attraversa le schermate di selezione account e permessi, quindi intercetta la redirect verso localhost contenente il parametro code. Il codice di autorizzazione viene salvato nei log e successivamente scambiato dagli operatori per un token OAuth valido. Il punto critico è che l’intero processo sfrutta il contesto autenticato dell’utente, non un furto classico di credenziali.

I client_id Google rendono l’attacco più credibile

Nel flusso osservato, Umbrij usa il client_id 279448736670, associato a Google Workspace Migration for Microsoft Outlook. Con il parametro -sync, il tool può sostituirlo con 1095133494869, collegato a un diverso scenario di sincronizzazione Google. Questa scelta è strategica perché gli attaccanti non devono registrare un’applicazione sospetta con nome arbitrario, ma abusano di identità applicative riconoscibili e coerenti con ambienti aziendali che usano strumenti di migrazione o sincronizzazione. L’URL OAuth include scope estesi per servizi come Gmail, Calendar, Drive e contatti, mentre omette alcuni elementi tipici dei flussi più moderni, come code_challenge e state, usando una redirect verso http://localhost. Dal punto di vista difensivo, la presenza di autorizzazioni concesse a Google Workspace Migration for Microsoft Outlook o Google Workspace Sync for Microsoft Outlook deve essere verificata con attenzione. Se queste applicazioni non sono realmente usate dall’organizzazione, la revoca dell’accesso diventa essenziale per invalidare token potenzialmente ottenuti dagli aggressori.

Umbrij prepara il profilo e impersona l’utente Windows

Prima di avviare il browser, Umbrij prepara l’ambiente con una sequenza precisa. Verifica che la porta di debugging sia disponibile, recupera il contesto dell’utente duplicando il token di explorer.exe e cerca i file Local State nei percorsi di Chrome e Edge. Il parametro -regex permette di filtrare i profili in base a una porzione dell’indirizzo email, mentre altre versioni supportano opzioni aggiuntive per domini Active Directory o controlli più profondi sull’identità dell’account. Il tool crea directory di backup in %LOCALAPPDATA% e copia elementi come IndexedDB, Local Storage, Login Data e Preferences. Se i file sono bloccati, ricorre a una funzione di copia forzata. Questa fase è importante perché consente agli attaccanti di lavorare su una copia del profilo, riducendo il rischio di interferire con la sessione dell’utente o generare segnali evidenti. Il browser viene quindi avviato dalla directory di installazione individuata in Program Files, con il profilo copiato e la porta di debug indicata dagli operatori.

DLL sideloading e task pianificati mascherano l’esecuzione

Il deployment di Umbrij avviene con tecniche già ricorrenti nell’arsenale di ToddyCat. Durante il threat hunting, Kaspersky ha individuato un task pianificato mascherato con il nome KasperskyEndpointSecurityEDRAvp, progettato per apparire come componente difensiva legittima. Il task eseguiva un file firmato digitalmente che caricava il tool tramite DLL sideloading. Tra gli eseguibili osservati figurano BDSubWiz.exe di Bitdefender, VSTestVideoRecorder.exe di Visual Studio e GoogleDesktop.exe, tutti abusati per caricare DLL come log.dll, Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll o GoogleServices.dll. Umbrij è una DLL .NET offuscata con ConfuserEx e rilevata da Kaspersky con firme euristiche come HEUR:Trojan-PSW.MSIL.Umbrij.gen. L’uso di binari firmati e nomi plausibili complica il rilevamento basato su reputazione, soprattutto in ambienti dove strumenti di sviluppo, agent di sicurezza e utility Google sono già presenti.

Versioni multiple indicano sviluppo operativo continuo

L’analisi ha identificato almeno tre varianti di Umbrij, indicate come versioni a, b e c, con parametri e funzioni leggermente differenti. La versione a supporta opzioni come -regex e -deepsearch per individuare profili legati a specifici account. La versione b introduce parametri come -domainAd, utile in ambienti di dominio, e -savepdf, capace di salvare informazioni o schermate del profilo in formato PDF. La versione c usa -lport come alias di -debugport. Parametri comuni includono -path, -browser e -sync, che consentono agli operatori di scegliere il browser, specificare la directory dell’eseguibile o cambiare il client_id OAuth. Il tool registra con dettaglio le proprie azioni, inclusi impersonificazione dell’utente, rilevamento dei profili, modalità sync e codice di autorizzazione recuperato. Questa verbosità operativa è utile agli attaccanti per controllare l’esito dell’operazione, ma offre anche artefatti preziosi per incident response e threat hunting.

Il rischio principale è l’accesso persistente alla posta cloud

L’impatto di Umbrij è particolarmente grave perché colpisce direttamente le comunicazioni aziendali ospitate su Google Workspace. Un token OAuth valido può consentire agli attaccanti di leggere email, accedere a file, consultare calendari, identificare contatti interni e preparare ulteriori movimenti laterali o campagne di spear phishing.

La vittima potrebbe non vedere un login anomalo tradizionale, perché l’attacco sfrutta una sessione già valida e un flusso autorizzativo pilotato localmente. Per le organizzazioni, il controllo non può quindi limitarsi a password e MFA. È necessario auditare periodicamente le app autorizzate dagli utenti, monitorare i token OAuth concessi, verificare accessi API insoliti e rilevare l’apertura di browser con –remote-debugging-port e –headless. Vanno inoltre cercati task pianificati con nomi ingannevoli, esecuzioni anomale di binari firmati da directory non standard, caricamenti sospetti di DLL e copie dei profili browser in percorsi di backup locali.

Difesa: revoca delle app OAuth e controllo del remote debugging

La mitigazione più immediata consiste nel controllare le connessioni autorizzate agli account Google e revocare applicazioni come Google Workspace Migration for Microsoft Outlook o Google Workspace Sync for Microsoft Outlook quando non sono previste dai processi aziendali. Gli amministratori Google Workspace dovrebbero limitare gli scope OAuth ad alto rischio, applicare policy di app access control, imporre verifiche sulle applicazioni consentite e monitorare pattern di accesso API incompatibili con l’attività ordinaria degli utenti. Sugli endpoint è essenziale rilevare processi Chrome o Edge avviati in modalità headless con porte di debug, copie improvvise di Local State, IndexedDB, Local Storage e Login Data, oltre a task pianificati che richiamano eseguibili legittimi ma caricano DLL inattese. La tecnica di ToddyCat dimostra che gli APT stanno spostando l’obiettivo dal furto delle credenziali al furto del consenso applicativo. In un ambiente cloud, proteggere l’identità significa controllare non solo chi accede, ma anche quali applicazioni ricevono token, con quali scope e da quale endpoint viene avviato il flusso di autorizzazione.