Warum klassische MFA weiterhin gegen Adversary-in-the-Middle-Angriffe verliert

Multifaktor-Authentifizierung (MFA) bleibt einer der nützlichsten Fortschritte gegenüber Passwörtern allein. Sie blockiert den Großteil automatisierten Stuffings und viele einfache Phishing-Seiten, die nur ein Passwort abgreifen. Phishing-sicher ist sie damit nicht. Im April 2026 hat das britische National Cyber Security Centre (NCSC) klassische MFA mit FIDO2-Credentials und Passkeys für den privaten Gebrauch verglichen und eine klare Lücke gezeigt: Adversary-in-the-Middle-Phishing (AitM) schlägt weiterhin Passwort plus SMS, TOTP, Push-Freigaben oder E-Mail-Codes – FIDO2 nicht.

Dieser Artikel erklärt die Lücke praxisnah und warum der Umstieg wertvoller Konten auf Passkeys wichtiger ist als noch ein weiterer SMS-Code.

MFA hat Stuffing gebremst — nicht Phishing-Proxys

Credential Stuffing funktioniert, weil Menschen Passwörter wiederverwenden. Sobald ein Passwort aus einer Breach durchsickert, testen Angreifer es bei E-Mail, Banken, Shops und Cloud-Diensten. Ein zweiter Faktor stoppt dieses Muster: Das gestohlene Passwort reicht nicht mehr.

Dieser Erfolg hat ein irreführendes mentales Modell geschaffen. Viele hörten, MFA „stoppt Phishing“. Gegen eine statische Fake-Login-Seite, die nur ein Passwort sammelt, hilft MFA oft. Gegen einen Live-Phishing-Proxy zwischen Ihnen und der echten Site scheitert klassische MFA meist. Branchenberichte nennen MFA oft als Blocker der großen Mehrheit automatisierter Kontoübernahmen; diese Zahl beschreibt Stuffing und wenig raffinierten Diebstahl, nicht AitM-Sitzungsdiebstahl.

So funktioniert Adversary-in-the-Middle-Phishing

Bei einem AitM-Angriff landet das Opfer auf einer täuschend echten Site unter Kontrolle des Angreifers. Das ist kein einfaches Formular. Es ist ein Reverse-Proxy, der jede Anfrage in Echtzeit an den echten Dienst weiterleitet.

Sie geben Benutzername und Passwort ein. Der Proxy schickt sie an die echte Site. Die echte Site verlangt einen zweiten Faktor. Sie tippen den SMS-Code, Authenticator-Code, E-Mail-OTP ein oder bestätigen eine Push-Aufforderung. Der Proxy leitet auch das weiter. Sobald die echte Site ein Sitzungscookie oder Token ausstellt, kopiert der Angreifer es und übernimmt die authentifizierte Sitzung – oft ohne das Passwort danach noch zu brauchen.

• Der Angreifer muss MFA-Kryptografie nicht „brechen“. Er wartet, bis Sie eine gültige Anmeldung abschließen.
• Das gestohlene Artefakt ist meist das Sitzungscookie oder Bearer-Token, nicht nur das Passwort.
• Werkzeuge im Stil von Evilginx haben diese Taktik für Kriminelle breit verfügbar gemacht.

Warum SMS, TOTP, Push und E-Mail-OTP alle gegen AitM scheitern

Diese zweiten Faktoren beweisen, dass jemand eine Nachricht empfangen, einen rotierenden Code lesen oder auf „Genehmigen“ tippen konnte. Sie beweisen nicht, dass der Browser, der mit der echten Website spricht, Ihrer ist.

• SMS-OTP: Der Code ist ein kurzlebiger gemeinsamer Geheimwert. Tippen Sie ihn in eine proxierte Seite, erhält der Angreifer einen funktionierenden Login.
• Authenticator-TOTP: dasselbe Problem. Der sechsstellige Code gilt kurzzeitig sowohl für die echte Site als auch für den Phishing-Proxy.
• Push-Freigaben: „Waren Sie das?“ zu bestätigen schließt den Login des Angreifers ab, sofern die Meldung kein starkes Number Matching hat und Sie die Quelle nicht sorgfältig prüfen.
• E-Mail-OTP: ein weiterer weiterleitbarer Code. Hat der Angreifer bereits das Passwort und kann den zweiten Schritt erzwingen, bindet die E-Mail-Zustellung den Login nicht an den echten Origin.

