Phishing adversary-in-the-middle: come EvilGinx sconfigge la MFA
L'autenticazione a più fattori doveva rendere inutili le password rubate. Il phishing adversary-in-the-middle (AiTM) — reso popolare da framework open source come EvilGinx — ha rotto in sordina quel presupposto rubando la sessione, non la password. Capire come funziona è il primo passo per difendersi.
Che cos'è il phishing adversary-in-the-middle
Il phishing classico mostra alla vittima un clone statico di una pagina di login e si limita a registrare ciò che digita. Non può gestire un codice usa e getta in tempo reale né superare una vera sfida MFA.
Il phishing AiTM elimina questo limite inserendo un reverse proxy tra la vittima e il sito autentico. Il server dell'aggressore non ospita affatto una pagina falsa: inoltra quella vera:
Vittima → login.micros0ft-verify.example (proxy dell'aggressore) → login.microsoftonline.com
Ogni richiesta della vittima viene inoltrata al servizio legittimo e ogni risposta rimandata indietro. La vittima vede il flusso di login autentico — branding vero, messaggi di errore veri, richieste MFA vere — perché di fatto sta parlando con il servizio reale, solo attraverso un relè che legge tutto in transito.
Perché sconfigge OTP e push
L'intuizione cruciale è che l'aggressore non cerca di conoscere la vostra password o il vostro codice. Cerca di catturare ciò che il login riuscito produce: il cookie di sessione autenticato.
- La vittima inserisce nome utente e password → inoltrati al sito reale.
- Il sito reale emette una sfida MFA → rimandata alla vittima.
- La vittima approva il push o digita l'OTP → inoltrato al sito reale.
- Il sito reale valida tutto e restituisce un token di sessione → il proxy lo cattura.
A quel punto l'OTP ha già svolto il suo compito ed è inutile riproporlo. L'aggressore importa il cookie rubato nel proprio browser ed è connesso come l'utente — nessuna password, nessun codice, nessuna seconda richiesta. Ecco perché codici SMS, app authenticator TOTP e approvazioni push cadono tutti davanti a un impianto AiTM competente: ciascuno è un segreto condiviso che l'essere umano può essere indotto a inoltrare in tempo reale.
La richiesta MFA che la vittima ha approvato era autentica. È proprio questo a rendere l'AiTM così efficace: nulla appare sbagliato all'utente, e nulla appare sbagliato al provider di identità.
Perché le difese esistenti faticano
- Il dominio è spesso nuovissimo. I domini simili appena registrati non hanno una storia di reputazione da segnalare.
- Il TLS sembra legittimo. Il proxy serve un certificato valido; il lucchetto c'è.
- Il contenuto è reale. La scansione basata su firme non trova nulla di falso da confrontare, perché la pagina è quella autentica, inoltrata.
- Le finestre di rilevamento sono brevi. I kit usano filtraggio anti-analisi, link monouso e geofencing, così una URL che era attiva per la vittima restituisce una pagina innocua a un SOC che indaga.
La vera soluzione: MFA resistente al phishing
L'AiTM funziona perché il secondo fattore passa attraverso l'aggressore. Togliete questa possibilità e l'attacco crolla. FIDO2 / WebAuthn e le passkey legano la credenziale crittograficamente all'esatta origine web per cui è stata registrata:
Credenziale registrata per : https://login.microsoftonline.com
Il browser vede l'origine : https://login.micros0ft-verify.example
→ discordanza di origine → l'authenticator rifiuta di firmare → il login fallisce
Non c'è codice da inoltrare né cookie da raccogliere, perché l'autenticazione non riesce mai contro l'origine sbagliata. Lo impone il browser — non l'utente. Controlli complementari irrobustiscono il resto:
- Accesso condizionale che lega le sessioni alla conformità del dispositivo e a reti gestite.
- Protezione dei token / valutazione continua dell'accesso per ridurre il valore di un cookie rubato.
- Rilevamento rapido dei domini simili appena registrati tramite monitoraggio della certificate transparency.
L'obiettivo è la MFA resistente al phishing come obbligatoria, non solo disponibile: qualsiasi ripiego phishabile è un percorso verso cui gli aggressori spingono gli utenti.
Come GottaPhish automatizza le simulazioni AiTM
Gli attacchi AiTM sconfiggono la MFA a OTP e push inoltrando la sessione in tempo reale, e nessun proxy o filtro da solo chiude quel divario in modo affidabile. GottaPhish e il suo team di esperti riproducono scenari adversary-in-the-middle in modo automatico e sicuro dentro simulazioni autorizzate: non c'è alcuna infrastruttura d'attacco che il vostro team debba allestire, ospitare o smantellare. Dimostriamo, con audit completo, come la MFA a OTP e push cade davanti a un proxy reale mentre le credenziali resistenti al phishing reggono, dandovi dati di esposizione misurabili per utente, reparto e ruolo; i nostri esperti vi aiutano a disegnare gli scenari, impostare le campagne e interpretare i risultati. Questa prova rende concreto il business case per FIDO2/passkey, e la nostra reportistica segue l'adozione insieme ai vostri tassi di clic e segnalazione, così potete dimostrare che il divario phishabile si sta davvero chiudendo — non solo che una policy esiste sulla carta.