MFA Fatigue in Entra ID: Erkennung und Prävention

Was ist MFA Fatigue?

MFA Fatigue, auch MFA Bombing oder Push Bombing genannt, ist die wiederholte Erzeugung von Multifaktor-Anfragen, bis ein Benutzer schließlich eine davon bestätigt. MITRE führt diese Technik als T1621, Multi-Factor Authentication Request Generation.

Der Mechanismus ist enger gefasst, als viele Teams ihn beschreiben. Im häufigsten Fall besitzt der Angreifer bereits das Passwort des Opfers und wird nur noch durch den zweiten Faktor geblockt. Statt dort zu stoppen, erzeugt er wiederholt Push-Benachrichtigungen an Microsoft Authenticator, Duo, Okta Verify oder einen ähnlichen MFA-Dienst und versucht, den Benutzer zu zermürben.

Der Scope dieses Artikels ist Microsoft Entra ID und push-basierte MFA mit Microsoft Authenticator, mit Fokus auf operative Detection und Tenant-Hardening. MFA Fatigue ist nicht dasselbe wie Password Spraying, Adversary-in-the-Middle-Phishing oder SIM Swapping, auch wenn diese Techniken häufig vorher oder parallel eingesetzt werden.

Das Kernrisiko ist einfach: Eine push-basierte MFA-Kontrolle hängt immer noch davon ab, dass ein Benutzer unter Druck die richtige Entscheidung trifft. Wenn der Angreifer wiederholte Prompts auslösen oder diese mit einem Social-Engineering-Vorwand koppeln kann, kann eine Kontrolle, die in der Richtlinie stark aussah, in der Praxis versagen.

Wie MFA Fatigue funktioniert

MITREs Definition ist präzise: Angreifer können versuchen, MFA zu umgehen, indem sie MFA-Anfragen an Benutzer generieren. Wenn sie bereits gültige Zugangsdaten besitzen, scheitern sie oft nur daran, dass ihnen der zweite Faktor fehlt. Um das zu umgehen, missbrauchen sie Push-Benachrichtigungen und hoffen, dass der Benutzer eine davon bestätigt.

Wichtig ist: Das ist kein kryptografischer Bruch. Es ist ein Missbrauch von Authentifizierungs-Workflow-Design und menschlichem Freigabeverhalten.

Eine typische Entra-orientierte Sequenz sieht so aus:

der Angreifer erhält einen gültigen Benutzernamen und ein gültiges Passwort durch Phishing, Password Spraying, Credential Stuffing oder Helpdesk-Social-Engineering
der Angreifer startet einen interaktiven Sign-in, der eine Microsoft-Authenticator-Freigabe erfordert
der Benutzer erhält wiederholte Push-Benachrichtigungen
der Angreifer versucht es weiter, oft zu Zeiten, die Verwirrung oder Müdigkeit erzeugen sollen
wenn der Benutzer schließlich einen Prompt bestätigt, erhält der Angreifer eine gültige authentifizierte Sitzung

MITRE nennt auch einen zweiten Pfad, den Verteidiger manchmal übersehen: Wenn der Angreifer noch keine Credentials besitzt, kann automatische Push-Erzeugung in bestimmten Self-Service-Password-Reset-Szenarien missbraucht werden, sofern dieser Workflow Push-Benachrichtigungen versendet.

MFA Fatigue ist nicht dasselbe wie andere Identitätsangriffe

Die Unterschiede sind wichtig, weil die Gegenmaßnahmen nicht identisch sind.

Password Spraying testet ein oder wenige Passwörter über viele Benutzer, um die erste gültige Credential zu erhalten. Siehe Password Spraying: Erkennung und Prävention für Active Directory und Entra ID.
MFA Fatigue beginnt, nachdem der Angreifer bereits einen gültigen ersten Faktor besitzt oder fast besitzt, und versucht, aus einem blockierten Login eine bestätigte Anmeldung zu machen.
Adversary-in-the-Middle-Phishing proxyt den Sign-in-Flow, um Tokens oder Sitzungs-Kontext in Echtzeit abzugreifen. Die Technik hängt nicht auf dieselbe Weise von Benutzerermüdung ab.
SIM Swapping zielt auf telefonbasierte Faktoren, indem die Mobilnummer des Opfers übernommen wird.

