Un attaquant qui vole vos cookies de session n’a pas besoin de votre mot de passe. Il n’a pas besoin de votre code SMS. Il n’a pas besoin de votre application d’authentification. Même avec une clé physique YubiKey, votre compte peut être compromis. On vous explique pourquoi, comment ces données sont volées, et ce que font concrètement les attaquants une fois qu’ils les ont en main. Les incidents cités ont été documentés par des firmes de sécurité indépendantes entre 2021 et 2025.

Les attaques sur les cookies de session se produisent désormais dans le même ordre de grandeur que les attaques basées sur les mots de passe. Ce changement structurel redéfinit la surface d’attaque de toute organisation.

La sécurité périmétrique classique, focalisée sur la protection des identifiants, est devenue insuffisante. La session post-authentification est la cible principale, et sa protection exige une surveillance comportementale continue, une gestion stricte de la durée de vie des tokens, et une architecture Zero Trust qui ne fait confiance à aucune session sans vérification contextuelle permanente.

La question n’est pas de savoir si viuos ou votre organisation sera ciblée. C’est de savoir combien de temps s’écoulera entre l’infection et la détection.

Ce qu’est vraiment un cookie de connexion

Quand un utilisateur s’authentifie sur un site web, le serveur doit résoudre un problème fondamental : le protocole HTTP est sans mémoire. Chaque requête est techniquement indépendante des précédentes. Sans mécanisme complémentaire, l’utilisateur devrait ressaisir ses identifiants à chaque clic.

La solution adoptée depuis les années 1990 est le cookie de session. À l’issue d’une authentification réussie, le serveur génère un identifiant unique, appelé session ID ou session token, et l’envoie au navigateur sous forme de cookie. Ce cookie est ensuite transmis automatiquement par le navigateur dans les en-têtes HTTP de toutes les requêtes suivantes vers ce même domaine. Le serveur le reçoit, consulte sa base de données interne, retrouve la session associée et en déduit l’identité de l’utilisateur ainsi que ses droits d’accès.

Le cookie de session est donc un laissez-passer numérique. Il ne contient pas le mot de passe, mais il en a la valeur fonctionnelle exacte : quiconque le possède peut agir comme s’il était l’utilisateur légitime, sans s’authentifier à nouveau.

La structure d’un token d’authentification moderne

Les applications modernes utilisent fréquemment des tokens plus sophistiqués, notamment les JWT (JSON Web Tokens). Un JWT se compose de trois parties encodées en Base64, séparées par des points :

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiI0MjEiLCJyb2xlIjoiYWRtaW4ifQ.sFlKxwRJSMeKKF2QT4fwpMeJf36POk6y

• L’en-tête (header) : l’algorithme de signature utilisé.
• La charge utile (payload) : les données encodées, identifiant utilisateur, rôle, date d’expiration.
• La signature : empreinte cryptographique permettant de vérifier l’intégrité.

Le payload est simplement encodé, pas chiffré. N’importe quel outil en ligne permet de décoder un JWT en clair en quelques secondes. C’est la signature qui garantit l’authenticité, à condition que la clé secrète du serveur ne soit pas compromise.

Pourquoi le vol de tokens contourne complètement le MFA

C’est le cœur du problème, et c’est la source de la confusion la plus répandue en sécurité des comptes.

Le MFA, sous toutes ses formes, protège l’acte d’authentification. Une fois la session créée, le serveur fait confiance au token, pas à l’identité de celui qui le présente. Un attaquant qui récupère le token de session saute intégralement la phase d’authentification. Il n’a jamais besoin de connaître le mot de passe, ni de posséder le téléphone, ni de valider quoi que ce soit.

La séparation radicale entre authentification et session

Le processus se décompose en deux phases parfaitement indépendantes :

De l’ensemble des techniques documentées pour contourner le MFA sur Microsoft 365, le vol de token représentait 31 % des cas recensés entre 2024 et 2025. C’est la méthode dominante, devant les attaques par force brute ou le SIM-swapping.

Le 2FA, la YubiKey et leur limite réelle

Ce que chaque forme de MFA protège, et ce qu’elle ne protège pas

