🛡️ Executive Summary

• Jalisco genera codici dispositivo OAuth in tempo reale e induce le vittime ad autorizzare sessioni Microsoft 365 controllate dagli attaccanti.
• I token validi superano password e MFA tradizionale, consentendo persistenza, associazione di dispositivi ed esfiltrazione SaaS in pochi minuti.
• Passkey FIDO2, Windows Hello e Conditional Access riducono il rischio imponendo metodi passwordless resistenti al phishing.

Il phishing alimentato dall’intelligenza artificiale è aumentato del 1380% tra la fine del 2025 e l’inizio del 2026, accompagnato da kit sempre più automatizzati e capaci di aggirare i controlli tradizionali. Tra gli strumenti più avanzati emerge Jalisco, un toolkit progettato per attacchi di device code phishing contro gli ambienti Microsoft 365. Il sistema genera codici OAuth validi in tempo reale, induce la vittima a completarli sulla pagina autentica di Microsoft e sottrae i relativi token senza intercettare direttamente la password. La difesa più efficace passa dall’adozione di metodi passwordless resistenti al phishing in Microsoft Entra ID, come passkey FIDO2 e Windows Hello for Business.

Jalisco trasforma il device code flow in un sistema industriale di furto dei token

Il toolkit Jalisco opera come intermediario tra la vittima e i servizi Microsoft, sfruttando un flusso OAuth nato per autenticare dispositivi con capacità di input limitate, come smart TV, terminali e appliance. Quando l’utente raggiunge la pagina malevola, il backend del toolkit richiede a Microsoft un nuovo codice dispositivo e lo incorpora in un’esca costruita per apparire come un documento, una richiesta aziendale o una procedura di accesso legittima. La vittima viene quindi indirizzata verso la pagina autentica Microsoft, dove inserisce il codice e completa normalmente l’autenticazione, compresa l’eventuale verifica MFA. Il problema è che il codice non autorizza il computer dell’utente, ma la sessione controllata dall’attaccante, che riceve dal servizio token i relativi access token e refresh token. Non avviene quindi un furto tradizionale della password e non è necessario clonare graficamente l’intera schermata di accesso: Microsoft stessa gestisce il login e la verifica multifattore, mentre Jalisco attende che l’utente completi volontariamente il flusso. Il modello segue l’evoluzione già osservata con Debull, capace di sottrarre account Microsoft 365 attraverso il device code senza chiedere password, ma aggiunge una piattaforma di gestione centralizzata delle sessioni compromesse. Attraverso un portale web, gli operatori possono controllare più account, rinnovare i token, interrogare i servizi disponibili e spostarsi rapidamente verso SharePoint, Outlook, Teams e altre applicazioni SaaS. Una volta dentro il tenant, gli aggressori possono inoltre registrare dispositivi sotto il proprio controllo o sfruttare i token persistenti per mantenere l’accesso anche dopo la chiusura della sessione originaria.

La lure-generation elimina il limite dei codici validi per quindici minuti

La caratteristica più importante di Jalisco è la lure-generation, progettata per superare uno dei principali limiti operativi del device code phishing. Nei kit precedenti il codice veniva generato insieme alla pagina o al documento malevolo e rimaneva valido per una finestra di circa 15 minuti. Se la vittima apriva il messaggio in ritardo, il codice risultava scaduto e l’attacco falliva, costringendo l’operatore a generare una nuova campagna o a inviare un’altra esca. Jalisco modifica questa sequenza: il codice non esiste quando il contenuto viene preparato, ma viene richiesto attraverso un’API backend soltanto nel momento in cui la vittima interagisce con la pagina.

