Changer de mot de passe peut laisser une session volée utilisable. Découvrez comment s’articulent le confinement du terminal, l’invalidation des jetons, le contrôle des sessions applicatives et la récupération du compte.
Une application web peut conserver une session active après un changement du mot de passe du compte. Selon ses capacités, un logiciel voleur d’informations peut collecter les mots de passe enregistrés, mais aussi les cookies de session, les jetons d’authentification, les clés API et d’autres données locales. Si ces informations ont quitté l’appareil, supprimer le logiciel malveillant ne les invalide pas.
Un mot de passe est un secret fourni lors de l’authentification. Un jeton d’accès permet à une application d’accéder à des ressources précises, tandis qu’un jeton de renouvellement permet d’obtenir un nouveau jeton d’accès lorsque le protocole l’autorise. Une session applicative se poursuit généralement au moyen d’un cookie ou d’un secret de session distinct, émis après l’authentification. Ces mécanismes peuvent être rattachés au même compte sans pour autant avoir la même durée de validité ni dépendre du même mécanisme de révocation.
Quels accès peuvent subsister après un changement de mot de passe ?
Un changement de mot de passe empêche les nouvelles connexions qui reposent sur l’ancien mot de passe. Il ne faut pas en déduire que tous les jetons ou toutes les sessions applicatives encore valides sont désactivés. Selon les consignes de Microsoft pour révoquer les accès en urgence dans Entra, le blocage des nouvelles connexions et la révocation des jetons de renouvellement empêchent l’utilisateur d’obtenir de nouveaux jetons Entra. Un jeton d’accès existant peut toutefois fonctionner jusqu’à la fin de sa durée de validité par défaut, qui est d’une heure. Continuous Access Evaluation peut raccourcir ce délai dans les cas pris en charge par Microsoft 365 ; cela ne garantit pas l’invalidation immédiate de tous les jetons.
Un cookie de session émis par une application doit être traité séparément. Entra ne peut pas révoquer directement un jeton de session émis par l’application elle-même. NIST SP 800-63B-4 décrit cette même séparation dans les systèmes fédérés : le fournisseur d’identité (IdP) et la partie utilisatrice (RP) établissent leurs sessions et y mettent fin indépendamment l’un de l’autre. Mettre fin à la session du fournisseur d’identité ne met pas, à lui seul, fin aux sessions de toutes les applications connectées.
Cette distinction peut profiter à un attaquant. MITRE ATT&CK explique comment un cookie de session web volé, encore valide et réutilisable, peut être importé dans un navigateur contrôlé par un attaquant. La session étant déjà authentifiée, certains parcours d’authentification peuvent ne pas exiger une nouvelle étape de MFA. Il s’agit d’une possibilité technique, et non d’une preuve qu’un compte donné a été pris sous le contrôle d’un attaquant.
Confinement du terminal et mesures de contrôle des comptes
Le terminal potentiellement compromis est isolé conformément au plan de réponse aux incidents de l’organisation, tandis que la nécessité de préserver les éléments de preuve pertinents est évaluée. Si le compte dispose de privilèges élevés ou donne accès à des données sensibles, le blocage des nouvelles connexions et la fermeture des voies d’accès existantes peuvent commencer avant la fin de l’analyse complète du terminal. Les changements de mot de passe, la récupération du compte et les opérations d’administration s’effectuent depuis un appareil de confiance et par un canal de confiance, afin de ne pas exposer les nouveaux identifiants au système suspect.
Données d’accès stockées sur l’appareil
L’examen ne se limite pas aux mots de passe enregistrés après le début présumé de l’infection. La date de début d’une infection peut être incertaine, et un logiciel voleur d’informations peut accéder à des identifiants déjà stockés sur l’appareil. Selon les éléments de preuve relatifs à l’incident, l’examen porte sur les profils de navigateur, les comptes utilisés ou enregistrés localement, les cookies de session, les jetons et les clés API. Nettoyer ou réinstaller le terminal n’invalide pas les mots de passe, les jetons ou les clés qui ont peut-être déjà été dérobés.
Mesures de contrôle des jetons et des sessions
Les mécanismes documentés par le fournisseur d’identité servent à bloquer les nouvelles connexions, à invalider les jetons de renouvellement lorsque cette opération est prise en charge et à mettre fin aux sessions de l’IdP. Les applications critiques sont ensuite vérifiées séparément, et leurs propres sessions sont fermées au moyen des contrôles disponibles dans chaque application. Un message de « succès » sur un écran d’administration ne prouve pas que tous les accès ont pris fin. Le type de jeton, les conditions prévues de son expiration et le moment où chaque application exigera une nouvelle authentification restent déterminants.
Le mot de passe et les autres données d’accès compris dans le périmètre de l’incident sont remplacés ou invalidés depuis un appareil de confiance. L’inclusion d’une clé API, d’un jeton de développeur ou d’un autre identifiant stocké localement dépend des éléments de preuve relatifs à l’incident et du comportement du système concerné. L’objectif n’est pas de réinitialiser tous les comptes à l’aveugle, mais de déterminer quels mots de passe, jetons, clés ou cookies de session ont pu quitter l’appareil et restent utilisables.
Modifications visant à maintenir l’accès
Un intrus peut ajouter un moyen de revenir dans le compte plutôt que de s’appuyer uniquement sur la session en cours. Les consignes de Microsoft pour traiter la compromission d’un compte de messagerie Microsoft 365 préconisent de vérifier les méthodes MFA et les appareils non reconnus, les consentements indésirables accordés aux applications, les rôles d’administration non autorisés, le transfert des messages et les règles masquées de la boîte de réception. Cette liste est propre à Microsoft 365 ; les contrôles équivalents et leurs effets varient selon les fournisseurs.
Une méthode MFA non reconnue ou suspecte est supprimée ou invalidée. Si la méthode de l’utilisateur légitime doit être réenregistrée, l’identité du titulaire du compte est d’abord vérifiée par un canal de récupération de confiance, puis seule une nouvelle méthode contrôlée par cet utilisateur est enregistrée. Réenregistrer une méthode ajoutée par un attaquant maintiendrait la voie d’accès au lieu de la fermer.
La MFA ne révoque pas une session active
La MFA ajoute un obstacle à l’ouverture d’une nouvelle session avec un mot de passe volé, mais elle n’invalide pas à elle seule un cookie réutilisable issu d’une authentification antérieure. Les méthodes MFA offrent également des protections différentes. Les exigences du NIST relatives aux moyens d’authentification ne considèrent pas les codes à usage unique saisis manuellement comme résistants à l’hameçonnage et citent WebAuthn/FIDO2 comme exemple d’authentification résistante à l’hameçonnage. Une authentification renforcée protège les connexions futures ; une session volée qui reste valide doit toujours être fermée séparément.
Ce que les journaux permettent — et ne permettent pas — d’établir
Lorsqu’ils sont disponibles, les journaux de connexion et d’actions sensibles couvrant la période de l’incident peuvent révéler des lieux ou des horaires inhabituels, des autorisations accordées aux applications et des modifications du compte. Pour Microsoft 365, le fournisseur déconseille de restreindre trop tôt la recherche d’audit initiale et recommande d’examiner les enregistrements depuis le début de l’activité suspecte jusqu’aux mesures correctives. Ne trouver aucun événement suspect ne prouve pas que le compte est sûr. Le résultat n’a de sens qu’au regard des données de télémétrie disponibles, de leur durée de conservation, des sources interrogées et de la période examinée.
De même, la preuve qu’un identifiant ou un cookie a été exposé ne constitue pas, à elle seule, une preuve d’utilisation non autorisée réussie ou de prise de contrôle du compte. L’exposition, la tentative d’utilisation observée et la prise de contrôle confirmée restent distinctes. Les voies d’accès potentiellement valides nécessitent néanmoins une réponse proportionnée, dont le périmètre dépend des privilèges du compte, de la sensibilité des données et des éléments de preuve disponibles. Le guide de LeakData sur l’évaluation après une fuite de données aborde cette distinction plus générale entre exposition et utilisation abusive confirmée.
Le dossier de l’incident répertorie les sessions fermées chez le fournisseur d’identité et dans les applications, les conditions prévues d’expiration des jetons, les modifications non autorisées supprimées et les lacunes de l’examen des journaux. Il permet ainsi de préciser quelles voies d’accès ont été traitées et quelles incertitudes subsistent.
Références
Microsoft Learn — Révoquer l’accès d’un utilisateur en urgence dans Microsoft Entra ID
Microsoft Learn — Traiter la compromission d’un compte de messagerie dans Microsoft 365
NIST SP 800-63B-4 — Exigences relatives aux moyens d’authentification
Specops Software — Au cœur des attaques par logiciels voleurs d’informations