Il faut d’abord établir une distinction entre les différentes formes de MFA, car elles n’ont pas le même niveau de résistance.

SMS et codes TOTP (applications comme Google Authenticator)

Ce sont les formes les plus vulnérables. Les codes SMS peuvent être contournés via le SIM-swapping. Les codes TOTP à 6 chiffres peuvent être capturés en temps réel par un proxy intermédiaire qui se positionne entre la victime et le site légitime. L’attaquant récupère le nom d’utilisateur, le mot de passe et le code à six chiffres en une seule opération, et les transmet instantanément avant que le code n’expire. Cette technique est au cœur des kits d’attaque AitM comme Evilginx2 ou Modlishka.

Passkeys et clés YubiKey (FIDO2 / U2F)

Ces méthodes offrent une protection robuste contre le phishing. Elles lient la tentative de connexion de manière cryptographique au domaine du site légitime. Un attaquant ne peut pas tromper l’utilisateur pour qu’il utilise sa passkey ou sa YubiKey sur un faux site : la clé ne répondra pas, parce que le domaine ne correspond pas à celui pour lequel elle a été enregistrée.

Mais il faut comprendre précisément ce que cette protection couvre. Les passkeys et les clés matérielles sécurisent l’acte de connexion. Une fois l’utilisateur connecté avec succès, quel que soit le moyen utilisé, le site émet quand même un token de session dans le navigateur. Les YubiKeys ne protègent pas contre le vol de ce token après la connexion.

Les trois méthodes d’authentification courantes (passkey dans un gestionnaire de mots de passe, passkey liée à un appareil, clé matérielle de type YubiKey) sont également vulnérables au vol de session par malware, dans lequel un logiciel malveillant extrait les cookies du navigateur après une connexion réussie.

Le scénario concret avec une YubiKey

Voici comment une organisation qui a correctement déployé des YubiKeys comme second facteur peut quand même être compromise :

• L’utilisateur s’authentifie avec sa YubiKey. La session est établie et le cookie est stocké dans Chrome.
• Un attaquant envoie un email malveillant, déguisé en notification d’une plateforme interne (outil RH, notification Workday, alerte sécurité).
• L’utilisateur clique. Un malware est déployé silencieusement sur son poste.
• Le malware extrait la base de données de cookies de Chrome et l’exfiltre vers un serveur distant.
• L’attaquant injecte le cookie Microsoft dans son propre navigateur et actualise la page.
• Il est maintenant connecté au compte, sans avoir jamais vu la YubiKey.

La YubiKey a parfaitement rempli son rôle : elle a protégé la connexion. Le problème est que personne ne demande à l’utilisateur de re-prouver son identité une fois la session active.

Tableau comparatif : que protège chaque méthode MFA ?

* DBSC : Device Bound Session Credentials, technologie en cours de déploiement dans Chrome (bêta Google, 2024-2025).

La piste d’avenir : le Device Bound Session Credential

Google a annoncé l’implémentation en bêta des Device Bound Session Credentials. Le principe : lier cryptographiquement le cookie de session à la clé privée du TPM (Trusted Platform Module) de l’appareil. Un cookie volé devient inutilisable en dehors de la machine d’origine, parce qu’il ne peut pas produire la signature cryptographique attendue par le serveur.

C’est la direction que prend l’industrie. Le déploiement est encore partiel en 2025 et implique une mise à jour coordonnée des navigateurs, des serveurs et des applications. La protection universelle n’est pas pour demain.

La vulnérabilité EUCLEAK : quand la YubiKey elle-même est en cause

En 2024, une vulnérabilité baptisée EUCLEAK a été découverte dans la librairie cryptographique Infineon utilisée par les YubiKey 5 Series avec un firmware antérieur à la version 5.7.0. Un attaquant disposant d’un accès physique à la clé et d’un équipement de laboratoire spécialisé pouvait théoriquement extraire la clé privée ECDSA par analyse de canal latéral. Yubico a qualifié la sévérité de « modérée » : l’attaque requiert la possession physique de l’appareil, une connaissance préalable du compte ciblé, et un matériel spécialisé. Ce n’est pas une attaque distante. Mais cela rappelle qu’aucun dispositif n’est parfaitement immunisé.

