Microsoft smantella la rete EvilTokens basata sull’AI, responsabile della compromissione di 12.000 account email

Microsoft ha interrotto le attività di EvilTokens, una piattaforma di phishing-as-a-service che aveva trasformato un meccanismo legittimo di autenticazione Microsoft in un sistema industrializzato per compromettere account email e realizzare frodi aziendali tramite posta elettronica.

L’operazione ha portato al sequestro di 50 siti web e alla disattivazione di oltre 150 domini di supporto. Microsoft ha ricondotto lo sviluppo, la gestione e l’assistenza clienti del servizio all’attore delle minacce che monitora con il nome Storm-2992.

EvilTokens è stato associato a oltre 12.000 caselle di posta compromesse presso più di 10.000 organizzazioni in tutto il mondo. Anziché sottrarre direttamente le password, il servizio induceva le vittime ad autorizzare sessioni controllate dagli attaccanti tramite il flusso di autorizzazione dei dispositivi OAuth 2.0 di Microsoft.

La Digital Crimes Unit di Microsoft ha ottenuto dal Tribunale distrettuale degli Stati Uniti per il distretto orientale della Virginia l’autorizzazione a condurre l’operazione. Hanno collaborato all’intervento Health-ISAC, Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation e TRM Labs.

Una piattaforma commerciale per il furto di token e la compromissione della posta aziendale

Storm-2992 promuoveva EvilTokens su Telegram come servizio completo per i criminali informatici. L’operatore utilizzava canali e bot di messaggistica per pubblicizzare i prodotti, distribuire il kit di phishing, annunciare gli aggiornamenti, assistere gli abbonati e offrire ricompense in criptovaluta per le segnalazioni di nuovi clienti.

La piattaforma è comparsa nel febbraio 2026. Huntress l’ha documentata nel marzo 2026, mentre Sekoia ha descritto un’offerta pronta all’uso venduta tramite Telegram dalla metà di febbraio. Microsoft ha poi monitorato una campagna riconducibile a EvilTokens nell’aprile 2026.

Tra gli account Telegram segnalati figuravano gli handle amministrativi @eviltokensadmin, @eviltokensadmins e @EvilTokenscontact, oltre ai bot del negozio @EvilTokens_bot e @EvilTokensStorebot. L’operazione gestiva inoltre il canale pubblico @EvilTokensChannel e un gruppo Telegram separato.

Secondo l’analisi tecnica di Microsoft, il kit principale costava 1.500 dollari, a cui si aggiungeva un abbonamento mensile di 500 dollari per accedere ai componenti di phishing e al pannello di controllo. Tra gli altri prodotti segnalati figuravano Antibot Redirector, B2B Sender, SMTP Sender e Office 365 Capture Link.

Un’analisi separata attribuita a Sekoia indicava un prezzo di 600 dollari per B2B Sender e di 1.000 dollari per SMTP Sender. I prezzi aggiuntivi e le modalità di licenza riportate non sono stati descritti in modo indipendente nell’avviso Microsoft disponibile.

Il pannello clienti gestiva molte più funzioni della semplice creazione di pagine di phishing. Gli abbonati potevano configurare domini e hosting, selezionare lingue e layout delle pagine, modificare il comportamento di CAPTCHA e reindirizzamenti, monitorare le vittime, gestire i token sottratti, analizzare le caselle di posta alla ricerca di parole chiave selezionate e ricevere avvisi tramite Telegram.

Le opzioni di distribuzione includevano l’infrastruttura Cloudflare Workers o Bunny e il tradizionale hosting PHP. Queste possibilità consentivano ai clienti di personalizzare le campagne senza dover sviluppare autonomamente sistemi di distribuzione o di compromissione degli account.

Come un accesso Microsoft autentico è diventato il meccanismo di phishing

Il flusso di autorizzazione dei dispositivi è stato progettato per l’hardware con capacità di input limitate, come smart TV, stampanti, dispositivi Teams e apparecchiature per videoconferenze. Di norma, il dispositivo mostra un codice breve che l’utente inserisce nel browser di un altro sistema per approvare l’accesso.

EvilTokens sfruttava la separazione tra il browser utilizzato per l’approvazione e la sessione che aveva richiesto inizialmente l’autorizzazione.

