Schützen Sie Ihre Identitäten
Sprechen Sie mit unseren Fachleuten darüber, wie Sie AiTM-Angriffe wirksam abwehren können.
Schützen Sie Ihre Identitäten
Sprechen Sie mit unseren Fachleuten darüber, wie Sie AiTM-Angriffe wirksam abwehren können.
Adversary-in-the-Middle (AiTM) bezeichnet einen hochentwickelten Angriff, bei der sich ein Angreifer in laufende Kommunikations- und insbesondere Authentifizierungsprozesse einklinkt, um Zugangsdaten oder Sitzungs-Token zu erlangen und sich unbefugt Zugang zu Clouddiensten zu verschaffen. AiTM-Angriffe sind in den letzten Jahren massiv auf dem Vormarsch: Immer mehr Dienste wandern in die Cloud und Multi-Faktor-Authentifizierung (MFA) wird verbreitet eingesetzt. Angreifer reagieren darauf, indem sie diese Schutzmechanismen mit neuen Methoden zu umgehen versuchen.
In diesem Blogbeitrag beleuchte ich die aktuellen Angriffsmethoden und Tools hinter AiTM, sowie typische Szenarien und technische Details der Funktionsweise.
Was ist Adversary-in-the-Middle (AiTM)?
In einem typischen AiTM-Angriffsszenario richtet der Angreifer einen Reverse Proxy ein (z.B. Evilginx), der dem Endanwender komplette und echte Anmeldeseiten präsentiert. Der Benutzer denkt, er kommuniziere direkt mit z. B. Microsoft 365, Google Workspace oder einer Bank.
Tatsächlich laufen seine Eingaben aber über den Angreifer-Server, der die Anmeldedaten dann wiederum an den eigentlichen Zieldienst weiterleitet. Dadurch kann der Angreifer Anmeldedaten (Benutzername / Passwort) und Session-Cookies stehlen.
Session-Cookies, die die Anmeldetoken des ausstellenden Identity Providers enthalten, werden vom jeweiligen Identity Provider erst nach vollständiger Authentifizierung ausgestellt und sind somit der Zugriffschlüssel für die Anmeldung. Dieser Schlüssel wird im Nachgang im Allgemeinen nicht weiter geprüft.
Was bedeutet das konkret: Selbst, wenn der Endanwender eine Standard-Multi-Faktor-Authentifizierung nutzt, wie eine Authenticator App, eine SMS oder einen Telefonanruf, kann der Anmeldetoken in Form des Sessions-Cookies abgefangen werden. Ein Angreifer kann sich dann (ohne Kennwort und Multi-Faktor-Authentifizierung) im Namen des Endanwenders authentifizieren.
Eine (Standard-) Multi-Faktor-Authentifizierung stellt somit grundsätzlich erst einmal keinen Schutz gegen einen AiTM-Angriff dar.
AiTM-Angriffe werden derzeit vor allem in Phishing-Kampagnen gegen Cloud-Dienste eingesetzt. Microsoft 365 und Google Workspace sind häufige Ziele, da erfolgreiche Angreifer hierdurch Zugang zu E-Mails, Dokumenten und weiteren Diensten der jeweiligen Organisation erhalten.
Ablauf eines AiTM-Angriffs: Methoden und Tools
Schauen wir uns am Beispiel von Evilginx als Reverse-Proxy-Lösung und einer Microsoft 365-Anmeldung an, wie ein typischer AiTM-Angriff verläuft. Meist beginnt der Angriff mit einer gezielten Phishing-E-Mail:
1. Phishing-Köder (Initialkontakt)
Der Angreifer versendet eine E-Mail (z.B. eine Teams Einladung) mit einem Link auf eine gefälschte Login-Seite. Diese Nachricht ist oft geschickt getarnt. Sie scheint von einem vertrauenswürdigen Absender zu kommen, etwa einem bekannten Partnerunternehmen oder einem beliebten Dienst (wie z.B. Microsoft Teams oder OneDrive).
Durch kompromittierte und vertrauenswürdige Absender oder geschicktes Social Engineering, umgehen solche Phishing-Mails vielfach standardmäßige Phishing-Filter.
2. Gefälschte Anmeldeseite (Proxy-Server)
Die im Link enthaltene URL führt den Benutzer nicht zur echten Anmeldeseite, sondern zu einem Angreifer-gesteuerten Webserver, in unserem Beispiel Evilginx, der sich als die legitime Login-Seite ausgibt.
Im Hintergrund fungiert dieser Server als Reverse Proxy: Jede Anfrage des Opfers wird an den echten Dienst weitergeleitet und die echten Antworten zurück an das Opfer gespielt. Für das Opfer wirkt alles authentisch, da die Seite identisch aussieht. Kundenindividuelle Brandings (Logos, Texte usw.) werden übernommen. Der Aufwand ist somit für den Angreifer für unterschiedliche Ziele minimal und selbst die Web-Adresse kann täuschend ähnlich sein (z. B. login.microsoft0nline.de/...).
Moderne Phishing-Kits erschweren die Erkennung zusätzlich mit CAPTCHAs und IP-Filtern, um automatische Scanner auszubremsen. Der Angreifer hat in diesem Stadium die volle Kontrolle über den Datenstrom. Durch die zwei verbundenen Sitzungen (Opfer ↔ Proxy und Proxy ↔ echter Dienst) kann er alles im Klartext einsehen, bevor es wieder verschlüsselt weitergeht.
3. Diebstahl von Zugangsdaten und Tokens
Gibt der Benutzer nun seine Login-Daten ein, laufen diese direkt über den Angreifer-Proxy. Der Proxy leitet Benutzername und Passwort sofort an den echten Dienst weiter. Oft folgt nun (falls aktiviert) die Abfrage eines MFA-Codes oder einer Push-Bestätigung. Auch diese MFA-Eingaben werden in Echtzeit an den legitimen Dienst weitergereicht und gleichzeitig vom Angreifer abgefangen.
Nachdem der Benutzer erfolgreich authentifiziert ist, erstellt der Cloud Identity Provider (IdP) normalerweise ein Session-Token (verfügbar als Cookie im Browser), um den Benutzer eingeloggt zu halten. Dieser Session-Token wird vom Proxy abgegriffen, noch bevor er im Browser des Opfers ankommt. Für den Benutzer läuft nach der MFA-Eingabe meist alles normal weiter. Er sieht vielleicht sein Exchange Online Postfach, Teams oder OneDrive. Nichts deutet dabei zunächst auf eine Kompromittierung hin.
Im Hintergrund hat der Angreifer jedoch die sprichwörtlichen Schlüssel in der Hand. Mit dem gestohlenen Session-Cookie kann er sich bei der echten Website als dieser Benutzer anmelden, ohne Benutzername, Passwort oder MFA erneut eingeben zu müssen.
4. Kontoübernahme (Session Hijacking)
Der Angreifer besitzt nun zwei Dinge, das Kennwort des Opfers im Klartext und den Session-Token. Dass das Kennwort offengelegt wurde, ist an sich schon ein großes Sicherheitsrisiko, der Session-Token ist allerdings das, was Angreifer eigentlich haben wollen. Denn in diesem Session-Token ist bereits ein bestätigter zweiter Faktor enthalten und somit eine einfache Anmeldung möglich, vorbei an allen gängigen Sicherheitsmaßnahmen. Zudem ist bei der Nutzung des abgefangenen Session-Tokens keine erneute Anmeldung am Cloud-IdP erforderlich, sodass man „unter dem Radar“ von Logs oder vielen XDR-Ansätzen operieren kann. Der Session-Token kann in Evilginx angezeigt und z.B. in einem Browser eingespielt werden.
5. Nutzung des Session-Token in einem Browser
Der abgefangene Session-Token kann nun recht einfach in einem Browser über Browser-Erweiterungen, wie „Cookie-Editor“ oder „StorageAce“ in Microsoft Edge oder Google Chrome importiert werden.
Eine weitere Validierung des Tokens findet vom Identity Provider (hier das Entra ID) nicht statt, da der Token noch gültig ist.
Das Beispiel zeigt den Import des Session-Tokens in einem Browser. Grundsätzlich kann der Token aber auch über verschiedene APIs genutzt werden, um sich anzumelden. Im Microsoft Kontext wäre das z.B. Microsoft Graph.
6. Folgeaktionen & Eskalation
Nachdem sich der Angreifer nun erfolgreich angemeldet hat, finden typischerweise weitere Aktionen statt, wie Regeln im E-Mail-Posteingang einrichten oder Aktionen im Namen des Benutzers ausführen, wie E-Mail-Versand, weitere MFA-Faktoren registrieren oder ähnliches. Hier sind der Fantasie fast keine Grenzen mehr gesetzt.
In jüngster Zeit kamen in der Mehrzahl der erfolgreichen Phishing-Angriffe AiTM-Techniken zum Einsatz.
Über automatisierte Toolkits können sehr schnell Massen-Phishing-Kampagnen aufgesetzt werden, die personalisierte Köder und Anti-Scan-Taktiken verwenden.Beispielsweise KI-gestützte personalisierte Texte und dynamische Fake-Seiten, die Sicherheitsscans ins Leere laufen lassen. Entsprechend verwundert es nicht, dass selbst gut geschützte Unternehmen Opfer solcher AiTM-Angriffe werden können.
Gängige Tools und Kits für AiTM-Phishing
Die Durchführung von AiTM-Angriffen erfordert zwar Know-how, doch zahlreiche spezialisierte Tools und Phishing-Kits machen es Angreifern leichter denn je. Einige wichtige Vertreter sind:
Evilginx
Ein Open-Source-“Phishing Proxy”-Toolkit, erstmals 2017 vorgestellt, welches speziell zum Abfangen von Web-Anmeldedaten (inkl. MFA) konzipiert wurde. Evilginx emuliert mit sogenannten Phishlets die Ziel-Websites (für Dienste wie Microsoft, Google, Facebook, GitHub, etc.) nahezu 1:1 und kümmert sich (in der Pro Version) automatisch um DNS-Auflösung sowie gültige TLS-Zertifikate (via Let’s Encrypt) für die jeweilige Fake-Domain.
Pentester und Angreifer gleichermaßen nutzen Evilginx, da es mit minimalem Aufwand innerhalb von Minuten einsatzbereit ist. Es gilt als das meistgenutzte AiTM-Toolkit in freier Wildbahn. Dieses Tool wurde auch für diesen Beitrag genutzt.
Modlishka
Ein weiteres bekanntes Open-Source-Tool (veröffentlicht 2019) für Reverse-Proxy-Phishing, ähnlich Evilginx, das Angreifern eine flexible Plattform bietet, um 2FA-geschützte Logins abzufangen.
EvilProxy
Ein Phishing-as-a-Service (PhaaS)-Angebot, das 2022 in Untergrundforen (Darknet) aufgetaucht ist. EvilProxy stellte Angreifern gegen Bezahlung eine fertig gehostete Plattform bereit, um MFA-geschützte Accounts zu kapern.
Tycoon 2FA
Ein modernes AiTM-Phishingkit, das im August 2023 erstmals identifiziert wurde. Tycoon 2FA wird als Phishing-as-a-Service betrieben und gewinnt seit 2024 an Verbreitung. Es imitiert vor allem Microsoft- und Google-Anmeldeseiten und fängt dabei Anmeldeinformationen samt MFA-Codes und Session-Cookies ein. Kampagnen mit Tycoon 2FA führten Anfang 2025 zur Kompromittierung mehrerer Unternehmensaccounts trotz MFA-Schutz.
Viele dieser Tools tauchen als Module größerer Malware-Suites oder Phishing-Services auf. Adversary-in-the-Middle ist also kein theoretisches Szenario mehr, sondern Realität. Von Cybercrime-Banden bis staatlichen APT bedienen sich mittlerweile Angreifer aller Couleur solcher MFA-Bypass-Phishingkits. Denn Cloud-Konten stellen extrem lohnende Ziele dar und klassische MitM-Ansätze sind angesichts verschlüsselter Verbindungen immer weniger erfolgversprechend. Die Barriere, solche Angriffe durchzuführen, sinkt zudem durch Phishing-as-a-Service-Angebote beträchtlich. Entsprechend sind Security-Verantwortliche gefordert, gezielt Abwehrmechanismen dagegen zu etablieren.
Schutzmechanismen gegen AiTM
Da AiTM-Angriffe die üblichen Schutzmaßnahmen wie MFA unterlaufen können, ist ein mehrschichtiges Verteidigungskonzept nötig. Im Folgenden stelle ich zentrale Schutzmechanismen vor: von fortschrittlichen Authentifizierungsverfahren über Systemmaßnahmen bis hin zu Security-Awareness der Endanwender. Wichtig ist zu verstehen, dass kein einzelner Schutz absolut ist. Wirkungsvolle Sicherheit entsteht immer durch das Zusammenspiel mehrerer Maßnahmen.
Phishing-resistente MFA (FIDO2/WebAuthn)
Da AiTM-Angriffe klassische MFA-Methoden, wie SMS, Telefonanruf, TAN, OTP, Push-Nachrichten aushebeln, empfiehlt sich der Einsatz von MFA-Methoden, die gegen Phishing gewappnet sind. FIDO2-Authentifizierung (z.B. mittels Hardware-Sicherheitsschlüssel, Windows Hello oder Apples Face ID) bindet den Authentifizierungsvorgang an das konkrete genutzte Gerät und die Ziel-Domain (z.B.: https://login.microsoftonline.com/). Keine Geheimnisse verlassen dabei das Gerät, stattdessen wird eine kryptographische Challenge/Response mit einem privaten Schlüssel durchgeführt. Abgefangene Daten sind für den Angreifer wertlos, da er weder den privaten Schlüssel erlangen noch eine gültige Antwort ohne das physische Gerät generieren kann. Somit verpufft der AiTM-Ansatz, da selbst das Proxying der Sitzung dem Angreifer nichts nützt. Der Login bleibt an den legitimen Client gebunden. Wo immer möglich, sollten Unternehmen also auf passwortlose Login-Verfahren mit FIDO2 umstellen. Zertifikatsbasierte Anmeldung z.B. per Smartcard bieten ähnliche Phishing-Resistenz, da auch hier mit privaten und öffentlichen Schlüsseln gearbeitet wird.
Hinweis: Auch bei Nutzung von FIDO2 oder Zertifikaten, werden Kennwörter vom Proxy abgefangen, wenn FIDO2 oder Zertifikate lediglich als zweiter Faktor (MFA) verwendet werden. Die erfolgreiche Anmeldung bei AiTM-Angriffen wird zwar verhindert, die Kennwörter sind trotzdem verloren bzw. abgefangen. Dies lässt sich nur mit einer komplett kennwortlosen Anmeldung am Endgerät verhindern.
Conditional Access & Kontextbasierte Authentifizierung
Moderne Cloud-Identitätsdienste (wie Microsoft Entra ID, Okta etc.) bieten Conditional Access Richtlinien, mit denen Zugriffe nur unter bestimmten Bedingungen erlaubt werden. Hier sollte man ansetzen, um AiTM zu erschweren: Gerätebindung, Geo-Location-Checks oder anormales Verhalten erkennen. Beispielsweise können Regeln erfordern, dass Anmeldungen nur von registrierten Firmen-Geräten (z.B. Microsoft Hybrid Join oder Prüfung Device Compliance) oder von bestimmten Ländern erfolgen dürfen – ein Angreifer auf einem Proxy-Server außerhalb dieser Bedingungen wird somit abgelehnt. Erkennung von Impossible Travel (gleichzeitige Anmeldungen aus weit entfernten Orten) oder ungewöhnliche User Agents (AiTM-Tools verraten sich manchmal durch generische Browser-Signatures) sind ebenfalls Indikatoren. Microsoft Entra ID Protection kann das Risikoniveau von Logins einstufen (basierend auf IP, Browsing-Historie, Gerät etc.) und bei hohem Risiko z.B. zusätzliche MFA oder Blockade erzwingen. Natürlich kann ein raffinierter Angreifer viele dieser Checks umgehen, etwa durch Proxy-Server im selben Land und Konfiguration des User-Agents auf den des Opfers. Dennoch erhöhen solche Mechanismen den Aufwand für Angreifer beträchtlich und filtern zumindest massentaugliche Kits oft aus.
Session-Management und Token-Schutz
Da AiTM-Angriffe auf Session-Tokens abzielen, sollte man deren Missbrauch erschweren und schnell erkennen.
Einige Best Practices:
- Verkürzte Gültigkeitsdauer für Tokens (z. B. signifikant kürzere Leerlauf- und Ablaufzeiten, sodass der Angreifer ein kleineres Zeitfenster zur Nutzung hat).
- Token-Binding / Token-Protection: Wenn möglich, Tokens an den Client oder die TLS-Verbindung binden. D.h. ein gestohlenes Token funktioniert nicht auf einem anderen Endgerät bzw. ohne bestimmte TLS-Attribute. Diese Technik ist noch nicht überall verfügbar, aber in Entwicklung (Browser und IdPs arbeiten an Mechanismen, die Session-Cookies an eine origin-spezifische TLS-Verbindung koppeln).
- Monitoring auf Token-Wiederverwendung: Systeme sollten alarmieren, wenn derselbe Session-Cookie von zwei verschiedenen IPs oder Devices genutzt wird. Microsoft z.B. hat mit Defender for Cloud Apps und XDR inzwischen die Fähigkeit, gleichzeitig mit einem Account auftretende Parallel-Sessions zu erkennen und automatisch Gegenmaßnahmen einzuleiten.
Erweiterte E-Mail-Sicherheit & Domain-Schutz
Da Phishing der häufigste Einstieg für AiTM ist, bleibt E-Mail-Security essenziell. Neben klassischen Spamfiltern sollten Domain-Authentifizierungen wie DMARC, DKIM, SPF konsequent umgesetzt werden, um E-Mail-Spoofing zu erschweren. Viele AiTM-Kampagnen missbrauchen jedoch legitime fremde Server (kompromittierte Accounts, erlaubte Newsletter-Dienste etc.), sodass KI-gestützte Phishing-Erkennung sinnvoll ist, die Inhalte und Kontext analysiert (z.B. ungewöhnliche Aufforderungen von sonst vertrauenswürdigen Absendern). URLs in E-Mails sollten automatisiert via Sandbox/Proxy geprüft werden z.B. per Microsoft Defender for Office (Safe Link Funktion).
Nutzerschulung und Awareness
Gut geschulte Nutzer sind eine wichtige Verteidigungslinie. IT-Security Verantwortliche sollten regelmäßige Awareness-Trainings der Endanwender durchführen, die auf AiTM-Phishing eingehen und dabei erklären, dass ein gültiger Domainname (mit HTTPS-Schloss) allein keine Garantie ist, wenn auch nur ein kleiner Unterschied zur echten Domain besteht.
Regelmäßige Übung erhöht die Erkennungsfähigkeit deutlich. Phishing-Simulationen können helfen, Mitarbeiter für subtile Anzeichen zu sensibilisieren (z. B. leicht abweichende URL, ungewohnte Login-Sequenz, CAPTCHAs an ungewöhnlicher Stelle etc.). Eine Passwort-Manager-Empfehlung gehört dazu: Passwort-Manager füllen Anmeldedaten nur auf tatsächlich passenden Domains automatisch aus. Versucht man auf einer Phishing-Domain (die nicht exakt mit der Original-URL übereinstimmt) sein Passwort einzugeben, schlägt der Manager Alarm oder füllt gar nichts ein. Das ist ein praktischer Indikator, um Fake-Seiten zu erkennen. Letztlich muss klar sein: Vorsicht bei Login-Aufforderungen. Im Zweifel lieber manuell die bekannte korrekte URL aufrufen, statt auf Links zu klicken.
Moderne Cloud-Identitätsdienste spielen eine Doppelrolle. Einerseits machen zentrale Identity-Provider (IdPs) wie Entra ID, Okta, Google Identity die angegriffenen Ziele attraktiver, da ein erbeuteter Token oft für eine Vielzahl verknüpfter Dienste gültig ist (Single Sign-On). Andererseits bieten Cloud-Plattformen moderne Schutzfunktionen, die in On-Premises Lösungen so nicht ohne Weiteres verfügbar wären: von Machine-Learning-gestützter Erkennung von Anomalien bis hocheffektiver Device-/Context-Policy (Erkennung bekannter und vertrauenswürdiger Geräte). Microsoft, Google & Co. reagieren aktiv auf die AiTM-Bedrohung, z.B. mit einer automatischen Session-Löschung („Session Invalidate“) bei verdächtigem Verhalten oder mit Zusatzprüfungen bei riskanten Logins. Die Empfehlung lautet daher, diese nativen Sicherheitsfunktionen maximal auszunutzen und fortlaufend zu prüfen, welche neuen Optionen (wie z.B. Continuous Access Evaluation, phishing-resistente MFA etc.) verfügbar werden.
Zusammenfassung und Ausblick
Adversary-in-the-Middle-Angriffe stellen eine Weiterentwicklung klassischer MiTM-Angriffe dar, die gezielt Schwachstellen in den heutigen Authentifizierungsabläufen ausnutzen. Indem sie Vertrauensbeziehungen auf Anwendungsebene missbrauchen, können sie selbst starke Sicherheitsmaßnahmen wie MFA umgehen. Die Gefahr für Unternehmen und Nutzer ist beträchtlich: Von Kontoübernahmen über Datendiebstahl bis zu Folgeangriffen, wie BEC (Business Email Compromise) oder Ransomware reicht das Spektrum der Schäden. Beispiele aus den Jahren 2023 bis 2025 zeigen, dass solche Angriffe längst Realität sind, teils in Massenkampagnen auf Breite angelegt, teils in hochgezielten Operationen gegen wertvolle Einzelziele.
Die Verteidigung gegen AiTM erfordert ein ganzheitliches Vorgehen:
- Prävention durch phishing-resistente Authentifizierung, wie FIDO2, Passkeys, Zertifikatsbasierte Authentifizierung, Windows Hello oder Apple Face ID und strenge Sicherheitsrichtlinien über z.B. Conditional Access (z.B. Prüfung auf bekannte Geräte)
- Detektion durch Überwachen von Anomalien (unnatürliche Login-Muster, parallele Sessions, unbekannte Devices)
- Reaktion durch automatisiertes Stoppen verdächtiger Aktivitäten (z.B. Token widerrufen, Account sperren) und gut geübte Incident-Response-Prozesse.
Letztlich entwickeln sich Identitäts- und Zugriffskontrollen hin zu einem Zero-Trust-Modell, in dem Identität der neue Perimeter ist. Und genau darauf zielen AiTM-Angriffe ab. Es gilt also, Identitäten und Sessions mit neuen Werkzeugen zu schützen und das Bewusstsein der Benutzer hochzuhalten.
Eine entscheidende Erkenntnis ist: MFA ist notwendig, aber nicht mehr hinreichend. Unternehmen müssen weitere Schutzebenen einziehen und insbesondere auf Phishing-Resistenz setzen, um der aktuellen AiTM-Bedrohung zu begegnen. Gleichzeitig sollten klassische MiTM-Schutzmaßnahmen (Verschlüsselung, Zertifikatsvalidierung, Netzwerksicherheit) nicht vernachlässigt werden. Sie bilden das Fundament, auf dem die neuen Schichten aufsetzen.
Autor