Les techniques d’extraction des cookies et tokens

Les infostealers : l’aspirateur silencieux

Les navigateurs stockent les cookies dans des bases de données SQLite sur l’appareil de l’utilisateur. Des logiciels malveillants spécifiquement conçus pour cibler ces bases de données peuvent extraire silencieusement les tokens de session et les transmettre vers des serveurs contrôlés par des attaquants.

Les familles d’infostealers RedLine, Raccoon, Vidar, Lumma et leurs dérivés automatisent ce processus. Ils envoient les tokens volés à des serveurs distants pour une utilisation quasi immédiate dans le détournement de comptes actifs. Ces attaques contournent entièrement la sécurité des mots de passe : l’attaquant se fait passer pour l’utilisateur avec un token de session valide.

Au troisième trimestre 2025, parmi les 30 principales familles de malwares distribués, plus de 57 % étaient des infostealers. 27 % supplémentaires étaient des chevaux de Troie à accès distant (RAT) disposant souvent de capacités de vol de cookies.

L’attaque AitM (Adversary-in-the-Middle)

Les kits de phishing avancés peuvent capturer les identifiants de connexion, les tokens MFA et les cookies de session en temps réel, permettant aux attaquants de détourner des sessions immédiatement après la connexion. Le principe :

• La victime reçoit un email de phishing avec un lien vers un faux portail (exemple : microsoft-login.attackerdomain.com).
• Ce site proxifie en temps réel vers le vrai Microsoft.
• La victime saisit ses identifiants et valide son MFA (push notification, TOTP, YubiKey).
• Le proxy capture le cookie de session généré par Microsoft au moment de l’authentification.
• L’attaquant réimporte ce cookie dans son propre navigateur et accède au compte.

L’utilisateur ne remarque rien : il a bien accédé à son vrai compte, via son vrai MFA. La session est déjà dans les mains de l’attaquant.

Le XSS (Cross-Site Scripting)

Sur les applications web qui n’appliquent pas le flag HttpOnly sur leurs cookies, un attaquant peut injecter du code JavaScript malveillant dans une page et envoyer les cookies de session vers un serveur distant. Ce vecteur cible spécifiquement les développeurs négligents : le flag HttpOnly interdit au JavaScript d’accéder aux cookies, neutralisant les attaques XSS sur ce vecteur. Son absence est une faute de configuration.

Le sniffing réseau

Sur un réseau ouvert (café, hôtel, aéroport), un attaquant peut positionner un point d’accès jumeau imitant le réseau légitime. Si le trafic HTTP n’est pas chiffré, les cookies transitent en clair. Ce vecteur est en recul grâce à la généralisation de HTTPS, mais il reste opérant sur les portails captifs et les sites mal configurés, notamment dans des environnements professionnels de petite taille.

L’extension de navigateur malveillante

En décembre 2024, au moins 35 extensions Google Chrome ont été compromises dans une campagne ciblant les développeurs d’extensions. Une extension compromise peut lire en temps réel tous les cookies du navigateur, tous les champs de formulaire, tout le trafic HTTP. Elle dispose des permissions nécessaires par design, car c’est précisément ce que font les extensions légitimes. L’utilisateur installe une extension apparemment utile (un correcteur orthographique, un utilitaire PDF, un bloqueur de publicités) qui envoie silencieusement ses cookies vers un serveur distant.

Mac contre PC : la fin d’un mythe

Pendant deux décennies, la réputation de sécurité des Mac a reposé sur un fait réel : les malwares étaient écrits pour Windows, qui détenait 90 % des parts de marché. Compromettre un Mac exigeait un développement spécifique pour un système peu répandu. C’était une protection par l’obscurité, pas par la robustesse intrinsèque du système.

Cette époque est terminée.

L’explosion des infostealers macOS depuis 2023

En 2023, un nouvel infostealer pour Mac appelé Atomic Stealer (AMOS) a fait ses débuts. Depuis son lancement, il a non seulement présenté de nouvelles fonctionnalités, mais il a aussi adopté les caractéristiques d’un service commercial. AMOS pouvait être loué à d’autres cybercriminels, de la même façon que les entreprises légitimes proposent leurs logiciels en abonnement mensuel. En janvier 2024, ce prix atteignait 3 000 dollars par mois. Les développeurs proposaient même des promotions saisonnières et publiaient des notes de mise à jour.