MFA Fatigue zielt ganz konkret auf den menschlichen Freigabeschritt bei push-basierter MFA.

Warum MFA Fatigue noch immer funktioniert

MFA Fatigue bleibt wirksam, wenn drei Probleme zusammenkommen: Der Angreifer verfügt über einen gültigen ersten Faktor, der Tenant verlässt sich weiterhin auf Push-Freigaben für wichtige Konten, und der Benutzer hat nicht genug Kontext oder Reibung, um die Anfrage sicher abzulehnen.

Microsofts eigene Guidance zu phishing-resistenter MFA ist hier klar: klassische MFA-Methoden wie SMS-Codes, E-Mail-OTPs und Push-Benachrichtigungen werden gegen moderne Angreifer zunehmend weniger effektiv. Das Dokument nennt User Fatigue und MFA Bombing explizit als Beispiele dafür, wie Angreifer ältere MFA-Muster umgehen.

In der Praxis funktioniert MFA Fatigue, weil:

Push-Freigaben sich leicht wiederholt auslösen lassen

Der Angreifer muss weder ein Token knacken noch einen Hardware-Schlüssel brechen. Es reicht, einen Sign-in-Flow zu haben, der immer wieder neue Prompts erzeugt.

Viele Benutzer immer noch Prompts mit wenig Kontext sehen

Wenn die Benachrichtigung nicht klar den Anwendungsnamen und den geografischen Kontext der Anmeldung anzeigt, hat der Benutzer weniger Informationen, um zwischen legitimer Anmeldung und Angriff zu unterscheiden. Microsoft empfiehlt inzwischen ausdrücklich, diesen Kontext in Authenticator-Benachrichtigungen anzuzeigen.

Benutzer während der Prompt-Serie sozial manipuliert werden können

Eine Push-Anfrage wird wahrscheinlicher bestätigt, wenn sie eintrifft, während der Angreifer den Benutzer telefonisch oder per Nachricht unter Druck setzt, wenn gerade ein echter Passwort-Reset läuft oder wenn der Benutzer ohnehin legitime Sign-in-Aktivität erwartet.

Hochwertige Konten oft nur durch Standard-MFA geschützt sind

Wenn Administratoren weiterhin nur auf Standard-Push-Freigaben statt auf phishing-resistente MFA setzen, wird die Zielliste des Angreifers deutlich wertvoller.

Voraussetzungen für einen erfolgreichen MFA-Fatigue-Angriff

Ein erfolgreicher MFA-Fatigue-Angriff setzt in der Regel Folgendes voraus.

1. Der Angreifer hat einen gültigen ersten Faktor oder kann einen Reset-Flow anstoßen

MITREs Grundannahme ist, dass der Angreifer bereits gültige Account-Credentials besitzt. In der Entra-Welt bedeutet das meist ein gestohlenes Passwort, ein Passwort aus einer anderen Kompromittierung oder ein Passwort, das nach Password Spraying: Erkennung und Prävention für Active Directory und Entra ID erlangt wurde.

2. Das Ziel nutzt push-basierte MFA

Die Attacke hängt davon ab, dass der Benutzer eine Freigabeanfrage erhält. Wenn das Zielkonto auf phishing-resistente Methoden beschränkt ist, etwa durch stärkere Authentication Strengths für privilegierte Sign-ins, verliert MFA Fatigue stark an Nutzen.

3. Der Tenant hat Low-Context-Approvals nicht genug reduziert

Wenn der Prompt nur eine generische Freigabeanfrage zeigt oder „Report suspicious activity“ nicht aktiviert ist, haben Benutzer weniger Kontext und Verteidiger weniger hochzuverlässige Signale bei Missbrauch.

4. Das Konto ist wertvoll genug, um wiederholte Versuche zu rechtfertigen

Administratoren, Cloud-Operatoren, Helpdesk-Mitarbeiter und Application Administrators sind besonders attraktive Ziele, weil eine einzige bestätigte Anfrage bereits breiten Folgezugriff eröffnen kann.

5. Response-Workflows sind zu langsam

