Entra ID AiTM-Token-Replay, Erkennung unmöglicher Reisen und MFA-Push-Fatigue

Entra ID AiTM-Token-Replay, Erkennung unmöglicher Reisen: Warum das jetzt wichtig ist

Multi-Faktor-Authentifizierung stoppt Angriffe, die nur auf Passwörtern basieren. Sie stoppt keinen Angreifer, der den gesamten Anmeldevorgang über einen Proxy leitet und mit einem gültigen Sitzungscookie davonzieht, nachdem der Nutzer die MFA abgeschlossen hat. Genau das tun Adversary-in-the-Middle-(AiTM)-Phishing-Kits, und genau diese Lücke sollen Entra ID AiTM-Token-Replay, die Erkennung unmöglicher Reisen und Signale für MFA-Push-Fatigue schließen. Microsoft hat unmissverständlich klargestellt, dass diese Angriffsklasse einen wachsenden Anteil an Identitätskompromittierungen ausmacht: Der Microsoft-Sicherheitsblog zu sich entwickelnden Identitätsangriffstechniken sowie mehrere Incident-Berichte beschreiben AiTM-Kits wie Evilginx, die einen Reverse-Proxy zwischen Opfer und der echten Microsoft-365-Anmeldeseite platzieren, dabei die legitimen Inhalte ausliefern und gleichzeitig Benutzername, Passwort und – entscheidend – das nach erfolgreicher MFA ausgestellte Sitzungs-/Refresh-Token abfangen. Deepwatch dokumentiert, dass dasselbe Kit von Bedrohungsakteuren eingesetzt wird, die vom produktiven Phishing-Akteur Storm-0485 bis zum russischen Spionageakteur Star Blizzard reichen, um Microsoft-365-Sitzungen unbemerkt zu kapern.

Microsoft Entra ID Protection wandelt diese Art von Aktivität in Risikosignale um, doch diese Signale sind über mehrere unterschiedliche Erkennungen, Log-Tabellen und Lizenzstufen verstreut. Dieser Artikel ist ein Feldleitfaden dazu, fünf davon gemeinsam zu lesen:

• AiTM-Token-Replay — ein gestohlenes Sitzungs- oder Refresh-Token wird von Infrastruktur aus wiederverwendet, die der echte Nutzer nie berührt hat
• Unmögliche / atypische Reise — zwei Anmeldungen derselben Identität, geografisch zu weit voneinander entfernt, um beide legitim sein zu können
• Missbrauch von MFA-Push-Genehmigungen — ein Angreifer mit gültigem Passwort versucht, einen Nutzer dazu zu bringen, eine nicht angeforderte Push-Benachrichtigung zu bestätigen
• Spitzen bei Service-Principal-Anmeldungen — eine Workload-Identität authentifiziert sich plötzlich weit häufiger oder weit breiter als in ihrer Baseline
• Ungewöhnliche Geografie bei Admin-Konten — eine privilegierte Identität meldet sich von einem Ort oder Gerät an, das sie nie zuvor genutzt hat

Wie sich jedes Signal in der Telemetrie von Entra ID zeigt

AiTM-Proxys und Token-Replay

MITRE erfasst den Diebstahl von Sitzungscookies als T1539 (Steal Web Session Cookie). Ein AiTM-Kit sitzt zwischen dem Nutzer und dem echten Login-Endpunkt von Microsoft, leitet jeden Schritt der Authentifizierung — einschließlich der MFA-Challenge — durch und erfasst anschließend das resultierende Sitzungsartefakt. Da das Opfer die MFA tatsächlich abgeschlossen hat, trägt das gestohlene Token diesen Nachweis weiter. Der Angreifer spielt es von seiner eigenen Infrastruktur aus erneut ab, nicht vom Gerät oder Netzwerk des Opfers.

Microsoft Entra ID Protection verfügt über mehrere Erkennungen, die Teile davon erfassen:

• Anomalous token (riskEventType: anomalousToken) — greift bei abnormalen Token-Eigenschaften: einer ungewöhnlichen Lebensdauer oder einem Token, das von einem Ort, einer Anwendung, IP-Adresse oder einem User-Agent verwendet wird, der nicht zur Historie des Nutzers passt. Microsofts eigene Dokumentation nennt dies als direkten Indikator für potenziellen Token-Replay. Die Erkennung erfolgt in Echtzeit oder offline und erfordert Entra ID P2.
• Attacker in the Middle (attackerinTheMiddle, eine nutzerbezogene Risikoerkennung) — eine hochpräzise Erkennung, die auslöst, wenn eine Sign-in-Session mit einem bekannten bösartigen Reverse-Proxy verknüpft ist; sie stammt aus Microsoft-Defender-for-Cloud-Apps-Telemetrie. Sie stuft den Nutzer direkt auf High Risk hoch und erfordert Microsoft 365 E5 mit Enterprise Mobility + Security E5 — anders als bei den meisten anderen aus Defender for Cloud Apps stammenden Erkennungen listet Microsoft für diese keinen eigenständigen Lizenzpfad Entra ID P2 + Defender for Cloud Apps.
• Unfamiliar sign-in properties (unfamiliarFeatures) — vergleicht eine Anmeldung mit der erlernten Historie des Nutzers (IP, ASN, Standort, Gerät, Browser, Tenant-Subnetz). Microsofts Leitfaden weist explizit darauf hin: Löst diese Erkennung bei einer nicht interaktiven Anmeldung aus, verdient das besondere Aufmerksamkeit, da dieses Muster mit einem im Hintergrund still wiederverwendeten Refresh-Token übereinstimmt statt mit einer interaktiven Anmeldung.
• Token issuer anomaly (tokenIssuerAnomaly) — markiert bei SAML-Tokens Issuer-Claims, die ungewöhnlich sind oder bekannten Angreifermustern entsprechen.

Microsofts Token-Theft-Playbook listet die konkreten Trigger auf, auf die ein SOC bei Token-Theft-Untersuchungen achten sollte: Anomalous Token, Unfamiliar Sign-in Properties, nicht interaktive Anmeldungen aus unbekannten Quellen, versuchte Zugriffe auf ein Primary Refresh Token (PRT, via Defender for Endpoint) sowie verdächtige URLs, die zu einer AiTM-Landingpage passen.

Unmögliche und atypische Reisen

Entra ID Protection liefert hier tatsächlich zwei verwandte, aber unterschiedliche Erkennungen, und eine Verwechslung führt zu falschen Annahmen bei Lizenzierung und Tooling:

• Impossible travel (mcasImpossibleTravel) — identifiziert Aktivität von geografisch weit entfernten Orten innerhalb eines Zeitfensters, das kürzer ist, als physisch mögliches Reisen zwischen ihnen erlauben würde. Die Erkennung stammt aus Microsoft Defender for Cloud Apps, wird offline berechnet und erfordert Entra ID P2 plus eine eigenständige Defender-for-Cloud-Apps-Lizenz (oder Microsoft 365 E5).
• Atypical travel (unlikelyTravel) — eine native Entra-ID-Protection-Erkennung (ohne Abhängigkeit von Defender for Cloud Apps), die zwei Anmeldungen von entfernten Orten markiert, bei denen mindestens einer auch für die Historie des jeweiligen Nutzers atypisch ist. Sie berücksichtigt die Reisezeit zwischen den Orten und unterdrückt bewusst häufige Falsch-Positive wie VPN-Ausgangspunkte und IPs, die im gesamten Unternehmen geteilt werden. Neue Nutzer durchlaufen eine Lernphase von entweder 14 Tagen oder 10 Anmeldungen, je nachdem, was zuerst eintritt, bevor die Erkennung aktiv wird.

Beide erfordern Entra ID P2. Verfügt Ihr Tenant nur über P1 oder Free, lösen diese als die generische Erkennung Additional risk detected ohne weitere Details aus.

Missbrauch von MFA-Push-Genehmigungen, kurz gefasst

