MFA Fatigue: Multi-Factor Authentication Request Generation (T1621)

Per simulare un attacco di MFA fatigue in laboratorio è necessario disporre di credenziali valide per un account protetto da push MFA. L'obiettivo dell'esercizio non è compromettere un utente reale, ma dimostrare al cliente quanto sia fragile un meccanismo di approvazione one-tap e quanto velocemente un attaccante possa automatizzare il bombardamento.

Il punto di partenza è un set di credenziali ottenute tramite phishing simulato o password spray. Con queste in mano, il red teamer deve automatizzare tentativi di login ripetuti verso il portale di autenticazione del target. Un approccio diretto è utilizzare EvilGinx2 (open source), il framework di adversary-in-the-middle phishing proxy che intercetta sessioni OAuth e può innescare il flusso MFA a ogni tentativo di autenticazione catturato. EvilGinx2 non genera direttamente push, ma ogni sessione che instrada verso l'identity provider reale scatena la notifica push sull'applicazione della vittima.

Per automatizzare i tentativi di login in modo più controllato, è possibile utilizzare script personalizzati con Selenium (open source) o Playwright (open source) che pilotano un browser headless verso la pagina di login dell'organizzazione target. Ogni iterazione del loop inserisce le credenziali note e arriva al punto in cui il provider genera la push notification. Un semplice ciclo Python con Playwright potrebbe iterare il processo ogni 30-60 secondi, simulando esattamente il comportamento documentato per Scattered Spider nella campagna C0027.

Per ambienti Microsoft 365, il tool Roadtx (open source) del progetto ROADtools permette di effettuare autenticazioni OAuth da riga di comando specificando il flusso interattivo. Eseguendo ripetutamente il flusso di device code o resource owner password credentials si innescano le push MFA su Entra ID.

Durante la simulazione è fondamentale documentare tre metriche: il numero di push inviate prima che l'utente accetti, il tempo trascorso tra la prima notifica e l'eventuale approvazione, e se il sistema impone un rate limit. Questi dati diventano l'evidenza per raccomandare al cliente il passaggio a number matching o a token hardware FIDO2.

Una variante avanzata prevede di combinare il bombardamento push con una telefonata di social engineering — tecnica che LAPSUS$ ha impiegato con successo — in cui l'attaccante si spaccia per l'help desk e chiede alla vittima di approvare la notifica "per risolvere un problema tecnico". In ambito red team questa fase va concordata esplicitamente nel Rules of Engagement.

Il cuore della detection per questa tecnica è il monitoraggio del volume e del pattern delle richieste MFA per singolo utente. Non serve cercare malware o payload: l'anomalia è puramente comportamentale e vive nei log dell'identity provider.

La fonte primaria per ambienti Microsoft è azure:signinlogs. Il campo chiave è ResultType combinato con AuthenticationRequirement e MfaDetail.AuthMethod. Un'analisi della detection strategy AN0449 suggerisce di configurare un alert su soglia temporale: più di 5 push MFA generate per lo stesso utente in una finestra di 10 minuti rappresenta un segnale forte, specialmente se le richieste provengono da IP che non compaiono nella baseline storica dell'utente. Il parametro di tuning GeoIPAllowList è essenziale per ridurre i falsi positivi su workforce distribuita o viaggiatori frequenti.

Per ambienti AWS, i log CloudTrail (AN0450) tracciano eventi di autenticazione federata. Qui il focus è su richieste MFA ripetute per la stessa sessione IAM, con particolare attenzione a mismatch tra la geolocalizzazione del login attempt e quella del dispositivo MFA registrato.

Su endpoint Windows, gli eventi 4625 (failed logon) seguiti da 4624 (successful logon) in rapida successione nel log WinEventLog:Security (AN0451) possono indicare che la push è stata infine accettata. Per i service account, il parametro ServiceAccountExclusion va configurato con attenzione per evitare che automazioni legittime generino alert continui.

In ambiente Linux (AN0452), i log auditd:AUTH e i messaggi PAM in syslog registrano i tentativi di autenticazione. Il parametro AuthRetryThreshold va tarato sull'uso normale: per utenti interattivi, più di 3 retry in 2 minuti merita investigazione.

Per piattaforme SaaS come Okta (AN0453), i log nativi espongono eventi di tipo system.push.send_factor_verify_push con esito denied o timeout. Un pattern di multipli denied seguiti da un singolo success è il segnale più nitido di MFA fatigue riuscita. Il tuning MFAProvider va configurato per normalizzare i campi in base al provider in uso.

Sul fronte preventivo, le mitigazioni M1032 e M1036 si traducono in azioni concrete: abilitare il number matching su Microsoft Authenticator o Okta Verify, imporre un rate limit sulle push (massimo 3 in 5 minuti prima del lockout temporaneo), e attivare conditional access policy che blocchino login da device non enrolled o da geolocalizzazioni anomale. La formazione utenti (M1017) completa il quadro: chi riceve push non richieste deve sapere che la risposta corretta è negare e segnalare, mai approvare.

L'analisi forense di un attacco MFA fatigue si gioca quasi interamente sui log dell'identity provider e, in seconda battuta, sugli artefatti endpoint che testimoniano la sessione risultante dall'approvazione fraudolenta.