Wenn wiederholte Prompt-Ablehnungen nicht schnell untersucht werden oder verdächtige Prompt-Meldungen kein Containment auslösen, kann der Angreifer weiter probieren, bis ein Benutzer bestätigt oder ein zweiter Social-Engineering-Schritt funktioniert.

Die Angriffskette

Eine praktische MFA-Fatigue-Intusionskette sieht typischerweise so aus.

Schritt 1 – Das Passwort erlangen

Der Angreifer beschafft sich das Passwort zunächst über Phishing, Password Spraying, Credential-Reuse oder Social Engineering.

Schritt 2 – Die MFA-Challenge auslösen

Der Angreifer versucht einen Sign-in auf einen Microsoft-365-, Azure- oder Entra-verbundenen Dienst, der eine Authenticator-Freigabe erfordert.

Schritt 3 – Die Prompt-Erzeugung wiederholen

Statt den fehlgeschlagenen Login zu akzeptieren, erzeugt der Angreifer immer neue Freigabeanfragen. Genau dieses Verhalten bildet MITRE in T1621 ab.

Schritt 4 – Sozialen Druck hinzufügen

Angreifer kombinieren die Prompts oft mit Anrufen oder Nachrichten, die den Benutzer zu einer Freigabe drängen, häufig unter dem Vorwand interner IT-Unterstützung oder in einem Moment der Verwirrung rund um einen echten Sign-in oder Passwort-Reset.

Schritt 5 – Die bestätigte Sitzung sofort ausnutzen

Sobald der Benutzer einen Prompt bestätigt, hat der Angreifer erreicht, was er wollte: eine gültige Sitzung im Ziel-Tenant. Von dort hängen die nächsten Schritte von Privileg und Policy Coverage ab. Typische Folgeaktionen sind Directory Review, Discovery privilegierter Rollen, Suche nach Application Registrations, Zugriff auf Mailboxen oder Änderungen an Authentifizierungseinstellungen.

Der bestätigte Prompt ist also nicht das Ende des Vorfalls. Er ist der Pivot von blockiertem Login zu authentifiziertem Zugriff.

Detection

Es gibt kein einzelnes Entra-Ereignis, das sagt: „Das war definitiv MFA Fatigue.“ Das richtige Modell ist sequenzbasierte Detection plus Kontext.

Auf wiederholte MFA-Ablehnungen für denselben Benutzer achten

Das offensichtlichste Signal ist eine Gruppe wiederholter Sign-in-Versuche, bei denen derselbe Benutzer mehrere MFA-Anfragen erhält und diese ablehnt oder ignoriert. In Entra Sign-in Logs erscheint das häufig als Serie unterbrochener Sign-ins mit MFA-Fehldetails vor einem möglichen späteren Erfolg.

Von Benutzern gemeldete verdächtige Prompts als High-Confidence-Signal behandeln

Microsofts Funktion Report suspicious activity ist das stärkste native Signal in diesem Workflow. Laut Microsoft Learn gilt:

Benutzer, die einen unbekannten MFA-Prompt als verdächtig melden, werden auf High User Risk gesetzt
das Ereignis erscheint in Sign-in Logs, Audit Logs und Risk Detections
der riskEventType lautet userReportedSuspiciousActivity

Das ist wichtig, weil es Verteidigern erlaubt, von Vermutung zu einem konkreten, vom Benutzer bestätigten Signal zu wechseln.

Untersuchungen sollten die Prompt-Sequenz mit Folgendem korrelieren:

Quell-IPs und Geografien, die der Benutzer normalerweise nicht nutzt
ungewöhnliche Anwendungen, die den Sign-in initiieren
wiederholte Versuche von derselben Quelle gegen ein High-Value-Konto
ein Muster aus mehreren Ablehnungen, gefolgt von einem einzigen Erfolg
Folgeaktivität unmittelbar nach der erfolgreichen Bestätigung

Privilegierte Identitäten besonders beachten

Ein einzelnes Push-Bombing-Ereignis gegen einen normalen Benutzer ist bereits ernst. Dasselbe Muster gegen einen Global Administrator, Conditional Access Administrator oder Privileged Role Administrator erfordert sofortiges Containment.

Darum sollten Azure Privilegierter Zugriff: Zu Viele Globale Admins und Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden zusammen mit diesem Angriffsmuster betrachtet werden.

