MFA-Fatigue erkennen: Warum Push-Bestätigungen kein reines Awareness-Problem sind

Eine unerwartete MFA-Anfrage wirkt zunächst wie eine kleine Störung. Folgen viele Push-Nachrichten kurz hintereinander, kann daraus ein Sicherheitsvorfall werden: Angreifer versuchen, eine Freigabe zu provozieren, nachdem sie bereits Zugangsdaten erlangt haben. Dieses Muster wird als MFA-Fatigue, MFA-Bombing oder Push-Bombing bezeichnet.

Für CISOs ist die entscheidende Frage deshalb nicht nur, ob Beschäftigte eine verdächtige Anfrage ablehnen. Zu prüfen ist, warum ein Angreifer beliebig viele Anfragen auslösen kann, welche Signale das Security-Team erhält und ob Betroffene den Vorgang sofort melden können. MFA-Fatigue ist ein Zusammenspiel aus Identitätsschutz, Konfiguration, Erkennung und menschlicher Entscheidung.

Was bei MFA-Fatigue technisch tatsächlich passiert

Multi-Faktor-Authentisierung bleibt eine wichtige Schutzschicht. MFA-Fatigue nutzt jedoch eine Schwäche bestimmter Push-Verfahren aus: Wer Benutzername und Passwort besitzt, kann wiederholt Anmeldeversuche starten. Jede Anfrage erzeugt eine Benachrichtigung auf dem registrierten Gerät. Bei einer einfachen Auswahl zwischen „Genehmigen“ und „Ablehnen“ genügt eine einzige falsche Bestätigung.

Die aktuelle NIST-Richtlinie SP 800-63B ordnet Out-of-Band-Authentisierung ausdrücklich als nicht phishing-resistent ein. Ein Verfahren, das auf einem zweiten Kanal lediglich um Zustimmung bittet, gilt dort wegen beobachteter „authentication fatigue“-Angriffe nicht mehr als ausreichend. NIST verlangt bei diesem Verfahren eine aktive Übertragung eines Geheimnisses zwischen den Kanälen und empfiehlt außerdem, Zahl oder Rate der Push-Nachrichten seit der letzten erfolgreichen Authentisierung zu begrenzen.

Das verändert die Verantwortung: Eine unerwartete Freigabe ist nicht bloß ein Fehler einer einzelnen Person. Wenn das Verfahren wiederholte Anfragen zulässt, Kontext vermissen lässt oder keine schnelle Reaktion auslöst, trägt die technische Gestaltung zum Risiko bei.

Scattered Spider zeigt die Verbindung von Technik und Social Engineering

Wie eng MFA-Fatigue mit weiteren Angriffsschritten verbunden ist, dokumentiert das 2025 aktualisierte gemeinsame Advisory von FBI, CISA und internationalen Partnerbehörden zur Gruppe Scattered Spider. Die Behörden beschreiben wiederholte MFA-Pushes, durch die Beschäftigte zum Akzeptieren gebracht werden sollten. Zugleich gaben sich die Akteure als IT- oder Helpdesk-Personal aus, ließen Passwörter zurücksetzen oder MFA-Token auf kontrollierte Geräte übertragen.

Der reale Fall ist für Verantwortliche relevant, weil er die Grenzen einer isolierten Awareness-Botschaft zeigt. „Keine unbekannte Anfrage bestätigen“ ist richtig, deckt aber nur einen Teil der Angriffskette ab. Wenn Helpdesk-Prozesse eine Identität unzureichend prüfen, MFA-Registrierungen nicht überwacht werden oder ein ungewöhnlicher Push-Sturm kein Signal erzeugt, bleibt der Zugang auch bei sensibilisierten Beschäftigten angreifbar.

Welche Kontrollen CISOs zuerst prüfen sollten

Die wirksamste Priorisierung beginnt beim Authentisierungsverfahren. Phishing-resistente kryptografische Verfahren binden die Authentisierung an den legitimen Dienst und vermeiden die einfache Push-Freigabe. Wo ein sofortiger Umstieg nicht möglich ist, kann Number Matching die unbeabsichtigte Bestätigung erschweren: Die anmeldende Person muss eine auf dem Anmeldebildschirm angezeigte Zahl in der Authenticator-App eingeben. Microsoft dokumentiert, dass Number Matching bei Push-Benachrichtigungen des Microsoft Authenticator verpflichtend aktiviert ist.

