Adversary-in-the-Middle Kits: Was sie sind und was sie so gefährlich macht

16:35 Uhr — fast Feierabend bei Northbridge Solutions LLC.
Du wirfst noch schnell einen Blick in dein Postfach, um sicherzugehen, dass nichts Dringendes liegengeblieben ist.
Beim Löschen der üblichen automatisch generierten Nachrichten bleibst du plötzlich an einer Mail hängen.

Oh Mann… Tom, dein Vorgesetzter. Was ist es diesmal? Wieder ein neues Briefing zum Kundenservice?

Du klickst auf den Link, meldest dich an, gibst den One-Time-Code von deinem Smartphone ein — und siehst nur: Error 404 — diese Datei existiert nicht.

Vielleicht war es ein Fehler und er hat sie schon wieder gelöscht? Na gut, ich frag ihn morgen.

Es ist 17:00 Uhr, du fährst den Rechner herunter und gehst mit deinen Kollegen nach Hause.

Am nächsten Tag, 10:00 Uhr im Büro. Du begegnest Tom und fragst:

Du: „Hey Tom, was ist mit der Datei, die du mir gestern im Firmenportal hochgeladen hast?“
Tom: „Welche Datei? Ich habe dir nichts geschickt.“

Seltsam. Du schaust wieder in dein Postfach — und findest eine neue Mail:

Erschrocken öffnest du die Mail „von Tom“ erneut.
Beim genaueren Hinsehen fällt dir der Link auf:

Nach dem „s“ wurde ein „-” eingefügt — eine Phishing-Domain.
Die Seite sah völlig identisch zum echten Firmenportal aus, und du hast sogar den echten MFA-Code erhalten.
Wie war das möglich?

Die Angreifer nutzten eine Technik namens Adversary-in-the-Middle (AiTM), realisiert durch ein Kit wie Evilginx.

Was ein AiTM-Kit eigentlich ist#

Ein AiTM-Kit fungiert als transparenter Proxy zwischen Opfer und echter Website.
Jede Anfrage und Antwort läuft über die Infrastruktur des Angreifers — so können Daten in Echtzeit abgefangen, gelesen und manipuliert werden.
Die folgende Abbildung zeigt den Ablauf:

Schritt-für-Schritt Ablauf#

1. Opfer gibt Zugangsdaten ein
   Das Opfer ruft die Phishing-Domain auf — ein Proxy der legitimen Website, der optisch völlig identisch wirkt — und gibt seinen Benutzernamen, sein Passwort und später den MFA-Code ein. Anstatt den echten Dienst zu erreichen, werden diese Anmeldedaten zunächst vom AiTM-Kit abgefangen.

2. MFA-Code wird abgefragt
   Das Smartphone des Opfers erzeugt oder empfängt einen Einmalcode (OTP). Das Opfer gibt diesen auf der Phishing-Seite ein.

3. Zugangsdaten werden weitergeleitet
   Das AiTM-Kit leitet die abgefangenen Zugangsdaten (Benutzername, Passwort, OTP) an die legitime Website weiter, sodass der Login authentisch wirkt.

4. Legitime Seite gibt Session-Cookies aus
   Nach erfolgreicher Authentifizierung sendet die echte Website ein Autorisierungs-Cookie (oder Token) an das AiTM-Kit zurück.

5. Cookies werden an das Opfer weitergegeben
   Um die Illusion aufrechtzuerhalten, leitet das AiTM-Kit die gültigen Cookies an das Opfer weiter, das sich daraufhin scheinbar erfolgreich auf der gefälschten Website einloggt — in dem Glauben, alles funktioniere normal.

6. Angreifer sammelt Zugangsdaten und Cookies
   Gleichzeitig speichert das AiTM-Kit eine Kopie der Zugangsdaten und Session-Cookies des Opfers.

7. Echte Session wird erstellt
   Mit diesen Cookies baut das AiTM-Kit eine echte, eingeloggte Session auf der legitimen Website auf.

8. Opfer sieht eine eingeloggte Session auf der Fake-Domain
   Die Phishing-Seite spiegelt die echten Inhalte wider, sodass das Opfer glaubt, sich im legitimen Firmenportal zu befinden.

9. Autorisierte Session für den Angreifer verfügbar
   Der Angreifer kann die gestohlenen Cookies nun wiederverwenden und direkt auf das Konto des Opfers zugreifen — ohne ein weiteres Passwort oder eine MFA-Eingabe zu benötigen.