Keine Schlüsse aus einem einzigen Ereignis ziehen

Benutzer lehnen gelegentlich auch legitime Prompts ab. Mobile Netzwechsel, Sign-ins von neuen Geräten oder bloße Benutzerverwirrung können ebenfalls Rauschen erzeugen. Der bessere Detektor ist daher nicht eine einzelne Ablehnung, sondern ein wiederholtes Muster, besonders in Kombination mit user-reported suspicious activity, ungewohntem Sign-in-Kontext oder privilegierter Folgeaktivität.

Remediation

MFA Fatigue zu stoppen bedeutet nicht, einfach mehr generische MFA-Prompts zu erzeugen. Es bedeutet, missbräuchliche Freigaben schwerer auszulösen, leichter erkennbar zu machen und weniger wertvoll werden zu lassen, wenn sie doch passieren.

1. Prüfen, dass Authenticator-Push-Flows Number Matching verwenden

Microsoft erklärt, dass Number Matching für aktuelle Authenticator-Push-Benachrichtigungen aktiviert ist, und beschreibt es als wesentliche Sicherheitsverbesserung gegenüber dem alten Approve/Deny-Modell.

Das ist wichtig, weil der Angreifer nicht mehr mit einem einzigen unaufmerksamen Tap auf einen generischen Prompt gewinnen kann. Der Benutzer muss eine Zahl eingeben, die im Sign-in-Flow angezeigt wird.

Wenn Ihre Umgebung noch auf ältere oder angrenzende MFA-Integrationspfade angewiesen ist, müssen Sie deren Verhalten separat validieren, statt anzunehmen, jeder Push-Workflow biete denselben Schutz wie die aktuelle Entra- plus Authenticator-Erfahrung.

Microsoft empfiehlt ausdrücklich, Anwendungsname und geografischen Ort in Authenticator-Benachrichtigungen anzuzeigen, damit Benutzer fundierte Freigabeentscheidungen treffen können.

Ein Tenant, der Push-Freigaben zu generisch hält, erleichtert Fatigue-Angriffe. Wenn der Prompt eine Anwendung oder einen Ort zeigt, den der Benutzer nicht erkennt, wird eine Ablehnung deutlich wahrscheinlicher.

Dieser Kontrollpunkt ist besonders nützlich, wenn der Angreifer bereits ein echtes Passwort hat und versucht, daraus eine bestätigte Sitzung zu machen.

3. Report suspicious activity aktivieren und in Response einbinden

Diese Einstellung ist einer der wertvollsten Entra-Kontrollpunkte gegen MFA Fatigue.

Microsoft dokumentiert: Wenn ein Benutzer einen verdächtigen MFA-Prompt meldet,

wird der Benutzer auf High User Risk gesetzt
das Ereignis erscheint in Sign-in Logs, Audit Logs und Risk Detections
Organisationen mit passender Lizenz können risk-based Conditional Access einsetzen, um den Zugriff zu blockieren oder sichere Remediation zu erzwingen
auch ohne diese Automatisierung entsteht ein konkretes Signal für Untersuchung und Containment

Operativ bedeutet das: Der Benutzer kann mehr tun als nur auf Deny tippen. Er kann mit demselben Prompt ein verteidiger-sichtbares Incident-Signal erzeugen.

4. Privilegierte Benutzer auf phishing-resistente MFA umstellen

Microsofts aktuelle Guidance ist klar: privilegierte Admin-Rollen sind häufige Ziele, und Organisationen sollten für diese Rollen phishing-resistant MFA verlangen.

Für das Thema dieses Artikels ist das zentral. Eine Standard-Push-Freigabe kann weiterhin durch Fatigue oder Social Engineering missbraucht werden. Eine phishing-resistente Authentication Strength macht diesen Pfad materiell schwerer.

Wenn Sie privilegierten Zugriff härten, kombinieren Sie das mit Azure Identitätssicherheit: Warum MFA Allein Nicht Ausreicht und Azure Identity Protection: Reaktion auf Kompromittierte Konten.

5. Die Zahl wiederverwendbarer Passwörter insgesamt reduzieren

