Wie moderne Phishing-Angriffe MFA aushebeln – und was wirklich schützt
„Wir haben MFA aktiviert, wir sind auf der sicheren Seite.” Dieser Satz stimmt – aber nur noch teilweise. Denn während MFA in den letzten Jahren zum Standard geworden ist, haben sich die Angriffe mitentwickelt. Wer heute noch glaubt, dass ein TOTP-Code oder ein Authenticator-Push ausreicht, unterschätzt, was Angreifer in der Praxis bereits routinemäßig einsetzen.
Dieser Post erklärt, wie moderne Phishing-Angriffe MFA konkret aushebeln – und welche Verfahren wirklich schützen.
Das Problem: MFA schützt das Passwort, nicht die Session
Klassisches MFA-Denken geht so: Der Angreifer braucht Passwort und zweiten Faktor. Wenn er nur das Passwort hat, kommt er nicht rein.
Das stimmt – solange der Angreifer versucht, sich direkt beim Dienst anzumelden. Moderne Angriffe tun das nicht. Sie schalten sich zwischen den Nutzer und den Dienst – und lassen den Nutzer die Authentifizierung selbst erledigen.
Das Stichwort: Adversary-in-the-Middle (AiTM).
Wie AiTM-Phishing funktioniert
Stell dir vor, du bekommst eine E-Mail mit dem Hinweis, dein Microsoft-365-Passwort läuft ab. Der Link führt auf eine Seite, die exakt wie das Microsoft-Login aussieht – selbes Design, selbe URL-Struktur, nur eine andere Domain.
Was im Hintergrund passiert:
- Du gibst deinen Benutzernamen ein – der Proxy leitet die Anfrage in Echtzeit an das echte Microsoft-Login weiter
- Microsoft antwortet mit der echten Login-Seite – der Proxy zeigt sie dir
- Du gibst dein Passwort ein – der Proxy fängt es ab und leitet es weiter
- Microsoft fordert MFA an – der Proxy zeigt dir die echte MFA-Anfrage
- Du bestätigst in der Authenticator App – der Proxy leitet die Bestätigung weiter
- Microsoft stellt einen Session-Token aus – der Proxy fängt ihn ab
Der Angreifer hat jetzt keine Zugangsdaten. Er hat etwas viel Wertvolleres: einen gültigen, authentifizierten Session-Token. Den lädt er in einen Browser – und ist eingeloggt. Ohne Passwort, ohne zweiten Faktor. Das Passwort ist egal geworden.
Tools wie Evilginx oder Modlishka automatisieren genau das. Sie sind Open Source, gut dokumentiert und werden aktiv in realen Angriffen eingesetzt. Die technische Hürde für einen AiTM-Angriff ist heute gering.
Welche MFA-Methoden betroffen sind
| MFA-Methode | Gegen AiTM schützend? | Warum |
|---|---|---|
| SMS-OTP | ✘ | Code wird in Echtzeit abgefangen und weitergeleitet |
| TOTP (Google Authenticator, etc.) | ✘ | 30-Sekunden-Fenster reicht für den Proxy |
| E-Mail-OTP | ✘ | Gleiches Prinzip |
| Push-Benachrichtigung (Authenticator) | ✘ | Nutzer bestätigt – Proxy leitet weiter |
| Push mit Number Matching | ✘ | Verbessert Resistenz gegen Push-Fatigue, nicht gegen AiTM |
| Passwortlos (Authenticator Phone Sign-in) | ✘ | Session-Token bleibt das Ziel |
| FIDO2 / Passkeys / WHfB | ✔ | Kryptografisch an Origin gebunden – funktioniert nicht auf Phishing-Domain |
Das ist keine theoretische Schwäche. TOTP und Push-MFA wurden nicht für Szenarien designed, in denen ein Proxy dazwischensteht. Sie schützen das Passwort – aber nicht die Session.
Push-Fatigue: der einfachere Angriff
AiTM ist technisch anspruchsvoll. Es gibt einen einfacheren Weg.
MFA Bombing – auch Push-Fatigue genannt – funktioniert so: Der Angreifer hat ein gültiges Passwort (aus einem Leak, Spray-Angriff oder Phishing). Er versucht sich wiederholt anzumelden und löst damit Welle für Welle von Authenticator-Push-Benachrichtigungen aus.
Viele Nutzer reagieren irgendwann – aus Verwirrung, Erschöpfung oder weil sie denken, es sei ein Bug. Ein Tipp reicht. Der Angreifer ist drin.
Dieser Angriff war in mehreren aufsehenerregenden Vorfällen der letzten Jahre ein zentraler Faktor – unter anderem bei Angriffen auf große Technologieunternehmen, die öffentlich bekannt wurden.
Gegenmaßnahmen die helfen, aber AiTM nicht stoppen:
- Number Matching (Nutzer muss eine Zahl aus der App in die Login-Seite eingeben – reduziert blinde Bestätigungen deutlich)
- Zusätzlicher Kontext in Push-Nachrichten (Standort, App)
- Limits für fehlgeschlagene MFA-Versuche
Diese Maßnahmen erschweren Push-Fatigue erheblich. Gegen AiTM helfen sie nicht.
Warum phishing-resistente MFA anders ist
FIDO2, Passkeys und Windows Hello for Business funktionieren grundlegend anders – und das ist der Punkt.
Wenn du dich mit einem Passkey oder WHfB bei einem Dienst anmeldest, signiert dein Gerät die Authentifizierungsanfrage kryptografisch. Dabei wird die Origin – also die genaue Domain der Website – in die Signatur einbezogen.
Das bedeutet: Eine Phishing-Seite auf m1crosoft-login.com bekommt eine Signatur, die für microsoft.com ausgestellt wurde. Die Signatur ist wertlos. Der Proxy kann nichts weiterleiten, was beim echten Dienst funktionieren würde. Es gibt kein übertragbares Geheimnis, keinen Token der auf einer anderen Domain erzeugt werden könnte.
Ein AiTM-Angriff gegen FIDO2 ist strukturell nicht möglich. Das ist kein Konfigurationsproblem, das noch gelöst werden muss – es ist ein Designmerkmal.
Was das in der Praxis bedeutet
Für Unternehmen
Wer heute Push-MFA oder TOTP einsetzt, ist besser aufgestellt als ohne MFA – keine Frage. Aber die Annahme, dass AiTM-Phishing nur große Konzerne trifft, ist falsch. Die Tools sind frei verfügbar, die Angriffe skalieren und KMU sind oft attraktive Ziele weil die Abwehr schlechter ist.
Die konkrete Empfehlung:
- Number Matching aktivieren – wenn noch nicht geschehen, sofort. Reduziert Push-Fatigue massiv und kostet nichts.
- Conditional Access: Token-Binding und Sign-in Risk – Entra ID kann risikobehaftete Anmeldungen (ungewöhnlicher Standort, verdächtige IP) automatisch blockieren oder Step-up-Authentifizierung erzwingen.
- Phishing-resistente MFA für privilegierte Accounts jetzt – Admins, PAM-Accounts, Service Accounts mit interaktivem Login. Hier ist das Schadenspotenzial am größten.
- Roadmap für flächendeckende FIDO2/WHfB-Migration – für Standard-Nutzer ist WHfB der pragmatischste Weg; kein Zusatzgerät, keine Zusatzkosten, nativ in M365 integriert.
Für Endnutzer
- Push-Benachrichtigungen nie blind bestätigen – besonders nicht wenn man sich gerade nicht aktiv angemeldet hat
- Bei mehreren unerwarteten Pushes: Passwort sofort ändern und IT informieren – das ist ein aktiver Angriff
- Passkeys aktivieren wo immer möglich – bei Google, Apple, Microsoft, GitHub und vielen weiteren Diensten ist das heute schon verfügbar
Das Sicherheitsversprechen von MFA neu einordnen
MFA ist nicht gleich MFA. Die Kategorie „Zweiter Faktor” enthält Methoden mit sehr unterschiedlichem Schutzniveau:
Nicht phishing-resistent: TOTP, SMS-OTP, E-Mail-OTP, Authenticator Push (auch mit Number Matching)
Phishing-resistent: FIDO2 / Passkeys (Hardware-Token oder synchronisiert), Windows Hello for Business, Zertifikat-basierte Authentifizierung (CBA)
Der Unterschied liegt nicht im Komfort oder der Benutzerakzeptanz – er liegt in der Architektur. Phishing-resistente Verfahren binden die Authentifizierung kryptografisch an die Origin. Das ist keine Verbesserung an einem bestehenden System; es ist ein anderes System.
Fazit
AiTM-Phishing und Push-Fatigue sind keine Edge Cases. Sie sind reale, skalierbare Angriffe die heute aktiv eingesetzt werden – und gegen die klassische MFA strukturell machtlos ist.
Das bedeutet nicht, dass TOTP oder Authenticator-Push wertlos sind. Sie schützen gegen Passwort-Angriffe ohne Phishing-Komponente und erhöhen den Aufwand für Angreifer erheblich. Aber wer glaubt, mit Push-MFA gegen gezielte Phishing-Angriffe geschützt zu sein, sitzt einem falschen Sicherheitsgefühl auf.
Die Antwort heißt FIDO2. Passkeys. Windows Hello for Business. Die Technologie ist da, sie ist produktionsreif, und in M365-Umgebungen ist der Rollout-Aufwand überschaubar.
Der beste Zeitpunkt war vor zwei Jahren. Der zweitbeste ist jetzt.
Mehr zum Thema: In den vorherigen Posts dieser Reihe haben wir Windows Hello for Business im Detail erklärt sowie einen Überblick gegeben, wo Passkeys gespeichert werden und wie man sie richtig einsetzt.