Il primo artefatto da acquisire è il log di autenticazione centralizzato. Su Entra ID, il report Sign-in logs contiene ogni singola push generata con timestamp, IP sorgente, User Agent, device info del richiedente e stato della risposta MFA. L'analista deve filtrare per l'utente compromesso e ordinare cronologicamente: il pattern tipico mostra una raffica di eventi con Status = MFA denied o Status = MFA timeout distanziati di pochi secondi, seguiti da un singolo evento Status = Success. Quel timestamp di successo è il T0 della compromissione.

Su Okta, gli eventi equivalenti sono user.authentication.auth_via_mfa con outcome FAILURE ripetuto, seguiti da outcome SUCCESS. Il campo debugContext.debugData.requestUri può rivelare se il flusso era un login standard o un password reset via SSPR — distinzione importante per ricostruire l'intent dell'attaccante.

Dal T0 in poi, l'analisi si sposta sugli artefatti endpoint e cloud che documentano cosa l'avversario ha fatto con l'accesso ottenuto. Su Azure AD, i log di Audit mostrano eventuali modifiche a conditional access policy, registrazione di nuovi dispositivi MFA (persistence), o creazione di app OAuth malevole. Su AWS, CloudTrail registra l'assunzione di ruoli e le API call successive al login.

Lato endpoint Windows, se l'attaccante ha usato la sessione per accedere via VPN o RDP, gli artefatti classici diventano rilevanti: eventi 4624 con LogonType 10 (RemoteInteractive) nel Security log, chiavi di registro NTUSER.DAT\Software\Microsoft\Terminal Server Client\Servers per sessioni RDP, e artefatti del browser (cookie, cronologia) se l'accesso è avvenuto via web. Gli Unified Audit Log di Microsoft 365 completano il quadro per attività su SharePoint, Exchange Online o Teams post-compromissione.

Per la correlazione temporale, l'analista dovrebbe costruire una timeline che allinei tre flussi: le push MFA (dall'IdP), l'eventuale telefonata di social engineering (dai log telefonici se disponibili, tecnica usata da LAPSUS$ e Scattered Spider), e le prime azioni post-login. La campagna C0027 mostra che Scattered Spider, dopo il bypass MFA, procedeva rapidamente con SIM swapping e movimento laterale verso le reti dei carrier mobili — un pattern utile come reference per anticipare dove cercare i prossimi artefatti.

Il panorama degli attori che sfruttano MFA fatigue è ristretto ma significativo: tre gruppi con motivazioni e target molto diversi, uniti dall'aver riconosciuto nel fattore umano dell'MFA push il vero anello debole.

APT29 (noto anche come Cozy Bear) è il più sofisticato dei tre. Gruppo di matrice statale russa con focus su spionaggio, ha utilizzato richieste MFA ripetute come tecnica complementare all'interno di operazioni ben più ampie. Per APT29 il bombardamento push non è l'attacco principale, ma un passaggio tattico per convertire credenziali già acquisite in accesso effettivo. La presenza di questa tecnica nel loro arsenale segnala che anche attori nation-state con capacità avanzate ricorrono a metodi "low-tech" quando il rapporto costo-efficacia lo giustifica.

Scattered Spider rappresenta il polo opposto come profilo: giovani attori con motivazione finanziaria, estremamente abili nel social engineering. La campagna C0027 (giugno-dicembre 2022) documenta il loro modus operandi contro aziende di telecomunicazioni e BPO. L'MFA fatigue per loro è un tassello di una catena che include SIM swapping e tentativo di pivot verso le reti dei mobile carrier. Il pattern è chiaro: credenziali rubate via phishing, bombardamento push per superare l'MFA, poi lateral movement aggressivo con l'obiettivo finale di accedere alle infrastrutture dei carrier per ulteriore SIM swap su larga scala.

LAPSUS$ condivide con Scattered Spider il profilo demografico giovane e la motivazione mista (finanziaria e notorietà). Il loro approccio documentato prevedeva lo spam di prompt MFA accompagnato da tattiche di social engineering diretto — contattando la vittima e sollecitandola ad approvare. LAPSUS$ ha dimostrato che la combinazione di pressione tecnologica (push incessanti) e pressione sociale (telefonata o messaggio) moltiplica drasticamente la probabilità di successo.

Dal punto di vista dei trend, emergono alcuni pattern utili per la previsione. Il primo è la convergenza delle tattiche: tutti e tre i gruppi combinano MFA fatigue con social engineering, suggerendo che le organizzazioni che mitigano solo il vettore tecnico (rate limiting sulle push) senza formare gli utenti restano vulnerabili. Il secondo pattern è la migrazione verso target con MFA push one-tap: gli attori selezionano vittime che ancora non hanno implementato number matching o token FIDO2, rendendo la ricognizione sulla configurazione MFA del target un indicatore di targeting precoce. Infine, il passaggio da push MFA a phishing di token FIDO2 tramite proxy adversary-in-the-middle potrebbe rappresentare l'evoluzione naturale per gli attori più sofisticati come APT29, man mano che le organizzazioni adottano meccanismi MFA resistenti al fatigue.

Framework MITRE ATT&CK: tecnica T1621, tattica TA0006, campagna C0027, mitigazioni M1032, M1036, M1017, detection AN0449–AN0454. Gruppi: G0016 (APT29), G1015 (Scattered Spider), G1004 (LAPSUS$). Tool di detection: azure:signinlogs, AWS CloudTrail, WinEventLog Security, auditd, Okta system log, macOS Unified Log. Integrato con conoscenza professionale per tool e procedure operative.