Comptes et authentification
Particuliers et entreprisesVol et détournement de session
Session hijacking
Une preuve de connexion volée permet de réutiliser votre session sans vous.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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 permet à un service de se souvenir que vous êtes connecté. Votre navigateur conserve souvent un petit élément qui vous identifie, comme un badge. Si quelqu’un vole ce badge et peut le réutiliser, il peut profiter de votre connexion. Changer le mot de passe ne désactive pas toujours les sessions existantes. Déconnectez les appareils depuis les réglages du compte et sécurisez celui sur lequel le vol a eu lieu.
- 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.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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 les sessions retirées ne peuvent plus ouvrir de ressources protégées. Contrôlez aussi les sessions propres aux applications et les jetons qui permettent de renouveler l’accès.
Un attaquant peut parfois réutiliser une session déjà validée même si la double authentification est active et que le mot de passe n’a pas changé.
À vous de décider
Fermer un onglet sur votre ordinateur invalide-t-il une copie volée de votre session ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Fermer l’onglet ne retire pas la preuve de connexion que le service accepte encore. Utilisez la fonction de déconnexion des sessions, puis vérifiez les accès restants.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Une session reste utilisable après le changement de mot de passe
Un cookie ou un jeton permet souvent de rester connecté sans retaper son mot de passe. S’il est volé, il peut donner accès à une session déjà authentifiée, parfois avec une MFA déjà validée. L’attaquant peut donc l’utiliser sans casser le mot de passe ni franchir un nouveau contrôle du second facteur à cet instant.
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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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é ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- CampagneCampagnes utilisant EvilProxy
Intercepter une session malgré la double authentification
Proofpoint décrit un faux site de connexion qui transmet les échanges au vrai service. Les attaquants récupèrent les identifiants et les cookies de session, puis les utilisent pour entrer dans les comptes, même lorsque certaines méthodes 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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
