MFA Fatigue in Entra ID: rilevamento e prevenzione

Che cos’è la MFA Fatigue?

La MFA fatigue, chiamata anche MFA bombing o push bombing, consiste nel generare richieste di multifactor authentication in modo ripetuto finché un utente non ne approva una. MITRE traccia questa tecnica come T1621, Multi-Factor Authentication Request Generation.

Il meccanismo è più ristretto di quanto molte organizzazioni descrivano. Nel caso più comune, l’attaccante possiede già la password della vittima ed è bloccato solo dal secondo fattore. Invece di fermarsi lì, genera in continuazione notifiche push verso Microsoft Authenticator, Duo, Okta Verify o un servizio MFA analogo, cercando di logorare l’utente.

L’ambito di questo articolo è Microsoft Entra ID e la MFA push con Microsoft Authenticator, con enfasi su rilevamento operativo e hardening del tenant. La MFA fatigue non è la stessa cosa di password spraying, phishing adversary-in-the-middle o SIM swapping, anche se queste tecniche vengono spesso usate prima o insieme.

Il rischio chiave è semplice: un controllo MFA basato su approvazioni push dipende ancora dal fatto che l’utente prenda la decisione giusta sotto pressione. Se l’attaccante può creare prompt ripetuti, o abbinarli a un pretesto di social engineering, un controllo che sembrava forte sulla carta può fallire nella pratica.

Come funziona la MFA Fatigue

La definizione MITRE è precisa: gli avversari possono tentare di aggirare la MFA generando richieste MFA inviate agli utenti. Se dispongono già di credenziali valide, possono restare bloccati soltanto perché non controllano il secondo fattore. Per superare questo ostacolo, abusano delle notifiche push sperando che l’utente ne approvi una.

Questo punto conta perché non si tratta di una rottura crittografica. È un abuso del design del workflow di autenticazione e del comportamento umano di approvazione.

Una sequenza tipica focalizzata su Entra assomiglia a questa:

l’attaccante ottiene un nome utente e una password validi tramite phishing, password spraying, credential stuffing o social engineering verso l’help desk
l’attaccante avvia un sign-in interattivo che richiede l’approvazione di Microsoft Authenticator
l’utente riceve notifiche push ripetute
l’attaccante continua a riprovare, spesso in momenti scelti per generare confusione o fastidio
se l’utente finisce per approvare un prompt, l’attaccante ottiene una sessione autenticata valida

MITRE segnala anche un secondo percorso che talvolta i difensori trascurano: se l’attaccante non possiede ancora le credenziali, la generazione automatica di push può essere abusata in alcuni scenari di self-service password reset quando quel workflow è configurato per inviare notifiche push.

La MFA fatigue non è la stessa cosa di altri attacchi di identità

Le differenze contano, perché le mitigazioni non sono identiche.

Password spraying prova una o poche password su molti utenti per ottenere il primo set di credenziali valido. Vedi Password Spraying: rilevamento e prevenzione per Active Directory ed Entra ID.
MFA fatigue comincia dopo che l’attaccante ha già, o è molto vicino ad avere, un primo fattore valido e cerca di trasformare un login bloccato in uno approvato.
Phishing adversary-in-the-middle proxya il flusso di login per catturare token o session context in tempo reale. Non dipende dall’affaticamento dell’utente nello stesso modo.
SIM swapping prende di mira fattori basati sul numero di telefono assumendo il controllo del numero mobile della vittima.

La MFA fatigue colpisce in modo specifico il passaggio umano di approvazione nella MFA basata su push.

Perché la MFA Fatigue funziona ancora

La MFA fatigue resta efficace quando tre problemi si sovrappongono: l’attaccante possiede un primo fattore valido, il tenant si affida ancora ad approvazioni push per account importanti e l’utente non ha abbastanza contesto o frizione per rifiutare con sicurezza la richiesta.

La guida Microsoft sulla phishing-resistant MFA è esplicita: metodi MFA tradizionali come SMS, OTP via email e notifiche push stanno diventando meno efficaci contro attaccanti moderni. Il documento cita user fatigue e MFA bombing come esempi concreti di bypass delle MFA legacy.

In pratica, la MFA fatigue funziona perché:

Le approvazioni push sono facili da innescare ripetutamente