Ogni visita produce quindi un codice fresco, legato a quella sessione e con l’intera finestra temporale ancora disponibile. Il controllo TTL non viene tecnicamente vulnerato, ma perde gran parte della sua utilità difensiva perché il conto alla rovescia inizia soltanto dopo il coinvolgimento della vittima. Il meccanismo consente di distribuire PDF, link o messaggi che rimangono operativi per giorni e di adattare automaticamente il lure al dominio o al marchio bersaglio. Questa evoluzione rende più affidabili le campagne e riduce la necessità di supervisione manuale. Microsoft aveva già reagito a questa classe di attacchi introducendo controlli contro il device code flow abusato nelle campagne di phishing Microsoft 365, ma i toolkit continuano a cercare modi per utilizzare flussi legittimi in contesti fraudolenti. La difficoltà principale risiede nel fatto che l’utente vede domini, certificati e interfacce Microsoft reali: l’elemento malevolo non è la pagina di autenticazione, ma l’identità della sessione che riceverà l’autorizzazione.

EvilTokens e i kit PhaaS usano l’AI per replicare qualsiasi organizzazione

Jalisco si inserisce in un ecosistema di Phishing-as-a-Service sempre più automatizzato, nel quale l’intelligenza artificiale riduce il tempo necessario per preparare domini, contenuti, pagine e messaggi personalizzati. Toolkit come EvilTokens possono partire dall’URL di un’organizzazione e riprodurne automaticamente loghi, colori, testi, layout e immagini, generando un sito difficilmente distinguibile dall’originale. Altri servizi come Tycoon2FA, Venom, Kali365 e Darcula forniscono pannelli amministrativi, hosting, gestione delle vittime, intercettazione delle sessioni e aggiornamenti continui per contrastare i rilevamenti. L’AI permette inoltre di correggere la grammatica, adattare il linguaggio al ruolo professionale del destinatario e creare documenti coerenti con il settore dell’impresa colpita. L’effetto è un abbassamento radicale della barriera d’ingresso: operatori con competenze tecniche limitate possono acquistare un abbonamento, scegliere il brand e avviare una campagna completa. La diffusione di EvilTokens come PhaaS specializzato negli attacchi contro Microsoft 365 mostra come il furto di token stia diventando un prodotto criminale standardizzato. L’infrastruttura viene spesso ospitata su piattaforme legittime come workers.dev ed edgeone.app, utilizzando sottodomini che combinano stringhe casuali con termini familiari come SharePoint, document, secure o il nome della vittima. Questi servizi sono normalmente utilizzati da sviluppatori e aziende, quindi il loro blocco indiscriminato produrrebbe conseguenze operative e falsi positivi. I controlli basati soltanto sulla reputazione del dominio o sulle firme statiche risultano perciò insufficienti contro pagine generate rapidamente e distribuite attraverso infrastrutture cloud affidabili.

Dopo il consenso gli attaccanti possono esfiltrare dati in sei minuti

L’impatto delle campagne non dipende soltanto dal numero crescente di messaggi, ma dalla velocità con cui gli operatori sfruttano i token catturati. In alcuni incidenti l’esfiltrazione è iniziata entro sei minuti dalla compromissione, lasciando ai team di sicurezza un margine estremamente ridotto per riconoscere l’anomalia e revocare l’accesso. Gli aggressori interrogano SharePoint, OneDrive, posta elettronica e altre applicazioni SaaS alla ricerca di dati personali, documenti finanziari, contratti e comunicazioni interne. Possono registrare più di cinque dispositivi controllati su un singolo account, rispetto alla presenza tipica di uno o due endpoint legittimi, costruendo percorsi alternativi di persistenza. I dati sottratti vengono quindi utilizzati per estorsioni, frodi, compromissioni di partner o nuove campagne di phishing condotte dall’account reale della vittima. Il possesso di un refresh token consente inoltre di ottenere nuovi access token senza ripetere continuamente il login, almeno fino alla revoca o all’applicazione di una policy che imponga una nuova autenticazione. La sola modifica della password può quindi non essere sufficiente, soprattutto quando sono stati registrati dispositivi, applicazioni o metodi di autenticazione aggiuntivi. Le organizzazioni devono monitorare creazioni anomale di device, consensi OAuth, richieste di device code, accessi improvvisi a grandi quantità di file ed esportazioni massicce. Il confronto con campagne come Kali365, progettato per rubare token Microsoft 365 senza conoscere le password, conferma che l’identità cloud è ormai il principale obiettivo: una volta ottenuta una sessione fidata, l’attaccante può operare all’interno delle API legittime senza distribuire malware sull’endpoint.