Les télémétries de Palo Alto Networks indiquent une augmentation de 101 % des détections d’infostealers macOS entre les deux derniers trimestres de 2024. Microsoft Defender Experts a observé, depuis fin 2025, des campagnes ciblées utilisant des techniques d’ingénierie sociale, notamment des invites de style ClickFix et des installateurs DMG malveillants, pour déployer des infostealers spécifiques à macOS comme DigitStealer, MacSync et AMOS.

Ce que les infostealers Mac volent concrètement

Atomic Stealer collecte les mots de passe du Keychain macOS, les informations système, les fichiers du bureau et du dossier documents, les mots de passe utilisateur macOS, les données des navigateurs (cookies, identifiants), et les portefeuilles de cryptomonnaies.

Le Keychain est précisément ce qui rend la compromission d’un Mac particulièrement grave. C’est le coffre-fort centralisé d’Apple : mots de passe Wi-Fi, tokens d’accès aux APIs, certificats, mots de passe des applications. Un infostealer qui en extrait le contenu n’obtient pas seulement les cookies de session, il obtient potentiellement l’ensemble de l’infrastructure d’accès de la victime.

Les vecteurs d’infection spécifiques à macOS

La malvertising via Google Ads

Dans une campagne menée entre juin et août 2025, des cybercriminels ont exploité des publicités malveillantes et de fausses pages « Apple Support » pour tromper les utilisateurs et les amener à s’infecter eux-mêmes avec une variante d’AMOS appelée SHAMOS. Le premier résultat Google sponsorisé pointait vers une copie parfaite du site officiel.

Les faux installateurs DMG

L’utilisateur télécharge ce qui ressemble à une application légitime, un fichier .dmg (Arc Browser, CleanMyMac, Tor Browser, Adobe Photoshop). À l’installation, une fenêtre de dialogue imite parfaitement la demande système macOS pour le mot de passe. Ce mot de passe est immédiatement exfiltré et permet au malware d’accéder au Keychain.

ClickFix sur terminal

Une page web affiche un faux message d’erreur ou d’installation : « Pour continuer, copiez cette commande dans votre terminal. » La commande, invisible ou obfusquée, est un script qui télécharge et exécute un infostealer directement en mémoire, sans écrire de fichier sur le disque. C’est une technique dite « fileless » qui contourne la plupart des antivirus basés sur la détection de fichiers. Elle n’est pas contrecarrée par les clés FIDO2.

Comparaison objective Mac / PC

Le Mac n’est pas plus sécurisé. Il est différemment attaqué. Et ses utilisateurs sont souvent moins vigilants, ce qui en fait une cible de choix.

Les cas réels documentés : une industrie structurée

Ce qui distingue la menace actuelle des attaques historiques, c’est son industrialisation. Chaque jour, des milliers d’identifiants volés sont proposés sur des places de marché spécialisées, à un prix moyen de 10 dollars par jeu de credentials. Ces plateformes offrent des interfaces de recherche permettant de filtrer par type de service, par pays, par ancienneté de la session.

Electronic Arts, 2021 : 780 Go de code source pour 10 dollars

Des acteurs malveillants ont acheté des cookies d’authentification volés pour 10 dollars sur une place de marché dark web appelée Genesis. Cela leur a permis d’accéder aux systèmes internes d’EA via les cookies Slack d’un employé infecté par un infostealer. En juin 2021, les hackers ont volé environ 780 Go de données, dont le code source de FIFA 21 et du moteur Frostbite. EA a tenté de négocier, les hackers ont refusé et ont tout publié.

Police nationale néerlandaise, septembre 2024

La police nationale des Pays-Bas a annoncé que des attaquants avaient volé les coordonnées de plusieurs officiers. L’enquête a révélé que l’accès initial avait été obtenu via des cookies de session, préalablement volés lors d’une campagne d’infostealer puis revendus sur un marché spécialisé. Les données des officiers avaient ainsi circulé pendant un temps indéterminé avant d’être exploitées.

Snowflake, 2024 : la compromission de masse