Number Matching ist dennoch keine Gleichsetzung mit phishing-resistenter MFA. NIST stellt klar, dass manuell übertragene Authentisierungsausgaben nicht an die konkrete Sitzung gebunden sind und deshalb nicht als phishing-resistent gelten. Für die Roadmap bedeutet das: Number Matching kann ein sinnvoller Zwischenschritt sein, sollte aber die Migration zu geeigneten kryptografischen Verfahren für besonders schützenswerte Konten nicht ersetzen.

Für die Bestandsaufnahme helfen fünf Prüffragen:

• Welche Konten und Anwendungen verwenden noch einfache Approve/Deny-Pushes, SMS oder Einmalcodes?

• Werden wiederholte MFA-Anfragen, ungewöhnliche Anmeldeorte und Änderungen registrierter Faktoren erkannt und korreliert?

• Begrenzen die eingesetzten Systeme die Zahl beziehungsweise Rate ausgelöster Push-Anfragen?

• Wie wird die Identität bei Passwort-Reset, Faktorwechsel und Helpdesk-Kontakt verifiziert?

• Können Beschäftigte eine unerwartete Anfrage mit einem bekannten, schnell erreichbaren Meldeweg eskalieren?

Diese Fragen verbinden Prävention und Reaktion. Eine Ablehnung auf dem Smartphone beendet den Anmeldeversuch, beseitigt aber nicht das möglicherweise kompromittierte Passwort. Der Meldeweg muss deshalb eine technische Untersuchung, die Absicherung des Kontos und die Prüfung weiterer Anmeldeereignisse auslösen können.

Awareness muss den Meldeweg mit der Technik verbinden

Awareness hat bei MFA-Fatigue eine präzise Aufgabe: Beschäftigte müssen unerwartete Anfragen als mögliches Zeichen kompromittierter Zugangsdaten einordnen und den vorgesehenen Meldeweg kennen. Die Botschaft sollte zur tatsächlichen Oberfläche des verwendeten Systems, zum Helpdesk-Prozess und zur Reaktion des Security-Teams passen. Allgemeine Appelle zur Wachsamkeit reichen dafür nicht.

Auch die Erfolgskontrolle sollte mehr erfassen als Schulungsteilnahmen. Relevant ist beispielsweise, ob verdächtige Anfragen zeitnah gemeldet werden, ob die Meldung die richtigen technischen Schritte auslöst und ob sich wiederholte Push-Ereignisse in der vorhandenen Telemetrie erkennen lassen. Das sind organisatorische Prüfpunkte; aus ihnen folgt noch kein pauschaler Wirksamkeitsnachweis für ein einzelnes Training.

Die Security-Awareness-Plattform von What The Hack! kann in diesem Zusammenhang als Baustein eines breiteren Programms dienen. Im Teamformat diskutieren Mitarbeitende Sicherheitsszenarien und einigen sich auf eine Antwort; der Solo-Modus und auswählbare Themenkampagnen unterstützen ergänzend die individuelle Nutzung. Für die fachliche Einordnung von Social Engineering und Meldeverhalten bietet die Seite zu Cybersecurity-Awareness mit What The Hack! einen passenden nächsten Einstieg. Technische Härtung, Identitätsprozesse und Incident Response bleiben eigenständige Aufgaben.

Fazit: Push-MFA als Gesamtsystem bewerten

MFA-Fatigue ist kein Argument gegen Multi-Faktor-Authentisierung. Sie zeigt, dass nicht jede MFA-Methode denselben Schutz bietet und dass eine Sicherheitskontrolle nur im Zusammenspiel mit Konfiguration, Überwachung und Reaktion belastbar ist.

Für CISOs ergibt sich eine klare Reihenfolge: einfache Push-Freigaben identifizieren, exponierte Konten auf phishing-resistente Verfahren umstellen, verbleibende Push-Verfahren härten und begrenzen sowie einen eindeutigen Melde- und Reaktionsweg etablieren. Awareness unterstützt diese Architektur, indem sie die Bedeutung unerwarteter Anfragen und den nächsten Schritt verständlich macht. Sie kann eine angreifbare Authentisierungskonfiguration jedoch nicht kompensieren.

Quellen und weiterführende Informationen

• NIST: SP 800-63B – Authentication and Authenticator Management, aktuelle Anforderungen und Einordnung von Out-of-Band-Authentisierung, Authentication Fatigue und Phishing-Resistenz.

• FBI, CISA und internationale Partnerbehörden: Scattered Spider – Joint Cybersecurity Advisory, Update vom 29. Juli 2025, dokumentierte Taktiken zu Push-Bombing, Helpdesk-Imitation und MFA-Manipulation.

• Microsoft Learn: How number matching works in MFA push notifications for Authenticator, Funktionsweise und Einsatz von Number Matching.