Kali365: il nuovo phishing che aggira il 2FA su Microsoft 365

A differenza del phishing classico che ruba username e password, la nuova minaccia segnalata dall'FBI il 21 maggio 2026 punta direttamente ai token di autenticazione OAuth di Microsoft 365. Il risultato? L'autenticazione a due fattori (2FA), considerata finora la difesa principe per gli account aziendali, viene semplicemente aggirata: l'utente è convinto di eseguire una verifica di sicurezza legittima, ma in realtà sta consegnando le chiavi del proprio ambiente cloud a un criminale. Il vettore si chiama Kali365, una piattaforma di Phishing-as-a-Service (PhaaS) distribuita principalmente via Telegram, che rende questo tipo di attacco accessibile anche a criminali informatici con competenze tecniche minime. Per le PMI italiane, che in larghissima maggioranza utilizzano Microsoft 365 come piattaforma cloud aziendale, la minaccia è concreta e richiede contromisure immediate.

Cos'è Kali365 e perché l'FBI ha lanciato l'allarme

Kali365 è una piattaforma di Phishing-as-a-Service comparsa per la prima volta nell'aprile 2026 e segnalata ufficialmente dall'FBI il 21 maggio 2026 tramite un Public Service Announcement dell'Internet Crime Complaint Center (IC3). Il kit viene distribuito prevalentemente attraverso canali Telegram e rappresenta un salto di qualità nel panorama del cybercrime: non si limita a rubare credenziali, ma intercetta i token OAuth — i "biglietti digitali" che Microsoft 365 utilizza per concedere l'accesso alle applicazioni cloud dopo l'autenticazione.

Il dato più allarmante è che Kali365 abbassa drasticamente la barriera d'ingresso per questo tipo di attacchi. Come riportato dall'advisory FBI, la piattaforma mette a disposizione dei suoi "clienti" — criminali che pagano un abbonamento — funzionalità come lure di phishing generate tramite intelligenza artificiale, template di campagne automatizzate, dashboard di tracciamento in tempo reale delle vittime e sistemi di cattura dei token OAuth [ic3.gov]. In pratica, anche un attaccante senza alcuna competenza di programmazione può lanciare una campagna sofisticata in pochi minuti.

La novità non riguarda tanto il meccanismo tecnico — il cosiddetto "device code phishing" è noto da tempo agli analisti di sicurezza — quanto la sua industrializzazione attraverso un modello "as-a-service", con automazione e AI che ne amplificano portata ed efficacia, come sottolineato anche dal CERT-AGID in un'analisi dedicata [cert-agid.gov.it]. A conferma della portata del fenomeno, società di incident response come Arctic Wolf hanno documentato centinaia di attacchi veicolati da Kali365 già nel mese di aprile 2026 [therecord.media].

Come funziona l'attacco: il device code phishing spiegato

Per comprendere la pericolosità di Kali365 bisogna prima capire il meccanismo del device code flow (o flusso tramite codice dispositivo). Si tratta di una modalità di autenticazione legittima, parte del protocollo OAuth 2.0 e supportata da Microsoft Identity Platform (Entra ID). È stata progettata per dispositivi con interfacce limitate — smart TV, stampanti, dispositivi IoT — dove inserire username e password risulta scomodo o impossibile. Il funzionamento standard prevede che il dispositivo mostri un breve codice alfanumerico e che l'utente lo inserisca, da un browser già autenticato, sulla pagina ufficiale microsoft.com/devicelogin per autorizzare l'accesso.

Il device code phishing capovolge completamente questo modello. Ecco la catena dell'attacco passo dopo passo:

1. Esca (lure): la vittima riceve un'email di phishing che imita servizi cloud legittimi — SharePoint, OneDrive, Teams — con la scusa di visualizzare un documento urgente, firmare un contratto o completare una verifica di sicurezza. Grazie all'AI integrata in Kali365, queste email sono sempre più credibili, prive di errori e adattate al contesto lavorativo del destinatario [ilsoftware.it].
2. Generazione del codice: quando la vittima clicca sul link, atterra su una pagina controllata dall'attaccante che, in background, avvia un flusso di device code verso il vero endpoint di autenticazione Microsoft. La pagina mostra il codice generato e, in alcuni casi, lo copia automaticamente nella clipboard del computer per ridurre l'attrito [cert-agid.gov.it].
3. Autorizzazione inconsapevole: la vittima clicca su un pulsante "Continua su Microsoft" e viene reindirizzata alla pagina di login Microsoft autentica (aka.ms/devicelogin o microsoft.com/devicelogin). Qui inserisce il codice — convinta di completare una verifica di sicurezza — e autorizza l'accesso. Se la vittima ha già una sessione attiva su Microsoft Entra ID, non le verranno nemmeno chieste le credenziali né il secondo fattore MFA [csirt.regione.toscana.it].
4. Furto del token: nel momento in cui la vittima completa l'autenticazione, il server dell'attaccante riceve i token OAuth — sia il token di accesso sia il refresh token. La vittima, nel frattempo, viene reindirizzata a una pagina fittizia che conclude la falsa procedura.
5. Persistenza: l'attaccante ora ha accesso all'ambiente Microsoft 365 della vittima — email, SharePoint, Teams, OneDrive — e può generare nuovi token di accesso anche dopo che la password è stata cambiata, grazie al refresh token. Arctic Wolf ha documentato casi in cui gli attaccanti hanno creato regole di posta in arrivo malevole per sopprimere le notifiche di sicurezza, estendendo il tempo di permanenza senza essere rilevati [therecord.media].

Il ruolo dell'AI nell'amplificare l'attacco

L'elemento che differenzia Kali365 dalle precedenti campagne di device code phishing è l'uso sistematico dell'intelligenza artificiale. Come evidenziato dal CERT-AGID, i modelli linguistici vengono impiegati per generare comunicazioni coerenti con lo stile aziendale della vittima, includendo riferimenti a strumenti reali e contestualizzando il messaggio in base al ruolo e al settore del destinatario [cert-agid.gov.it]. La piattaforma offre lure brandizzate che imitano servizi noti come Adobe, DocuSign e SharePoint, disponibili in decine di lingue e template grafici [therecord.media]. Questo supera uno dei principali campanelli d'allarme del phishing tradizionale — gli errori grammaticali e le incongruenze — e rende molto più difficile per l'utente distinguere una comunicazione autentica da una fraudolenta.

Perché il 2FA non basta più: il vero bersaglio sono i token

C'è un equivoco diffuso che Kali365 smaschera in modo impietoso: l'idea che l'autenticazione a due fattori (2FA/MFA) sia una protezione sufficiente contro il phishing. Nel device code phishing, l'evento MFA è reale e legittimo. Microsoft verifica effettivamente le credenziali e il secondo fattore: è la vittima stessa, in carne e ossa, a completare l'autenticazione. Il problema è che la vittima sta autenticando non la propria sessione, ma quella dell'attaccante [etcsec.com].

Diversamente dal phishing tradizionale — che ruba credenziali e viene contrastato efficacemente dal 2FA (approfondisci nella nostra guida completa al 2FA) — questo attacco si colloca a un livello diverso della catena di autenticazione: non intercetta le credenziali, ma i token che vengono emessi dopo che l'autenticazione è stata completata con successo. È la differenza tra rubare la chiave di casa e farsi aprire la porta dal proprietario.

La gravità della compromissione è amplificata da tre fattori:

• Persistenza: il refresh token consente all'attaccante di generare nuovi token di accesso senza dover rieseguire l'autenticazione. Cambiare la password dell'account compromesso non revoca automaticamente i token OAuth già emessi. Come rilevato dall'analisi di AtWorkStudio sul Bollettino CSIRT BL01/260407, lo scope offline_access incluso nel token permette di rinnovare l'accesso indefinitamente finché il grant non viene revocato manualmente dal tenant [atworkstudio.it].
• Invisibilità: l'accesso avviene tramite un'applicazione autorizzata, non tramite login sospetti. Nei log di accesso di Microsoft Entra ID, l'evento appare come una normale autenticazione completata con successo.
• Movimento laterale: se l'account compromesso dispone di privilegi amministrativi, l'attaccante può potenzialmente compromettere l'intero tenant aziendale, con accesso a raccolte di contatti, phishing laterale verso colleghi e monitoraggio di parole chiave per frodi di tipo Business Email Compromise (BEC) [csirt.regione.toscana.it].

Perché le PMI italiane sono un bersaglio privilegiato

