Comptes et authentification
Particuliers et entreprisesVol et détournement de session
Session hijacking
Une preuve de connexion volée permet d’utiliser une session déjà ouverte.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Vous vous êtes connecté à un service puis avez fermé la page. Un logiciel malveillant récupère la preuve que votre navigateur utilisait pour rester connecté. L’attaquant tente de la réutiliser sans connaître votre mot de passe. Il peut obtenir un accès jusqu’à l’expiration ou la révocation de cette session.
Comment cela fonctionne
Une session est la continuité d’une connexion. Le navigateur conserve souvent un petit élément qui permet au service de vous reconnaître. Si cet élément est volé et réutilisable, il peut agir comme un badge. Changer le mot de passe ne désactive pas toujours ce badge. Il faut utiliser les fonctions de déconnexion des appareils et sécuriser l’appareil à l’origine du vol.
- Une connexion crée un badge
Le service reconnaît la session.
- Le badge est copié
Un tiers tente de le réutiliser.
- Le service accepte la copie
Le tiers agit avec les droits de la session tant qu’elle reste valide.
Les signes qui doivent attirer l’attention
- Des actions apparaissent sans nouvelle connexion visible de votre part.
- Un appareil ou une session inconnue est signalé.
- Une infection du navigateur ou une extension non autorisée a été détectée.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Gardez le navigateur à jour et limitez ses extensions. Si une session est volée, utilisez « Déconnecter les appareils » depuis un appareil fiable, puis faites traiter le poste suspect.
Si vous êtes responsable du service ou de l’organisation
Vérifiez que la révocation bloque réellement l’accès aux ressources protégées. Couvrez les sessions locales des applications et leurs jetons de renouvellement.
Un mot de passe inchangé ou une MFA activée n’empêche pas toutes les réutilisations d’une session déjà authentifiée.
À vous de décider
Fermer un onglet sur votre ordinateur invalide-t-il une copie volée de votre session ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Fermer une page ne révoque pas le badge de connexion conservé par le service. Utilisez la déconnexion des sessions et vérifiez les accès restants.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Une session reste utilisable après le changement de mot de passe
Un cookie ou un jeton de session permet souvent de continuer à travailler sans ressaisir le mot de passe. Celui qui le vole peut donc disposer d’un accès déjà authentifié, parfois marqué comme ayant satisfait la MFA. Il n’a pas nécessairement cassé le mot de passe ni contourné le facteur au moment de l’utilisation.
Dans le cas présenté, l’empreinte de session fp7 apparaît depuis le réseau habituel puis depuis un hébergeur, avec un client différent. Le changement de mot de passe est suivi d’une réponse 200. Ce statut ne suffit pas : il faut vérifier que la requête a réellement obtenu une ressource protégée avec cette session, et non une page publique ou une erreur renvoyée en HTTP 200.
Une adresse différente peut s’expliquer par un VPN. L’empreinte stable du jeton et les actions réalisées rendent le rapprochement plus solide. Pour fermer l’accès, vérifier séparément la révocation de la session, des jetons de renouvellement et des éventuelles délégations. Leur durée de validité et leurs mécanismes de révocation dépendent du service.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Authentification initiale
Navigateur légitime vers Service d’identité
Trace login u2
- Réponse
Session délivrée
Service d’identité vers Navigateur légitime
Trace empreinte fp7
- Action
Requête habituelle
Navigateur légitime vers Application
Trace réseau office
- Action
Même session, autre contexte
Client de rejeu vers Application
Trace export à t145
- Action
Mot de passe modifié
Navigateur légitime vers Service d’identité
Trace t150
- Action
Réponse reçue après changement du mot de passe
Client de rejeu vers Application
Trace HTTP 200 à t160 : vérifier le contenu renvoyé
- Refus / blocage
Invalidation vérifiée
Service d’identité vers Application
Trace ancienne version refusée
Comment repérer cette attaque
Indices à rechercher
Chercher l’utilisation rapprochée d’une même session depuis des environnements incompatibles et les actions non reconnues, y compris sans nouvelle authentification.
Éléments à croiser
Suivre la même session applicative entre deux contextes, puis vérifier si les requêtes postérieures à la révocation ont été acceptées. Le lien doit être établi par le service, pas supposé depuis la seule adresse IP.
Limites de l’interprétation
Une IP ou un navigateur qui change peut s’expliquer légitimement. La persistance d’un accès après changement de mot de passe peut venir de la politique de session : elle ne prouve pas à elle seule un vol de cookie.
Comment réagir
Révoquer les sessions de la bonne portée, invalider les jetons de renouvellement et traiter le poste ou le navigateur à l’origine de l’exposition. Vérifier les changements de facteurs et de permissions. Tester le refus de l’ancienne valeur sur chaque service, plutôt que conclure à partir du seul succès de l’API de révocation.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Une session révoquée ne peut plus lire une ressource protégée sur aucune instance de l’application.
- Les jetons de renouvellement et délégations concernés sont invalidés selon le mécanisme du service.
- Les sessions légitimes et le parcours de récupération restent utilisables après la correction.
À vous de raisonner
Après révocation, un ancien cookie reçoit encore une réponse HTTP 200. Est-ce suffisant pour dire que la révocation a échoué ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Vérifiez le contenu et la ressource demandée : une page publique ou une erreur peut aussi être renvoyée avec le statut 200. L’échec est établi si l’ancienne session permet encore un accès protégé. Vérifiez également les jetons de renouvellement et les différentes instances du service.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
session_fp- Empreinte fictive non réutilisable pour suivre la session. Ce champ n’est pas automatiquement commun à Entra, au proxy et à l’application.
Authentification et accès applicatifs
JSONLLes empreintes servent à la corrélation. Une clé de HMAC séparée et une durée de conservation limitée réduisent leur exposition.
{"ts":100,"event":"login","user":"u2","session_fp":"fp7","device":"managed-1"}
{"ts":140,"event":"request","session_fp":"fp7","route":"/profile","network":"office","ua_family":"A"}
{"ts":145,"event":"request","session_fp":"fp7","route":"/export","network":"hosting","ua_family":"B"}
{"ts":150,"event":"password_changed","user":"u2"}
{"ts":160,"event":"request","session_fp":"fp7","route":"/export","status":200}Préparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Dans le service utilisé, chercher création et révocation de session, accès aux ressources, IP et User-Agent. Un identifiant de session pseudonymisé peut servir au rapprochement ; ne jamais copier le cookie ou jeton utilisable.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Microsoft Entra ID — Sign-in logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Sign-in logs. Examiner séparément les connexions interactives, non interactives et celles des applications si elles sont concernées.
- Quoi relever
- Comparer les authentifications du compte à l’activité applicative. Une session déjà valide peut être réutilisée sans nouvel événement de saisie de mot de passe ou de MFA.
- Accès et prérequis
- Rôle de lecture adapté, par exemple Reports Reader. Vérifier la période conservée et les exports disponibles ; une session applicative n’engendre pas nécessairement une nouvelle connexion Entra.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- CampagneCampagnes utilisant EvilProxy
Intercepter une session malgré la double authentification
Proofpoint décrit des campagnes où un faux point de connexion relaie les échanges avec le vrai service. Les attaquants récupèrent les identifiants et les cookies de session pour accéder aux comptes, même lorsque certaines formes de MFA sont activées.
Ce qu’établit la source. EvilProxy est un service et un kit d’hameçonnage utilisé par plusieurs acteurs. Ce rapport ne permet pas d’attribuer toutes ces campagnes à un groupe unique.
Consulter le rapport Cloud Account Takeover Campaign Leveraging EvilProxy Targets Top-Level ExecutivesProofpoint · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
- Révoquez les sessions concernées depuis un appareil fiable.
- Traitez l’origine du vol avant de vous reconnecter depuis le poste suspect.
- Vérifiez les actions, autorisations et moyens de récupération modifiés.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- OWASP — Session Management — cheatsheetseries.owasp.org
- MITRE ATT&CK — Web Session Cookie — attack.mitre.org
- OWASP — journalisation — cheatsheetseries.owasp.org
