Entra ID Sitzungswiderruf: Warum Passwort-Reset scheitert — Akuity SOC

Nach einem erfolgreichen Adversary-in-the-Middle (AiTM)-Phishing-Angriff besteht die typische Erstreaktion vieler Sicherheitsteams im sofortigen Zurücksetzen des Benutzerkennworts. In modernen Cloud-Identitätsarchitekturen wie Microsoft Entra ID ist diese Maßnahme allein jedoch wirkungslos, um Angreifer zu stoppen. Bei Anwendung der MITRE ATT&CK-Technik T1539 (Steal Web Session Cookie) erbeutet der Angreifer authentifizierte Post-MFA-Sitzungscookies (wie ESTSAUTH) sowie OAuth-Refresh-Tokens und umgeht damit den Kennwortschutz vollständig.

Die Architekturlücke: Token-Persistenz und CAE-Grenzen

Wird eine Sitzung etabliert, erzeugt Microsoft Entra ID zwei Artefakte: ein kurzlebiges Zugriffstoken (Access Token, Gültigkeit 60 bis 90 Minuten) und ein langlebiges Aktualisierungstoken (Refresh Token, Laufzeit bis zu 90 Tage bei regelmäßiger Nutzung). Ein Kennwort-Reset – ob via Microsoft Entra Connect aus dem lokalen Active Directory synchronisiert oder nativ in der Cloud ausgeführt – widerruft aktive Access Tokens nicht unmittelbar.

Obwohl Continuous Access Evaluation (CAE) für unterstützte Dienste (Exchange Online, SharePoint Online, Microsoft Teams) einen nahezu echtzeitfähigen Sitzungsabbruch bietet, sind zahlreiche Drittanbieter-Apps und REST-APIs nicht CAE-fähig. Angreifern verbleibt somit ein Zeitfenster von bis zu 90 Minuten, um Postfächer via Microsoft Purview zu durchsuchen, bösartige Weiterleitungsregeln zu aktivieren oder persistente Unternehmensanwendungen in Microsoft Entra ID zu registrieren.

Advanced Hunting Erkennung (KQL): Sitzungsaktivität nach Kennwort-Reset

Um unbefugte Aktivitäten nach einem Kennwort-Reset aufzudecken, müssen Ereignisse aus Defender for Identity mit den nicht-interaktiven Anmeldedaten aus Defender for Endpoint und Microsoft Entra ID in der Tabelle AADSignInEventsBeta korreliert werden.

let PasswordResets = IdentityDirectoryEvents
| where ActionType in ("Account Password Reset", "Account Password Change")
| project ResetTime = Timestamp, AccountUpn = tolower(TargetAccountUpn);
AADSignInEventsBeta
| where Timestamp > ago(24h) and IsInteractive == 0
| extend TargetUpn = tolower(AccountUpn)
| join kind=inner (PasswordResets) on $left.TargetUpn == $right.AccountUpn
| where Timestamp between (ResetTime .. (ResetTime + 90m))
| summarize 
    AccessCount = count(),
    DistinctApps = make_set(Application),
    IPs = make_set(IPAddress),
    Countries = make_set(Country)
    by AccountUpn, SessionId, ResetTime
| where array_length(IPs) > 0

Diese Advanced Hunting (KQL)-Abfrage filtert nicht-interaktive Anmeldungen heraus, die innerhalb von 90 Minuten nach einem Kennwortwechsel auftreten und von abweichenden IP-Adressen oder Geostandorten ausgehen.

Chirurgische Remediierung mit dem Akuity SOC SOAR

Die Unterbrechung eines T1539-Sitzungsdiebstahls erfordert koordinierte Reaktionsschritte. Die Incident-Response-Engine von Akuity SOC automatisiert diesen Prozess präzise:

• In-App Token-Claim-Dekodierung: Der integrierte KI-Assistent von Akuity SOC dekodiert und validiert Token-Claims direkt in der Plattform, ohne Daten an externe Webservices zu senden – wodurch das Risiko von Secret-Exfiltrationen ausgeschlossen wird.
• Granularer Sitzungsabbruch: Direkte Ausführung von revokeSessions() und confirmUserCompromised() via Microsoft Graph API aus dem Alert-Kontext heraus. Dies entwertet alle aktiven Refresh-Tokens, erzwingt CAE-Widerrufe und stuft das Benutzerkonto auf High Risk hoch, wodurch Conditional Access-Sperren greifen.
• AAL2-Authentifizierung und Revisionssicherheit: Jede Remediierungsmaßnahme erfordert eine zwingende MFA-Erhöhung (AAL2) durch den Analysten und wird in einem manipulationssicheren Prüfprotokoll nach NIS 2 und SOC 2 Type II Standards dokumentiert.

Technische FAQ

Warum beendet der globale Sitzungswiderruf nicht alle aktiven Verbindungen sofort?

Der globale Widerruf entwertet Refresh Tokens und Browser-Cookies. Access Tokens sind eigenständige JWTs, die von Ressourcen-Servern bis zu ihrem planmäßigen Ablauf (in der Regel 60 Minuten) akzeptiert werden, es sei denn, die Anwendung unterstützt das Continuous Access Evaluation (CAE)-Protokoll von Microsoft Entra ID.

Was unterscheidet revokeSignInSessions von confirmUserCompromised?

revokeSignInSessions entwertet alle aktiven Aktualisierungstoken und erzwingt eine Neuanmeldung des Anwenders. Der Aufruf von confirmUserCompromised stuft den Benutzer in Microsoft Entra ID Identity Protection auf das Risikoniveau 'Hoch' ein, wodurch strengere Richtlinien für bedingten Zugriff (Conditional Access) sofort aktiviert werden.