MFA-Bypass-Techniken: Warum ein zweiter Faktor nicht ausreicht\n\n> Key Takeaways\n> - MFA schützt nicht gegen Session-Token-Diebstahl und Adversary-in-the-Middle-Angriffe\n> - AiTM-Phishing-Kits wie EvilGinx2 umgehen klassisches TOTP/SMS-MFA vollständig\n> - MFA Fatigue (Push Bombing) ist eine niedrigschwellige, hocheffektive Angriffstechnik\n> - Phishing-resistente MFA (FIDO2) und Conditional Access Policies sind der richtige Gegenstandard\n> - Wazuh und Microsoft Sentinel können verdächtige Authentifizierungsmuster erkennen — wenn korrekt konfiguriert\n\n## MFA ist keine Sicherheitsgarantie — nur eine Hürde\n\nZwei-Faktor-Authentifizierung gilt seit Jahren als Pflichtmaßnahme gegen Credential-Diebstahl. Wer Benutzername und Passwort hat, kommt ohne den zweiten Faktor nicht rein — so die Theorie. In der Praxis haben Angreifer mehrere Techniken entwickelt, die diese Hürde vollständig umgehen, ohne den Code jemals zu kennen oder abzufangen.\n\nDer Angriff auf Uber im September 2022 zeigte das exemplarisch: Die Gruppe Lapsus$ nutzte MFA Fatigue, um einen externen Auftragnehmer zu überwältigen. Nach Dutzenden unerwünschter Push-Benachrichtigungen gab dieser irgendwann nach. Kein Zero-Day, keine Malware. Nur Ausdauer und ein schlecht konfigurierter Authenticator.\n\nDieser Artikel beschreibt die fünf relevantesten MFA-Bypass-Techniken, erklärt wie sie funktionieren und zeigt konkrete Gegenmaßnahmen — insbesondere für Umgebungen mit Microsoft 365, Azure Entra ID und Wazuh-basiertem SIEM.\n\n## Technik 1: Adversary-in-the-Middle (AiTM) Phishing\n\nAiTM ist die technisch ausgereifteste und am häufigsten unterschätzte Methode. Das Prinzip: Ein Reverse-Proxy sitzt zwischen Opfer und legitimer Website und leitet sämtlichen Traffic — inklusive MFA-Codes und Session-Cookies — in Echtzeit weiter.\n\nSo läuft ein Angriff ab:\n\n1. Das Opfer klickt auf einen Phishing-Link und landet auf einer täuschend echten Login-Seite (z. B. login.microsoft-secure.com)\n2. Der AiTM-Proxy leitet Credentials und MFA-Code live an Microsoft weiter\n3. Microsoft antwortet mit einem gültigen Session-Cookie\n4. Der Proxy stiehlt diesen Cookie — der Angreifer hat nun eine authentifizierte Sitzung, ohne Passwort oder MFA-Code je direkt genutzt zu haben\n\nTools wie EvilGinx2, Modlishka oder Evilnginx automatisieren diesen Prozess weitgehend. Microsoft hat in mehreren MSTIC-Berichten (2022, 2023) dokumentiert, dass Angreifer auf diesem Weg gezielt Microsoft 365-Tenants kompromittierten — mit anschließenden BEC-Kampagnen (Business Email Compromise), die im Schnitt erst nach 11 Tagen entdeckt wurden.\n\nDer gestohlene Session-Token ist für die Dauer seiner Gültigkeit ohne MFA und ohne Passwort nutzbar. Token-Lebenszeiten von 24 Stunden oder mehr sind in vielen Standard-Konfigurationen die Norm.\n\nErkennungssignale in den Microsoft Entra ID Sign-in Logs:\n\n\nImpossible Travel: Anmeldung aus DE um 09:00, nächste Anmeldung aus US um 09:03\nUnbekannte IP-Adresse / Hosting-Provider (Datacenter-IP statt ISP-IP)\nUserAgent-Anomalien: bekannter Browser, abweichender UA-String\nFehlende CA-Policy-Compliance: Gerät nicht registriert trotz erfolgreicher Anmeldung\n\n\nKQL-Query für Microsoft Sentinel zur AiTM-Erkennung:\n\n```kql\nSigninLogs\n| where TimeGenerated > ago(1h)\n| where ResultType == 0\n| extend IPType = tostring(NetworkLocationDetails[0].networkType)\n| where IPType == \