Passkey e Windows Hello impediscono di replicare la credenziale fuori dal sito legittimo

Microsoft Entra ID supporta diversi metodi passwordless progettati per resistere al phishing, tra cui passkey FIDO2, chiavi di sicurezza hardware, Windows Hello for Business, autenticazione basata su certificati e credenziali gestite tramite Microsoft Authenticator. Questi sistemi utilizzano crittografia asimmetrica: la chiave privata resta sul dispositivo o nel supporto hardware, mentre il servizio conserva soltanto la chiave pubblica. Durante l’accesso, la credenziale verifica anche l’origine del sito e non può essere riutilizzata su un dominio differente. Un attaccante che clona la pagina Microsoft non riceve quindi una password o un codice da inoltrare, mentre una chiave FIDO2 non firma una richiesta proveniente da un’origine non autorizzata. Windows Hello lega l’accesso al dispositivo e richiede biometria o PIN locale, impedendo che il segreto venga trasmesso attraverso la rete. I passkey sincronizzati tramite provider supportati migliorano la disponibilità su più dispositivi, mentre smart card e certificati restano adatti agli ambienti con requisiti hardware e normativi più rigidi. Questi metodi vengono considerati MFA perché combinano il possesso del dispositivo con biometria o conoscenza del PIN, senza introdurre OTP intercettabili. Tuttavia, il passwordless non blocca automaticamente ogni forma di device code phishing: la protezione deve essere applicata attraverso Authentication Strength e Conditional Access, imponendo credenziali phishing-resistant per le risorse sensibili e limitando o disabilitando i flussi non necessari. Senza una policy coerente, un utente può continuare ad autorizzare un’applicazione o una sessione malevola pur utilizzando un metodo forte per autenticarsi.

Il rollout passwordless richiede governance, licenze e coinvolgimento organizzativo

L’implementazione in Microsoft Entra ID non consiste nella semplice attivazione di un pulsante. Le organizzazioni devono censire applicazioni, dispositivi, categorie di utenti e scenari nei quali i metodi legacy restano ancora necessari. La registrazione e l’utilizzo di credenziali passwordless non richiedono sempre una licenza specifica, ma Microsoft Entra ID P1 consente di sfruttare funzionalità essenziali come Conditional Access, reporting e applicazione delle policy. I ruoli amministrativi devono essere separati secondo il principio del minimo privilegio: User Administrator per l’esperienza di registrazione combinata, Authentication Administrator per la gestione dei metodi e Authentication Policy Administrator per le policy globali. Il progetto deve coinvolgere Identity and Access Management, architettura di sicurezza, Security Operations, audit, help desk e comunicazione interna. Gli utenti devono ricevere procedure chiare per registrare passkey, chiavi hardware o Authenticator, insieme a metodi di recupero che non reintroducano fattori facilmente attaccabili. È inoltre necessario integrare le applicazioni con Entra ID, eliminare progressivamente protocolli legacy e definire gruppi pilota prima del rollout generale. Le policy dovrebbero richiedere autenticazione phishing-resistant per amministratori, finanza, personale con accesso a dati sensibili e operazioni ad alto rischio, per poi estendere la protezione all’intera organizzazione. Contestualmente vanno limitati i consensi OAuth, controllate le applicazioni enterprise, revocati i token sospetti e bloccata la registrazione incontrollata di dispositivi. Il vantaggio operativo accompagna quello di sicurezza: mentre un accesso con password può richiedere fino a 24 secondi, i passkey riducono mediamente il processo a circa 8 secondi, scendendo fino a 3 secondi nei flussi sincronizzati. Una maggiore semplicità favorisce l’adozione e riduce le richieste di reset, ma la vera efficacia dipende dalla capacità di sostituire realmente password, OTP e metodi deboli, non di affiancarli indefinitamente come alternative disponibili.