L’attaccante non deve rompere un token o una chiave hardware. Gli basta un flusso di login che continui a generare prompt.

Molti utenti vedono ancora prompt con poco contesto

Se la notifica non mostra chiaramente il nome dell’applicazione e il contesto geografico del sign-in, l’utente ha meno informazioni per distinguere un login legittimo da un attacco. Microsoft ora raccomanda esplicitamente di mostrare questo contesto nelle notifiche di Authenticator.

Gli utenti possono essere socialmente manipolati mentre arrivano i prompt

Una richiesta push ha più probabilità di essere approvata se arriva mentre l’attaccante sta facendo pressione via telefono o messaggio, durante un vero reset password o quando l’utente si aspetta già qualche attività di login legittima.

Gli account ad alto valore sono spesso protetti solo da MFA standard

Se gli amministratori si affidano ancora a semplici approvazioni push invece che a MFA resistente al phishing, la lista target dell’attaccante diventa molto più preziosa.

Prerequisiti per un attacco MFA Fatigue riuscito

Un attacco MFA fatigue riuscito richiede di solito queste condizioni.

1. L’attaccante ha un primo fattore valido o può innescare un workflow di reset

L’assunzione di base di MITRE è che l’attaccante possieda già credenziali valide. Nel mondo Entra, questo significa in genere una password rubata, una password recuperata da un’altra intrusione o una password ottenuta dopo Password Spraying: rilevamento e prevenzione per Active Directory ed Entra ID.

2. Il target usa MFA push

L’attacco dipende dal fatto che l’utente riceva una richiesta di approvazione. Se l’account target è limitato a metodi phishing-resistant, ad esempio tramite authentication strengths più forti per i login privilegiati, la MFA fatigue diventa molto meno utile.

3. Il tenant non ha ridotto abbastanza le approvazioni a basso contesto

Se il prompt mostra solo una richiesta generica, o se il report di attività sospetta non è attivo, l’utente ha meno contesto e il difensore meno segnali ad alta confidenza in caso di abuso.

4. L’account è abbastanza prezioso da giustificare tentativi ripetuti

Amministratori, cloud operator, help desk staff e application administrator sono target particolarmente appetibili, perché una sola approvazione può aprire molto accesso successivo.

5. I workflow di risposta sono troppo lenti

Se rifiuti ripetuti di prompt non vengono investigati rapidamente, o se i report di prompt sospetti non attivano containment, l’attaccante può continuare a insistere finché un utente approva o un secondo passaggio di social engineering non riesce.

La catena di attacco

Una catena di intrusione MFA fatigue tipica si presenta così.

Passo 1 - Ottenere la password

L’attaccante ottiene prima la password tramite phishing, password spraying, riuso di credenziali o social engineering.

Passo 2 - Innescare la challenge MFA

L’attaccante tenta un login su Microsoft 365, Azure o su un carico collegato a Entra che richiede l’approvazione di Authenticator.

Passo 3 - Ripetere la generazione dei prompt

Invece di accettare il fallimento iniziale, l’attaccante continua a generare richieste di approvazione. È esattamente questo il comportamento catturato da MITRE in T1621.

Passo 4 - Aggiungere pressione sociale

Gli attaccanti possono accompagnare i prompt con chiamate o messaggi che spingono l’utente ad approvare una richiesta, spesso fingendosi supporto interno o sfruttando un momento di confusione intorno a un login o a un reset password reale.

Passo 5 - Usare subito la sessione approvata

Una volta che l’utente approva un prompt, l’attaccante ottiene quello che cercava: una sessione valida nel tenant target. Da lì le azioni successive dipendono da privilegi e copertura delle policy. Le più comuni includono review del directory, discovery di ruoli privilegiati, ricerca di application registrations, accesso a mailbox o modifica di impostazioni di autenticazione.

Il prompt approvato, quindi, non è il punto finale dell’incidente. È il pivot da login bloccato ad accesso autenticato.

Rilevamento

Non esiste un singolo evento Entra che dica “questo era sicuramente MFA fatigue”. Il modello corretto è rilevamento basato su sequenze più contesto.

Cercare rifiuti MFA ripetuti sullo stesso utente