MFA Fatigue beginnt meist nach einer Passwortkompromittierung. Wenn Sie Passwortdiebstahl und Password-Spray-Erfolge reduzieren, reduzieren Sie auch die Zahl der Push-Bombing-Gelegenheiten.

Darum sind Azure Bedingter Zugriff: MFA-Bypass mit Gestohlenem Passwort und Azure Tenant-Härtung: Unsichere Defaults hier direkt relevant. Stärkere MFA-Freigabeflüsse sind wichtig, sollten aber auf einem Tenant aufsetzen, der passwortbasierten Initial Access bereits reduziert.

6. Externe und Gast-Identitäten separat prüfen

Push-basierte MFA-Risiken beschränken sich nicht auf Mitarbeiterkonten. Externe Identitäten, B2B-Gastkonten und Partnerzugänge können ebenfalls zu lauten oder schlecht überprüften Freigabepfaden werden, wenn sie von stärkeren Kontrollen ausgenommen sind oder schwächer überwacht werden. Deshalb gehört Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant in denselben Review.

7. Stärkere Richtlinien kontrolliert ausrollen

Microsofts Administrator-Guidance enthält eine echte operative Warnung: Bevor Sie phishing-resistente MFA breit für Administratoren verlangen, müssen Sie sicherstellen, dass diese Benutzer bereits für die benötigten Methoden registriert sind. Sonst drohen selbstverschuldete Lockouts.

Dasselbe gilt allgemeiner für Conditional-Access-Änderungen:

Report-Only-Modus nutzen, wo verfügbar
Emergency-Access-Konten bewusst schützen
Service Accounts und Workload Identities separat prüfen
validieren, dass Helpdesk- und Identity-Recovery-Workflows weiterhin funktionieren

Gutes Identity Hardening bedeutet nicht nur stärkere Kontrollen. Es bedeutet auch, selbst verursachte Ausfälle zu vermeiden.

Validierung nach der Härtung

Schließen Sie dieses Thema nicht ab, nur weil eine Entra-Einstellung aktiviert wurde. Validieren Sie den gesamten Prompt-Freigabe-Workflow.

bestätigen Sie, dass der Tenant für die tatsächlich genutzten Authenticator-Push-Szenarien Number Matching präsentiert
bestätigen Sie, dass der Prompt Anwendungsname und geografischen Ort anzeigt, wo dies erwartet wird
bestätigen Sie, dass Report suspicious activity für die vorgesehene Benutzerpopulation aktiviert ist
bestätigen Sie, dass verdächtige Prompt-Meldungen die erwarteten Signale in Sign-in Logs, Audit Logs und Risk Detections erzeugen
bestätigen Sie, dass der Response-Workflow Sitzungen widerruft, Sign-ins untersucht und Credentials zurücksetzt, wenn ein Benutzer einen bösartigen Prompt meldet
bestätigen Sie, dass privilegierte Administratoren stärkeren Authentifizierungsanforderungen unterliegen als normale Benutzer

Der eigentliche Test ist nicht, ob MFA im Tenant aktiviert ist. Der eigentliche Test ist, ob ein gestohlenes Passwort plus wiederholte Push-Versuche noch einen realistischen Weg zur Freigabe hat.

Wie EtcSec verwandte Exposition erkennt

MFA Fatigue ist eine Angriffstechnik, keine einzelne Entra-Fehlkonfiguration. Die nächsten Catalogue-Findings sind die Kontrolllücken, die Push Bombing wahrscheinlicher erfolgreich machen oder schwerer einzugrenzen sind.

Die relevantesten verwandten Expositionen sind:

fehlende risk-based sign-in response, die Containment schwächt, nachdem ein Benutzer einen verdächtigen Prompt gemeldet hat
schwacher oder unvollständiger Schutz privilegierter Identitäten, insbesondere wenn administrative Benutzer nicht auf stärkere Authentifizierungsmuster umgestellt wurden
Conditional-Access-Designs, die weiterhin zu stark auf Standard-MFA-Prompts statt auf stärkere Authentifizierungsanforderungen setzen

Darum sitzt dieses Thema neben Azure Identity Protection: Reaktion auf Kompromittierte Konten, Azure Identitätssicherheit: Warum MFA Allein Nicht Ausreicht und Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden – nicht als isolierte Tenant-Einstellung.