Vol de jetons de session : pourquoi les infostealers contournent le MFA et comment réagir

Réponse courte : le MFA réduit le risque lié au vol de mot de passe, mais il ne protège pas automatiquement une session valide une fois l'authentification effectuée. Les infostealers ciblent les cookies et les jetons parce que rejouer une session déjà authentifiée est souvent plus rapide que de vaincre le MFA frontalement.

Les infostealers sont devenus l'un des principaux moteurs d'accès initial du paysage de la menace actuel. Ces malwares sont souvent bon marché et distribués via des logiciels crackés, des publicités malveillantes, de fausses mises à jour, du phishing ou des sites web compromis. Une fois installés, ils moissonnent les données de navigateur, les cookies, les identifiants, les portefeuilles crypto, les fichiers et les jetons d'applications locales. Le butin est ensuite revendu, échangé ou exploité directement.

Pour les défenseurs, le point le plus douloureux reste le vol de session. Un utilisateur peut avoir un mot de passe robuste et le MFA activé. Si un malware dérobe un cookie ou un jeton valide dans le navigateur après l'authentification, l'attaquant peut rejouer cette session depuis une autre machine. Il n'a pas besoin de connaître le mot de passe : la session incarne déjà la confiance accordée.

Microsoft et d'autres chercheurs en threat intelligence ont récemment mis en avant l'importance des attaques sur l'identité, des infostealers et du vol de jetons. La leçon est claire : le MFA est nécessaire, mais la protection des sessions et l'hygiène des postes de travail comptent désormais tout autant.

Ce qui est dérobé

Les infostealers ciblent couramment :

• Les cookies de navigateur.
• Les mots de passe enregistrés.
• Le session storage et le local storage.
• Les refresh tokens.
• Les bases d'authentification stockées dans les profils de navigateur.
• Les portefeuilles de cryptomonnaies.
• Les clés SSH et les identifiants de développeurs.
• Les clés d'API présentes dans des fichiers locaux.
• Les profils VPN et d'accès distant.
• Les captures d'écran et les métadonnées système.

Le navigateur est une cible de grande valeur parce que c'est là que vivent les utilisateurs. Sessions SaaS, consoles d'administration, tableaux de bord cloud, messagerie, outils de collaboration et portails d'identité y laissent tous des traces exploitables par le malware.

Pourquoi le rejeu de jeton fonctionne

Les applications web modernes émettent des cookies ou des jetons de session après la connexion. Ces artefacts indiquent au service que l'authentification a déjà eu lieu. Si un attaquant parvient à les copier et à les rejouer, le service peut le traiter comme l'utilisateur légitime, à moins que des contrôles supplémentaires ne détectent le changement de contexte.

Le MFA intervient généralement avant l'émission de la session. Une fois la session créée, l'application ne redemande pas nécessairement de MFA à chaque requête. C'est confortable pour l'usage, mais dangereux quand le poste est compromis.

Des contrôles comme le token binding, la conformité de l'appareil, l'accès conditionnel, l'évaluation continue de l'accès (CAE) et la révocation de session réduisent ce risque. Mais la couverture varie selon la plateforme, le navigateur, le client et la configuration.

Les signes d'un vol de jeton de session

Le rejeu de jeton ne ressemble pas à une compromission classique de mot de passe. Vous ne verrez peut-être aucune tentative de connexion échouée. Vous ne verrez peut-être aucune sollicitation MFA suspecte. En revanche, vous observerez une activité de session valide depuis un contexte anormal.

Recherchez :

• Des accès depuis de nouvelles IP peu après une connexion légitime.
• Une même session utilisée depuis des zones géographiques ou des ASN différents.
• Des accès SaaS depuis des infrastructures de datacenter, de proxy, de VPN ou Tor.
• Des téléchargements massifs après un accès inhabituel.
• De nouvelles règles de boîte de réception ou de redirection.
• Des accès à des consoles d'administration depuis des appareils non gérés.
• L'utilisation de jetons cloud sans authentification interactive.
• Des anomalies de user-agent du navigateur.
• Des connexions réussies sans la posture d'appareil attendue.