Il segnale più evidente è un cluster di tentativi ripetuti in cui lo stesso utente riceve più richieste MFA e le rifiuta o ignora. Nei sign-in logs di Entra questo spesso appare come una serie di sign-in interrotti con dettagli di failure MFA prima di un eventuale successo.

Trattare i report utente di prompt sospetti come evidenza ad alta confidenza

La funzionalità Microsoft Report suspicious activity è il segnale nativo più forte in questo workflow. Secondo Microsoft Learn:

gli utenti che segnalano un prompt MFA sconosciuto come sospetto vengono impostati a High User Risk
l’evento appare in sign-in logs, audit logs e risk detections
il riskEventType è userReportedSuspiciousActivity

Questo conta perché consente ai difensori di passare da supposizioni a un segnale concreto confermato dall’utente.

Le indagini dovrebbero correlare la sequenza di prompt con:

IP e geografie che l’utente non usa normalmente
applicazioni insolite che iniziano il sign-in
tentativi ripetuti dalla stessa fonte contro un account ad alto valore
una serie di rifiuti seguita da un unico successo
attività immediatamente successiva all’approvazione riuscita

Prestare attenzione speciale alle identità privilegiate

Un singolo episodio di push bombing contro un utente ordinario è già serio. Lo stesso pattern contro un Global Administrator, un Conditional Access Administrator o un Privileged Role Administrator richiede containment immediato.

Questo è uno dei motivi per cui conviene rivedere Accesso Privilegiato Azure: Troppi Admin Globali e Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica insieme a questo pattern di attacco.

Evitare conclusioni da un singolo evento

Gli utenti a volte rifiutano prompt legittimi. Cambi di rete mobile, sign-in da nuovi dispositivi o semplice confusione possono generare rumore. Il rilevatore migliore non è quindi un singolo rifiuto, ma un pattern ripetuto, soprattutto se accompagnato da user-reported suspicious activity, contesto di sign-in insolito o azioni privilegiate successive.

Remediazione

Fermare la MFA fatigue non significa aggiungere ancora più prompt MFA generici. Significa rendere le approvazioni malevole più difficili da innescare, più facili da riconoscere e meno preziose quando comunque avvengono.

1. Verificare che i flussi push di Authenticator usino il number matching

Microsoft dichiara che il number matching è attivo per le attuali notifiche push di Authenticator e lo descrive come un miglioramento di sicurezza fondamentale rispetto al vecchio modello Approve/Deny.

Questo conta perché l’attaccante non può più vincere con un semplice tap distratto su un prompt generico. L’utente deve inserire un numero mostrato nel flusso di login.

Se il tuo ambiente dipende ancora da integrazioni MFA più vecchie o adiacenti, occorre validarne il comportamento separatamente invece di assumere che ogni workflow push abbia lo stesso livello di protezione dell’esperienza corrente Entra + Authenticator.

Microsoft raccomanda esplicitamente di mostrare nome dell’applicazione e posizione geografica nelle notifiche di Authenticator in modo che l’utente possa prendere decisioni informate.

Un tenant che lascia le approvazioni push troppo generiche facilita gli attacchi di fatigue. Quando il prompt mostra un’applicazione o una località che l’utente non riconosce, il rifiuto diventa molto più probabile.

Questo controllo è particolarmente utile quando l’attaccante ha già una password reale e sta cercando di convertirla in una sessione approvata.

3. Abilitare Report suspicious activity e integrarlo nella risposta

Questa impostazione è uno dei controlli Entra più preziosi contro la MFA fatigue.

Microsoft documenta che quando un utente segnala un prompt MFA sospetto:

l’utente viene marcato come High User Risk
l’evento è visibile in sign-in logs, audit logs e risk detections
le organizzazioni con licenze adeguate possono usare risk-based Conditional Access per bloccare o forzare una remediation sicura
anche senza questa automazione, resta disponibile un segnale concreto da investigare e contenere

Operativamente, questo significa che l’utente può fare più che toccare Deny. Può creare dallo stesso prompt un segnale d’incidente visibile al difensore.

4. Portare gli utenti privilegiati verso MFA resistente al phishing

La guida attuale di Microsoft è chiara: i ruoli amministrativi privilegiati sono bersagli frequenti, e le organizzazioni dovrebbero richiedere phishing-resistant MFA per questi ruoli.