10. Angreifer imitiert das Opfer vollständig
    Mithilfe der gestohlenen Session meldet sich der Angreifer beim echten Dienst an, als wäre er das Opfer, mit denselben Rechten und Zugriffsmöglichkeiten.

Warum das funktioniert#

• Das Opfer sieht den echten Login-Seiten-Inhalt, der über den Proxy ausgeliefert wird.
• MFA-Codes sind gültig — der Angreifer leitet sie lediglich in Echtzeit weiter.
• Sobald das autorisierte Session-Cookie abgefangen wurde, benötigt der Angreifer weder das Passwort noch das Telefon des Opfers.

Darum ist AiTM-Phishing so gefährlich: Es umgeht traditionelle Schutzmechanismen und macht MFA von einer Sicherheitsebene zu einem Einfallstor.

Warum Angreifer es nutzen#

Die eigentliche Stärke von AiTM-Kits liegt in ihrer Fähigkeit, klassische Multi-Faktor-Authentifizierung (MFA) zu umgehen.
Normalerweise erfordert MFA, dass der Nutzer entweder einen Einmalcode vom Smartphone eingibt oder eine Push-Benachrichtigung auf einem zweiten Gerät bestätigt.
Mit AiTM muss der Angreifer dieses Gerät überhaupt nicht kompromittieren — er leitet den Login einfach über seinen Proxy, überträgt den MFA-Code in Echtzeit und fängt anschließend das autorisierte Session-Cookie oder den Bearer-Token ab, das nach erfolgreichem Login ausgestellt wird.

Sobald das Session-Cookie gestohlen ist, kann der Angreifer es wiederverwenden, um das Opfer zu imitieren — ohne dass zusätzliche Zugangsdaten oder MFA-Abfragen erforderlich wären. Das macht AiTM zu einer der effizientesten Methoden, MFA in der Praxis auszuhebeln.

Warum Angreifer AiTM-Kits bevorzugen#

Kurz gesagt: AiTM-Angriffe sind attraktiv, weil sie kostengünstig, äußerst überzeugend sind und selbst bei Zielen funktionieren, die eigentlich durch MFA „abgesichert“ sein sollten.

Was Verteidiger wissen müssen#

Adversary-in-the-Middle-Phishing bedeutet eine Veränderung im Bedrohungsmodell.
Traditionelle Awareness-Schulungen sagen den Nutzern, sie sollen „auf das Schloss-Symbol achten“ oder „sicherstellen, dass MFA aktiviert ist“.
Mit AiTM-Kits können jedoch beide Prüfungen erfolgreich bestehen — und trotzdem geht der Angreifer mit einer gültigen Session davon.

Deshalb müssen Verteidiger über Zugangsdaten hinausdenken und sich auf die Erkennung von Sessions, die nicht dorthin gehören, konzentrieren.

Wichtige Indikatoren für AiTM-Aktivität#

• TLS- und Domain-Auffälligkeiten
  Die Phishing-Seite besitzt ihr eigenes Zertifikat und ihren eigenen Hostnamen. Beides sieht auf den ersten Blick gültig aus, entspricht jedoch möglicherweise nicht den unternehmensinternen Namenskonventionen. Automatisierte Prüfungen können neue Domains erkennen, die der eigenen Marke stark ähneln.

• Verdächtige HTTP-Header
  AiTM-Proxys fügen manchmal Header ein oder entfernen sie. Beispielsweise können X-Forwarded-For oder veränderte Host-Header darauf hinweisen, dass die Anfrage nicht direkt vom Client stammt.

• Inkonsistenzen bei User-Agent und IP
  Opfer melden sich in der Regel von einer vorhersehbaren Menge an Geräten und geografischen Standorten an. AiTM-Angriffe können plötzliche Abweichungen zeigen: gestern Chrome auf Windows 11, heute plötzlich Safari auf macOS in einem anderen Land — mit demselben Session-Cookie.

• Session-Replay
  Ein Token, das einem Mitarbeiter in Deutschland ausgestellt wurde und Sekunden später von einem Server auf einem anderen Kontinent wiederverwendet wird, ist ein starkes Indiz für Session Hijacking.

Abwehrstrategien#

1. Kurzlebige Session-Tokens
   Verkürzen Sie die Lebensdauer von Session-Cookies und erzwingen Sie regelmäßige Revalidierungen. Dies begrenzt die Nützlichkeit gestohlener Tokens.

2. Gerätebindung
   Verknüpfen Sie die Authentifizierung nicht nur mit „etwas, das man weiß“ (Passwort) und „etwas, das man hat“ (MFA-Code), sondern auch mit dem Gerät selbst. FIDO2/WebAuthn erreichen dies elegant.