Il profilo delle PMI italiane le rende particolarmente vulnerabili a Kali365 per una combinazione di fattori strutturali e congiunturali. Innanzitutto, la quasi totalità delle piccole e medie imprese italiane utilizza Microsoft 365 come piattaforma cloud per email, documenti e collaborazione. Questo crea un bacino di vittime omogeneo che consente agli attaccanti di massimizzare il ritorno sull'investimento di una singola campagna.

In secondo luogo, la configurazione predefinita di Microsoft 365 non blocca il device code flow: è l'amministratore del tenant che deve intervenire attivamente per limitarlo o disabilitarlo. Molte PMI non dispongono di personale IT dedicato alla sicurezza o, se ne dispongono, non hanno ancora preso in considerazione questa specifica superficie d'attacco. Come riportato nell'analisi del CERT-AGID, la campagna ha già avuto un impatto documentato sulla Pubblica Amministrazione italiana, segno che gli attaccanti stanno prendendo di mira attivamente il nostro Paese [cert-agid.gov.it].

Infine, il modello PhaaS di Kali365 rende l'attacco economicamente accessibile: invece di sviluppare un'infrastruttura di phishing da zero, un criminale può "noleggiare" la piattaforma a costi contenuti. Questo abbassa il livello di competenza tecnica necessario e moltiplica il numero di potenziali attaccanti, in un ecosistema — quello del cybercrime — che continua a professionalizzarsi e a distribuire capacità offensive a soggetti sempre meno qualificati [infosecurity-magazine.com].

Le 5 contromisure immediate per mettere in sicurezza il tenant Microsoft 365

La buona notizia è che il device code phishing si può contrastare con interventi mirati, molti dei quali sono configurabili direttamente dal pannello di amministrazione di Microsoft 365. Ecco le cinque contromisure prioritarie, ordinate per urgenza e impatto.

1. Bloccare (o limitare) il device code flow con Conditional Access

L'intervento più efficace è anche il più diretto: Microsoft Entra ID offre una condizione specifica nelle Conditional Access policy chiamata "Authentication Flows" che consente di bloccare selettivamente il device code flow. L'FBI stessa raccomanda di creare una policy di Conditional Access per bloccare il device code flow per tutti gli utenti, con eccezioni limitate ai soli processi aziendali che lo richiedono [ic3.gov]. L'Agenzia per la Cybersicurezza Nazionale, tramite il CSIRT Italia, ha ribadito la stessa raccomandazione nel Bollettino BL01/260407 del 7 aprile 2026 [atworkstudio.it].

Procedura sintetica:

1. Accedere al portale di Azure/Entra ID → Protezione → Conditional Access
2. Creare una nuova policy
3. In "Condizioni" → "Authentication Flows", selezionare "Device Code Flow" e impostare il blocco
4. Applicare a tutti gli utenti (con eventuali eccezioni documentate)
5. Attivare la policy in modalità report-only per una settimana prima di forzarla, così da identificare eventuali usi legittimi

Attenzione: se l'organizzazione utilizza il device code flow per la registrazione dei dispositivi (Device Registration Service), è necessario escludere quello specifico servizio dal blocco per evitare malfunzionamenti [etcsec.com]. L'FBI raccomanda inoltre di escludere gli account di emergenza (break-glass) per prevenire lockout amministrativi [ic3.gov].

2. Audit completo dei token OAuth e delle applicazioni autorizzate

Molte organizzazioni non hanno visibilità su quante e quali applicazioni OAuth siano state autorizzate dagli utenti nel proprio tenant. Kali365 sfrutta proprio questa mancanza di controllo. È fondamentale eseguire un audit immediato:

• Nel portale Entra ID, sezione "Applicazioni aziendali" → "Autorizzazioni e consenso", verificare tutte le applicazioni con permessi concessi
• Revocare immediatamente qualsiasi applicazione non riconosciuta o non necessaria
• Abilitare l'Admin Consent (consenso amministratore) disabilitando lo User Consent, per impedire che i singoli utenti possano autorizzare applicazioni senza l'approvazione esplicita di un amministratore [csirt.regione.toscana.it]

3. Monitoraggio proattivo delle attività anomale

Anche dopo aver bloccato il device code flow, è essenziale attivare un monitoraggio continuo per individuare eventuali compromissioni già in corso. I segnali da tenere sotto osservazione nei log di accesso di Microsoft Entra ID includono:

• Accessi da località geografiche insolite subito dopo una procedura di device login
• Creazione anomala di nuove applicazioni OAuth
• Incremento improvviso delle richieste API verso Microsoft Graph
• Presenza di sessioni attive da dispositivi o indirizzi IP non riconosciuti

Per le PMI con risorse IT limitate, Microsoft offre strumenti integrati come Microsoft Defender for Cloud Apps che automatizzano parte di questo monitoraggio con alert configurabili [ilsoftware.it]. Il Purview Unified Audit Log di Microsoft 365, disponibile anche nel piano base con retention di 90 giorni, registra tutti gli eventi rilevanti legati ai consensi OAuth. Per un rilevamento tempestivo, è consigliabile abbinare una regola di alerting — anche tramite Microsoft Sentinel o notifiche automatiche sugli eventi critici — per ridurre il tempo medio di rilevamento da settimane a ore [atworkstudio.it].

4. Revoca immediata dei token in caso di sospetta compromissione

Se si sospetta che un account sia stato compromesso tramite device code phishing, il cambio della password non è sufficiente. È necessario revocare esplicitamente tutti i token OAuth associati all'account. La procedura può essere eseguita tramite:

• PowerShell: comando Revoke-AzureADUserAllRefreshToken per revocare tutti i refresh token di un utente specifico
• Portale Entra ID: dalla sezione "Utenti", selezionare l'account compromesso e utilizzare l'opzione "Revoca sessioni"
• Microsoft 365 Admin Center: forzare la disconnessione da tutte le sessioni attive

L'FBI raccomanda inoltre di segnalare l'incidente all'Internet Crime Complaint Center (IC3) su www.ic3.gov, includendo tutte le informazioni disponibili: email di phishing ricevute (header e corpo), IP e orari degli accessi sospetti, dispositivi non autorizzati aggiunti all'account [ic3.gov].

5. Formazione anti-phishing specifica sul device code phishing

Le simulazioni di phishing tradizionali non preparano gli utenti a riconoscere un attacco di tipo device code. È necessario aggiornare i programmi di formazione e awareness con scenari specifici che includano:

• Il principio fondamentale: mai inserire un codice di autorizzazione su richiesta di terzi, a meno che non si stia configurando personalmente un dispositivo noto (smart TV, stampante, IoT)
• Riconoscere le email che chiedono di "verificare l'account" fornendo codici o visitando pagine di device login
• La consapevolezza che Microsoft non chiede mai di inserire codici dispositivo per visualizzare documenti o completare verifiche di sicurezza via email

Il CSIRT della Regione Toscana, nella propria advisory, pone l'accento proprio sulla formazione come prima linea di difesa: l'utente deve sapere che l'inserimento di un codice dispositivo è un'operazione che autorizza un accesso permanente, non una procedura di verifica temporanea [csirt.regione.toscana.it].

Bloccare il device code flow: quando conviene e quando no

La decisione di bloccare completamente il device code flow nel proprio tenant Microsoft 365 non è priva di trade-off. Ecco un confronto pragmatico per aiutare le PMI a prendere una decisione informata.

Quando conviene bloccare totalmente

• PMI sotto i 50 dipendenti senza dispositivi IoT aziendali: in questo scenario, il device code flow non ha quasi mai un uso legittimo. Il blocco totale è la scelta più sicura e non impatta le operazioni quotidiane.
• Organizzazioni che hanno già subito tentativi di phishing: se l'azienda è stata bersaglio di campagne di phishing, bloccare il device code flow riduce immediatamente la superficie d'attacco.
• Settori regolamentati (sanità, finanza, PA): dove i requisiti di compliance rendono inaccettabile qualsiasi rischio di accesso non autorizzato.

Quando è preferibile limitare anziché bloccare

• Aziende con dispositivi IoT o stampanti di rete integrate con Entra ID: in questi casi, limitare il flusso ai soli dispositivi gestiti tramite piattaforme MDM (Mobile Device Management) o a specifici range IP aziendali.
• Team di sviluppo che utilizzano Azure CLI o strumenti da riga di comando: alcune automazioni legittime si appoggiano al device code flow. In questo scenario, è possibile creare policy di Conditional Access che consentano il flusso solo per specifici gruppi di utenti tecnici.
• Organizzazioni con processi di registrazione dispositivi consolidati: prima di bloccare, verificare sempre le dipendenze dal Device Registration Service [etcsec.com].

