Warum dies ein wichtiges Thema ist
Viele Unternehmen setzen mittlerweile auf MFA (Mehrfaktor-Authentifizierung), um Benutzerkonten besser zu schützen und die Anforderungen ihrer Sicherheitsstrategie zu erfüllen. Doch Angreifer haben längst gelernt, wie sie diese zusätzliche Schutzebene austricksen können ohne sie technisch zu „brechen“.
Das Zauberwort heißt: AiTM-Phishing (Adversary-in-the-Middle „Angreifer in der Mitte“).
Und genau das passiert: Der Angreifer stellt sich einfach zwischen Nutzer und echten Login-Dienst und leitet alles weiter.
„Das Tückische daran ist: Der Nutzer macht alles richtig und wird trotzdem Opfer.“
Ich sehe das in der Praxis immer wieder: Selbst erfahrene Administratoren, die jahrelang Sicherheitskonzepte umsetzen, geraten in diese Falle. Nicht, weil sie unaufmerksam sind, sondern weil der Angriff psychologisch perfekt orchestriert ist. Es fühlt sich alles „echt“ an. Es ist kein Tippfehler in der Domain, keine grobe Fälschung sondern ein nahtloser Zwischenserver, der jeden Tastendruck und jede Bestätigung spiegelt.
Was genau passiert bei einem AiTM-Phishing?
Stell dir vor, du klingelst an deiner eigenen Haustür, gibst dein Passwort ein und bestätigst deine MFA-Anfrage aber jemand steht zwischen dir und der Tür, reicht deine Eingaben brav weiter und nimmt dir am Ende den Schlüssel (Session-Cookie) ab. Genau das geschieht bei einem AiTM-Angriff im digitalen Raum.
Ein sogenannter Reverse-Proxy (Zwischenserver) imitiert die echte Login-Seite. Der Nutzer sieht nichts Verdächtiges: Die Seite sieht vertraut aus, die MFA-Abfrage erscheint ganz normal. Doch im Hintergrund läuft der gesamte Login-Prozess über den Server des Angreifers.
Dieser liest:
Benutzername und Passwortden zweiten Faktor (z. B. Push-Bestätigung, SMS-Code)und vor allem: das Session-Cookie (Sitzungsnachweis), das nach erfolgreicher Anmeldung vom echten System ausgestellt wird.
Mit diesem Cookie kann der Angreifer die Sitzung übernehmen ohne nochmal MFA durchlaufen zu müssen.
So läuft der Angriff Schritt für Schritt ab
Vorbereitung: Der Angreifer erstellt eine täuschend echte Phishing-Domain (Fakeseite) und setzt einen Reverse-Proxy auf (z. B. EvilProxy, Caffeine, Tycoon 2FA).Köder: Das Opfer erhält eine E-Mail mit einem scheinbar legitimen Login-Link („Ihr Dokument wartet auf Freigabe“).Verbindung: Der Nutzer öffnet den Link sieht eine echte Login-Maske (die der Proxy im Hintergrund lädt).Eingabe: Benutzername und Passwort werden eingegeben der Proxy leitet sie live an den echten Dienst weiter.MFA-Abfrage: Der echte Dienst fordert die MFA an (z. B. Push, SMS oder Einmalcode). Der Proxy zeigt sie ebenfalls an.Bestätigung: Der Nutzer bestätigt der echte Dienst akzeptiert und stellt eine gültige Session aus.Session-Diebstahl: Der Angreifer fängt das Session-Cookie ab und nutzt es auf seinem eigenen Gerät.
Ergebnis: Der Angreifer ist vollständig eingeloggt trotz MFA. Von hier aus kann er E-Mails weiterleiten, Regeln setzen, Daten exfiltrieren oder interne Phishing-Kampagnen starten.
🚨 Warum MFA allein hier nicht reicht
Viele MFA-Verfahren sind nicht „origin-gebunden“ das heißt, sie prüfen nicht, von welcher Webseite die Authentifizierungsanfrage stammt. Der Proxy kann die Anfrage einfach weiterleiten und den Rückkanal übernehmen.
Dazu kommt:
Session-Tokens (Cookies) sind oft zu lange gültig.Push-Fatigue: Wiederholte MFA-Prompts führen dazu, dass Nutzer irgendwann „Zulassen“ klicken.Ausnahmen: Manche Konten oder IP-Bereiche sind von MFA befreit das sind offene Türen.
Bezug zum ISMS wie AiTM im Rahmen von ISO 27001 und TISAX einzuordnen ist
Im ISMS (Informationssicherheits-Managementsystem) wird das Thema AiTM-Phishing in mehreren Kontrollen und Phasen abgedeckt. Bereits in der Risikobeurteilung (ISO 27001 Kap. 6.1 / TISAX 1.2.1) sollte die Bedrohung „Kontoübernahme trotz MFA durch AiTM-Angriff“ als Risiko identifiziert und mit passender Maßnahme hinterlegt werden.
Die konkrete Umsetzung findet sich u. a. in folgenden Controls wieder:
A.5.15 / Benutzeridentifizierung und Authentifizierung, fordert sichere, mehrstufige Authentifizierungsmethoden; hier ist phish-resistente MFA (z. B. FIDO2/WebAuthn) eine anerkannte Maßnahme.
A.8.23 / Sicherheitsüberwachung, Detection & Monitoring von verdächtigen Logins, Anomalien („Impossible Travel“) und Session-Reuse.
A.5.18 / Zugriff auf Netzwerke und Systeme, Umsetzung von Conditional Access und Zero Trust.
A.6.3 / Informationssicherheit bei der Nutzung von Cloud-Diensten, adressiert Cloud-Login-Szenarien wie Microsoft 365.
A.6.1 / Technische Verwundbarkeiten managen, gilt auch für unsichere MFA-Implementierungen.
A.5.32 / Schulung und Bewusstsein, Awareness gegen Social Engineering und MFA-Missbrauch.
Im TISAX-Kontext ist das vor allem in den Controls
1.4.2 (Authentisierung und Zugriffsschutz), 1.4.3 (Sitzungsverwaltung) und 5.1.1 (Bewusstseinsbildung) relevant.
Ein reifes ISMS bewertet solche Szenarien regelmäßig im Rahmen des PDCA-Zyklus:
Plan → Do → Check → Act: Risikoaufnahme, Umsetzung, Überwachung, Verbesserung.
So wird AiTM-Phishing vom Einzelfall zur steuerbaren, messbaren Sicherheitsmaßnahme.
Die wichtigsten Gegenmaßnahmen (technisch & organisatorisch)
1️⃣ Sofortmaßnahmen, was jetzt passieren muss
✅ Phishing-resistente MFA (FIDO2 / WebAuthn): Diese Methode ist kryptografisch an die echte Webseite gebunden. Ein Proxy kann die Signatur nicht wiederverwenden.
Beispiele: YubiKey, Titan Key, Windows Hello, macOS TouchID.
✅ Keine MFA-Ausnahmen: Jede Anmeldung muss MFA durchlaufen auch Admins und interne IP-Adressen.
✅ Legacy-Authentifizierung blockieren: Alte Protokolle wie Basic Auth, POP oder IMAP umgehen MFA vollständig.
✅ Session-Härtung: Kurze Sitzungsdauer, sichere Cookies (SameSite, Secure, HttpOnly), Token-Binding an Gerät/IP.
2️⃣ Mittelfristige Härtung, strukturelle Maßnahmen
Conditional Access / Zero-Trust: Zugriff nur von bekannten Geräten, Standorten oder konformen Clients.Push-MFA härten (Number Matching): Der Nutzer muss eine Zahl von der Login-Seite in der App eingeben verhindert blindes Klicken.Privileged Access Management (PAM): Admin-Rechte nur temporär (Just-in-Time) gewähren.
3️⃣ Detection & Monitoring, Angriffe erkennen
Alarme bei MFA-Geräteänderungen (neues Gerät hinzugefügt / entfernt).Session-Reuse-Erkennung: Gleiche Session von unterschiedlichen IPs.Anomalie-Erkennung („Impossible Travel“) → Wenn derselbe Account in kurzer Zeit aus Berlin und Singapur zugreift.Push-Flooding-Detektion: Zu viele MFA-Anfragen in kurzer Zeit = Angriff.
4️⃣ Awareness, die wichtigste menschliche Firewall
Mitarbeitende regelmäßig trainieren:Keine ungefragten MFA-Pushs bestätigen. Links genau prüfen (URL / Domain / Zertifikat).Verdächtige Login-Vorgänge sofort melden.Phishing-Simulationen mindestens zweimal im Jahr.Klare Slogans etablieren:
„Awareness ist kein einmaliges Training sie ist eine Haltung.“
oder
„Wenn du keinen Login gestartet hast, bestätige auch keinen MFA-Prompt!“
Kurz-Checkliste für Admins
☑ FIDO2/WebAuthn aktiviert für kritische Konten
☑ SMS-MFA deaktiviert (nicht phish-resistent)
☑ Legacy-Auth blockiert (Basic, POP/IMAP)
☑ Conditional Access mit Risiko-Bewertung aktiv
☑ MFA-Alerts & Session-Überwachung eingerichtet
☑ Awareness-Programm implementiert
☑ Incident-Playbook: Token-Revocation, Passwortreset, Forensik
Business-Impact
Ein erfolgreicher AiTM-Angriff führt zu:
Kontoübernahme trotz MFAinterner Weiterverbreitung (Phishing von Kollegen)potenziellen Datenschutzvorfällen (DSGVO-Meldung)Reputationsverlust und hoher Wiederherstellungsaufwand
Investitionen in FIDO2-basierte Authentifizierung und Conditional-Access-Architekturen sind deshalb kein „Nice to Have“, sondern eine Pflichtmaßnahme für alle, die moderne Cloud-Systeme wie Microsoft 365, Google Workspace oder Salesforce nutzen.
Die kritische Gegenperspektive
Die Gegenposition lautet, dass zusätzliche Sicherheitsanforderungen Aufwand schaffen, Projekte verlangsamen und gerade kleinere Organisationen überfordern können. Dieser Einwand ist berechtigt. Er spricht aber für risikogerechte, umsetzbare Kontrollen bei „AiTM-Phishing: Wie Angreifer MFA (Mehrfaktor-Authentifizierung) umgehen und was wirklich schützt“ – nicht dafür, bekannte Risiken einfach auszublenden.
Was beide Seiten leicht übersehen
Oft liegt der entscheidende Punkt zwischen Technik und Organisation. Werkzeuge können Grenzen setzen, aber Menschen vergeben Rechte, definieren Prozesse und reagieren auf Warnungen. Bei „AiTM-Phishing: Wie Angreifer MFA (Mehrfaktor-Authentifizierung) umgehen und was wirklich schützt“ müssen deshalb technische Maßnahmen, verständliche Kommunikation und eindeutige Verantwortung zusammenpassen.
Mein Fazit
MFA ist unverzichtbar aber nicht unangreifbar. AiTM-Phishing zeigt, dass Angreifer menschliches Verhalten und technische Lücken gleichermaßen ausnutzen. Nur wer auf phish-resistente MFA, saubere Policies, Detection-Mechanismen und Awareness-Kultur setzt, bleibt langfristig sicher.
„Akzeptiere niemals eine MFA-Anfrage, wenn du dich nicht gerade selbst angemeldet hast – im Zweifel lieber einmal mehr nachfragen.“
Quellen und Einordnung
Grundlage dieses Beitrags ist mein ursprünglich am 2025-10-12 auf LinkedIn veröffentlichter Artikel. Die dort enthaltenen Verweise und fachlichen Einordnungen wurden für diese Fassung übernommen und um die Perspektiven dieses Blogs ergänzt.
Themen: #Cybersecurity · #Digitale Zukunft · #Informationssicherheit · #IT-Sicherheit · #KI · #KI-Governance