Hier sind zwei native Entra-Signale relevant: Suspicious MFA authentication approval (authenticatorPhishing) ist eine Echtzeit-Erkennung, die nur mit P2 verfügbar ist und ASN-, Browser-, Geräte- und GPS-Abweichungen zwischen dem Gerät, das die Anmeldung anfordert, und dem Gerät, das sie über Microsoft Authenticator genehmigt, korreliert, und diese Paarung direkt als High Risk markiert. User reported suspicious activity (userReportedSuspiciousActivity) löst aus, wenn ein Nutzer eine nicht selbst ausgelöste MFA-Aufforderung ablehnt und dies explizit meldet — Microsoft behandelt dies als hochverlässlichen, nutzerbestätigten Nachweis und setzt das Konto sofort auf High User Risk. Nur Letzteres hängt davon ab, dass die Funktion Report suspicious activity aktiviert ist; authenticatorPhishing löst automatisch aus der Sign-in-Telemetrie aus und benötigt kein separates Opt-in. Die vollständige Angriffskette und Härtungssequenz (Number Matching, Phishing-resistente MFA für Admins, Reaktionsworkflow) finden Sie im oben verlinkten dedizierten Artikel.

Spitzen bei Service-Principal-Anmeldungen

Workload-Identitäten erscheinen nicht in derselben SigninLogs-Tabelle wie Nutzer — sie protokollieren in AADServicePrincipalSignInLogs (je nach Workspace-/Tabellenbenennung auch als ServicePrincipalSignInLogs bezeichnet). Thomas Naunheims Leitfaden zur Auditierung von Managed Identities und Service Principals empfiehlt, nach ServicePrincipalName und IPAddress zu gruppieren und dann Fehleranzahlen (ResultType != "0") sowie die Diversität der zugegriffenen Ressourcen (dcount(ResourceDisplayName)) zu aggregieren — eine Spitze in einer der beiden Dimensionen, insbesondere von einer IP oder ASN, die der Service Principal noch nie genutzt hat, ist das Signal, dem nachgegangen werden sollte. Microsoft Entra ID Protection verfügt zudem über eine dedizierte Erkennungsfläche für Workload-Identitätsrisiko genau für dieses Szenario, getrennt vom Nutzerrisiko.

Ungewöhnliche Geografie bei Admin-Konten

Microsofts eigener Leitfaden für Security Operations bei privilegierten Konten macht deutlich, dass Admin-Anmeldungen eine strengere, separate Überwachung verdienen als Standardnutzer — neues Gerät oder neuer Standort, Anmeldungen außerhalb der erwarteten Arbeitszeiten und jede Entra-ID-Protection-Risikoerkennung (auf jeder Risikostufe) bei einer privilegierten Identität sollten allesamt einen hochprioren Alert auslösen. Derselbe Leitfaden empfiehlt, jede Unfamiliar sign-in- oder aus TOR stammende Aktivität gegen eine privilegierte Rolle als sofort prüfungswürdig zu behandeln, statt zu warten, bis sie zu High Risk eskaliert.

Erkennung: Was aus den Logs zu ziehen ist

Das Microsoft-Entra-Token-Theft-Playbook liefert konkrete Startabfragen für SigninLogs, AADUserRiskEvents und AuditLogs. Hier angepasst für das AiTM-/Reise-/Admin-Geo-Signalset:

Risikoerkennungen finden, die als unfamiliar oder anomalous von einer bestimmten IP markiert sind (Ausgangspunkt, sobald eine verdächtige IP aus einer Phishing-Meldung oder EDR-Warnung vorliegt):

AADUserRiskEvents
| where RiskEventType contains "unfamiliar" or RiskEventType contains "anomalous"
| where IpAddress == "<suspect-ip>"

Jede Anmeldung von derselben Quell-IP abrufen, um den Blast-Radius abzugrenzen:

SigninLogs
| where IPAddress == "<suspect-ip>"

Anmeldegeografie und Geräte einer bestimmten Identität als Baseline erfassen — dies ist die Abfrage, die das Playbook empfiehlt, bevor entschieden wird, ob eine markierte Anmeldung für diesen Nutzer tatsächlich anomal ist:

SigninLogs
| where UserId == "<user-object-id>"
| extend deviceId_ = tostring(DeviceDetail.deviceId)
| extend city_ = tostring(LocationDetails.city)
| extend countryOrRegion_ = tostring(LocationDetails.countryOrRegion)
| summarize min(TimeGenerated), max(TimeGenerated)
  by IPAddress, ResultDescription, deviceId_, city_, countryOrRegion_, AppDisplayName