Fatigue-Angriffe und SIM-Swap als weitere Schwächen klassischer MFA

AitM ist nicht der einzige Weg, auf dem klassische MFA scheitert. Fatigue-Angriffe bombardieren Push-Benachrichtigungen, bis jemand eine annimmt, um die Störung zu beenden. SIM-Swap und SMS-Abfangen stehlen Codes, bevor sie Sie erreichen.

Der NCSC-Vergleich behandelt diese Szenarien als weitere Gründe, warum klassische MFA über den Credential-Lebenszyklus hinweg schwächer ist als FIDO2. Selbst ohne Phishing-Klick bleiben Push-Fatigue und SIM-Missbrauch realistische persönliche Bedrohungen.

• Push-Fatigue gelingt, weil „Genehmigen“ einfach ist und die Meldung oft wenig Kontext hat.
• SIM-Swap zielt auf die Telefonnummer, die SMS-Codes empfängt, nicht auf das Passwort selbst.
• Diese Fehlschläge bestätigen dieselbe Lektion wie AitM: Ein Faktor, der erzwungen, weitergeleitet oder umgeleitet werden kann, ist nicht phishing-resistent.

Warum FIDO2 und Passkeys AitM widerstehen

FIDO2-/WebAuthn-Credentials – einschließlich Passkeys – sind an den echten Website-Origin gebunden. Ihr Authenticator schließt eine Zeremonie für evil-bank.example nicht ab, wenn das Credential zu bank.example gehört.

Der private Schlüssel verlässt den Authenticator nie (bzw. den geschützten Sync-Fabric bei synchronisierten Passkeys). Die Site erhält eine Signatur über eine Challenge mit Origin-Information, kein wiederverwendbares Geheimnis, das man in einen Proxy tippen könnte.

Deshalb markiert die NCSC-Tabelle Adversary-in-the-Middle-Phishing gegen klassische MFA als immer erfolgreich und gegen FIDO2-Credentials im bewerteten privaten Bedrohungsmodell als nie erfolgreich.

• Origin-Binding verhindert die Nutzung des Credentials auf Lookalike-Domains.
• Es gibt kein kurzes OTP, das der Angreifer in Echtzeit weiterleiten kann.
• Sitzungsdiebstahl über proxierte 2SV-Abschlüsse ist nicht mehr derselbe Angriffspfad.

Die Übergangs-Falle: MFA-Downgrade, solange Passwörter als Fallback bleiben

Selbst wenn ein Dienst Passkeys unterstützt, behalten viele Konten weiterhin Passwort plus schwächere MFA als Backup. Angreifer wissen das. MFA-Downgrade-Angriffe steuern das Opfer auf den schwächeren Pfad: Passwort-Reset, „auf andere Weise anmelden“, SMS statt Sicherheitsschlüssel oder ein Recovery-Flow, der nie die Passkey-Abfrage zeigt.

Während der langen Koexistenz von Passwörtern und Passkeys entscheidet oft der schwächste erlaubte Pfad über das echte Sicherheitsniveau. Eine Passkey hilft nur, wenn Sie auch Downgrade-UX widerstehen und Recovery-Optionen so sorgfältig behandeln wie den Primärlogin.

Was Sie jetzt tun sollten

Sie müssen nicht warten, bis jede Website passwortlos wird. Priorisieren Sie die Konten, die alles andere freischalten, und härten Sie danach den Rest.

• Bevorzugen Sie Passkeys oder Sicherheitsschlüssel für E-Mail, Passwortmanager, Banking, Cloud und Entwicklerkonten. Starten Sie mit unserem Passkeys-Leitfaden.
• Wo Push-MFA bleibt, nutzen Sie Number Matching und behandeln Sie unerwartete Aufforderungen als feindlich.
• Vermeiden Sie SMS als primären zweiten Faktor, wenn eine bessere Option existiert.
• Solange ein Konto keine Passkeys anbietet, nutzen Sie ein einzigartiges langes Passwort aus einem Passwortmanager – Stuffing lebt von Wiederverwendung.
• Prüfen Sie Recovery-Optionen, damit „Passwort vergessen“ oder „andere Methode“ die Phishing-Resistenz nicht stillschweigend aufheben.