Un déplacement de la menace
Pendant des années, la sécurité des accès s’est concentrée sur le mot de passe, puis sur l’authentification multifacteur (MFA). En relevant le coût du vol d’identifiants, ces dispositifs ont modifié les tactiques des attaquants. Beaucoup ne cherchent plus d’abord à voler un mot de passe, mais à dérober ce qui vient après l’authentification : le jeton de session.
Les logiciels voleurs d’informations (infostealers) et le vol de sessions authentifiées — cookies et jetons — figurent aujourd’hui parmi les vecteurs d’accès initial les plus actifs. Le Threat Landscape 2025 de l’ENISA décrit les infostealers comme un maillon solide et prévalent de la chaîne cybercriminelle, facilitant le vol d’identifiants, le détournement de sessions et le courtage d’accès. La même analyse indique que le phishing reste le principal mode d’intrusion initiale, à l’origine d’environ 60 % des cas observés, et qu’il sert notamment à voler des identifiants et à détourner des sessions.
Cet article propose une lecture opérationnelle de cette menace : comprendre la chaîne d’attaque, comprendre pourquoi elle défait des dispositifs de MFA fondés sur des facteurs faibles, et identifier les réponses réellement efficaces. Il complète l’article consacré aux passkeys, qui traitait une partie de la réponse ; ici, l’angle est d’abord celui de la menace.
Comprendre le mécanisme : voler ce qui vient après l’authentification
Le principe est simple et souvent mal compris. Lorsqu’un utilisateur s’authentifie — y compris avec une MFA —, le serveur lui délivre un jeton de session, matérialisé côté navigateur par un cookie. Ce jeton représente l’état « authentifié » : il évite de redemander une authentification à chaque action.
Or ce jeton est, dans la plupart des implémentations, un identifiant « au porteur » : quiconque le détient hérite de la session. Un attaquant qui parvient à copier ce jeton peut l’importer dans son propre navigateur et reprendre la session complète — sans mot de passe, sans nouvelle demande de MFA, en apparaissant au système comme l’utilisateur légitime.
La formule qui résume le mieux la situation est la suivante : la MFA protège la connexion initiale ; l’attaquant, lui, utilise ce que cette connexion a produit. Le contournement ne vise pas le facteur d’authentification, mais le jeton qui en résulte.
Deux voies principales de vol : infostealers et AiTM
Le vol de session emprunte principalement deux voies.
La première est l’infostealer. Il s’agit d’un logiciel malveillant qui, une fois exécuté sur le poste de la victime, copie les cookies de session, les mots de passe enregistrés dans le navigateur, les jetons et parfois les clés d’API stockées localement. La diffusion s’appuie sur des techniques variées : le Threat Landscape 2025 de l’ENISA mentionne notamment les scams de type « ClickFix », qui affichent de fausses vérifications de type CAPTCHA pour inciter l’utilisateur à exécuter des commandes PowerShell installant l’infostealer, ou encore des campagnes exploitant des sites compromis pour diffuser des voleurs comme Lumma et Vidar par téléchargement furtif. L’ENISA identifie Lumma comme l’infostealer le plus répandu depuis le début de 2025.
La seconde voie est l’attaque de type « adversary-in-the-middle » (AiTM). L’attaquant place un proxy inverse entre la victime et le service légitime. La victime voit la véritable page de connexion, saisit ses identifiants et valide sa MFA — tout fonctionne —, mais le proxy capture au passage le jeton de session émis. Les identifiants sont même souvent vérifiés contre les API légitimes du service : l’utilisateur ne perçoit rien d’anormal. Cette approche s’est industrialisée via des kits de phishing (Evilginx, Tycoon 2FA, FlowerStorm, entre autres), certains proposés en mode « phishing-as-a-service ». Une variante, le « device code phishing », détourne le flux OAuth 2.0 d’autorisation par code d’appareil pour faire émettre des jetons directement vers l’attaquant.
Dans les deux cas, le résultat est le même : l’attaquant obtient un jeton de session valide, postérieur à l’authentification.
Le marché des « logs » et des accès
Ces vols alimentent une économie structurée. Les données exfiltrées par les infostealers sont regroupées dans des « logs » — contenant identifiants, cookies de session actifs et parfois clés d’API — puis revendues sur des places de marché clandestines. Des courtiers en accès initial (initial access brokers) achètent, qualifient et revendent ces accès à d’autres acteurs.
Ces accès deviennent le point de départ d’attaques plus larges : rançongiciels, compromission de messagerie professionnelle (BEC), prise de contrôle de comptes. C’est précisément cette position de « maillon » dans la chaîne cybercriminelle que souligne l’ENISA : l’infostealer n’est pas une fin en soi, mais un fournisseur d’accès pour l’ensemble de l’écosystème.
Le secteur financier est directement concerné. Le Threat Landscape 2025 de l’ENISA place les services financiers parmi les cibles régulières, avec une attention particulière aux chevaux de Troie bancaires, à la fraude mobile et aux opérations de vol d’identifiants. La sensibilité des données et la valeur des accès en font une cible de choix, aussi bien pour les cybercriminels que pour d’autres acteurs.
Pourquoi cela défait des MFA fondés sur des facteurs faibles
Le vol de session met en évidence une limite des dispositifs de MFA reposant sur des facteurs faibles. Un code à usage unique par SMS ou par application (OTP), ou une notification « push » à approuver, peut être relayé en temps réel par un kit AiTM : l’attaquant transmet la demande à la victime, récupère la validation, et capte le jeton, le tout dans la courte fenêtre de validité du code. Le facteur d’authentification est certes utilisé — mais il ne protège pas le jeton produit.
Un constat public l’illustre : à mesure que certains grands fournisseurs ont généralisé la double authentification et les passkeys — qui bloquent le phishing d’identifiants —, les attaquants se sont déplacés vers le vol de cookies de session, que ces mécanismes ne suffisent pas toujours à empêcher une fois la session établie.
Autrement dit, renforcer le facteur d’authentification est nécessaire, mais insuffisant si le jeton de session, lui, reste un simple identifiant au porteur, réutilisable depuis n’importe quelle machine.
Un enjeu spécifique pour la finance
Pour les banques et les assurances, l’enjeu est double. D’une part, les accès dérobés peuvent ouvrir la porte à des systèmes critiques : messagerie, applications métiers, portails clients, environnements d’administration. D’autre part, la chaîne « infostealer → logs → courtier en accès → attaque » raccourcit le délai entre une infection initiale et une compromission à fort impact, et rend la surface d’exposition difficile à mesurer.
Le vol de session concerne aussi bien les parcours clients (prise de contrôle de comptes) que les accès internes à privilèges. Il touche donc à la fois la lutte contre la fraude et la sécurité opérationnelle, et s’inscrit pleinement dans les attentes de maîtrise des accès portées par les cadres de résilience du secteur.
Les réponses efficaces : lier le jeton au terminal
La réponse la plus directe au vol de session consiste à faire en sorte qu’un jeton dérobé soit inutilisable ailleurs que sur le terminal qui l’a obtenu — c’est la liaison du jeton au terminal (token ou session binding).
Le mécanisme le plus visible est le Device Bound Session Credentials (DBSC), proposé par Google et intégré au navigateur. Il lie le cookie de session au matériel de l’appareil : une clé privée est générée dans un composant matériel de sécurité (TPM sous Windows, Secure Enclave sous macOS) et n’en sort jamais, le serveur vérifiant périodiquement que le navigateur contrôle toujours cette clé avant de renouveler la session. Un cookie volé devient alors cryptographiquement inutile sur une autre machine. Le DBSC est passé en disponibilité générale sous Windows dans Chrome 146 en avril 2026, un support macOS étant annoncé pour la suite, et Google fait état d’une réduction significative du vol de sessions pour les sessions protégées.
Des mécanismes équivalents existent dans d’autres écosystèmes : la « token protection » de Microsoft Entra et le jeton de rafraîchissement principal lié à l’appareil (Primary Refresh Token) pour l’authentification unique Entra, ou encore des contrôles de liaison de session côté administration pour certaines suites collaboratives.
Ces dispositifs constituent une avancée majeure, mais ne sont pas une solution unique. Ils traitent le vol local de cookies et, lorsque la liaison atteint le navigateur de la victime, l’interception par un proxy AiTM ; en revanche, ils ne couvrent pas la fraude commise depuis le terminal légitime, et leur couverture reste en cours d’extension selon les navigateurs et les applications.
Les réponses efficaces : authentification résistante au phishing
L’authentification résistante au phishing — reposant sur les standards FIDO2/WebAuthn, dont les passkeys et les clés de sécurité matérielles — s’attaque à l’autre extrémité du problème : l’interception au moment de l’authentification.
Son principe est un ancrage cryptographique au domaine légitime : l’authentification ne peut pas être relayée vers un site tiers. Un kit AiTM ne peut donc pas se placer en proxy pour capter la validation, ce qui neutralise ce vecteur d’interception. Ces mécanismes résistent en outre au phishing d’identifiants, à la fatigue liée aux notifications et au détournement de carte SIM.
Une nuance s’impose toutefois : l’authentification résistante au phishing empêche l’attaquant de relayer l’authentification, mais elle n’élimine pas à elle seule le rejeu d’un jeton déjà émis, notamment lorsqu’un infostealer dérobe le cookie après l’établissement de la session. C’est précisément pourquoi elle se combine avec la liaison du jeton au terminal, des sessions courtes et de la détection. Les passkeys sont une partie essentielle de la réponse, pas la réponse entière.
Les réponses efficaces : sessions courtes, réévaluation continue et détection
Plusieurs mesures complémentaires réduisent la valeur d’un jeton volé.
Raccourcir la durée de vie des sessions et des jetons diminue mécaniquement la fenêtre de rejeu. La réévaluation continue de la validité de la session (par exemple via des mécanismes de type Continuous Access Evaluation) permet de révoquer un accès lorsque le contexte change, même après l’authentification initiale — étant entendu que cette couverture reste inégale selon les applications et qu’un jeton peut être exploité dans l’intervalle avant réévaluation.
La détection d’anomalies de session complète le dispositif : accès depuis un nouvel appareil, déplacement géographique impossible, adresse ou horaire inhabituels, changement d’empreinte technique. Ces contrôles s’appuient sur des politiques d’accès conditionnel et sur l’exigence de terminaux conformes. Enfin, la surveillance des « logs » d’infostealers et des fuites permet d’identifier les identifiants et cookies exposés associés à l’organisation, afin d’invalider les sessions concernées plutôt que de supposer qu’elles sont couvertes par la MFA.
Les réponses efficaces : durcissement des postes et réponse à incident
Les infostealers s’exécutent sur le poste de travail : la sécurité du terminal reste donc déterminante. Le durcissement des postes, la protection comportementale (EDR), la restriction de l’exécution de scripts — notamment PowerShell, exploité par les techniques de type ClickFix —, le durcissement du navigateur et la limitation des données sensibles stockées localement réduisent la surface d’exposition.
La réponse à incident doit par ailleurs intégrer une spécificité essentielle : une compromission par infostealer ne se traite pas comme un simple nettoyage de logiciel malveillant. Elle impose d’invalider les sessions et de révoquer les jetons, puis de renouveler les identifiants exposés. Tant que les jetons dérobés n’ont pas été révoqués, l’attaquant peut conserver un accès valide, indépendamment de la suppression du logiciel.
Perspective Forum des Compétences
La menace s’est déplacée : du vol de mot de passe vers le vol de session. Ce déplacement explique une observation contre-intuitive — des organisations dotées de MFA, voire de passkeys, restent compromises. La raison n’est pas l’inutilité de ces dispositifs, mais le fait qu’ils protègent l’authentification sans protéger, à eux seuls, le jeton qui en résulte.
La réponse efficace est donc en couches. Lier le jeton au terminal (token binding, DBSC, token protection) traite le cœur du problème. L’authentification résistante au phishing neutralise l’interception au moment de la connexion. Les sessions courtes, la réévaluation continue et la détection d’anomalies réduisent la valeur et la durée d’exploitation d’un jeton volé. Le durcissement des postes limite l’infection initiale. Et la réponse à incident doit traiter la compromission de jetons comme un scénario à part entière, avec révocation des sessions.
Pour les banques et les assurances, l’enjeu concret est de prioriser les contrôles de session et de terminal, longtemps moins investis que le facteur d’authentification. Le changement de posture tient en une phrase : le jeton de session est désormais un actif de grande valeur, à protéger avec la même rigueur qu’un identifiant.
Sources publiques utilisées
Cet article s’appuie sur des travaux et référentiels publics reconnus, ainsi que sur des mécanismes de sécurité documentés publiquement :
- ENISA, Threat Landscape 2025 (publié le 1er octobre 2025, analysant près de 4 875 incidents entre juillet 2024 et juin 2025), notamment sur le rôle des infostealers comme maillon de la chaîne cybercriminelle (vol d’identifiants, détournement de sessions, courtage d’accès), la prévalence de Lumma depuis le début de 2025, le phishing comme principal vecteur d’intrusion initiale (environ 60 % des cas), l’industrialisation via des plateformes de phishing-as-a-service et des kits AiTM, et le ciblage du secteur financier.
- ANSSI et CERT-FR, travaux et recommandations relatifs à la menace des infostealers, au vol d’identifiants et de sessions, et aux mesures de sécurisation des accès et des postes.
- FIDO Alliance et standard WebAuthn (W3C), pour l’authentification résistante au phishing (FIDO2/WebAuthn, passkeys, clés de sécurité) et sa résistance aux attaques de type AiTM.
- Mécanismes de liaison de session documentés publiquement : Device Bound Session Credentials (DBSC) de Google (disponibilité générale sous Windows dans Chrome 146, avril 2026) et « token protection » / Primary Refresh Token lié à l’appareil de Microsoft Entra.
