AiTM-Phishing und MFA-Bypass

Wie der Angriff abläuft

AiTM (manchmal auch „Man-in-the-Middle-Phishing") nutzt einen Reverse-Proxy zwischen Opfer und echter Anmeldeseite. Die gefälschte Seite, die das Opfer sieht, ist kein statischer Klon — sie ist eine live durchgeschleifte Version der echten Seite.

Schritt für Schritt:

1. Opfer klickt auf Phishing-Link. Browser landet auf z. B. login.microsoftt-online.com (gefälschte Domain). Hinter dieser Domain läuft ein Reverse-Proxy mit Evilginx/EvilProxy.
2. Reverse-Proxy holt die echte Microsoft-Login-Seite und reicht sie an das Opfer durch. Das Opfer sieht ein echtes Microsoft-Login — Layout, Sprache, Fehlermeldungen, Cookies, alles wie original.
3. Opfer gibt Benutzername und Passwort ein. Daten fließen durch den Proxy zur echten Microsoft-Seite. Microsoft verifiziert, schickt die TOTP-Abfrage oder Push-Bestätigung.
4. Opfer beantwortet 2FA auf der echten Seite (durch den Proxy). Microsoft prüft, OK.
5. Microsoft gibt ein Session-Cookie aus — dieser Cookie geht durch den Proxy. Der Angreifer hat eine vollständige, gültige Session des Opfers. Mit diesem Cookie kann er sich direkt einloggen, ohne erneut Passwort oder 2FA zu brauchen.
6. Opfer wird auf eine harmlose Seite weitergeleitet und merkt im Idealfall nichts.

Der Angriff hat nicht das Passwort gestohlen (das war früher das Ziel) — er hat die bereits authentifizierte Session gestohlen. Damit greift fast jede Verteidigung ins Leere, die nur das Authentifizierungs-Moment absichert.

Welche 2FA-Verfahren versagen — und welche nicht

Die entscheidende Unterscheidung:

Der entscheidende Punkt: FIDO2 und Passkeys binden die Signatur an die Browser-Origin. Wenn das Opfer auf login.microsoftt-online.com ist und der Hardware-Key signieren soll, fließt diese gefälschte Domain in die Signatur ein. Die echte Microsoft-Seite — die der Proxy im Hintergrund anspricht — erwartet aber die Signatur für login.microsoft.com. Die Signatur passt nicht, der Login schlägt fehl, der Cookie wird nicht ausgegeben. AiTM scheitert strukturell.

Das ist nicht eine Frage von „besseren Filtern" oder „mehr Aufmerksamkeit" — es ist eine Frage der Protokoll-Architektur. Genau deshalb empfehlen heute FBI, CISA, NIST, BSI und alle großen Cloud-Anbieter (Microsoft, Google, Cloudflare) FIDO2 als einzigen wirklich phishing-resistenten Faktor.

Die Toolkits

Evilginx ist das bekannteste Open-Source-AiTM-Toolkit. 2017 von Kuba Gretzky veröffentlicht, seit 2022 in Version 3.x mit vielen vorgefertigten „Phishlets" für Microsoft 365, Google Workspace, Okta, Facebook, GitHub und Dutzende andere Dienste. Wird offiziell als Pentest-Werkzeug entwickelt — wie viele Pentest-Tools wird es trotzdem aktiv von Angreifern eingesetzt.

EvilProxy ist ein Phishing-as-a-Service auf der gleichen technischen Basis, gemietet im Untergrund. Hat 2022/23 mehrere große Kampagnen ermöglicht — die Resecurity-Veröffentlichungen 2022 dokumentieren Mietpreise von 150 USD pro Woche. Damit hat AiTM die Hürde von „muss man selbst hosten" auf „muss man bezahlen" gesenkt.

Modlishka ist ein älteres Toolkit (2018, Piotr Duszyński), das das technische Prinzip in Polen populär gemacht hat.

Wichtig zur Einordnung: AiTM ist kein neuartiger Trick, sondern eine technische Generalisierung. Was diese Toolkits ändern, ist die Skalierbarkeit: Was vor zehn Jahren spezialisierte Pentester konnten, ist heute Mietservice.

Wie eine kompromittierte Session ausgenutzt wird

Sobald der Angreifer das Session-Cookie hat, hat er dieselben Rechte wie das Opfer — solange das Cookie gültig ist. Typische Folge-Aktionen, oft automatisiert:

• Mail-Filter-Regeln einrichten. Eingehende Sicherheits-Mails (Microsoft, Bank, Recovery-Benachrichtigungen) werden in einen unbeachteten Ordner verschoben. Das Opfer merkt verdächtige Aktivität nicht.
• OAuth-Apps autorisieren. Stellt langfristigen Zugriff sicher, der die einzelne Session überlebt.
• Datenexport. Mailbox-Search, OneDrive-Download, SharePoint-Sammlung — alles, was die Identität des Opfers erlaubt.
• Internes Spear-Phishing. Aus dem Account gehen Mails an Kolleg:innen — meist über die echte Mail-Identität, daher sehr glaubwürdig. Die häufigste Folge: kompromittierte Account-Identität führt zu mehr kompromittierten Accounts.
• Vendor-EC. Mails an Lieferanten oder Kunden mit IBAN-Wechsel-Anweisungen, um BEC-Schäden zu erzeugen.
• Persistenz über App-Passwörter. Wenn der Dienst App-spezifische Passwörter unterstützt, generiert der Angreifer eines — das umgeht künftige 2FA-Schritte.
• Privileged-Access-Eskalation. Wenn der gekapertes Account Admin-Rechte hat, werden weitere Konten kompromittiert.

Das Cookie ist meist mehrere Stunden bis Tage gültig. In dieser Zeit hat der Angreifer freien Lauf, außer der Dienst hat zusätzliche Kontroll-Mechanismen wie Risk-based-Authentication oder Conditional Access.

---

Verteidigung: was wirklich wirkt

Drei Schichten:

1. FIDO2 / Passkeys statt TOTP für kritische Konten. Der einzige strukturelle Schutz. Microsoft, Google, Apple, Cloudflare, GitHub, AWS unterstützen alle FIDO2/WebAuthn. Cloudflare hat 2022 nach einem eigenen AiTM-Angriff komplett auf Hardware-Keys umgestellt — die Mitarbeitenden, die phishing-relevante Mails öffneten, bemerkten den Phish-Versuch nicht; die FIDO2-Keys haben den Angriff trotzdem strukturell verhindert. Dieser Fall ist in der Cloudflare-Blog-Post zum 2022-Twilio-Lapsus-Incident detailliert dokumentiert.

2. Risk-based / Conditional Access. Erkennt anomale Logins und verlangt zusätzliche Verifikation oder blockt:

• Geo-Anomalie — Login aus einer neuen Region.
• Unknown Device / Unknown Browser-Fingerprint.
• Impossible Travel — Login aus Deutschland und 30 Minuten später aus Brasilien.
• Risk-Score über Schwellwert.

Microsoft Entra Conditional Access, Okta Adaptive MFA, Google Context-Aware Access bieten das. Vertieft im Artikel autorisierung-grundlagen.

3. Session-Hardening.

• Kurze Session-Lebensdauer für kritische Anwendungen — täglich neu authentifizieren.
• Re-Auth bei sensitiven Aktionen (Passwort-Wechsel, OAuth-App-Genehmigung, Massen-Export) — der Cookie allein reicht dann nicht mehr.
• Token-Binding (Cloudflare bietet das als „Cloudflare Access Token Binding") — bindet Tokens an spezifische Geräte/IPs.
• Pinned Session-Cookies — Cookies mit HttpOnly + Secure + SameSite=Strict + kurzem TTL, sodass Cookies-Diebstahl schwerer ist.

4. Detection auf Sign-In-Events. Logging und Alarmierung auf:

• Neue OAuth-Apps mit erweiterten Rechten.
• Neue Mail-Forward-Regeln.
• Login aus neuem Land oder mit neuem Gerät.
• Mehrfache fehlgeschlagene + dann erfolgreiche Logins (oft Indikator für AiTM).
• Token-Refresh aus ungewöhnlichen IP-Bereichen.

5. URL-Filterung im Mail-Gateway + Browser-Schutz.

• Microsoft Defender for Office 365 mit Safe Links.
• Mimecast / Proofpoint URL-Rewriting.
• Browser-Schutz (Google Safe Browsing, Microsoft SmartScreen) — fängt einen Teil der neuen Phishing-Domains.

Nicht hilfreich (oder nur als Teil eines größeren Stacks):

• Bloße Awareness-Trainings — die AiTM-Seite sieht 1:1 wie das Original aus, weil sie das Original durchschleift. Erkennung über „auf die Optik achten" funktioniert nicht.
• DMARC/SPF/DKIM — wirkt gegen gefälschten Absender, nicht gegen Phishing-Domain mit eigenem DKIM-Setup.

Für Privatpersonen

Was du als Einzelperson tun kannst:

• Auf kritische Konten Hardware-Keys. Mail-Hauptkonto, Apple ID / Google / Microsoft, Bank, Passwort-Manager. Zwei Keys (Alltag + Backup) — siehe zwei-faktor-und-mfa.
• Passkeys aktivieren, wo verfügbar. Sind FIDO2 mit Sync — gleicher Phishing-Schutz wie Hardware-Keys, deutlich höherer Komfort.
• Login niemals über Mail-Link. Wenn deine Bank dir eine Mail schickt, in der du dich „einloggen" sollst: nicht klicken, eigene Bookmark oder App nutzen.
• Verdächtige Login-Push-Benachrichtigungen sehr ernst nehmen. „Wurde dieser Login auf [unbekanntem Gerät] versucht?" — ablehnen, dann Passwort wechseln und Sessions abmelden.
• Aktive Sessions regelmäßig prüfen. Siehe session-und-geraete-verwaltung.

Aus Entwickler-Sicht: was beim Bau hilft

Wer Web-Anwendungen baut, kann strukturell verhindern, dass Konten anfällig sind:

• FIDO2/WebAuthn als bevorzugte 2FA-Methode anbieten. Auch wenn TOTP weiter unterstützt wird — Passkey im Onboarding-Flow vorschlagen.
• Origin-strikte Cookies mit SameSite=Strict für Session-Cookies, HttpOnly, Secure, kurze Lebensdauer.
• Token-Binding wo möglich (DBSC — Device Bound Session Credentials, ein aufkommender Standard).
• Risk-based Login-Bewertung mit Anomalie-Detektion.
• Re-Authentifizierung für sensitive Aktionen (Passwort-Wechsel, Auszahlungs-Anweisungen, OAuth-Erlaubnisse).
• CSP mit connect-src und frame-ancestors — verhindert, dass die Anmeldeseite in einen Iframe in fremder Origin gelegt wird.
• Logging aller Auth-Events — Login-Erfolg, -Fehler, Token-Refresh, OAuth-App-Erstellung — mit Anomalie-Alarm.

Vertieft in den Entwickler-Kapiteln, insbesondere Authentifizierung (Entwickler) und Webauthn und Passkeys.

Besonderheiten

Cloudflare-Twilio-Lapsus-Welle 2022 als Wendepunkt

Im Juli/August 2022 wurden über 130 Unternehmen Opfer einer einheitlichen AiTM-Phishing-Welle (Cloudflare, Twilio, Mailchimp, Doordash u. a.). Cloudflare verhinderte den Schaden durch konsequenten Hardware-Key-Einsatz; Twilio nicht. Der Vorfall hat in der Branche die Trendwende zugunsten FIDO2 beschleunigt — viele Unternehmen haben innerhalb 12 Monaten ihre Auth-Strategien umgestellt.

Microsoft hat 2022 explizit auf AiTM hingewiesen

In der Threat-Intel-Veröffentlichung beschrieb Microsoft eine AiTM-Welle, die innerhalb weniger Monate über 10 000 Organisationen erreicht hat. Die Verteilung war Massen-Scale — AiTM ist kein Nischen-Angriff mehr.

EvilProxy-Mietpreise verraten den Geschäftsbetrieb

Resecurity dokumentierte 2022 Preise: 150 USD/Woche, 250 USD/14 Tage, 400 USD/Monat — inklusive vorgefertigter Phishlets für Microsoft, Google, Apple ID, GitHub. Der Service-Charakter (Tickets, Support, Updates) zeigt, wie professionalisiert dieser Markt ist.

FIDO2-Erkenntnisse: Origin-Bindung ist die ganze Geschichte

Die Schutzwirkung von FIDO2 basiert auf einem einzigen Detail: in den signierten Daten steckt die echte Browser-Origin. Phishing-Domain → andere Origin → Signatur wird vom echten Dienst nicht akzeptiert. Es ist keine Frage von "besser" oder "schlechter" — es ist strukturell anders. Kein Software-Update wird TOTP jemals AiTM-resistent machen.

Browser-Schutz fängt einen Teil — aber nicht zuverlässig

Google Safe Browsing und Microsoft SmartScreen melden viele AiTM-Domains innerhalb von Stunden bis Tagen nach Auftauchen. Aber: Angreifer rotieren Domains schnell, ein frischer Phish hat oft 30–60 Minuten unentdeckter Lebenszeit. Verlass nicht auf Browser-Warnungen als alleinigen Schutz.

DBSC – Device Bound Session Credentials kommen

Eine neue Browser-Technologie (Vorschlag von Google, Chrome-Entwicklung 2024/25) bindet Session-Cookies kryptografisch an das Endgerät — gestohlene Cookies wären auf einem anderen Gerät unbrauchbar. Wenn DBSC sich durchsetzt, würde es einen wichtigen Layer gegen AiTM-Sessions-Diebstahl hinzufügen. Stand Mitte 2026: in Chrome experimentell verfügbar.

Risk-Based-Auth ist nicht trivialer Ersatz

Conditional-Access-Setups sind mächtig — aber pflegeintensiv. False Positives (legitime Reisen, neue Geräte, neue Netzwerke) führen zu Frustration; zu aufgeweichte Regeln schützen wenig. Sinnvoll ist ein Stack: FIDO2 als Erst-Schutz, Conditional Access als Zusatz-Schicht für Anomalien.

Weiterführende Ressourcen

Externe Quellen

• Cloudflare – "The mechanics of a sophisticated phishing scam" (2022)
• Microsoft – "From cookie theft to BEC: AiTM phishing sites" (2022)
• Resecurity – EvilProxy Phishing-as-a-Service
• Evilginx GitHub – offizielle Pentest-Doku
• FIDO Alliance – Phishing-Resistent Authentication
• CISA – Implementing Phishing-Resistant MFA
• NIST SP 800-63B – Authenticator Assurance Levels
• BSI – Lagebericht zur IT-Sicherheit in Deutschland

Verwandte Artikel

• Social Engineering Grundlagen
• Phishing erkennen
• Spear-Phishing und CEO-Fraud
• Smishing und Vishing
• Phishing melden und nach Klick reagieren
• Zwei-Faktor und MFA
• Passkeys
• Session- und Geräte-Verwaltung