3. Anomalieerkennung
   Überwachen Sie ungewöhnliche Zugriffsmuster, etwa wenn mehrere IPs innerhalb weniger Minuten dasselbe Cookie verwenden oder OTP-Codes ungewöhnlich schnell verbraucht werden.

4. Nutzerschulungen
   Schulen Sie Mitarbeiter dahingehend, dass MFA kein Allheilmittel ist. Sie sollten auf Lookalike-Domains und unerwartete Login-Aufforderungen achten, selbst wenn die Login-Seite „echt“ aussieht.

5. Integration von Threat Intelligence
   Viele AiTM-Kampagnen nutzen wiederholt dieselbe Infrastruktur. Das Abonnieren von Threat Feeds und das Blockieren bekannter Phishing-Domains oder Zertifikate kann Angriffe stoppen, bevor sie den Nutzer erreichen.

6. Individuelle Sicherheitskontrollen
   Einige Unternehmen fügen JavaScript-Integritätsprüfungen, CSP-Header oder eigene Geräte-Fingerprints hinzu, um Proxying zu erschweren. Zwar sind diese Maßnahmen nicht narrensicher, sie erhöhen jedoch die Hürde für Angreifer.

Pentester-Perspektive#

Aus Red-Team-Sicht ist AiTM-Phishing eine der realistischsten und wirkungsvollsten Techniken, um die Widerstandsfähigkeit einer Organisation gegenüber Phishing und MFA-Umgehung zu bewerten.
Während Password Spraying oder Brute-Force lediglich die Passwort-Hygiene prüfen, testet eine AiTM-Simulation die gesamte Identitätskette — von den Login-Flows über die MFA-Verarbeitung bis hin zum Session-Management.

In kontrollierten Engagements ermöglicht uns dies, für den Kunden kritische Fragen zu beantworten:

• Würden Mitarbeiter eine Lookalike-Domain erkennen, bevor sie ihre Zugangsdaten eingeben?
• Erkennt das SOC verdächtige Wiederverwendung von Tokens oder Cookies?
• Sind MFA-Richtlinien wirklich phishing-resistent, oder können Sessions nach Eingabe eines Codes gekapert werden?
• Welche kompensierenden Kontrollen (Gerätebindung, Anomalieerkennung, Conditional Access) greifen tatsächlich?

Das hat zwei entscheidende Vorteile:

1. Genauigkeit — der Angriff wird so ausgeführt, wie es echte Angreifer tun würden, ohne Fehlalarme, die durch Standard-Tools entstehen.
2. Klarheit — Verteidiger sehen genau, wo ihre Erkennungs- und Reaktionskette funktioniert hat und wo sie stillschweigend versagt hat.

Und natürlich gilt:

Erfahrungen aus der Praxis#

Ohne gefährlichen Code preiszugeben, hier einige Erkenntnisse, die wir beim Entwickeln und Testen von AiTM-Kits während autorisierter Engagements gesammelt haben.
Diese Erfahrungen verdeutlichen, wie vielfältig und zugleich fragil reale Authentifizierungssysteme sein können.

• Cookie-Handling ist komplex
  Anwendungen geben oft mehrere Set-Cookie-Header mit unterschiedlichen Flags (HttpOnly, Secure, SameSite) aus.
  Alle korrekt in einem Proxy-Setup zu handhaben, ist schwieriger, als viele denken — und jeder Fehler zerstört die Illusion eines „nahtlosen“ Logins.

• Nicht jede App verwendet Cookies
  Manche modernen Anwendungen setzen stark auf Authorization-Header (Bearer Tokens, JWTs, OAuth-Flows) anstelle klassischer Cookies.
  Für Angreifer bedeutet das eine größere Bandbreite an Tokens, die abgefangen werden können. Für Verteidiger heißt es: reiner Cookie-Schutz reicht nicht aus.

• Mangel an Anti-AiTM-Schutz ist weit verbreitet
  Erstaunlicherweise haben viele Inhouse- und sogar einige Enterprise-Webanwendungen keine wirksamen Mechanismen gegen Proxying.
  Sie validieren keine Domain-Bindings, koppeln Sessions nicht an Geräte und erkennen nicht, wenn der Traffic aus einem unerwarteten Pfad kommt.

• Demonstrationen wirken stärker als Berichte
  Dem Management einen Report mit „Session Hijacking möglich“ vorzulegen, ist das eine.
  Einen Browser zu öffnen, das gestohlene Cookie zu importieren und sofort als CEO eingeloggt zu sein, ist weit eindrücklicher.
  Es verwandelt ein abstraktes Sicherheitsproblem in ein greifbares Geschäftsrisiko.

