Attacco AiTM e furto del token MFA

All'attaccante non serve costruire un falso sito: installa un server web che fa passare i pacchetti HTTP tra la vittima e il servizio preso di mira, nei due sensi¹. La pagina contiene due sessioni TLS distinte, una con la vittima e una con il sito vero, e questo gli permette di estrarre dalle richieste le password e, cosa più importante, i cookie di sessione¹.

Questo lavoro si può automatizzare con kit open source. Microsoft cita Evilginx2, Modlishka e Muraena¹. MITRE precisa che Evilginx2 può fungere da relay AiTM tra un sito legittimo e una persona colpita da phishing per catturare credenziali, token di autenticazione e cookie di sessione⁵. Ottenuto il cookie, l'attaccante lo inserisce nel proprio browser per saltare l'autenticazione, anche se l'MFA del bersaglio è attiva¹.

All'inizio c'è un messaggio. MITRE descrive l'e-mail con link malevolo, usata in particolare per evitare le difese che ispezionano gli allegati⁶. Nella campagna studiata da Microsoft, l'e-mail conteneva un allegato HTML e annunciava un messaggio vocale¹. La pagina mostrava una barra di download del messaggio, ma la barra era scritta direttamente nel file: nessun file audio veniva scaricato¹. La vittima veniva poi reindirizzata a una pagina che precompilava il suo indirizzo e-mail, rendendo la trappola più credibile¹.

Poi arriva la pagina di accesso, copia del portale Microsoft. Una volta inserite le credenziali e completata l'autenticazione, la vittima approdava sulla vera pagina office.com¹. Nulla segnala l'intercettazione: in secondo piano, l'attaccante aveva già intercettato le credenziali e aperto a sua volta una sessione¹.

Ecco un'illustrazione neutralizzata della forma di un indirizzo di questo tipo, per mostrare che solo l'indirizzo tradisce la trappola:

Illustrazione (indirizzo neutralizzato, inventato per l'esempio):
hxxps://login[.]exemple-portail[.]invalid/[identificativo della vittima]
Pagina mostrata: [copia del modulo di accesso Microsoft]
Indirizzo atteso: [l'indirizzo ufficiale del servizio, digitato o salvato da Lei]

Un servizio web apre una sessione dopo l'autenticazione, per non chiedere di nuovo l'identità a ogni pagina. Questa sessione si basa su un cookie fornito dal servizio di autenticazione, che prova al server che l'utente è connesso¹. MITRE osserva che questi cookie restano spesso validi a lungo, anche quando l'applicazione non è usata attivamente⁷. Un attaccante che ne possiede uno può importarlo in un browser che controlla e accedere all'applicazione².

Nella campagna del 2022 i cookie contenevano una dichiarazione MFA: l'attaccante li usava quindi per accedere all'account nonostante la politica MFA dell'organizzazione¹. MITRE cita anche un caso in cui APT29 ha usato cookie rubati per accedere a risorse cloud, e un cookie duo-sid contraffatto per aggirare l'MFA di un account di posta, durante la compromissione di SolarWinds².

Sul fronte della difesa, la CISA classifica le forme di MFA dalla più forte alla più debole. I codici monouso di un'app sono vulnerabili al phishing, come gli SMS e le chiamate vocali³. Le notifiche push con inserimento di un numero resistono al «push bombing» ma non al phishing³. Solo FIDO/WebAuthn è, secondo la CISA, l'autenticazione resistente al phishing ampiamente disponibile³. L'NCSC britannico dedica una guida ai metodi di MFA più solidi⁸. Microsoft raccomanda inoltre politiche di accesso condizionale, valutate a ogni tentativo di utilizzo di un cookie rubato (dispositivo conforme, indirizzo IP attendibile)¹.

Luglio 2022: una campagna rivolta a più di 10.000 organizzazioni

Il 12 luglio 2022 Microsoft pubblica l'analisi di una campagna di phishing AiTM su larga scala. Ha rubato password, dirottato sessioni e aggirato l'autenticazione anche con l'MFA attiva. Secondo i dati di Microsoft, ha tentato di colpire più di 10.000 organizzazioni da settembre 2021¹. Gli attaccanti imitavano la pagina di autenticazione online di Office, con il kit Evilginx2¹.

Dopo il furto: la frode dei bonifici

Gli attaccanti usavano poi le credenziali e i cookie rubati per accedere alle caselle di posta e avviare frodi dei bonifici (BEC) contro altri bersagli¹. Microsoft ha osservato che potevano bastare cinque minuti tra il furto e l'inizio della frode¹. Nei giorni successivi l'attaccante consultava ogni poche ore le e-mail e gli allegati finanziari, cercava scambi in corso, poi cancellava l'e-mail di phishing iniziale¹.

Creava quindi una regola della posta in arrivo che spostava in «Archivio», contrassegnati come letti, i messaggi provenienti dal dominio del bersaglio della frode, perché il titolare non vedesse nulla¹. Infine rispondeva ai thread su pagamenti e fatture, poi eliminava le proprie risposte dagli elementi inviati¹. Una volta ha condotto più tentativi in parallelo dalla stessa casella¹.