Vol de cookies de session et jetons porteurs
Un cookie de session volé permet de se faire passer pour un salarié sans mot de passe ni second facteur. Mécanisme, cas réel et réflexes.
En 30 secondes
- Où ça arrive
- Sur le poste de travail (logiciel malveillant), sur un faux site qui relaie la vraie page de connexion1, ou dans un navigateur compromis8.
- Ce que veut l'attaquant
- Reprendre une session déjà ouverte, lire les messages et agir au nom de la victime, en contournant certains seconds facteurs2.
- Le réflexe
- Se déconnecter des services quand on a fini, révoquer ses sessions en cas de doute, fermer régulièrement les sessions du navigateur.
- Si c'est déjà fait
- Prévenir le support informatique sans attendre, car la session volée reste utilisable tant qu'elle est active2.
De quoi parle-t-on
Quand un salarié se connecte à sa messagerie ou à un outil en ligne, le service lui remet un petit élément d'identification, le plus souvent un cookie, qui prouve qu'il est déjà authentifié. Si un attaquant s'empare de cet élément, il peut entrer comme s'il était la victime, sans connaître son mot de passe1.
Côté salarié, rien de visible en général : sa session continue, son travail aussi. Cette fiche explique d'où vient le vol, ce qu'un attaquant en fait et ce que chacun peut faire pour réduire le risque.
Questions directes
Qu'est-ce qu'un cookie de session ?
Après une connexion réussie, de nombreuses applications web emploient un cookie de session comme preuve d'authentification1. Le protocole web ne retient pas, par lui-même, qui est qui d'une requête à l'autre : le serveur envoie donc au navigateur un jeton, que le navigateur présente ensuite à chaque échange3.
Qu'est-ce qu'un jeton d'accès, et en quoi diffère-t-il du cookie ?
Un jeton d'accès sert à faire des requêtes autorisées au nom d'un utilisateur ou d'un service. Il est courant dans les applications en ligne (SaaS) et les services cloud4. Les deux objets ont la même faiblesse : celui qui le présente est accepté comme la personne qui l'a obtenu. La SP 800-63B du NIST, version remplacée depuis le 1er août 2025 par la SP 800-63-4, précisait d'ailleurs que la présence d'un jeton d'accès OAuth ne doit pas être interprétée comme la présence de l'utilisateur en l'absence d'autres signaux, et qu'un tel jeton peut rester valable bien après la fin de la session d'authentification5.
Mon second facteur ne me protège-t-il pas ?
Il protège la connexion, pas la session qui suit. MITRE indique que cette technique contourne certains protocoles d'authentification multifacteur, puisque la session est déjà authentifiée2. Microsoft précise qu'il ne s'agit pas d'une faille de l'authentification multifacteur : le cookie volé authentifie l'attaquant quelle que soit la méthode de connexion de l'utilisateur6.
Combien de temps un cookie volé reste-t-il utilisable ?
Les cookies restent souvent valables longtemps, même si l'application n'est pas utilisée activement1. L'attaquant peut s'en servir tant que le cookie est actif2. L'OWASP note aussi qu'un délai d'inactivité ne limite pas un attaquant qui a pris la session : il peut générer de l'activité pour la maintenir ouverte7.
1Dans la peau de l'attaquant1 min
L'attaquant cherche un élément réutilisable plutôt qu'un secret à deviner. Les cookies se trouvent sur le disque, dans la mémoire du navigateur et dans le trafic réseau vers des systèmes distants. D'autres applications du poste peuvent aussi garder en mémoire des cookies d'authentification, par exemple celles qui se connectent à des services cloud1.
Une fois le cookie obtenu, l'attaquant l'importe dans un navigateur qu'il contrôle. Il utilise alors le site comme l'utilisateur, tant que la session est active. Il peut consulter des informations sensibles, lire des courriels ou faire ce que le compte de la victime a le droit de faire2.
Pour le jeton d'accès, une voie décrite est l'hameçonnage : l'attaquant enregistre une application piégée et envoie un lien pour inciter la victime à lui accorder l'accès. Une fois le jeton accordé, l'application peut obtenir un accès potentiellement durable au compte4. Les jetons d'accès ont parfois une durée de vie limitée, mais l'attaquant peut aussi voler un jeton de renouvellement, qui lui donne de nouveaux jetons d'accès sans rien demander à l'utilisateur4.
2Ce que vous voyez à l'écran1 min
Le salarié ne voit rien : des alertes peuvent exister côté administrateur (voir plus bas). Dans le cas d'un faux site relais (décrit plus bas), la page ressemble trait pour trait à la vraie : la seule différence visible est l'adresse6. Après la saisie du mot de passe, la victime est redirigée vers la page légitime, et l'attaque se poursuit en arrière-plan6.
Voici une illustration neutralisée d'une adresse de faux site relais. Elle est inventée pour l'exemple.
Illustration (adresse fictive, neutralisée) :
hxxps://login[.]exemple-connexion[.]invalid/
[page identique à la vraie page de connexion, seule l'adresse diffère]Quelques signes indirects existent. Si l'attaquant se connecte pendant que la victime travaille, des alertes de « déplacement impossible » peuvent apparaître côté administrateur6. Des règles de boîte de réception inconnues sont un autre signe : dans le cas décrit plus bas, l'attaquant en a créé une pour que la victime ne voie pas les réponses de sa cible6.
3Sous le capotÉquipes IT2 min
Trois voies de vol sont décrites par les sources citées ici.
- Le logiciel voleur : des logiciels malveillants ciblent les cookies des navigateurs présents sur le poste1. Certains extraient le cookie de session et l'envoient au serveur de l'attaquant1.
- Le faux site relais : dans l'attaque dite de l'intercepteur (adversary-in-the-middle), l'attaquant place un serveur mandataire entre l'utilisateur et le site visé. Il capte ainsi le mot de passe et le cookie de session6. Des outils libres comme Evilginx2, Modlishka et Muraena automatisent ce procédé6.
- Le navigateur compromis : un attaquant peut injecter du logiciel dans un navigateur pour hériter des cookies, des sessions HTTP et des certificats clients de l'utilisateur, puis s'en servir pour entrer dans un intranet authentifié8. Cette technique peut aussi contourner l'authentification à deux facteurs8. Elle peut exiger des droits particuliers sur le poste8.
Pourquoi le rejeu fonctionne-t-il ? Le cookie est la preuve de la connexion : le serveur ne revérifie pas le mot de passe à chaque page6. La SP 800-63B du NIST admet d'autres méthodes d'identification sûre de l'appareil, dont le TLS mutuel et la liaison de jeton (token binding)5. L'OWASP recommande de lier l'identifiant de session à d'autres propriétés du client, comme l'adresse IP ou le User-Agent. Il reconnaît cependant qu'un attaquant habile peut contourner ce contrôle, par exemple en partageant le même réseau que la victime ou en copiant le User-Agent7.
Du côté des durées, l'OWASP cite des délais d'inactivité courants de 2 à 5 minutes pour les applications à forte valeur et de 15 à 30 minutes pour les applications à faible risque. Pour un employé de bureau qui utilise une application toute la journée, il cite un délai absolu de 4 à 8 heures7. La SP 800-63B du NIST, remplacée depuis le 1er août 2025 par la SP 800-63-4, demandait que les secrets de session soient effacés ou invalidés à la déconnexion5.
4AutopsiesCas réels2 min
Campagne d'hameçonnage par faux site relais contre Microsoft 365 (documentée le 12 juillet 2022)
Le 12 juillet 2022, Microsoft publie l'analyse d'une campagne de grande ampleur. Selon ses données, elle a tenté de viser plus de 10 000 organisations depuis septembre 20216. Les attaquants ont utilisé des sites relais pour voler des mots de passe et détourner la session de la victime, même si l'authentification multifacteur était activée6.
Dans l'une des vagues observées, un courriel avec une pièce jointe HTML annonçait un message vocal. La pièce jointe affichait une fausse barre de téléchargement, puis redirigeait vers un site relais construit avec Evilginx2, qui reprenait la page de connexion de l'organisation6. La victime saisissait ses identifiants, était redirigée vers la page légitime office.com, et l'attaquant, lui, était authentifié en son nom6.
La suite visait la fraude au paiement. Selon Microsoft, il a fallu parfois cinq minutes seulement entre le vol et le début de la fraude. L'attaquant utilisait le cookie volé pour entrer dans la messagerie en ligne, parfois avec un cookie qui portait déjà la mention d'authentification multifacteur6. Il cherchait ensuite des échanges liés aux paiements, supprimait le courriel d'hameçonnage initial et créait une règle de boîte de réception qui archivait et marquait comme lues les réponses de sa cible, afin que la victime ne remarque rien6. Il supprimait enfin ses propres réponses des dossiers d'éléments envoyés et supprimés6.
Microsoft recommande des authentifications résistantes à l'hameçonnage (FIDO 2.0 ou certificats) et des politiques d'accès conditionnel, qui évaluent chaque tentative d'usage d'un cookie volé6.
5Ce que vous faites1 min
Ces gestes viennent des sources citées ici. Leur effet est de réduire la durée ou la portée d'une session volée, pas de garantir qu'elle ne le sera pas.
- Se déconnecter explicitement des services quand on a fini. L'OWASP indique que la fermeture du navigateur ne force pas la déconnexion de façon fiable et préconise une déconnexion explicite, avec des délais côté serveur7.
- Révoquer ses sessions si un doute apparaît (poste infecté, page de connexion suspecte). Les sources citées ici ne détaillent pas la marche à suivre : le support informatique de l'entreprise indique la procédure.
- Fermer régulièrement les sessions ouvertes dans le navigateur. MITRE recommande de fermer régulièrement toutes les sessions du navigateur8.
- Contrôler l'adresse avant de saisir son mot de passe : l'adresse est la seule différence visible entre un faux site relais et le vrai6.
- Signaler tout doute au support informatique, sans attendre : tant que la session est active, l'attaquant peut s'en servir2.
Côté entreprise, MITRE cite la configuration des navigateurs pour supprimer régulièrement les cookies persistants2.
Fiche
- Identifiant
- CP-048
- Aile
- 1. Attaques et techniques
- Compétence Brain
- Maîtriser ses mots de passe (master_passwords)
- Réflexe Brain
- cr-023
- Schéma
- G3 · Coupe Anatomique
- Langues
- de, en, fr
- Sources
- 8 sources vérifiées le 3 novembre 2026
Sources8 sources
- MITRE ATT&CK, « Steal Web Session Cookie ». https://attack.mitre.org/techniques/T1539/ (consulté le 3 novembre 2026)
- MITRE ATT&CK, « Use Alternate Authentication Material: Web Session Cookie ». https://attack.mitre.org/techniques/T1550/004/ (consulté le 3 novembre 2026)
- OWASP, « Session hijacking attack ». https://community.owasp.org/attacks/Session_hijacking_attack (consulté le 3 novembre 2026)
- MITRE ATT&CK, « Steal Application Access Token ». https://attack.mitre.org/techniques/T1528/ (consulté le 3 novembre 2026)
- NIST, « NIST Special Publication 800-63B ». https://pages.nist.gov/800-63-3/sp800-63b.html (consulté le 3 novembre 2026)
- Microsoft, « From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud », 12 juillet 2022. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ (consulté le 3 novembre 2026)
- OWASP, « Session Management - OWASP Cheat Sheet Series ». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consulté le 3 novembre 2026)
- MITRE ATT&CK, « Browser Session Hijacking ». https://attack.mitre.org/techniques/T1185/ (consulté le 3 novembre 2026)
Citer cet article
Brain, « Vol de cookies de session et jetons porteurs », Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp048_fr_2026,
author = {Brain},
title = {Vol de cookies de session et jetons porteurs},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/fr/articles/vol-cookies-session-jetons-porteurs/},
note = {CC BY 4.0}
}