Multi-Faktor-Authentifizierung gilt seit Jahren als Standard und bleibt das Rückgrat moderner Anmeldeverfahren. Aber selbst MFA hat eine Schwachstelle: den Menschen, der spät abends auf seinem Sperrbildschirm zum dritten Mal eine Push-Bestätigung wegtippt, ohne nachzudenken. Genau diese Schwachstelle nutzen Angreifer mit einer Methode, die als „MFA-Fatigue“ oder „Push-Bombing“ bekannt ist.
Wie ein Push-Bombing-Angriff abläuft
Der Angreifer hat das Passwort des Opfers bereits — etwa über ein älteres Datenleck, eine Phishing-Welle oder durch Credential Stuffing. Er versucht sich anzumelden und löst damit eine MFA-Push-Anfrage auf dem Smartphone des Mitarbeitenden aus.
Akzeptiert der Mitarbeitende nicht, sendet der Angreifer weitere Push-Anfragen — manchmal 20, manchmal 100 Pushs in zehn Minuten. Oft kombiniert mit einem parallelen Anruf vom angeblichen IT-Support: „Bitte bestätigen Sie kurz, wir versuchen gerade, einen Sicherheitsfehler zu beheben.“ Irgendwann tippt jemand aus Reflex, Genervtheit oder Vertrauen auf Bestätigen.
Drei wirksame Gegenmaßnahmen gegen Push-Bombing
1. Number-Matching aktivieren
Statt nur „Bestätigen / Ablehnen“ muss der Nutzer eine Zahl eingeben, die im Login-Browser angezeigt wird. Das verhindert reflexartiges Bestätigen und macht Push-Bombing weitgehend nutzlos. Microsoft hat Number-Matching im Authenticator inzwischen als Standard aktiviert; in vielen Unternehmen ist die Konfiguration dennoch unvollständig.
2. Risk-based MFA
Anmeldungen aus untypischen Locations, von neuen Geräten oder zu untypischen Zeiten triggern zusätzliche Verifikation oder werden blockiert. Conditional Access in Microsoft Entra ID, Okta Adaptive MFA und vergleichbare Lösungen unterstützen diese Logik nativ — sie muss nur sauber konfiguriert sein.
3. Hardware-Keys für privilegierte Konten
Admins, Geschäftsführung und Buchhaltung sollten auf FIDO2-Schlüssel umsteigen. FIDO2 ist phishing-resistent: Anders als TOTP-Codes oder Push-Bestätigungen lässt sich ein FIDO2-Schlüssel nicht durch Social Engineering austricksen.
Awareness ist auch hier zentral
Mitarbeitende müssen klar wissen: Eine Push-Anfrage, die sie nicht selbst ausgelöst haben, ist kein Versehen, sondern ein Warnsignal. Sie gehört gemeldet, nicht bestätigt — auch nicht „nur einmal“, um Ruhe zu haben.
Diese Botschaft sollte Teil jeder Awareness-Schulung sein. Idealerweise mit konkreten Beispielen aus dem eigenen Unternehmen, die anonymisiert vorgestellt werden. Wir integrieren Push-Bombing-Szenarien standardmäßig in unsere Awareness-Trainings vor Ort.
Phishgate als Frühwarnung — eine Stufe vor MFA
Push-Bombing setzt voraus, dass der Angreifer bereits das Passwort hat. Genau hier setzt Phishgate eine Stufe früher an: Phishgate warnt, bevor Zugangsdaten überhaupt eingegeben werden — auf nicht freigegebenen Domains.
Konkret: Wenn ein Mitarbeitender auf einer Phishing-Seite landet, die wie das interne Microsoft-365-Login aussieht, schlägt Phishgate Alarm, sobald er beginnt, sein Passwort einzugeben. Im LOW Mode kann er die Warnung bewusst übergehen; im FULL Mode wird der Zugriff stärker eingeschränkt. Wenn das Passwort nie auf der Phishing-Seite landet, kann der Angreifer auch keine Push-Bombing-Welle starten.
Defense in Depth: Phishgate plus MFA
Phishgate ersetzt MFA nicht. MFA ersetzt Phishgate nicht. Beide Schichten greifen ineinander:
- Phishgate verhindert in vielen Fällen, dass Zugangsdaten überhaupt erst gestohlen werden.
- Number-Matching, Risk-based MFA und FIDO2 schützen den Login auch dann, wenn das Passwort schon kompromittiert ist.
- Awareness sorgt dafür, dass Mitarbeitende beide Schichten nicht versehentlich aushebeln.
Fazit
Push-Bombing kapert auch MFA-geschützte Accounts, wenn Mitarbeitende übermüdet, gestresst oder schlecht informiert sind. Die Kombination aus Number-Matching, Risk-based MFA, Hardware-Keys für sensible Rollen, klarer Awareness-Botschaft und einer Browser-Warnschicht wie Phishgate schließt die Lücke deutlich.