Das Playbook weist ausdrücklich darauf hin, dass nicht jeder Entra-Risiko-Alert eine passende Zeile in SigninLogs hat — insbesondere Anomalous-Token-Erkennungen sind manchmal nur über AADUserRiskEvents oder die Risk-Detections-API von ID Protection sichtbar, nicht über den rohen Sign-in-Stream.

Spitze bei Service Principals, angepasst nach der Auditierungsanleitung von cloud-architekt.net:

AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(1d)
| where ResultType != "0"
| summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated),
    count(), applicationCount = dcount(ResourceDisplayName),
    applicationSet = make_set(ResourceDisplayName)
  by ServicePrincipalName, IPAddress, ResultType

Für die Geografie privilegierter Konten und die Überwachung von MFA-Ablehnungen stellt Microsoft fertige Sentinel-Inhalte bereit, statt einer einzelnen Abfrage zum Abtippen — der Security-Operations-Leitfaden für privilegierte Konten verweist auf benannte Vorlagen wie SuspiciousSignintoPrivilegedAccount.yaml, MFARejectedbyUser.yaml und AADPrivilegedAccountsFailedMFA.yaml im Azure-Sentinel-GitHub-Repository, was eine bessere Quelle der Wahrheit ist, als die exakte Filterlogik hier zu rekonstruieren.

Remediation

Bei AiTM / Token-Replay:

1. Privilegierte und hochwertige Konten auf Phishing-resistente MFA umstellen (FIDO2-Sicherheitsschlüssel oder zertifikatsbasierte Authentifizierung) — ein per Proxy erfasstes Sitzungscookie nützt einem Angreifer deutlich weniger, wenn sich die ursprüngliche Authentifizierungszeremonie nicht einfach weiterleiten lässt. Warum Standard-Push-MFA allein nicht ausreicht, erklärt Azure Identity Security: Warum MFA allein nicht reicht.
2. Continuous Access Evaluation und den Conditional-Access-Token-Schutz dort aktivieren, wo unterstützt, damit ein an ein Gerät gebundenes Token nicht einfach von Angreiferinfrastruktur aus wiederverwendet werden kann. Der Katalog von EtcSec erfasst diese Lücke direkt als CA_TOKEN_PROTECTION_DISABLED — siehe Entra ID Conditional-Access-Lücken für die breitere Richtlinienprüfung.
3. Die Erkennungen Attacker in the Middle und Anomalous token aktivieren (erfordert P2, für Erstere zusätzlich Defender for Cloud Apps) und in eine Sign-in-Risk-Conditional-Access-Richtlinie einbinden, statt sie nur als Dashboard-Sichtbarkeit stehen zu lassen.
4. Einen bestätigten AiTM-Treffer als Token-Theft-Incident behandeln, nicht als Passwort-Reset: den Containment-Schritten aus Microsofts Token-Theft-Playbook folgen — Sitzungen widerrufen, die Angreifer-IP blockieren und nach neu registrierten MFA-Methoden oder Mailbox-Regeln suchen, die nach Nutzung der Sitzung zurückgelassen wurden.

Bei unmöglichen / atypischen Reisen:

1. Lizenzierung prüfen — Atypical Travel ist nativer Bestandteil von ID Protection P2, Impossible Travel benötigt zusätzlich eine verbundene Defender-for-Cloud-Apps-Instanz. Fehlt diese Verbindung, fällt das Signal mcasImpossibleTravel still weg.
2. Das 14-Tage-/10-Anmeldungen-Lernfenster für neue oder kürzlich migrierte Konten abschließen lassen, bevor Schwellenwerte anhand verrauschter Anfangsdaten justiert werden.
3. Das Sign-in-Risiko in eine Conditional-Access-Richtlinie einspeisen, die bei mittlerem/hohem Risiko MFA verlangt oder blockiert, statt den Risky-Sign-ins-Bericht nur reaktiv zu prüfen.