C’est l’exemple le plus révélateur de la maturité industrielle de ces attaques.

Au milieu de l’année 2024, au moins 160 organisations ont été compromises via leurs environnements Snowflake. Parmi les victimes : AT&T (journaux d’appels de 109 millions de clients), Ticketmaster/Live Nation, Santander Bank, LendingTree, Advance Auto Parts, Neiman Marcus et Bausch Health.

Le groupe UNC5537 (aussi connu sous les noms ShinyHunters et Scattered Spider) n’a pas exploité de vulnérabilité zero-day. Il a simplement utilisé des identifiants volés via des infostealers, achetés sur des forums criminels et des canaux Telegram. Les variants utilisés comprennent VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA et METASTEALER.

Sources : Mandiant/Google Cloud Threat Intelligence, juin 2024 ; Wikipedia Snowflake data breach ; HP Wolf Security Threat Research, décembre 2025.

Comment se faire voler ses cookies : les scénarios du quotidien

La question n’est pas théorique. Voici les situations concrètes dans lesquelles une personne peut perdre l’ensemble de ses sessions actives, sans avoir commis aucune erreur évidente.

Scénario 1 : l’email malveillant

Un email imite une notification légitime : une facture, une alerte de sécurité, une invitation à approuver une demande RH. L’utilisateur clique sur le lien. Un malware est déployé silencieusement. L’attaquant extrait les cookies depuis Chrome, les injecte dans son navigateur, et accède au compte. La YubiKey de l’utilisateur n’a jamais été sollicitée.

Scénario 2 : le faux logiciel téléchargé

Un crack de logiciel, un keygen, une version « gratuite » d’un outil payant, un film en torrent : autant de vecteurs classiques. L’installateur légitime en apparence exécute silencieusement l’infostealer en arrière-plan pendant que l’application demandée s’installe normalement. L’utilisateur ne remarque rien. Dans l’affaire Snowflake, plusieurs prestataires avaient été infectés exactement de cette manière, sur des machines utilisées à la fois pour le travail et pour des jeux piratés.

Scénario 3 : la publicité Google empoisonnée

L’utilisateur recherche « télécharger VLC » ou « installer Arc Browser » sur Google. Le premier résultat sponsorisé pointe vers une copie parfaite du site officiel. Il télécharge ce qui semble être la version légitime. Le fichier est un installateur piégé. Cette technique, la malvertising, est désormais industrialisée et cible aussi bien Windows que macOS.

Scénario 4 : la commande Terminal copiée-collée (ClickFix)

Une page web affiche un faux message : « Pour installer ce composant, copiez cette commande dans votre terminal. » La commande, courte et incompréhensible, est un script qui télécharge et exécute un infostealer directement en mémoire. Sur Mac, c’est le vecteur en pleine expansion depuis 2024. La technique ne laisse pas de fichier sur le disque et contourne la plupart des antivirus. Elle n’est pas contrecarrée par FIDO2.

Scénario 5 : l’extension de navigateur compromise

L’utilisateur installe une extension apparemment utile (un correcteur, un utilitaire PDF, un assistant de comparaison de prix). Cette extension, soit malveillante dès l’origine, soit compromise ultérieurement, lit en temps réel tous les cookies du navigateur et les exfiltre. Elle dispose des permissions nécessaires par design.

Scénario 6 : le Wi-Fi ouvert

Dans un café ou un aéroport, un attaquant positionne un point d’accès jumeau imitant le réseau légitime. Si le site consulté n’impose pas HTTPS ou si le certificat TLS est invalide et accepté sans vérification par l’utilisateur, les cookies transitent en clair et peuvent être capturés. Ce vecteur est en recul mais pas disparu.

Scénario 7 : la compromission d’un prestataire

Le collaborateur d’un prestataire, infecté via son ordinateur personnel, porte sans le savoir des cookies d’accès valides vers les environnements de son client. C’est exactement le schéma de l’affaire Snowflake. Les machines des prestataires sont souvent moins bien protégées que celles des employés directs, et leurs profils de navigateur synchronisés sur leurs appareils personnels.

Scénario 8 : la synchronisation du profil navigateur

