MFA-Bypass-Techniken: Warum ein zweiter Faktor nicht ausreicht\n\n> Key Takeaways\n> - Adversary-in-the-Middle-Phishing (AiTM) umgeht klassische MFA vollständig — ohne das Passwort des Opfers zu kennen\n> - MFA Fatigue ist kein Randproblem: Mehrere hochkarätige Einbrüche der letzten Jahre wurden durch Push-Bombing ermöglicht\n> - Phishing-resistente Verfahren wie FIDO2/Passkeys sind der einzig zuverlässige Schutz gegen AiTM\n> - Conditional Access in Microsoft Entra ID ist keine optionale Härtungsmaßnahme, sondern Basisanforderung nach NIS-2\n> - Ohne zentrales Logging auf Session-Ebene bleiben kompromittierte Konten oft wochenlang unentdeckt\n\n---\n\n## Warum MFA allein nicht mehr reicht\n\nMulti-Faktor-Authentifizierung gilt zu Recht als einer der wirksamsten Schutzmaßnahmen gegen Credential-basierte Angriffe. Das BSI empfiehlt sie explizit, NIS-2 setzt sie voraus, und Cyberversicherungen machen sie zur Bedingung. Trotzdem taucht MFA in Incident-Reports als überwundene Barriere auf — nicht als verhinderte Einbruchsstelle.\n\nDer Grund ist konzeptionell: MFA schützt den Authentifizierungsvorgang. Es schützt nicht die Session danach, nicht vor Proxys, die Authentifizierung in Echtzeit weiterleiten, und nicht vor Nutzern, die durch Wiederholung mürbe gemacht werden. Angreifer brechen MFA heute nicht — sie gehen daran vorbei.\n\nDieser Artikel beschreibt die vier praktisch relevantesten MFA-Bypass-Techniken, zeigt konkrete Erkennungsansätze in Microsoft Entra ID und Wazuh und erklärt, welche Gegenmaßnahmen tatsächlich wirken.\n\n---\n\n## Technik 1: Adversary-in-the-Middle-Phishing (AiTM)\n\n### Wie der Angriff funktioniert\n\nAiTM ist die wirksamste und am häufigsten eingesetzte Methode, MFA zu umgehen. Ein Reverse-Proxy sitzt zwischen dem Opfer und dem echten Dienst — etwa Microsoft 365. Der Angreifer sieht den gesamten Datenverkehr in Echtzeit, inklusive der Session-Cookies, die nach erfolgreicher Authentifizierung ausgestellt werden.\n\nDas Open-Source-Framework Evilginx2 ist das bekannteste Werkzeug für solche Angriffe. Es klont die Login-Seite des Zieldienstes, leitet alle Eingaben transparent weiter und extrahiert dabei Session-Tokens.\n\nTypischer Ablauf gegen Microsoft 365:\n\n1. Opfer erhält eine Phishing-E-Mail mit einem Link zu login.microsoftonline.com.attacker-domain.com\n2. Evilginx2 proxied die echte Microsoft-Login-Seite in Echtzeit\n3. Opfer gibt Benutzername und Passwort ein — wird transparent an Microsoft weitergeleitet\n4. Microsoft fordert MFA an — Opfer bestätigt per Authenticator-App oder SMS\n5. Microsoft stellt einen Session-Cookie aus — Evilginx2 fängt diesen ab\n6. Angreifer injiziert den Cookie in seinen Browser: vollständiger Kontozugang, kein weiterer Schritt nötig\n\nDas Passwort des Opfers ist für den Angreifer weitgehend irrelevant. Der Session-Cookie reicht.\n\n### Erkennung in Microsoft Entra ID\n\nVerdächtige Logins lassen sich über die Sign-in Logs identifizieren. Relevante Indikatoren sind Login-IPs aus Hosting-Providern oder anonymisierten Netzen, unbekannte User Agents sowie Token-Replay — ein Session-Token wird kurz nach Ausstellung von einer anderen IP genutzt.\n\nEin KQL-Query für Microsoft Sentinel:\n\n```kql\nSigninLogs\n| where ResultType == 0\n| where NetworkLocationDetails has \