La télémétrie des postes de travail compte aussi. Si une machine a exécuté un infostealer connu, considérez que les sessions de navigateur présentes sur cet appareil sont potentiellement compromises.

Le lien avec le dark web

Les logs d'infostealers sont souvent conditionnés puis revendus. Les acheteurs y cherchent des domaines d'entreprise, des cookies SaaS, des panneaux d'administration, des portails VPN, des portefeuilles crypto et des identifiants cloud. Un simple ordinateur personnel infecté peut exposer des comptes professionnels si l'utilisateur s'y connecte depuis cet appareil.

La frontière entre risque personnel et risque d'entreprise s'estompe. Des collaborateurs utilisent des machines personnelles pour travailler dans des contextes non gérés. Des prestataires accèdent au SaaS depuis des appareils hors périmètre EDR. Des télétravailleurs synchronisent leurs profils de navigateur entre plusieurs appareils.

La surveillance du dark web peut révéler que des identifiants ou des cookies liés à votre domaine circulent, mais la réponse exige toujours une action côté identité et côté poste de travail.

Pour un contexte plus large, lisez Infostealers et vol d'identifiants et Surveillance du dark web pour la protection de marque.

Playbook de réponse

En cas de suspicion de vol de jeton :

1. Révoquez les sessions actives de l'utilisateur concerné.
2. Révoquez les refresh tokens lorsque la plateforme le permet.
3. Réinitialisez les identifiants après la révocation des sessions.
4. Isolez et analysez le poste de travail.
5. Passez en revue l'activité récente sur le SaaS, la messagerie, les fichiers et le cloud.
6. Vérifiez les règles de boîte aux lettres, les redirections, les consentements applicatifs et les téléchargements de données.
7. Recherchez des accès similaires provenant de la même infrastructure.
8. Enrichissez les IP et domaines sources pour identifier les usages malveillants connus, proxy, VPN ou datacenter.

Ne vous contentez pas de réinitialiser le mot de passe. Si la session reste valide, l'attaquant conserve son accès.

Contrôles de prévention

Durcissez les postes de travail. Empêchez l'exécution de malwares, restreignez les téléchargements à risque, bloquez les publicités malveillantes lorsque c'est possible et maintenez les navigateurs à jour. La détection sur les endpoints doit traiter les infostealers comme une urgence élevée, même lorsqu'ils apparaissent sur des systèmes non privilégiés.

Utilisez l'accès conditionnel. Exigez des appareils conformes pour les applications sensibles. Bloquez les connexions à risque élevé. Imposez une réauthentification pour les actions sensibles. Restreignez les sessions provenant d'anonymiseurs et d'infrastructures suspectes.

Limitez la durée de vie des sessions pour les applications sensibles. Trouvez l'équilibre entre confort d'usage et risque, en particulier pour les administrateurs et les utilisateurs à forte valeur.

Protégez les jetons là où la plateforme le permet. Le token binding, les sessions liées à l'appareil et l'évaluation continue de l'accès réduisent le risque de rejeu.

Endpoint et identité doivent travailler ensemble

Le vol de jeton se situe à la charnière entre la sécurité des endpoints et la sécurité des identités. L'équipe endpoint voit un malware sur un ordinateur portable. L'équipe identité voit une activité SaaS étrange. Si ces équipes ne partagent pas leur contexte, l'organisation peut passer à côté de la compromission.

Mettez en place une réponse identité automatique pour les détections d'infostealers à haute confiance. Si un appareil géré exécute un stealer connu, révoquez les sessions des comptes actifs sur cet appareil, imposez une réinitialisation de mot de passe et inspectez l'activité SaaS récente. Attendre la preuve d'un rejeu de jeton laisse du temps aux attaquants.

