Aumentano le campagne di phishing basate sui codici dispositivo OAuth grazie al toolkit EvilTokens

4 maggio 2026

Di Rikesh Vekaria, Archa Archa, Hiwot Mendahun, Samantha Clarke e il team di ricerca sulle minacce di Mimecast

Panoramica della campagna

Il team Mimecast Threat Research ha rilevato un aumento significativo delle campagne di phishing basate sul codice OAuth dei dispositivi, rivolte agli utenti di Microsoft 365 in tutte le regioni e in tutti i settori. A partire dal marzo 2026, oltre 50.000 campagne di e-mail malevole hanno sfruttato il flusso di autorizzazione dei dispositivi OAuth 2.0 di Microsoft, un meccanismo originariamente progettato per dispositivi privi di tastiera, quali smart TV e apparecchiature IoT, al fine di sottrarre token di autenticazione e compromettere account basati sul cloud.

Questa tecnica è diventata rapidamente uno dei metodi di attacco preferiti dagli autori delle minacce, proprio come gli attacchi ClickFix hanno dominato il panorama delle minacce lo scorso anno. La facilità di esecuzione dell’attacco è stata amplificata dalla comparsa di EvilTokens, un toolkit di tipo Phishing-as-a-Service (PhaaS) venduto su Telegram che automatizza l’intera catena di attacco. EvilTokens integra contenuti di ingegneria sociale generati dall’intelligenza artificiale, consentendo anche agli autori di attacchi con scarse competenze di condurre campagne convincenti di usurpazione d’identità dei marchi su larga scala.

Comprendere il phishing tramite codice dispositivo

Gli attacchi di phishing tradizionali mirano a sottrarre le credenziali di accesso presentando pagine di accesso fasulle che imitano i servizi legittimi. Il phishing tramite codice dispositivo rappresenta un’evoluzione fondamentale: anziché simulare l’interfaccia di accesso di Microsoft, gli autori degli attacchi sfruttano la stessa infrastruttura di autenticazione di Microsoft per ottenere token di accesso reali e validi. Il flusso di autorizzazione dei dispositivi OAuth 2.0 funziona come segue in caso di utilizzo legittimo:

1. Un dispositivo (ad esempio una smart TV) genera un codice dispositivo e lo visualizza all'utente
2. L'utente accede alla pagina microsoft.com/devicelogin su un dispositivo separato
3. L'utente inserisce il codice del dispositivo ed effettua l'autenticazione utilizzando le proprie credenziali
4. Microsoft rilascia un token di accesso al dispositivo originale, concedendogli l'accesso autorizzato

Negli attacchi di phishing basati sul codice dei dispositivi, gli autori delle minacce sfruttano questo flusso:

1. Registrazione di un'applicazione OAuth dannosa su Microsoft Azure AD
2. Avvio di un flusso di autorizzazione dei dispositivi sulla propria infrastruttura di backend
3. Ottenere un codice dispositivo valido dai server di autorizzazione di Microsoft
4. La diffusione di questo codice alle vittime tramite e-mail di phishing e pagine web contraffatte dei marchi
5. Convincere le vittime a visitare la vera pagina di accesso ai dispositivi Microsoft e a inserire il codice
6. Acquisizione dei token OAuth risultanti quando la vittima completa l'autenticazione

Poiché le vittime effettuano l’autenticazione sull’infrastruttura originale di Microsoft e i token emessi sono legittimi, questa tecnica aggira l’autenticazione a più fattori, supera tutti i controlli di reputazione del dominio ed elude i tradizionali meccanismi di rilevamento del phishing. L'attacco non si basa sull'acquisizione delle credenziali, ma sfrutta la fiducia degli utenti nei flussi di lavoro aziendali a loro familiari per autorizzare applicazioni dannose.

L'ecosistema di EvilTokens

Secondo una ricerca condotta da Sekoia, EvilTokens rappresenta un’importante innovazione nel panorama degli attori malintenzionati: una piattaforma di phishing-as-a-service completamente automatizzata che trasforma in un prodotto di massa il sofisticato abuso del protocollo OAuth. Il toolkit mette a disposizione degli autori delle minacce:

• Ingegneria sociale basata sull’intelligenza artificiale: generazione automatizzata di e-mail di phishing e pagine di destinazione convincenti che imitano marchi affidabili e processi aziendali
• Infrastruttura chiavi in mano: sistemi di backend preconfigurati che gestiscono la generazione del codice dei dispositivi, il monitoraggio delle sessioni delle vittime e la raccolta dei token
• Monitoraggio in tempo reale: interfacce della dashboard che mostrano le campagne attive, le interazioni con le vittime e le acquisizioni di token andate a buon fine
• Scalabilità: capacità di lanciare migliaia di campagne di phishing simultanee con competenze tecniche minime. Questa democratizzazione delle tecniche di attacco avanzate spiega la crescita esplosiva osservata a partire dal marzo 2026. Mentre in passato il phishing tramite codice dispositivo richiedeva conoscenze tecniche sofisticate, EvilTokens consente a qualsiasi autore di minacce, dotato di conoscenze di base in materia di sicurezza operativa, di condurre campagne di compromissione degli account su scala aziendale.

Varianti della campagna

Campagna di registrazione dei dispositivi Mimecast

Questa campagna, rilevata per la prima volta il 16 aprile, mette in luce uno sviluppo preoccupante: gli autori delle minacce hanno iniziato a simulare la procedura di registrazione dei dispositivi di Mimecast, sfruttando il flusso di lavoro di sicurezza legittimo che i clienti utilizzano per accedere ai contenuti protetti.

Flusso di registrazione fasullo dei dispositivi Mimecast: i destinatari ricevono e-mail che dichiarano di contenere documenti protetti o link che richiedono la registrazione dei dispositivi Mimecast. Quando le vittime cliccano sul link, si ritrovano su una pagina visivamente identica all’interfaccia di registrazione dei dispositivi di Mimecast.

1. Pagina iniziale: mostra il logo Mimecast con le istruzioni per accedere a "e ottenere il codice di autenticazione"
2. Visualizzazione del codice: dopo aver cliccato sul pulsante, la pagina si aggiorna e mostra il codice del dispositivo direttamente sulla pagina web
3. Accesso ai documenti: viene visualizzato il pulsante "Visualizza documento" ( "" ), che, se cliccato, reindirizza alla pagina microsoft.com/devicelogin
4. Richiesta di autenticazione: la pagina ufficiale di Microsoft richiede il codice, invitando gli utenti a "inserire il codice visibile sulla propria app o sul proprio dispositivo per concedere l'autorizzazione completa al proprio account"
5. Furto di token: al momento dell’autenticazione, il backend dell’autore dell’attacco intercetta i token OAuth mentre le vittime credono di aver completato una procedura legittima di registrazione del dispositivo

Flusso di registrazione legittimo dei dispositivi Mimecast:

Comprendere il processo autentico è fondamentale per la formazione degli utenti e il rilevamento delle minacce:

1. L'utente fa clic su un link modificato da Mimecast contenuto in un'e-mail che richiede la registrazione del dispositivo e viene reindirizzato alla pagina di registrazione del dispositivo di Mimecast        
2. La pagina web richiede l'indirizzo e-mail dell'utente, che verrà verificato confrontandolo con il database dei clienti di Mimecast per confermare che si tratti di un utente legittimo di Mimecast
3. Dopo aver cliccato su “ "” (Ottieni il codice di registrazione del dispositivo),", la pagina web si aggiorna per visualizzare un campo di inserimento del codice di registrazione e informa l’utente che il codice è stato inviato al suo indirizzo e-mail. NOTA: il codice NON viene visualizzato sulla pagina web
 
4. L'utente recupera il codice dalla propria e-mail e lo inserisce nel campo di immissione della pagina web
5. Una volta completata con successo la convalida, l'utente viene reindirizzato al contenuto originariamente richiesto.

La differenza fondamentale è che la procedura legittima di registrazione dei dispositivi Mimecast non mostra mai i codici di registrazione direttamente sulle pagine web. I codici vengono sempre inviati via e-mail come canale di verifica secondario.

Questa imitazione è particolarmente efficace perché:

• Gli utenti si aspettano che vengano applicate procedure di sicurezza quando accedono a contenuti protetti
• La registrazione dei dispositivi risulta essere un requisito di sicurezza legittimo
• La fedeltà visiva delle pagine contraffatte rispecchia fedelmente l’immagine coordinata originale di Mimecast

Campagna di revisione dei documenti DocuSign

La variante più diffusa della campagna si avvale dell’usurpazione dell’identità del marchio DocuSign, sfruttando l’ampio ricorso, in ambito aziendale, ai flussi di lavoro basati sulla firma elettronica. I destinatari ricevono e-mail in cui si sostiene che sia necessaria la revisione o la firma di un documento, con oggetti del tipo:

• "DocuSign - Revisione del documento"
• "Agreement_Review.pdf - Firma richiesta"
• "Urgente: contratto in attesa della Sua firma"

L'efficacia della campagna deriva dallo sfruttamento di un processo aziendale reale: molte organizzazioni integrano infatti DocuSign con Microsoft 365 per la verifica dell'identità, facendo sì che la richiesta di verifica appaia come una procedura di routine piuttosto che come un'attività sospetta.

Campagna di notifica dei messaggi vocali su Microsoft Teams

Un’altra variante della campagna sfrutta la diffusione capillare delle notifiche della segreteria telefonica di Microsoft negli ambienti aziendali. Poiché le organizzazioni fanno sempre più affidamento su piattaforme di comunicazione unified, gli avvisi relativi alla segreteria telefonica sono diventati comunicazioni di routine, date per scontate, che i dipendenti raramente esaminano con attenzione. I destinatari ricevono e-mail concepite per sembrare autentiche notifiche relative alla segreteria telefonica di Microsoft, con oggetti del tipo:

• "Ha ricevuto un nuovo messaggio vocale da [Nome]"
• "Chiamata persa - Nuovo messaggio in segreteria"
• "Microsoft Teams: nuovo messaggio vocale"
• "Notifica di messaggio vocale - È richiesta un'azione"

Analisi tecnica: occultamento ed elusione

Schema di crittografia multistrato

Le campagne più recenti adottano misure anti-analisi per impedire ai ricercatori nel campo della sicurezza e ai sistemi automatizzati di esaminare le infrastrutture utilizzate per il phishing. Il meccanismo di offuscamento principale utilizza la crittografia AES-GCM con decrittografia lato client.

Fase 1: Carico iniziale Quando le vittime accedono per la prima volta a un URL di phishing, ricevono un documento HTML contenente codice JavaScript

Una piccola funzione di caricamento JavaScript decodifica le stringhe Base64 in array di byte, importa la chiave AES-GCM tramite l'API Web Crypto e decifra il testo cifrato utilizzando l'IV fornito.

Fase 2: Sostituzione dinamica dei contenuti Una volta completata con successo la decrittografia, lo script sostituisce l’intero documento HTML con il contenuto decrittografato:

Questo approccio garantisce che la pagina di phishing vera e propria — contenente i loghi dei marchi, i testi di ingegneria sociale e gli elementi di modulo dannosi — rimanga invisibile a:

• Scanner di sicurezza per le e-mail che analizzano le destinazioni dei link
• Servizi di valutazione della reputazione degli URL che effettuano la scansione e l'analisi delle pagine
• Ricercatori nel campo della sicurezza impegnati nella valutazione iniziale
• Raccolta automatizzata di informazioni sulle minacce

Solo quando JavaScript viene eseguito in un contesto browser completo, il vero contenuto di phishing diventa visibile. Gli strumenti di analisi statica che esaminano il codice sorgente HTML rilevano solo il payload crittografato e lo script di caricamento.

Fase 3: Coordinamento del backend La pagina di phishing decriptata comunica con l’infrastruttura di backend controllata dall’autore dell’attacco per coordinare il flusso del codice sul dispositivo:

Avvio della sessione:

Tale richiesta induce il backend ad avviare un flusso di autorizzazione OAuth legittimo del dispositivo con Microsoft. La risposta contiene:

• userCode: il codice effettivo del dispositivo ottenuto dai server di autorizzazione di Microsoft
• sessionId: un identificatore univoco per il monitoraggio della sessione di questa vittima

Interrogazione dello stato:

La pagina di phishing effettua continue richieste al backend per stabilire quando la vittima abbia completato l'autenticazione sulla piattaforma Microsoft. Quando il backend riesce a sostituire il codice del dispositivo con i token OAuth, risponde con lo stato: "completed", facendo sì che la pagina di phishing visualizzi un messaggio di esito positivo e reindirizzi all’autentico sito web del marchio.

Infrastruttura e hosting

Le pagine di phishing sono spesso ospitate su:

• Bucket AWS S3: un servizio di archiviazione cloud affidabile che garantisce elevata disponibilità e un’infrastruttura sicura
• Server web compromessi: domini esistenti con una reputazione consolidata per eludere le liste di blocco
• Domini registrati di recente: domini con scarsa reputazione che presentano varianti di typosquatting di marchi legittimi

