Ein Nutzerkonto zeigt Aktivität aus einem neuen Land, aber es gibt keinen fehlgeschlagenen MFA-Prompt. Wie untersuchst du das?

Vermute gestohlene Session Tokens oder einen Adversary-in-the-middle-Proxy statt eines Passwortangriffs. Zieh die Sign-in-Logs und vergleich Session IDs, Device IDs, User Agents und IP-Reputation gegen die Baseline dieses Nutzers. Ein wiedereingespieltes Token zeigt sich meist als bestehende Session ID, die von einer neuen Adresse ankommt. Widerruf Refresh Tokens, erzwing eine erneute Authentifizierung, und prüf dann Posteingangsregeln, registrierte MFA-Methoden und OAuth-App-Zustimmungen.

Kein fehlgeschlagenes MFA bei neuer Geografie deutet auf eine gestohlene Session statt auf ein erratenes Passwort, ich gehe also direkt in die Sign-in-Telemetrie. Ich vergleiche Session-Identifikator und Device-Identifikator gegen die Historie des Nutzers: wenn dieselbe Session ID von einer neuen Adresse mit einem anderen User Agent auftaucht, ist das ein wiedereingespieltes Token und kein frischer Login. Ich prüfe, ob Conditional Access überhaupt ausgewertet hat, und ob der ursprüngliche Sign-in über ein Proxy-Muster kam, das zu einem Adversary-in-the-middle-Phishing-Kit passt. Die Reihenfolge der Eindämmung zählt hier. Ein Passwort-Reset tötet kein bestehendes Refresh Token, ich widerrufe also zuerst Sessions und Refresh Tokens, dann Reset, dann erzwungene Neuauthentifizierung auf verwalteten Geräten. Danach jage ich Persistence: neue Posteingangsregeln, hinzugefügte OAuth-Zustimmungen, neu registrierte MFA-Methoden, Postfachdelegierungen. In dem Fall, den ich bearbeitet habe, hatte der Angreifer eine Regel angelegt, die alles mit dem Wort Rechnung in einen Archivordner einsortierte, und genau das hat das Motiv Business Email Compromise verraten.