Symétriquement, les alertes identité doivent déclencher une revue côté endpoint. Si une session apparaît depuis une infrastructure suspecte, vérifiez si les appareils de l'utilisateur présentent un malware, des téléchargements à risque, des extensions de navigateur inhabituelles ou des outils d'accès distant. L'événement identité peut être le premier symptôme visible d'une compromission du poste.

Le risque des profils de navigateur

Les profils de navigateur sont de véritables coffres au trésor. Ils peuvent contenir cookies, mots de passe enregistrés, données de saisie automatique, données d'extensions, local storage et sessions synchronisées. L'usage personnel du navigateur sur un poste professionnel et l'usage professionnel sur un appareil personnel augmentent tous deux l'exposition.

Les organisations devraient définir quelles applications exigent un navigateur géré ou un appareil géré. Les consoles d'administration très sensibles, les tableaux de bord cloud, les systèmes financiers et les systèmes contenant des données clients ne devraient pas être accessibles depuis n'importe quel appareil personnel. L'accès conditionnel doit imposer cette règle techniquement, et pas seulement dans le texte d'une politique.

Les extensions de navigateur méritent une attention particulière. Certaines réclament des permissions très larges et peuvent lire le contenu des pages. Une extension malveillante ou compromise devient alors un vecteur d'exposition des jetons. Passez en revue les listes d'extensions autorisées pour les navigateurs gérés et surveillez les extensions à risque.

Cadrage de l'incident

Quand un jeton est dérobé, cadrez large. Un même log de stealer peut contenir plusieurs comptes, des identifiants personnels, des jetons cloud et des secrets de développement. Un seul poste infecté peut exposer le SaaS d'entreprise, GitHub, des identifiants de CLI cloud, des clés SSH et des clés d'API d'IA.

Posez ces questions :

• Quels comptes se sont connectés depuis l'appareil infecté ?
• Quels navigateurs et quels profils étaient présents ?
• Des gestionnaires de mots de passe étaient-ils accessibles ?
• Des outils de développement ou des CLI cloud étaient-ils configurés ?
• Le malware a-t-il exfiltré des fichiers ?
• Des jetons ont-ils été rejoués depuis des infrastructures malveillantes connues ?
• L'attaquant a-t-il créé de la persistance dans des applications SaaS ?

Ce cadrage empêche l'équipe de clore l'incident après une simple réinitialisation de mot de passe.

Métriques à suivre

Suivez les détections d'infostealers, les révocations de sessions consécutives à un événement malware, les alertes de rejeu de jeton, les accès aux applications sensibles depuis des appareils non gérés, les infrastructures de session suspectes et le délai entre la détection sur le poste et le confinement côté identité.

Suivez également les résultats de la sensibilisation des utilisateurs. Beaucoup d'infections par infostealer commencent par un logiciel cracké, une fausse mise à jour, une publicité malveillante ou un téléchargement non officiel. Réduire ces comportements diminue le risque de vol de jeton bien plus efficacement qu'un énième rappel générique sur le MFA.

Améliorer la réponse en 30 jours

La première semaine, rendez la révocation de session opérationnelle. Identifiez qui peut révoquer les sessions sur les principales plateformes SaaS, les fournisseurs d'identité, les consoles cloud et les outils de collaboration. Documentez les commandes ou les chemins dans les consoles. Un incident de vol de jeton n'est pas le moment de découvrir qu'un seul administrateur sait comment faire.

La deuxième semaine, connectez les files d'attente endpoint et identité. Les alertes infostealer à haute confiance doivent ouvrir automatiquement une tâche de revue identité. Les connexions suspectes depuis un proxy ou une infrastructure malveillante connue doivent automatiquement demander du contexte endpoint. Même un simple modèle de dossier partagé vaut mieux que deux équipes travaillant séparément.

La troisième semaine, passez en revue les accès depuis des appareils non gérés. Identifiez quelles applications sensibles autorisent encore des sessions de navigateur depuis des postes personnels ou inconnus. Resserrez d'abord les systèmes les plus critiques : administration cloud, gestion de code source, CI/CD, finance, RH et données clients.