L’attaccante avviava innanzitutto una richiesta di codice dispositivo. EvilTokens inviava quindi il codice risultante alla vittima tramite una pagina di phishing, inducendola ad approvare una sessione controllata dall’attaccante.

Le campagne utilizzavano 44 temi-esca, tra cui fatture, richieste di offerta, documenti condivisi, avvisi di scadenza delle password, messaggi vocali, comunicazioni eFax, notifiche di pagamento e servizi per la firma dei documenti. I link malevoli potevano essere distribuiti direttamente oppure incorporati in allegati PDF e HTML.

Dopo aver seguito l’esca, la vittima arrivava su una pagina contenente un’automazione in background che comunicava con il provider di identità Microsoft e generava un codice dispositivo attivo. La pagina mostrava un controllo “Copia codice” e un pulsante con l’etichetta “Continua” o “Continua con Microsoft”.

Il pulsante inviava la vittima alla pagina legittima microsoft.com/devicelogin. Il dominio autentico conferiva credibilità che una pagina clonata per il furto delle credenziali non avrebbe potuto garantire.

La vittima inseriva il codice generato dall’attaccante e, se necessario, completava le normali richieste di password e autenticazione a più fattori. Il servizio di autorizzazione Microsoft rilasciava quindi i token di accesso e di aggiornamento al client dell’attaccante.

L’operatore di EvilTokens non doveva ricevere alcuna password. Neppure l’MFA impediva la compromissione, perché la vittima stava approvando una richiesta di autenticazione reale, ma non quella avviata dal dispositivo o dal servizio a cui credeva di accedere.

I token sottratti alimentavano una catena di frodi assistita dall’AI

Una volta ottenuti token validi, i clienti di EvilTokens potevano accedere alla casella di posta della vittima, esfiltrare i messaggi, creare regole della posta in arrivo per nascondere le comunicazioni malevole e registrare ulteriori dispositivi. I token di aggiornamento e le sessioni attive potevano mantenere l’accesso oltre l’intrusione iniziale.

La piattaforma utilizzava inoltre Microsoft Graph per esaminare utenti, ruoli, autorizzazioni, strutture gerarchiche e altre relazioni organizzative. Questa ricognizione aiutava a individuare i dipendenti con potere decisionale in ambito finanziario e i contatti le cui identità sarebbero state utili per le attività di impersonificazione.

Le funzioni di AI erano integrate in questa fase successiva alla compromissione. L’assistente poteva analizzare il contenuto delle caselle di posta alla ricerca di fatture di fornitori, approvazioni di pagamento, discussioni finanziarie, responsabilità sensibili e persone autorizzate a trasferire denaro.

Poteva quindi riassumere o tradurre i messaggi in più di 20 lingue, individuare relazioni di fiducia, proporre strategie di frode e redigere messaggi che imitavano contatti conosciuti. I contenuti di phishing potevano essere adattati al ruolo della vittima e al contesto individuato nella casella di posta.

EvilTokens era quindi molto più di un kit per la raccolta di token. In un’unica interfaccia combinava l’accesso iniziale, l’analisi delle caselle di posta, la selezione dei bersagli, la mappatura dell’organizzazione, l’impersonificazione e la preparazione di frodi aziendali tramite posta elettronica.

Il risultato riduceva le competenze necessarie per condurre frodi mirate. Un affiliato non doveva sviluppare un sistema di phishing OAuth, esaminare manualmente migliaia di messaggi o comprendere l’organizzazione della vittima prima di tentare di dirottare un pagamento.

L’infrastruttura a vita breve complicava il rilevamento

EvilTokens utilizzava reindirizzamenti concatenati, controlli CAPTCHA contraffatti e hosting serverless per evitare il semplice blocco dei domini. Tra le infrastrutture osservate figuravano Vercel, Cloudflare Workers e AWS Lambda.

Nella campagna monitorata da Microsoft nell’aprile 2026, le piattaforme di automazione generavano migliaia di nodi di polling unici e a vita breve. Una complessa logica backend Node.js supportava il processo dalla generazione del codice dispositivo attivo fino alle successive attività sull’account.