Gli endpoint dell'API backend che gestiscono la generazione dei codici dei dispositivi e l'acquisizione dei token operano su un'infrastruttura separata, avvalendosi spesso di:

• Server privati virtuali (VPS) offerti da provider che richiedono una verifica minima dell’identità
• Indirizzi IP dotati di certificati TLS validi emessi da Let's Encrypt, che conferiscono una falsa legittimità

Questa separazione tra le pagine di phishing visibili e l’infrastruttura di acquisizione dei token complica le operazioni di smantellamento e l’attribuzione della responsabilità.

Indicatori di compromissione (IOC)

Campagna DocuSign

Domini utilizzati per il phishing:

• 00a7af15-a112-4457-86c2-5c56751f0f47-endpoint[.]com
• index-yfb.kpenza-htrenchless-com-s-account.workers[.]dev

Esempi di oggetti delle e-mail:

• "DocuSign - Revisione del documento"
• "Agreement_Review.pdf - Firma richiesta"
• "Urgente: contratto in attesa della Sua firma"
• "Documento in attesa della Sua firma elettronica"

Campagna sulla segreteria telefonica di Microsoft

Domini utilizzati per il phishing:

• voice-mail-auth-office-com.saxeco7653.workers[.]dev
• auth-login-office-com.saxeco7653.workers[.]dev
• delicate-poetry-debc.dporozok.workers[.]dev

Esempi di oggetti delle e-mail:

• "Notifica di messaggio vocale - È richiesta un'azione"
• "Chiamata persa - Nuovo messaggio in segreteria"
• "Ha ricevuto un nuovo messaggio vocale da [Nome]"

Campagna di registrazione dei dispositivi Mimecast

Domini utilizzati per il phishing:

• sso-nodeconnect[.]icu/

Esempi di oggetti delle e-mail:

• "Visualizza il documento"
• "Agreement_Review.pdf - Firma richiesta"

Obiettivi

Ambito geografico: globale — tutte le regioni

Settore di riferimento: trasversale; particolarmente efficace nei confronti delle organizzazioni che utilizzano DocuSign, Microsoft o Mimecast

Raccomandazioni

Formazione sulla sensibilizzazione alla sicurezza degli utenti

• Informare i dipendenti sulle caratteristiche specifiche di queste campagne
• Gli utenti non devono mai inserire codici relativi ai dispositivi provenienti da e-mail non richieste, anche qualora la pagina di accesso di Microsoft sembri autentica. I flussi di lavoro autentici per la registrazione dei dispositivi offerti da Mimecast e da altri servizi seguono schemi specifici: i codici vengono inviati tramite e-mail, non vengono visualizzati sulle pagine web e non richiedono mai l’autenticazione sulla pagina di accesso ai dispositivi di Microsoft.
• Verifichi i consensi relativi alle applicazioni OAuth. Le organizzazioni dovrebbero verificare i consensi esistenti relativi alle applicazioni di terze parti nei propri tenant Microsoft 365, individuando e revocando le applicazioni con nomi sospetti, date di autorizzazione recenti o editori sconosciuti.

Ricerca proattiva delle minacce

• Effettuare una ricerca nei registri delle ricevute e-mail utilizzando gli indicatori (IOC) elencati

Il phishing tramite codice dispositivo rappresenta una sfida fondamentale per l'autenticazione basata sul cloud: l'attacco sfrutta funzionalità legittime previste dal design di OAuth 2.0, non una vulnerabilità che possa essere corretta con una patch. Poiché i toolkit di phishing-as-a-service come EvilTokens continuano a rendere accessibili a tutti tecniche sofisticate, le organizzazioni devono potenziare le proprie difese andando oltre i tradizionali controlli perimetrali. Microsoft ha introdotto criteri di autenticazione basati sul rischio e funzionalità di governance delle applicazioni, ma una protezione ottimale richiede una difesa a più livelli: controlli tecnici che limitino l’autorizzazione OAuth, la formazione degli utenti affinché sappiano riconoscere gli abusi dei codici dei dispositivi e operazioni di sicurezza in grado di rilevare rapidamente gli indicatori di compromissione. L’aumento dei casi di phishing tramite codice dispositivo evidenzia come i modelli di autenticazione basati sulla fiducia, concepiti per garantire la comodità degli utenti, creino al contempo opportunità di ingegneria sociale su una scala senza precedenti.