Bei Missbrauch von MFA-Push-Genehmigungen: Number Matching und die Funktion Report suspicious activity aktivieren und Phishing-resistente MFA für Administratoren verlangen — die vollständige Sequenz finden Sie im dedizierten MFA-Fatigue-Artikel.

Bei Spitzen bei Service Principals:

1. AADServicePrincipalSignInLogs regelmäßig auf Baseline- versus Spitzenverhalten prüfen, nicht nur während der Incident Response.
2. Keine dauerhaften High-Privilege-Rollen auf Service Principals belassen; Client-Secrets/Zertifikate nach festem Zeitplan rotieren und, wo möglich, Managed Identities bevorzugen.
3. Die Workload-Identity-Risikoerkennungen von Entra ID Protection aktivieren, sofern lizenziert — Nutzerrisiko-Richtlinien decken Service Principals nicht ab.

Bei ungewöhnlicher Admin-Geografie:

1. Alle privilegierten Rollen in Privileged Identity Management (PIM) mit zeitgebundener Aktivierung einschreiben und bei Aktivierung eine erneute Authentifizierung verlangen.
2. Bei jeder ID-Protection-Risikoerkennung gegen eine privilegierte Identität Alarm schlagen, unabhängig von der Risikostufe, die Microsoft zuweist — Microsofts eigener Leitfaden für privilegierte Konten empfiehlt diese strengere Messlatte gegenüber Standardnutzern.
3. Admin-Elevation, wo machbar, auf freigegebene Geräte (PAW/SAW) beschränken und Alarm auslösen, wenn Elevation außerhalb dieser Gerätegruppe stattfindet.

Wie EtcSec das erkennt

Die Kategorien Risk Protection und Conditional Access von EtcSec prüfen, ob ein Tenant über das Richtlinien- und Lizenz-Gerüst verfügt, von dem diese Erkennungen abhängen — nicht nur, ob Entra ID Protection aktiviert ist. Relevante Katalog-Checks umfassen auf Signalebene MFA_SUSPICIOUS_ACTIVITY (verdächtige MFA-/Sign-in-Aktivitätsmuster) und MFA_UNUSUAL_LOCATION (MFA-Anmeldung von ungewöhnlichem Geostandort), sowie auf Reaktionsebene RISK_NO_SIGNIN_RISK_POLICY (keine Sign-in-Risk-Richtlinie, die eine Reaktion erzwingt), RISK_SIGNINS_NOT_INVESTIGATED (riskante Anmeldungen häufen sich ohne Prüfung) und CA_TOKEN_PROTECTION_DISABLED (keine Token-Bindung, um Replay zu erschweren).

Ein Tenant, der im Portal riskante Anmeldungen anzeigt, aber keine darauf reagierende Richtlinie hat und keinen Token-Schutz vor Sitzungscookies, ist genau die Lücke, die diese Checks aufdecken sollen.

Verwandte Kontrollen

Lesen Sie dazu auch Azure Identity Protection: Geleakte Anmeldedaten blockieren zur Konfiguration der Sign-in- und Nutzerrisiko-Richtlinien, MFA Fatigue: Erkennung und Prävention für Microsoft Entra ID zur Angriffskette bei Push-Genehmigungen, Azure Privileged Access: Zu viele globale Admins und Wie man Microsoft Entra ID Security auditiert zur PIM- und Admin-Härtungsseite sowie OAuth-Consent-Phishing und bösartige Apps und Device-Code-Phishing in Entra ID zu angrenzenden Identity-Phishing-Techniken, die in dieselben Risikosignale einfließen.

Primärquellen

• Microsoft Learn: What are risk detections? (Entra ID Protection)
• Microsoft Learn: Token theft playbook
• Microsoft Learn: Security operations for privileged accounts
• Microsoft Learn: Securing workload identities with Entra ID Protection
• Microsoft Learn: How number matching works in MFA push notifications
• MITRE ATT&CK: Steal Web Session Cookie (T1539)
• nicolonsky/ITDR: AiTM phishing detection in Entra ID
• cloud-architekt.net: Sign-in logs and auditing of managed identities and service principals
• Microsoft Security Blog: Defending against evolving identity attack techniques
• Elastic Security Labs: Microsoft Entra ID OAuth phishing and detections