# Was ist Adversary-in-the-Middle-Phishing (AiTM)?

> Adversary-in-the-Middle-Phishing platziert Angreifer-Infrastruktur zwischen dem Opfer und dem echten Dienst und leitet den echten Authentifizierungsaustausch live weiter, sodass der Angreifer Credentials und das resultierende Sitzungstoken erfasst.

- Kanonische URL: https://yellowcube.eu/de/glossary/adversary-in-the-middle-phishing/
- Herausgeber: Yellow Cube
- Sprache: de
- Kontakt: hello@yellowcube.eu

## Inhalt

Phishing-Kits wirken als Reverse Proxies: Das Opfer sieht eine überzeugende Seite, gibt Credentials ein und schließt die MFA auf der echten Seite über das Relay des Angreifers ab — und der Angreifer erhält ein nutzbares Session-Cookie. Dies besiegt SMS-Codes, Einmalpasswörter und Push-Bestätigungen: Die Faktoren sind korrekt, werden aber weitergeleitet statt an den legitimen Origin gebunden.

Die Verteidigungsgrenze ist kryptographische Bindung, nicht besseres Urteilsvermögen. Phishing-resistente Authentifizierung — Passkeys, FIDO2/WebAuthn, zertifikatsbasierte Verfahren — bindet die Credential-Antwort an den legitimen Origin, sodass eine proxied Seite nichts Wiederverwendbares erhält. Sitzungsschutzmaßnahmen verkürzen das Fenster selbst dann, wenn ein Token gestohlen wird.

### Wichtigste Punkte

- **Mechanismus:** Der Angreifer leitet den echten Anmeldefluss in Echtzeit weiter, erntet Credentials und das Sitzungstoken nach der Authentifizierung und nutzt die Sitzung anschließend von der eigenen Infrastruktur aus.
- **Erkennungssignale:** Impossible-Travel- oder abnormale Anmeldegeographie, neue Sitzungsmerkmale nach einem kürzlichen Login, Token-Wiederverwendung von unerwarteten Clients sowie die Phishing-Domain-Infrastruktur selbst.
- **Abwehr:** Für Hochrisiko-Benutzer phishing-resistente Authenticators bevorzugen, Sitzungen binden und verkürzen, bei Token-Wiederverwendung und anomalen Sitzungseigenschaften alarmieren sowie Sitzungen bei Verdacht widerrufen.
- **Wichtige Einschränkung:** Phishing-resistente Authentifizierung schützt den Credential-Austausch, nicht die Sitzung danach. Ein gestohlenes Post-Authentication-Token, ein bösartiges OAuth-Consent oder ein kompromittierter Endpunkt gewährt weiterhin Zugriff, ohne einen Faktor besiegen zu müssen.

### Verwandte Begriffe

[Phishing](<https://yellowcube.eu/de/glossary/phishing/>) · [Phishing-resistente Authentifizierung](<https://yellowcube.eu/de/glossary/phishing-resistant-authentication/>) · [Session Hijacking](<https://yellowcube.eu/de/glossary/session-hijacking/>) · [Multi-Faktor-Authentifizierung (MFA)](<https://yellowcube.eu/de/glossary/multi-factor-authentication/>) · [Business Email Compromise (BEC)](<https://yellowcube.eu/de/glossary/business-email-compromise/>)

### Quellen

[CISA, NSA, FBI, MS-ISAC, Phishing Guidance: Stopping the Attack Cycle at Phase One](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf) · [CISA, Phishing-Resistant Multi-Factor Authentication](https://www.cisa.gov/MFA) · [NIST SP 800-63B-4: Authentication and Authenticator Management](https://csrc.nist.gov/pubs/sp/800/63/b/4/final)

## Quellenangabe und Geltungsbereich

Diese Markdown-Darstellung wird aus denselben freigegebenen Inhalten wie die kanonische HTML-Seite erzeugt. Verwenden Sie beim Zitieren die kanonische URL.