MFA wird nicht gebrochen — sie wird umgangen. Und Ihre Mitarbeiter merken es nicht.

Die Illusion der Sicherheit

Multi-Faktor-Authentifizierung galt jahrelang als Goldstandard. Passwort gestohlen? Kein Problem — der Angreifer braucht noch den zweiten Faktor. Diese Annahme ist überholt.

Adversary-in-the-Middle (AiTM) Phishing hat die Spielregeln verändert. Diese Angriffe stehlen nicht Passwort und MFA-Code getrennt. Sie fangen die gesamte Authentifizierung in Echtzeit ab — einschließlich des Session-Tokens, der beweist, dass ein Benutzer angemeldet ist.

Der Mitarbeiter macht alles richtig: prüft auf HTTPS, bestätigt die MFA-Anforderung, vermeidet verdächtige Anhänge. Und wird trotzdem kompromittiert.

---

Wie Adversary-in-the-Middle funktioniert

Klassisches Phishing bedeutete schlampige Fake-Login-Seiten mit Tippfehlern. Diese Seiten konnten MFA nicht umgehen, weil sie keine Verbindung zum echten Authentifizierungsdienst hatten.

Moderne Phishing-Seiten sind keine Fälschungen — sie sind Proxies. Tools wie Evilginx sitzen zwischen dem Benutzer und dem legitimen Dienst (Microsoft 365, Google Workspace, Okta) und leiten alles in Echtzeit weiter:

• Der Mitarbeiter gibt sein Passwort ein → Es geht an Microsoft
• Microsoft sendet die MFA-Challenge → Sie fließt über den Proxy zurück
• Der Mitarbeiter bestätigt die MFA → Der Session-Cookie wandert zurück durch den Proxy
• Der Angreifer nimmt den Session-Cookie, öffnet einen Browser auf einem völlig anderen Rechner — und ist drin

Kein fehlgeschlagener Login-Versuch. Kein MFA-Fatigue-Bombing. Kein Brute-Force-Alert. Alles sieht normal aus, weil es technisch gesehen normal war. Die Authentifizierung war echt — der Angreifer hat nur zugesehen.

---

Phishing-as-a-Service macht es zur Massenware

Das ist längst keine Nation-State-Technik mehr. Phishing-as-a-Service-Plattformen wie Tycoon 2FA, Sneaky2FA und FlowerStorm haben AiTM-Angriffe zur Massenware gemacht. Laut Barracuda werden bis Ende 2026 über 90 Prozent aller Credential-Compromise-Angriffe auf ausgefeilte Phishing-Kits setzen. Die Zahl bekannter Kits hat sich 2025 verdoppelt.

Man braucht keine Kenntnisse über Reverse Proxies. Man braucht eine Kreditkarte und ein Abonnement.

---

Drei Gründe, warum Unternehmen scheitern

1. Training für die falsche Bedrohung

Die meisten Security-Awareness-Programme lehren immer noch: Achte auf Tippfehler, prüfe die Absenderadresse, fahre mit der Maus über Links. Das war für Phishing von 2015. Bei AiTM gibt es keine Tippfehler, weil die Seite echt ist. Das SSL-Zertifikat ist gültig. Der Login-Flow verhält sich wie erwartet. Laut Push Security wird inzwischen jeder dritte Phishing-Angriff außerhalb von E-Mail ausgespielt — über LinkedIn-DMs, Google-Suche oder Teams-Nachrichten.

2. Blindes Vertrauen in Session-Cookies

Sobald MFA abgeschlossen ist, behandeln die meisten Organisationen die resultierende Session als heilig. Aber Session-Cookies sind Bearer Tokens — wer sie hat, ist der authentifizierte Benutzer. Es gibt keine Bindung zwischen dem Cookie und dem Gerät, das ihn erzeugt hat. Kein Fingerprint. Kein Anker. Forschung von Silverfort zeigt: Selbst nach erfolgreicher FIDO2-Authentifizierung bleiben viele Identity Provider anfällig für Session-Hijacking.

3. Reaktion auf Credential-Diebstahl, nicht Session-Diebstahl

Incident-Response-Playbooks sind auf kompromittierte Passwörter ausgelegt: Reset erzwingen, Tokens widerrufen, MFA neu einrichten. Aber bei AiTM ist das Passwort nicht das Problem — die Session ist es. Wer nicht alle aktiven Sessions widerruft und auf Session Replay monitort, behebt die Kompromittierung nicht wirklich.

---

Was wirklich hilft: Technische Gegenmaßnahmen

1. FIDO2 / Passkeys deployen

FIDO2-Security-Keys und Passkeys binden die Authentifizierung kryptografisch an die spezifische Domain. Kommt die Login-Anforderung von einer Proxy-Domain statt vom echten Dienst, verweigert der Key die Signatur. Das ist der einzige MFA-Mechanismus, der AiTM-Phishing strukturell blockiert.