Alternative e approcci complementari

Il blocco del device code flow non è l'unica strategia di difesa e, per alcune organizzazioni, potrebbe non essere sufficiente. Approcci complementari includono:

• Conditional Access basato sul rischio: invece di un blocco secco, usare policy che valutano il livello di rischio dell'accesso (Microsoft Entra ID Protection) e richiedono step aggiuntivi solo quando il rischio è elevato. Richiede licenza Entra ID Premium P2.
• Soluzioni di terze parti per il monitoraggio OAuth: strumenti come SaaS Security Posture Management (SSPM) offrono visibilità granulare sui permessi OAuth e alert in tempo reale.
• Token Lifetime Policy: ridurre la durata degli access token a 1 ora (anziché il default di 60-90 minuti rinnovabili senza limite) restringe la finestra di accesso post-compromissione, costringendo l'attaccante a ri-autenticarsi più frequentemente [atworkstudio.it].
• Zero Trust Network Access (ZTNA): un approccio più radicale che verifica ogni richiesta di accesso indipendentemente dalla provenienza, riducendo la dipendenza dal singolo token come prova di autenticazione.

La scelta tra queste opzioni dipende da tre fattori chiave: maturità dell'infrastruttura IT (un'azienda senza personale dedicato alla sicurezza farà fatica a gestire policy complesse), tolleranza al rischio (un'azienda che gestisce dati sanitari ha esigenze diverse da un'azienda manifatturiera) e budget (le soluzioni di terze parti e ZTNA hanno costi significativi rispetto alle policy native di Microsoft).

Oltre il fai-da-te: come Neomedia supporta le PMI nella sicurezza della rete e degli endpoint

Per molte PMI italiane, il principale ostacolo alla protezione dagli attacchi come Kali365 non è la mancanza di strumenti, ma la mancanza di competenze interne per configurarli e monitorarli correttamente. La cybersecurity per le PMI italiane richiede un approccio che bilanci efficacia e sostenibilità operativa.

Neomedia, in quanto Internet Service Provider con competenze verticali sulla sicurezza delle reti e dei servizi cloud, mette a disposizione delle PMI un ecosistema di soluzioni integrate: Next-Generation Firewall (NGF) per il controllo avanzato del traffico di rete e il blocco di domini malevoli, Endpoint Detection and Response (EDR) per il monitoraggio continuo dei dispositivi aziendali e la rilevazione di comportamenti anomali, e programmi di Security Awareness per formare i collaboratori a riconoscere le minacce — incluso il device code phishing descritto in questo articolo. La combinazione di protezione perimetrale (NGF), difesa degli endpoint (EDR) e consapevolezza umana (Security Awareness) costituisce una strategia a più livelli che riduce significativamente la superficie d'attacco sfruttata da piattaforme come Kali365.

Per chi desidera approfondire il tema generale del phishing e delle contromisure disponibili, è disponibile anche la guida completa al phishing 2026 pubblicata su Neomedia Learn.

Conclusioni: la sicurezza si sposta oltre le password

Kali365 segna un punto di svolta nel panorama delle minacce informatiche rivolte alle PMI. Non perché introduca una tecnica inedita — il device code phishing esiste da anni — ma perché la industrializza attraverso un modello PhaaS accessibile, la potenzia con l'intelligenza artificiale e la distribuisce su canali (Telegram) che sfuggono ai tradizionali controlli di sicurezza.

Il messaggio centrale per le PMI italiane è chiaro: l'autenticazione a due fattori, per quanto fondamentale, non è più una difesa sufficiente se non accompagnata da una gestione consapevole dei flussi di autenticazione e dei token OAuth. La sicurezza si gioca ora sul controllo di ciò che accade dopo il login, non solo sulla protezione delle credenziali.

Le cinque contromisure illustrate in questo articolo — bloccare il device code flow, fare audit dei token, monitorare le anomalie, saper revocare i token e formare gli utenti — rappresentano un piano d'azione immediato e realizzabile anche per organizzazioni con risorse IT limitate. La tempestività è cruciale: Kali365 è già attivo, e le campagne rivolte al contesto italiano sono state documentate dal CERT-AGID e dal CSIRT Toscana. Attendere potrebbe significare scoprire una compromissione quando il danno è già fatto.