Un collaborateur utilise le même profil Chrome sur son ordinateur personnel (compromis) et son ordinateur professionnel. La synchronisation automatique du navigateur propage les cookies entre les deux appareils. L’infostealer installé sur la machine personnelle extrait également les cookies professionnels. C’est le vecteur le plus méconnu, et potentiellement le plus dévastateur dans un contexte de télétravail.

Ce que fait l’attaquant une fois le cookie en main

La séquence est rapide, documentée, et souvent automatisée.

1. L’infostealer exfiltre la base de données de cookies du navigateur (un fichier SQLite) vers un serveur de commande et contrôle.
2. L’attaquant sélectionne les cookies les plus intéressants : Microsoft 365, Google Workspace, Salesforce, GitHub, AWS console, outils RH, plateformes bancaires.
3. Il injecte ces cookies dans son propre navigateur via les Developer Tools ou une extension dédiée.
4. Il accède aux comptes sans aucune authentification. Les sessions SSO lui permettent ensuite de pivoter vers toutes les applications connectées.
5. Il crée des règles de transfert d’emails, exfiltre des documents, modifie des paramètres de compte, ou prépare une attaque BEC (Business Email Compromise) sur des tiers.

Une fois l’accès à la boîte mail obtenu, l’attaquant crée des règles de boîte de réception pour transmettre tous les emails vers une adresse qu’il contrôle. Ces règles garantissent que même si l’accès initial est perdu, il conserve une visibilité totale sur les communications et peut infiltrer des échanges en cours pour tenter des virements frauduleux.

L’effet multiplicateur du SSO est particulièrement grave. Une entreprise dont les collaborateurs utilisent Google Workspace ou Microsoft Entra comme fournisseur d’identité SSO expose, avec un seul cookie volé, l’ensemble des applications connectées : messagerie, cloud, outils de gestion de projet, CRM, facturation. Les tokens de session sont souvent durables et dotés de larges privilèges, ce qui signifie que l’attaquant peut maintenir une persistance pendant des jours ou des semaines.

Ce que les équipes peuvent faire concrètement

Côté développeurs et architectes

• Appliquer systématiquement les flags HttpOnly, Secure et SameSite=Strict sur chaque cookie d’authentification.
• Stocker les tokens dans des cookies HTTP-only plutôt que dans le localStorage ou le sessionStorage (accessibles par JavaScript).
• Mettre en œuvre la rotation des refresh tokens : un token volé ne doit pas pouvoir être réutilisé indéfiniment.
• Implémenter des durées de session courtes avec re-authentification pour les actions sensibles (changement de mot de passe, ajout d’un appareil, accès aux données financières).
• Surveiller les anomalies de session : connexions depuis des localisations inhabituelles, changements d’adresse IP en cours de session, accès hors horaires.

Côté DSI et responsables sécurité

• Mettre fin à la synchronisation des profils de navigateur entre appareils personnels et professionnels.
• Imposer un EDR (Endpoint Detection and Response) sur tous les postes, y compris ceux des prestataires ayant accès aux environnements internes.
• Activer le MFA sur tous les comptes, sans exception. En 2024, 80 % des comptes Snowflake compromis n’avaient pas de MFA activé.
• Invalider les credentials anciens. Dans l’affaire Snowflake, des identifiants volés en 2020 étaient encore valides en 2024.
• Mettre en place des politiques de confiance conditionnelle : si un token de session est utilisé depuis une adresse IP inhabituelle, exiger une re-authentification.
• Considérer le déploiement de Device Bound Session Credentials via Chrome Enterprise dès que la technologie sera disponible en production stable.

Pour les utilisateurs finaux

• Ne jamais installer de logiciel depuis une source non officielle, même si le site a l’air identique à l’original.
• Ne jamais copier-coller une commande dans un terminal depuis une page web, quelle que soit l’instruction affichée.
• Vérifier attentivement les extensions de navigateur installées et supprimer celles qui ne sont plus utilisées ou d’origine douteuse.
• Utiliser un profil de navigateur distinct pour les usages professionnels, sans synchronisation avec les appareils personnels.
• Une YubiKey est une excellente protection contre le phishing de connexion. Elle ne protège pas contre un poste déjà infecté.