• Fehlerhafte Schutzmaßnahmen sind entlarvend
  Wir haben Fälle gesehen, in denen Entwickler versuchten, AiTM durch eine Prüfung von document.location in JavaScript abzusichern.
  Eine einzige übersehene Rewrite-Regel auf Proxy-Seite hat den Schutz vollständig ausgehebelt.
  Das zeigt: Halbherzige Abwehrmaßnahmen können ein falsches Gefühl von Sicherheit vermitteln.

Diese Erfahrungen verdeutlichen, dass AiTM-Tests nicht nur dazu dienen, „Passwörter abzufangen“.
Es geht darum, aufzuzeigen, wie sich reale Anwendungen unter Druck verhalten — und wo Organisationen falsche Annahmen über die Sicherheit von MFA gemacht haben.

Handlungsempfehlungen für Verteidiger#

Was können Organisationen also tun, um AiTM-Angriffen einen Schritt voraus zu sein?
Die Antwort ist kein einzelnes Tool, sondern eine gestaffelte Verteidigungsstrategie.

1. Authentifizierung stärken#

• Phishing-resistente MFA wie FIDO2 / WebAuthn / Hardware-Sicherheitsschlüssel einführen.
• Sessions an Geräte binden, sodass ein gestohlenes Cookie nicht von einem anderen Endpunkt wiederverwendet werden kann.
• Session-Laufzeiten verkürzen und für sensible Aktionen erneute Authentifizierung erzwingen.

2. Verdächtige Sessions erkennen#

• Überwachen Sie Cookie- oder Token-Reuse (wenn dieselbe Session von zwei Orten gleichzeitig genutzt wird).
• Markieren Sie Impossible Travel — Logins aus weit entfernten Regionen innerhalb weniger Minuten.
• Nutzen Sie Verhaltensanalysen, um Anomalien in User-Agent-Strings, IP-Adressen oder Login-Frequenzen zu erkennen.

3. Webanwendungen härten#

• Erzwingen Sie strikte Domain-Prüfungen (z. B. CSP, HSTS, Referer-Validierung).
• Implementieren Sie Integritätsprüfungen, die brechen, wenn Traffic proxied oder verändert wird.
• Prüfen Sie Unterstützung für Conditional Access Policies (z. B. nur Logins von verwalteten Geräten zulassen).

4. Nutzer schulen und testen#

• Machen Sie deutlich, dass MFA kein Allheilmittel ist — Phishing-Seiten können dennoch täuschend echt aussehen.
• Schulen Sie Mitarbeiter darin, Lookalike-Domains und unerwartete Login-Aufforderungen zu erkennen.
• Führen Sie regelmäßig Phishing-Simulationen durch, die auch AiTM-Techniken enthalten, nicht nur einfachen Credential-Diebstahl.

5. Threat Intelligence integrieren#

• Abonnieren Sie Phishing-Domain-Feeds und blockieren Sie Lookalikes auf DNS- oder Proxy-Ebene.
• Überwachen Sie verdächtige Zertifikate, die auf Ihre Marke ausgestellt werden.
• Teilen und nutzen Sie IoCs aus Branchennetzwerken, um aktiven Kampagnen immer einen Schritt voraus zu sein.

Vom Bewusstsein zur Handlung#

Adversary-in-the-Middle-Kits verändern die Regeln der Phishing-Abwehr. Es reicht nicht mehr zu sagen: „Wir haben MFA, wir sind sicher.“
Organisationen müssen davon ausgehen, dass Angreifer Sessions abfangen können — und sich darauf vorbereiten, diese zu erkennen und darauf zu reagieren.

Sicherheitsteams, die AiTM-Angriffe in kontrollierter Umgebung simulieren, erhalten einen realistischen Einblick darin, wie belastbar ihre Abwehrmaßnahmen tatsächlich sind.
Dies ist der einzige Weg, echte Resilienz aufzubauen, bevor echte Kriminelle an die Tür klopfen.

Bei 0xda7a simulieren wir Adversary-in-the-Middle-Angriffe in kontrollierten Penetrationstests.
So können Organisationen prüfen, ob ihre MFA- und Identity-Security-Strategien wirklich tragen — bevor Kriminelle die Lücke ausnutzen.

Wir nutzen unser eigenes AiTM-Framework — entwickelt für Tests, niemals für Missbrauch.
Unser Ziel: Verteidigern helfen, Angreifern stets einen Schritt voraus zu sein.