Per il tema di questo articolo, questo punto è centrale. Una semplice approvazione push standard può ancora essere abusata tramite fatica o social engineering. Un’authentication strength resistente al phishing rende quel percorso sensibilmente più difficile.

Se stai hardenizzando l’accesso privilegiato, abbinalo a Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta e Azure Identity Protection: Criteri di Rischio.

5. Ridurre il numero di password che gli attaccanti possono riutilizzare a monte

La MFA fatigue inizia di solito dopo un compromesso di password. Se riduci il furto di password e il successo del password spraying, riduci anche il numero di opportunità di push bombing.

È ciò che rende Accesso Condizionale Azure: bypass MFA e auth legacy e Azure Tenant Hardening: Security Defaults direttamente rilevanti. Flussi MFA più robusti sono importanti, ma devono poggiare su un tenant che riduce già l’accesso iniziale basato su password.

6. Rivedere separatamente identità esterne e guest

Il rischio legato alla MFA push non si limita agli account dipendenti. Identità esterne, account B2B guest e accessi partner possono diventare percorsi di approvazione rumorosi o poco controllati se vengono esclusi da controlli più forti o monitorati con meno attenzione. Ecco perché Account Guest Azure: governance, MFA e rischio di accesso esterno rientra nello stesso movimento di review.

7. Distribuire policy più forti con cautela

La guida Microsoft per amministratori include un vero avvertimento operativo: prima di richiedere in modo esteso MFA resistente al phishing per gli amministratori, bisogna confermare che quegli utenti siano già registrati con i metodi necessari. In caso contrario, il rischio è bloccare il tenant a se stessi.

La stessa logica si applica più in generale alle modifiche di Conditional Access:

usare la modalità report-only dove disponibile
proteggere intenzionalmente gli account di accesso di emergenza
rivedere separatamente service account e workload identities
validare che i workflow di help desk e di recupero identità continuino a funzionare

Un buon hardening dell’identità non consiste solo nell’aumentare i controlli. Consiste anche nell’evitare interruzioni auto-inflitte.

Validazione dopo l’hardening

Non chiudere questo tema solo perché hai attivato un’impostazione in Entra. Bisogna validare l’intero workflow di approvazione.

confermare che il tenant presenti davvero il number matching negli scenari Authenticator push che usi realmente
confermare che il prompt mostri nome dell’applicazione e posizione geografica dove previsto
confermare che Report suspicious activity sia abilitato per la popolazione di utenti desiderata
confermare che i report di prompt sospetti generino i segnali attesi nei sign-in logs, audit logs e risk detections
confermare che il workflow di risposta revochi sessioni, indaghi i sign-in e resetti le credenziali quando un utente segnala un prompt malevolo
confermare che gli amministratori privilegiati siano coperti da requisiti di autenticazione più forti rispetto agli utenti normali

Il vero test non è capire se la MFA è abilitata nel tenant. Il vero test è capire se una password rubata, combinata a prompt push ripetuti, abbia ancora una strada realistica verso un’approvazione.

Come EtcSec rileva esposizione correlata

La MFA fatigue è una tecnica di attacco, non una singola misconfigurazione Entra. I finding di catalogo più vicini sono i gap di controllo che rendono il push bombing più probabile da avere successo o più difficile da contenere.

Le esposizioni correlate più rilevanti sono:

assenza di risk-based sign-in response, che indebolisce il containment dopo che un utente ha segnalato un prompt sospetto
protezione debole o incompleta delle identità privilegiate, soprattutto quando gli utenti amministrativi non vengono spostati verso pattern di autenticazione più forti
design di Conditional Access che si appoggiano ancora troppo su prompt MFA standard invece di richiedere metodi più forti

Per questo il tema si colloca accanto a Azure Identity Protection: Criteri di Rischio, Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta e Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica, invece di vivere come una singola impostazione isolata del tenant.

Controlli correlati

Se stai rivedendo la MFA fatigue, dovresti rivedere anche i controlli che modellano lo stesso percorso di attacco: Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta, Azure Identity Protection: Criteri di Rischio, Accesso Condizionale Azure: bypass MFA e auth legacy, Azure Tenant Hardening: Security Defaults, Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica e Account Guest Azure: governance, MFA e rischio di accesso esterno.