La quatrième semaine, testez un scénario de rejeu de jeton. Faites-le en exercice sur table, pas avec un vrai vol de jeton. L'équipe doit s'entraîner à la révocation, à l'isolement du poste, à la revue des journaux d'audit SaaS, à l'enrichissement des IP sources et à la communication vers l'utilisateur concerné et son manager.

Consignes pour les utilisateurs

Les collaborateurs doivent comprendre que le MFA est important mais pas magique. Si un appareil est infecté, l'attaquant peut dérober le résultat d'une connexion réussie. Le comportement responsable sur l'appareil fait donc partie intégrante de la sécurité des identités.

Les consignes doivent être concrètes : éviter les logiciels crackés, signaler les fausses invites de mise à jour, utiliser des navigateurs gérés pour le travail, ne pas synchroniser les sessions professionnelles vers des appareils personnels et signaler les notifications de connexion inattendues. Associez ces consignes à des contrôles techniques, pour que les utilisateurs ne portent pas seuls toute la charge.

Notes d'ingénierie de détection

Les détections de rejeu de jeton fonctionnent mieux lorsqu'elles comparent le contexte dans le temps. Une seule connexion réussie depuis une nouvelle IP ne suffit pas forcément. Une session valide dont l'ASN, la géographie, le user-agent et la posture d'appareil changent en quelques minutes est un signal bien plus fort. Une session valide provenant d'un datacenter après une connexion depuis un accès grand public est également suspecte pour beaucoup de profils.

Utilisez un scoring de risque plutôt qu'une règle unique et fragile. Ajoutez du poids pour les infrastructures malveillantes connues, les indicateurs de proxy ou de VPN, le voyage impossible, l'appareil non géré, l'accès à un SaaS sensible, les téléchargements massifs, la création de règles de boîte aux lettres et la présence récente d'un malware sur le poste. C'est le tableau d'ensemble qui compte.

Conservez suffisamment de journaux pour pouvoir enquêter après une exposition sur le dark web. Si un log de stealer refait surface des semaines plus tard, les analystes ont besoin de l'historique des connexions, de l'activité SaaS, des données endpoint et réseau pour déterminer si le jeton a été rejoué avant la découverte.

Validation de la remédiation

Après la révocation, vérifiez que l'attaquant n'a pas mis en place de persistance. Contrôlez les consentements OAuth, les mots de passe d'application, les règles de boîte aux lettres, les adresses de redirection, les délégations d'accès, les méthodes de récupération, les clés d'API et les personal access tokens. Une session dérobée laisse souvent aux attaquants assez de temps pour poser une autre porte d'entrée.

La remédiation doit aussi inclure un accompagnement de l'utilisateur. Si l'infection a débuté sur un appareil personnel, le collaborateur peut avoir besoin d'aide pour réinitialiser ses comptes personnels, auditer son gestionnaire de mots de passe et nettoyer son profil de navigateur. L'aider à faire le ménage réduit le risque que les mêmes données volées reviennent plus tard par un autre chemin.

Documentez ce qui a été révoqué et quand, car des tentatives de rejeu répétées après le confinement peuvent révéler d'autres artefacts dérobés.

Conservez cette trace avec la chronologie de l'incident, de façon permanente.

Ce qu'il faut retenir côté threat intelligence

Le vol de jetons de session fait passer l'état d'esprit du défenseur de « l'utilisateur a-t-il passé le MFA ? » à « cette activité authentifiée provient-elle toujours du bon appareil, du bon réseau et du bon contexte ? ».

isMalicious aide à enrichir l'infrastructure derrière un usage de session suspect. Lorsqu'un compte valide apparaît depuis une IP malveillante connue, un réseau de proxy ou un hôte cloud suspect, les analystes passent plus vite de l'anomalie à la réponse à incident.