Révocation sessions Entra ID : le reset mot de passe échoue — Akuity SOC

Face à une alerte d'usurpation de compte consécutive à une attaque par hameçonnage de type Adversary-in-the-Middle (AiTM), le réflexe pavlovien de nombreuses équipes de sécurité consiste à changer immédiatement le mot de passe de l'utilisateur impacté. Pourtant, sur l'infrastructure d'identité en nuage moderne telle que Microsoft Entra ID, cette action seule s'avère totalement inefficace pour neutraliser un adversaire actif. En exploitant la technique MITRE ATT&CK T1539 (Steal Web Session Cookie), l'attaquant intercepte des cookies d'authentification post-MFA (comme ESTSAUTH ou ESTSAUTHPERSISTENT) et des jetons de rafraîchissement (OAuth Refresh Tokens), s'affranchissant définitivement du mot de passe initial.

L'anatomie de l'angle mort : persistance par jetons et latence du CAE

Lorsqu'une session utilisateur est négociée, Microsoft Entra ID émet deux artefacts majeurs : un jeton d'accès (Access Token, d'une durée de vie par défaut de 60 à 90 minutes) et un jeton de rafraîchissement (Refresh Token, pouvant vivre jusqu'à 90 jours s'il est renouvelé continuellement). La réinitialisation du mot de passe via l'Active Directory local synchronisé (Entra Connect) ou nativement dans le cloud n'invalide pas instantanément les jetons d'accès déjà émis et en circulation.

Bien que le protocole Continuous Access Evaluation (CAE) apporte une révocation quasi temps réel pour les applications compatibles (Exchange Online, SharePoint Online, Teams), de nombreuses applications tierces et flux API OAuth non-CAE demeurent totalement insensibles à la mise à jour du mot de passe. L'attaquant dispose ainsi d'une fenêtre de tir critique de plusieurs dizaines de minutes pour exfiltrer des boîtes courriels via Microsoft Purview, configurer des règles de boîte de réception malveillantes ou persister via l'enregistrement de nouvelles applications d'entreprise dans Microsoft Entra ID.

Détection dans Advanced Hunting (KQL) : persistance post-réinitialisation

Pour traquer les adversaires qui continuent d'utiliser une session volée après une tentative naïve de remédiation par mot de passe, nous devons corréler les événements de changement de mot de passe collectés par Defender for Identity avec les flux de connexion non-interactives supervisés dans Defender for Endpoint et Microsoft Entra ID via la table AADSignInEventsBeta.

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

Cette requête de chasse avancée (KQL) met en évidence les sessions qui maintiennent un trafic non interactif immédiatement après le renouvellement d'identifiants, révélant des requêtes issues d'adresses IP disparates ou de pays incohérents avec la géolocalisation légitime de l'utilisateur.

Remédiation chirurgicale avec le SOAR Akuity SOC

Neutraliser une compromission de session T1539 requiert une réponse en profondeur sans friction opérationnelle disproportionnée. Le moteur de réponse aux incidents d'Akuity SOC standardise et fiabilise cette démarche :

• Décodage et inspection in-app des claims : L'assistant IA in-app d'Akuity SOC décode et valide instantanément les claims du token sans aucune fuite vers des utilitaires web tiers, éliminant tout risque d'exfiltration de secrets industriels ou de jetons sensibles.
• Révocation granulaire et marquage du risque : Déclenchement direct depuis l'inventaire des éléments de preuve des fonctions revokeSessions() et confirmUserCompromised() via Microsoft Graph API, purgeant l'ensemble des refresh tokens, appliquant la réévaluation CAE immédiate et basculant le statut de l'utilisateur en High Risk au sein des politiques de Conditional Access.
• Traçabilité et conformité réglementaire : L'exécution de cette remédiation est protégée par un challenge d'élévation MFA AAL2 obligatoire imposé à l'analyste, et l'ensemble des actions est consigné dans un journal d'audit immuable certifié conforme aux exigences NIS 2 et SOC 2 Type II.

Mini-FAQ Technique

Pourquoi la révocation globale des sessions ne déconnecte-t-elle pas instantanément toutes les applications ?

La commande de révocation invalide les jetons d'actualisation (Refresh Tokens) et les sessions de navigateur. Toutefois, les jetons d'accès JWT déjà délivrés (Access Tokens) restent valides jusqu'à leur expiration intrinsèque (durée typique de 60 minutes), sauf si la ressource cible implémente le protocole Continuous Access Evaluation (CAE) de Microsoft Entra ID.

Quelle est la différence entre revokeSignInSessions et confirmUserCompromised ?

revokeSignInSessions force la réauthentification de l'utilisateur sur tous ses terminaux en révoquant ses jetons de rafraîchissement. L'action confirmUserCompromised élève le niveau de risque d'identité au niveau Élevé (High), activant instantanément les règles strictes de Conditional Access pour bloquer tout accès futur tant qu'une réinitialisation sécurisée n'a pas été achevée.