La rapida evoluzione dell’infrastruttura riduceva l’efficacia degli indicatori statici e delle firme semplici. Un dominio identificato in un messaggio poteva scomparire o diventare irrilevante, mentre lo stesso flusso backend ricompariva tramite un altro endpoint serverless.

SpyCloud ha fornito dati di phishing recuperati relativi a 8.708 account vittima unici, associati a 6.585 domini di posta aziendale in 79 Paesi. Le acquisizioni recuperate più datate risalivano al 18 febbraio 2026.

Le maggiori concentrazioni di vittime osservate si trovavano negli Stati Uniti, in Canada, nel Regno Unito, in Australia, in India e in Francia. Tra i settori colpiti figuravano la distribuzione all’ingrosso, l’edilizia, i servizi finanziari, il settore immobiliare, l’istruzione superiore e la sanità.

Secondo i partner che hanno contribuito alle analisi, tra ottobre 2025 e giugno 2026 circa 1,1 milioni di dollari di ricavi della piattaforma sarebbero stati attribuiti a quattro indirizzi Tron. Coinbase avrebbe individuato oltre 1.000 depositi provenienti da più di 700 indirizzi di criptovaluta. Microsoft non ha quantificato separatamente questi dati finanziari nel proprio avviso.

Sequestro disposto dal tribunale e due arresti

La Digital Crimes Unit di Microsoft ha utilizzato l’ordinanza del tribunale federale della Virginia per sequestrare 50 siti web coinvolti nella gestione di EvilTokens e disattivare oltre 150 domini correlati.

Secondo le notizie sull’operazione coordinata, il Metropolitan Police Service ha arrestato il 11 settembre 2026 due uomini di 32 e 38 anni in relazione alla gestione commerciale dell’operazione. I loro nomi non sono stati resi noti nel materiale disponibile.

Microsoft ha pubblicato la propria analisi il 22 settembre 2026. Il sequestro rimuove una parte consistente dell’infrastruttura, ma non è stato divulgato alcun elenco completo degli account interessati, delle identità dei clienti o dei sistemi ancora controllati dagli affiliati.

Le organizzazioni devono quindi verificare l’eventuale esposizione, anziché considerare l’interruzione dell’infrastruttura una bonifica degli ambienti già compromessi.

I difensori devono revocare i token, non limitarsi a reimpostare le password

Microsoft raccomanda di bloccare l’autenticazione tramite codice dispositivo laddove non sia necessaria per le attività operative. Le organizzazioni possono utilizzare Conditional Access per disabilitare o limitare rigorosamente il flusso.

Quando l’hardware Teams dipende dall’autenticazione tramite codice dispositivo, le eccezioni devono essere limitate agli account risorsa designati per i dispositivi Teams. Microsoft raccomanda inoltre di escludere la risorsa Device Registration Service dai criteri Conditional Access pertinenti.

In seguito a una sospetta compromissione, i difensori devono revocare le sessioni attive e i token di aggiornamento, rimuovere le registrazioni di dispositivi non autorizzate e reimpostare le credenziali. La sola modifica della password potrebbe lasciare intatto l’accesso dell’attaccante basato sui token già ottenuti.

I team di sicurezza devono inoltre verificare:

• I dispositivi registrati di recente e le autorizzazioni OAuth sospette.
• Le regole malevole della posta in arrivo, i messaggi nascosti e i reindirizzamenti insoliti.
• Le query anomale a Microsoft Graph relative a utenti, ruoli, autorizzazioni o struttura organizzativa.
• I link indesiderati che utilizzano piattaforme serverless come Vercel, Cloudflare Workers o AWS Lambda.
• Le esche basate su fatture, RFP, file condivisi, scadenza delle password, pagamenti, messaggi vocali, eFax e firma dei documenti.
• I connettori di terze parti che potrebbero consentire a messaggi contraffatti di aggirare le normali protezioni della posta.

Gli utenti devono considerare sospette le istruzioni inattese che chiedono di inserire un codice su microsoft.com/devicelogin, anche se il sito è legittimo. La domanda decisiva è se l’utente abbia avviato personalmente una procedura di autenticazione del dispositivo autorizzata.

Questa distinzione era centrale nel caso EvilTokens: l’accesso Microsoft era reale, il codice era valido e l’MFA funzionava come previsto. L’inganno riguardava la sessione che la vittima stava autorizzando.