Wichtig: Proofpoint hat gezeigt, dass ein Downgrade-Angriff gegen FIDO in Microsoft Entra ID möglich ist, indem ein nicht unterstützter Browser vorgetäuscht wird. Daher: Fallback-Authentifizierungsmethoden deaktivieren, wo immer möglich.

2. Sessions an Geräte binden (Device Compliance)

Conditional Access Policies, die verwaltete, konforme Geräte erfordern, schaffen einen Hardware-Anker, den Cookie Replay nicht umgehen kann. Stiehlt jemand einen Session-Cookie und versucht, ihn von einem nicht verwalteten Gerät abzuspielen, wird die Session beendet. Das ist eine der wirksamsten Änderungen, die Organisationen implementieren können.

3. Geo-Blocking und Country-Based Conditional Access

Die meisten AiTM-Infrastrukturen operieren aus Regionen, aus denen Ihre Mitarbeiter nie arbeiten. Geo-basierte Conditional Access Policies können Authentifizierungen aus nicht-genehmigten Ländern blockieren oder zusätzliche Verifizierung erzwingen.

In Microsoft Entra ID lässt sich das über Named Locations und Conditional Access umsetzen: Alle Anmeldungen aus Ländern außerhalb einer definierten Whitelist (z.B. Deutschland, Österreich, Schweiz) werden geblockt oder erfordern ein konformes Gerät. In Kombination mit Device Compliance entsteht ein doppelter Anker: richtiges Land UND richtiges Gerät.

Einschränkung: Geo-Blocking basiert auf IP-Geolokation, die umgangen werden kann. Angreifer nutzen zunehmend Residential Proxies im Zielland, um Geo-Blocking zu umgehen. Daher ist Geo-Blocking eine nützliche Schicht, aber niemals die alleinige Verteidigung.

4. Proxy- und VPN-Detection

Da AiTM-Angriffe über Proxy-Infrastrukturen laufen, ist die Erkennung von Proxy-, VPN- und Tor-Verbindungen eine effektive Abwehrschicht. Mehrere Ansätze:

• Microsoft Entra ID: Conditional Access kann Anmeldungen von anonymen IP-Adressen (Tor, anonyme Proxies) blockieren. Entra ID Protection erkennt “atypische Anmeldestandorte” und “unmögliche Reisen”
• IP-Reputation-Services: Dienste wie IPQualityScore, MaxMind, Spur.us oder IPinfo bewerten IP-Adressen nach Risiko — Datacenter-IPs, bekannte Proxy-Provider, Residential-Proxy-Netzwerke
• Reverse-Proxy-Fingerprinting: AiTM-Proxies hinterlassen Spuren — zusätzliche HTTP-Header, TLS-Fingerprint-Abweichungen (JA3/JA4-Hashes), minimale Latenz-Anomalien. Spezialisierte Anti-Phishing-Lösungen erkennen diese Muster
• SIEM-Korrelation: Wenn eine erfolgreiche Authentifizierung von einer IP kommt, die als Proxy/VPN/Datacenter klassifiziert ist, und gleichzeitig von einem nicht-konformen Gerät erfolgt — ist das ein hochprioritärer Alert

5. Session-Anomalie-Monitoring

AiTM-Angriffe erzeugen keine fehlgeschlagenen Logins. Sie erzeugen perfekt aussehende erfolgreiche. Die Signale liegen in dem, was nach der Authentifizierung passiert:

• Impossible Travel: Authentifizierungs-IP in München, nächste Aktivität 5 Minuten später aus Moskau
• Neue MFA-Geräteregistrierung innerhalb von Minuten nach dem Login
• Inbox-Rule-Erstellung: Angreifer erstellen E-Mail-Weiterleitungsregeln, um Evidenz zu verstecken
• Massen-Downloads: SharePoint/OneDrive-Zugriffe in ungewöhnlichem Umfang
• Token-Replay von neuer IP: Dieselbe Session taucht plötzlich von einer anderen IP auf

6. Continuous Access Evaluation (CAE)

Microsoft Continuous Access Evaluation ist ein Game-Changer: Statt Sessions bis zum Token-Ablauf laufen zu lassen, werden Änderungen (IP-Wechsel, Risikoerhöhung, Admin-Aktion) in Echtzeit an den Resource Provider kommuniziert. Eine gestohlene Session wird beim ersten IP-Wechsel sofort invalidiert — nicht erst nach einer Stunde.

CAE ist in Microsoft 365 verfügbar und sollte zusammen mit Token Protection (Preview) aktiviert werden, das Session-Tokens kryptografisch an das Gerät bindet.

7. Security Awareness neu denken

Hören Sie auf, Mitarbeitern beizubringen, Phishing-Seiten zu erkennen — gegen moderne Angriffe können sie das nicht. Stattdessen eine einfache Regel:

Wenn Sie den Login nicht selbst initiiert haben, indem Sie die URL direkt eingegeben haben — vertrauen Sie ihm nicht. Keine Login-Links in E-Mails klicken, auch wenn sie legitim aussehen. Login-Seiten bookmarken. Direkt navigieren.