AiTM: come gli attaccanti bypassano la MFA nel 2026 e come difendersi
Il 4 marzo 2026, Europol ha coordinato lo smantellamento di Tycoon 2FA, la piattaforma di phishing-as-a-service che Microsoft ha definito la piattaforma più prolifera da essa osservata nel 2025. A metà 2025, Tycoon 2FA era responsabile di circa il 62% di tutte le email di phishing bloccate da Microsoft, con oltre 30 milioni di messaggi intercettati in un singolo mese. L’operazione aveva colpito 96.000 vittime accertate, di cui oltre 55.000 clienti Microsoft. Già due settimane prima del takedown, il 19 febbraio 2026, Abnormal AI aveva documentato un nuovo kit chiamato Starkiller, dimostrando che la tecnica è ormai commoditizzata e indipendente da qualsiasi singola piattaforma.
Il messaggio è inequivocabile: la MFA tradizionale basata su TOTP, push notification e SMS è superata come difesa contro attaccanti motivati. Non perché la MFA sia inutile: è perché gli attaccanti hanno risolto il problema in modo elegante, senza nemmeno doverla rompere.
Cos’è un attacco AiTM e perché supera la MFA
Il phishing tradizionale clona una pagina di login e cattura credenziali. Un attacco Adversary-in-the-Middle (AiTM) non clona nulla: fa da proxy alla pagina reale. Il flusso è il seguente:
La vittima sta interagendo con il servizio legittimo. La pagina che vede è quella autentica, perché è il proxy a servirla in tempo reale. L’autenticazione va a buon fine: l’utente inserisce la password, fornisce il codice TOTP dall’app, Microsoft o Google inviano il session token al browser. Il proxy lo intercetta prima che raggiunga il browser legittimo.
Questo è il motivo per cui la MFA tradizionale non ferma l’attacco: l’utente si sta autenticando correttamente. Non c’è nessun errore da rilevare. Il proxy copia il risultato. Come spiegato da Cloudflare nel suo briefing sul takedown di Tycoon 2FA, la piattaforma trasmetteva in tempo reale i prompt di autenticazione per catturare session token e cookie attivi.
Il mercato delle piattaforme AiTM: Tycoon 2FA, EvilProxy e il fenomeno PhaaS
La differenza tra il 2022 e il 2026 non è tecnica: è economica. Secondo la ricerca Sekoia.io pubblicata a giugno 2025, basata su dati raccolti tra gennaio e aprile 2025, 11 kit PhaaS di rilievo circolano con capacità AiTM. Non si tratta di strumenti per nation-state actor: sono abbonamenti mensili da poche centinaia di euro, con dashboard, template e documentazione.
Tycoon 2FA è apparso nell’agosto 2023 targettando Microsoft 365 e Gmail. Il suo punto di forza era la sofisticazione evasiva: CAPTCHA per filtrare i bot, verifica dello user-agent per escludere i crawler delle aziende di sicurezza, obfuscation del JavaScript, e un sistema di precision-validated phishing che valida se l’utente è un target prima di mostrare la pagina di phishing. Proofpoint ha rilevato campagne che hanno targettato migliaia di organizzazioni in tutto il mondo nell’aprile 2025.
EvilProxy ha introdotto tecniche di fingerprinting del browser per aggirare i sistemi di rilevamento e supporta la registrazione di nuovi metodi di autenticazione post-compromissione: dopo aver rubato il session token, un attaccante può accedere al portale di sicurezza dell’utente e registrare una propria chiave FIDO2, ottenendo accesso persistente anche dopo la scadenza del token rubato.
Starkiller, documentato da Abnormal AI il 19 febbraio 2026 circa due settimane prima del takedown di Tycoon 2FA, usa headless Chrome all’interno di un container Docker per le richieste, rendendo inefficace il browser fingerprinting. Come analizzato da Dev.to e KrebsOnSecurity, l’operazione è gestita da un threat group che si chiama Jinkusu e offre il kit come subscription service con dashboard UI. La presenza di Starkiller già prima del takedown di Tycoon 2FA dimostra che l’ecosistema si rigenera indipendentemente dagli interventi delle forze dell’ordine.
Il dato più allarmante non è il volume degli attacchi: è il loro tasso di successo. Secondo il 2025 SaaS Security Threat Report di Obsidian Security, la MFA non ha impedito l’attacco nell’84% degli incident response analizzati. Quattro account su cinque che sono stati violati erano teoricamente protetti.
Anatomia tecnica: come viene rubato il session token
Per comprendere perché certe difese funzionano e altre no, è necessario capire esattamente cosa intercetta il proxy AiTM e come lo usa.
Fase 1 — Delivery: La vittima riceve un’email di phishing con un link. Il link include un identificatore univoco che associa la sessione a un target specifico (precision-validated phishing). Se la vittima non corrisponde al profilo atteso, viene reindirizzata a una pagina legittima per evitare il rilevamento.
Fase 2 — Proxying: Il browser della vittima si connette al server proxy dell’attaccante. Il proxy recupera la pagina di login reale di Microsoft 365 o Google e la serve al browser della vittima. Per la vittima sembra la pagina originale perché lo è, con il branding dell’organizzazione incluso (Entra ID mostra il logo dell’azienda, che il proxy copia in tempo reale).
Fase 3 — Intercettazione credenziali e TOTP: La vittima inserisce username e password. Il proxy le cattura e le passa al servizio reale. Il servizio risponde richiedendo il secondo fattore. L’utente inserisce il codice TOTP dall’app: il proxy lo cattura e lo ritrasmette entro i 30 secondi di validità. L’autenticazione va a buon fine.
Fase 4 — Furto del session token: Il servizio legittimo genera un session cookie e lo invia al browser della vittima. Il proxy intercetta questo cookie prima che raggiunga il browser. Da questo momento, l’attaccante ha un token di sessione valido che può usare da qualsiasi dispositivo senza dover ripetere l’autenticazione.
Fase 5 — Persistenza (opzionale): L’attaccante con il token attivo accede al portale di gestione dell’identità e registra un proprio metodo di autenticazione, tipicamente una chiave FIDO2 sotto il proprio controllo o un numero di telefono alternativo. Anche dopo la scadenza del token rubato, mantiene l’accesso.
Come evidenziato anche nell’approfondimento di ICT Security Magazine sulla sicurezza hardware e le architetture innovative per i sistemi critici, le chiavi FIDO2 usano secure enclave per proteggere le chiavi private che non lasciano mai il dispositivo. Il meccanismo di firma di un nonce ricevuto dal server impedisce strutturalmente gli attacchi adversary-in-the-middle. Il problema è che questo vale solo se FIDO2 è il metodo primario, non se viene aggiunto come secondo fattore dopo che l’account è già compromesso.
Perché il Conditional Access da solo non è sufficiente
Una risposta comune alla minaccia AiTM è: “Abbiamo il Conditional Access, siamo protetti”. La realtà è più sfumata, e ignorarla crea false certezze.
Secondo l’analisi di Jeffrey Appel nella sua guida aggiornata al 2025, senza configurazione specifica il Conditional Access non protegge di default dall’AiTM. I controlli che forniscono protezione sono:
La configurazione più solida in Microsoft Entra ID consiste nell’impostare, sotto Access controls, la policy “Require authentication strength: Phishing-resistant MFA strength”. Come documentato dalla guida ufficiale Microsoft, questo limita l’accesso esclusivamente a utenti che si autenticano con FIDO2 security key, Windows Hello for Business o certificate-based authentication: i tre metodi che per design sono immuni al credential phishing.
Il Token Protection di Microsoft Entra, disponibile dal 2024, crea un legame crittografico tra il token e il dispositivo che lo ha generato. Senza il secret del client, il token è inutilizzabile dall’attaccante anche se lo intercetta. Tuttavia, come segnalato nella stessa guida, il comportamento in ambienti complessi può essere variabile e richiede test approfonditi prima del deployment in produzione.
Perché solo FIDO2 e le passkeys fermano l’AiTM strutturalmente
Il motivo per cui FIDO2 e WebAuthn sono immuni agli attacchi AiTM non è configurativo: è crittografico. La difesa è integrata nel protocollo.
Durante la registrazione FIDO2, il dispositivo genera una coppia di chiavi specifica per un determinato origin, ovvero il dominio della Relying Party. Quando l’utente si autentica, il dispositivo firma la challenge usando la chiave privata legata a quell’origin specifico. Se il browser si trova su un dominio diverso da quello per cui la chiave è stata registrata, l’autenticazione fallisce.
Login legittimo:
L’attaccante non può rubare quello che non viene mai trasmesso. La chiave privata non esce mai dal dispositivo. Non c’è OTP da intercettare. Non c’è session token acquisibile tramite proxying perché l’autenticazione non avviene.
Come ribadito nell’analisi sull’autenticazione multifattoriale nell’era della cyber-vulnerabilità pubblicata su ICT Security Magazine, FIDO2, WebAuthn e le passkeys rappresentano l’implementazione concreta del paradigma passwordless che sostituisce il fattore più debole dell’autenticazione, la password condivisa, con chiavi crittografiche asimmetriche ancorate a dispositivi fisici.
Questa protezione strutturale vale indipendentemente dal livello tecnico dell’attaccante, dalla sofisticazione del kit PhaaS utilizzato e dalla velocità di intercettazione. Non è una difesa da configurare correttamente: è una proprietà matematica del protocollo.
La matrice di protezione: quale metodo di autenticazione ferma cosa
Roadmap di difesa: priorità operative per il CISO
Le priorità variano in base alla postura attuale dell’organizzazione, ma la sequenza logica è la stessa per quasi tutti i contesti enterprise italiani.
Priorità 1: abilitare il Token Protection in Microsoft Entra (dove applicabile)
Per le organizzazioni con Entra ID, il Token Protection crea una mitigazione immediata parziale senza richiedere la migrazione dei metodi di autenticazione. Va configurato in Conditional Access come ulteriore control e testato su un gruppo pilota prima del deployment. Non è la soluzione definitiva, ma riduce la finestra di utilizzo dei token rubati.
Priorità 2: applicare l’authentication strength “Phishing-resistant” agli account privilegiati
Prima ancora di migrare tutti gli utenti, applicare la policy di Conditional Access che richiede FIDO2 o Windows Hello for Business agli amministratori, agli account con accesso a dati sensibili e ai ruoli finance. Questi account sono il target primario delle campagne AiTM. Come da raccomandazione Microsoft, fare provisioning dei metodi phishing-resistant prima di abilitare la policy per evitare lockout.
Priorità 3: rivedere il processo di reset delle credenziali MFA
Il vettore più sottovalutato non è l’AiTM diretto: è il social engineering al team di helpdesk per resettare i metodi di autenticazione. Un attaccante con accesso temporaneo all’account può registrare metodi propri. I processi di reset devono richiedere verifica dell’identità fuori banda, con callback video o conferma del manager, mai solo su richiesta telefonica. Verificare sempre se nuovi metodi di autenticazione sono stati registrati nell’account compromesso entro la finestra di incidente.
Priorità 4: ridurre la durata dei session token e abilitare la revoca centralizzata
Token con durata di 24 ore danno agli attaccanti 24 ore di accesso per ogni token rubato. Politiche di token lifetime aggressive, combinate con la capacità di revocare tutte le sessioni attive tramite portale o integrazione SIEM, limitano significativamente il danno post-compromissione.
Priorità 5: deployment progressivo di passkeys o FIDO2 per il workforce standard
Seguire la roadmap di migrazione descritta nell’articolo sulle passkeys in azienda: pilota sul team IT, enrollment flow contestuale, rollout per coorti, disabilitazione delle password per gli utenti migrati. L’obiettivo non è la migrazione totale immediata: è ridurre la popolazione di account vulnerabili agli AiTM ogni settimana.
Priorità 6: implementare DMARC, DKIM, SPF e monitoraggio dei domain lookalike
La fase di delivery dell’attacco AiTM richiede che la vittima clicchi su un link in un’email. Le policy di autenticazione email (DMARC con policy reject, DKIM, SPF) riducono la percentuale di email di phishing che arrivano nelle caselle. Il monitoraggio di nuovi domini registrati che imitano il dominio aziendale con varianti lookalike permette di revocare o bloccare proattivamente le infrastrutture AiTM prima che vengano usate nelle campagne.
Il contesto normativo: NIS2, NIST SP 800-63-4 e le implicazioni per l’Italia
Il 2025 ha segnato un cambio regolatorio importante. Il NIST SP 800-63-4, finalizzato il 31 luglio 2025, introduce per la prima volta un requisito obbligatorio: le organizzazioni che richiedono l’AAL2 (Authenticator Assurance Level 2) devono offrire almeno un’opzione di autenticazione phishing-resistant. Non “should” o “may”: must. AAL3, il livello più alto, richiede autenticatori phishing-resistant con chiavi private non esportabili. Benché lo standard NIST sia tecnicamente rivolto al mercato statunitense, è il riferimento internazionale che orienta le scelte di tutti i vendor e i framework di compliance globali.
In Europa, il D.Lgs. 138/2024 che recepisce la NIS2 richiede misure tecniche proporzionate al rischio, inclusa l’autenticazione a più fattori o forme di autenticazione continua. In un contesto dove la MFA non ha impedito l’attacco nell’84% degli incident response analizzati da Obsidian Security, la “proporzionalità al rischio” per organizzazioni essenziali o importanti richiede di fatto l’adozione di MFA phishing-resistant, non solo di qualsiasi MFA. I prossimi audit ACN su soggetti NIS2 inizieranno a distinguere tra MFA generica e MFA effettivamente resistente al phishing.
Il takedown di Tycoon 2FA non cambia il problema strutturale
La dimensione del takedown coordinato da Europol il 4 marzo 2026, con la partecipazione di Microsoft, Cloudflare, Proofpoint, TrendAI, Intel 471, SpyCloud, Coinbase, Crowell, eSentire, Health-ISAC, Resecurity e la Shadowserver Foundation, è significativa come operazione di law enforcement. Il Microsoft Digital Crimes Unit ha documentato come oltre 18 mesi di intelligence abbiano permesso di identificare gli operatori e smantellare l’infrastruttura. La cooperazione pubblico-privato ha funzionato.
Ma come si legge nell’analisi post-takedown di Trend Micro: l’operazione ha aumentato il costo e il rischio per chi gestisce questi servizi. Non ha eliminato la tecnica. Starkiller era già operativo e documentato settimane prima del takedown. EvilProxy continua. Decine di kit con capacità AiTM sono disponibili sul mercato underground.
Il takedown di una piattaforma PhaaS non cambia il calcolo difensivo: ogni organizzazione che dipende da TOTP o push notification per proteggere account critici rimane vulnerabile a qualsiasi kit AiTM, attuale o futuro. La soluzione non è aspettare il prossimo takedown: è rendere la propria autenticazione strutturalmente immune all’intercettazione.
