Adversary-in-the-Middle-Phishing: wie EvilGinx MFA aushebelt

Mehr-Faktor-Authentifizierung sollte gestohlene Passwörter wertlos machen. Adversary-in-the-Middle-Phishing (AiTM) — populär gemacht durch Open-Source-Frameworks wie EvilGinx — hat diese Annahme leise gebrochen, indem es die Sitzung stiehlt, nicht das Passwort. Zu verstehen, wie das funktioniert, ist der erste Schritt zur Abwehr.

Was Adversary-in-the-Middle-Phishing ist

Klassisches Phishing zeigt dem Opfer einen statischen Klon einer Login-Seite und zeichnet einfach auf, was getippt wird. Es kann keinen Live-Einmalcode verarbeiten und keine echte MFA-Prüfung bestehen.

AiTM-Phishing beseitigt diese Grenze, indem es einen Reverse-Proxy zwischen Opfer und echte Seite einschiebt. Der Server des Angreifers hostet gar keine gefälschte Seite — er reicht die echte weiter:

Opfer → login.micros0ft-verify.example (Angreifer-Proxy) → login.microsoftonline.com

Jede Anfrage des Opfers wird an den legitimen Dienst weitergeleitet, jede Antwort zurückgereicht. Das Opfer sieht den authentischen Login-Ablauf — echtes Branding, echte Fehlermeldungen, echte MFA-Aufforderungen —, weil es tatsächlich mit dem echten Dienst spricht, nur über ein Relais, das alles in Übertragung mitliest.

Warum es OTP und Push schlägt

Die entscheidende Einsicht: Der Angreifer will Ihr Passwort oder Ihren Code gar nicht kennen. Er will erbeuten, was der erfolgreiche Login erzeugt: das authentifizierte Session-Cookie.

• Das Opfer gibt Benutzername und Passwort ein → an die echte Seite weitergeleitet.
• Die echte Seite stellt eine MFA-Prüfung → an das Opfer zurückgereicht.
• Das Opfer bestätigt den Push oder tippt das OTP → an die echte Seite weitergeleitet.
• Die echte Seite validiert alles und liefert ein Session-Token → der Proxy fängt es ab.

Zu diesem Zeitpunkt hat das OTP seine Aufgabe bereits erfüllt und ist als Wiederholung wertlos. Der Angreifer importiert das gestohlene Cookie in den eigenen Browser und ist als der Nutzer angemeldet — kein Passwort, kein Code, keine zweite Aufforderung. Deshalb fallen SMS-Codes, TOTP-Authenticator-Apps und Push-Freigaben allesamt vor einem kompetenten AiTM-Aufbau: jedes ist ein geteiltes Geheimnis, zu dessen Echtzeit-Weitergabe der Mensch verleitet werden kann.

Die MFA-Aufforderung, die das Opfer bestätigt hat, war echt. Genau das macht AiTM so wirksam — für den Nutzer sieht nichts falsch aus und für den Identitätsanbieter auch nicht.

Warum bestehende Abwehr sich schwertut

• Die Domain ist oft brandneu. Frisch registrierte, ähnlich aussehende Domains haben keine Reputationshistorie zum Markieren.
• TLS sieht legitim aus. Der Proxy liefert ein gültiges Zertifikat; das Schloss ist da.
• Der Inhalt ist echt. Signaturbasiertes Scannen findet nichts Gefälschtes zum Abgleich, weil die Seite die echte ist, weitergereicht.
• Erkennungsfenster sind kurz. Kits nutzen Anti-Analyse-Filter, Einmal-Links und Geofencing, sodass eine URL, die für das Opfer aktiv war, einem ermittelnden SOC eine harmlose Seite zurückgibt.

Die echte Lösung: phishing-resistente MFA

AiTM funktioniert, weil der zweite Faktor durch den Angreifer läuft. Nehmen Sie diese Möglichkeit weg, und der Angriff bricht zusammen. FIDO2 / WebAuthn und Passkeys binden die Zugangsdaten kryptografisch an genau den Web-Ursprung, für den sie registriert wurden:

Zugangsdaten registriert für : https://login.microsoftonline.com
Browser sieht Ursprung       : https://login.micros0ft-verify.example
→ Ursprungs-Mismatch → der Authenticator verweigert die Signatur → Login scheitert

Es gibt keinen Code zum Weiterreichen und kein Cookie zum Abgreifen, weil die Anmeldung gegen den falschen Ursprung nie gelingt. Der Browser erzwingt das — nicht der Nutzer. Ergänzende Kontrollen härten den Rest:

• Conditional Access, das Sitzungen an Gerätekonformität und verwaltete Netzwerke bindet.
• Token-Schutz / Continuous Access Evaluation, um den Wert eines gestohlenen Cookies zu senken.
• Schnelle Erkennung frisch registrierter ähnlich aussehender Domains per Certificate-Transparency-Monitoring.

Das Ziel ist phishing-resistente MFA als erforderlich, nicht bloß verfügbar — jeder phishbare Rückfallweg ist ein Pfad, zu dem Angreifer die Nutzer lenken.

Wie GottaPhish AiTM-Simulationen automatisiert

AiTM-Angriffe schlagen OTP- und Push-MFA, indem sie die Sitzung in Echtzeit weiterreichen, und kein Proxy und kein Filter allein schließt diese Lücke zuverlässig. GottaPhish und sein Expertenteam reproduzieren Adversary-in-the-Middle-Szenarien automatisch und sicher innerhalb autorisierter Simulationen — es gibt keine Angreifer-Infrastruktur, die Ihr Team aufsetzen, hosten oder abbauen muss. Wir zeigen mit vollständiger Auditierung, wie OTP- und Push-MFA vor einem echten Proxy fallen, während phishing-resistente Zugangsdaten halten, und geben Ihnen messbare Expositionsdaten je Nutzer, Abteilung und Rolle; unsere Fachleute helfen beim Entwerfen der Szenarien, beim Aufsetzen der Kampagnen und beim Deuten der Ergebnisse. Dieser Beleg macht den Business Case für FIDO2/Passkeys konkret, und unser Reporting verfolgt die Adoption neben Ihren Klick- und Melderaten, sodass Sie belegen können, dass die phishbare Lücke sich wirklich schließt — nicht bloß, dass eine Richtlinie auf dem Papier existiert.