Le MFA, c'est devenu le cataplasme universel de la cybersécurité. On active le double facteur, on coche la case, on dort tranquille. Sauf qu'en 2026, une génération entière de malwares n'essaie même plus de voler vos mots de passe. Ils attendent que vous vous connectiez vous-même — et ils volent le résultat.

Le cookie de session : la clé du royaume que personne ne surveille

Pour comprendre pourquoi le MFA est insuffisant face aux stealers modernes, il faut d'abord comprendre comment fonctionne une authentification web. Quand vous tapez votre mot de passe et votre code 2FA sur Gmail, deux choses se passent. Premièrement, Google vérifie que vous êtes bien qui vous prétendez être — c'est le moment où le MFA intervient. Deuxièmement — et c'est là où ça devient intéressant — Google génère un cookie de session, un jeton alphanumérique qu'il dépose dans votre navigateur. Ce cookie dit essentiellement : « cet utilisateur s'est authentifié avec succès à telle date, faites-lui confiance ».

À partir de là, chaque requête que votre navigateur envoie à Gmail transporte ce cookie. Google ne vous demande plus votre mot de passe ni votre code 2FA — il vous reconnaît via le cookie. Et ce cookie peut rester valide pendant des jours, des semaines, parfois des mois selon les paramètres de session de l'organisation.

La faille conceptuelle est là. Le MFA protège le moment de l'authentification. Il ne protège pas le jeton qui en résulte. Si quelqu'un récupère ce cookie — ce qui est trivial sur une machine compromise — il peut rejouer exactement la même session que vous, depuis n'importe où, sans avoir besoin de votre mot de passe ni de votre code 2FA. L'authentification a déjà eu lieu. La preuve est dans le cookie.

Ce n'est pas une nouvelle découverte théorique. Microsoft documentait déjà ce vecteur en 2022 dans ses analyses des attaques AiTM (Adversary-in-the-Middle). Ce qui est nouveau en 2026, c'est la commoditisation de l'exploitation. Des outils comme DarkCore, découvert par BlackFog en août 2026, vendent une interface complète pour voler ces cookies, les gérer et les réutiliser — avec des options pour Gmail, WhatsApp, YouTube, Office 365 — depuis un panneau de contrôle accessible à n'importe quel opérateur de malware.

L'anatomie d'une attaque post-MFA réussie

Décrivons le scénario type. Un employé d'une entreprise utilisant Google Workspace clique sur un lien dans un email qui ressemble à une notification interne. Le lien télécharge un fichier qui installe silencieusement un stealer — Lumma, Redline, ou l'un de leurs successeurs. L'infection prend moins de 30 secondes et l'antivirus ne détecte rien : le binaire est polymorphe, packagé pour éviter les signatures connues.

Dans les minutes suivantes, le stealer fait un inventaire. Il lit les magasins de credentials des navigateurs (Chrome stocke ses cookies dans une base SQLite locale dans le profil utilisateur, chiffrée avec les credentials Windows — facilement déchiffrable une fois sur la machine). Il extrait les cookies de session actifs pour tous les services web ouverts dans le navigateur. Il liste les fichiers récents. Puis il exfiltre tout vers un serveur de commande et contrôle.

L'attaquant récupère le package quelques minutes plus tard. Il filtre les cookies par service cible : Gmail, Slack, Microsoft 365, GitHub, AWS Console. Il importe les cookies dans son navigateur attaquant. Pour DarkCore, il y a même une interface dédiée qui fait ça automatiquement et route la session via l'adresse IP de la victime. Il se retrouve maintenant « connecté » à tous ces services comme si c'était lui l'employé légitime — sans avoir jamais vu le mot de passe, sans avoir jamais reçu une notification push 2FA.

Du côté des services web, tout semble normal. La connexion vient de la bonne adresse IP (celle de la victime), du bon profil navigateur, à une heure raisonnable. Google ne déclenche aucune alerte. Slack ne signale rien. L'employé ne reçoit aucune notification. L'attaquant dispose d'un accès silencieux et persistant tant que le cookie reste valide.

Combien de temps ? Pour Gmail avec une session active et une IP stable, plusieurs semaines. Pour AWS Console sans politique de session forcée, potentiellement des jours voire des semaines également. Pour GitHub, les sessions web peuvent durer très longtemps. Ce délai laisse à l'attaquant tout le temps nécessaire pour extraire les emails sensibles, accéder aux documents partagés, comprendre l'organisation, identifier les systèmes critiques — et préparer une attaque secondaire plus destructive.

Le marché des stealers en 2026 : un écosystème mature

DarkCore n'est que la dernière entrée dans un catalogue bien fourni. L'écosystème des information stealers a connu une professionnalisation spectaculaire depuis 2020. On est passé d'outils brutaux développés par des individus isolés à de véritables produits commerciaux avec documentation, support client, mises à jour régulières et garanties de non-détection par les principaux antivirus (évidemment non contractuelles).

Lumma Stealer (aussi connu sous Lumma C2) est devenu l'un des plus utilisés. Vendu en abonnement de 250 à 1 000 dollars par mois selon les fonctionnalités, il supporte l'extraction de cookies pour plus de 50 navigateurs différents, les credentials de portefeuilles crypto, les fichiers de configuration des clients VPN et les documents Office récents. Il est régulièrement mis à jour pour contourner les nouvelles protections navigateur (la protection des cookies de Chrome a évolué avec Application-Bound Encryption en 2024 — Lumma a eu un contournement fonctionnel en quelques semaines).

Vidar Stealer, Redline Stealer, RisePro, StealC — chacun de ces outils cible les cookies de session comme fonctionnalité centrale. Certains ont évolué pour intégrer des capacités de RAT complètes (Remote Access Trojan), permettant non seulement de voler les données mais aussi de maintenir un accès persistant à distance. C'est dans cette catégorie que se positionne DarkCore avec son module de proxy inverse : le stealer devient un outil de contrôle complet.

Les chiffres de distribution sont éloquents. Selon les données de Hudson Rock, un agrégateur de marchés cybercriminels, plus de 1,3 million de credentials volés par des stealers étaient en vente sur les marchés darkweb au premier trimestre 2026. Ces credentials incluent massivement des cookies de session pour des services cloud professionnels : Google Workspace, Microsoft 365, Salesforce, ServiceNow, AWS.

Le modèle de distribution Malware-as-a-Service abaisse considérablement la barrière d'entrée. Un opérateur n'a pas besoin de savoir coder — il achète un accès mensuel à un stealer, télécharge un builder qui génère un binaire configuré, et le distribue via les vecteurs classiques (email de phishing, faux logiciels crackés, publicités malveillantes). Le coût d'entrée pour lancer une campagne de vol de cookies à grande échelle est aujourd'hui inférieur à 500 dollars.

Le reverse proxy : se cacher derrière sa victime

La fonctionnalité de reverse proxy présente dans DarkCore — et dans d'autres outils comme Cobalt Strike en usage APT — mérite une attention particulière car elle représente une évolution tactique importante. Elle s'attaque spécifiquement aux mécanismes de détection basés sur la localisation et le profil d'appareil.

Google et Microsoft ont tous deux investi massivement dans la détection des connexions anormales. Une connexion depuis un pays inhabituellement différent de l'historique de l'utilisateur, depuis un appareil inconnu, ou depuis plusieurs géographies en succession rapide (impossible travel) déclenche une vérification supplémentaire ou un blocage automatique. Ces contrôles compensent en partie les limites du MFA.

Le reverse proxy contourne directement ces contrôles. En routant le trafic de la session volée à travers la machine infectée de la victime, l'attaquant présente au service web exactement le bon triplet (adresse IP, User-Agent du navigateur, profil géographique). Aucune anomalie de localisation. Aucune alerte sur un appareil inconnu. Les contrôles post-authentification voient une connexion parfaitement normale.

C'est une sophistication qui était auparavant réservée aux groupes APT disposant de ressources importantes. Sa présence dans un outil commercial accessible pour quelques centaines de dollars marque un saut qualitatif dans la menace pesant sur les organisations qui se reposent uniquement sur les détections comportementales de Google ou Microsoft.

Les angles morts des organisations face à cette menace

La première erreur est de traiter le MFA comme une solution complète. Beaucoup d'organisations ont déployé le MFA — souvent sous la pression des assureurs cyber et des certifications ISO 27001 — et ont considéré le risque de compromission de compte comme traité. Ce n'est pas le cas. Le MFA protège le secret (le mot de passe) mais pas la preuve d'authentification (le cookie). C'est une confusion fréquente dans les analyses de risque.

La deuxième erreur est l'angle mort BYOD. Beaucoup d'organisations permettent, voire encouragent, l'accès aux outils professionnels (Gmail, Teams, Slack) depuis des appareils personnels. Ces appareils n'ont généralement pas d'EDR d'entreprise, pas de politiques de sécurité navigateur, et une hygiène numérique variable. Un seul appareil BYOD compromis peut fournir un accès non détecté à tous les services professionnels de l'employé.

La troisième erreur est de sous-estimer la durée de vie des sessions. Les équipes sécurité configurent soigneusement les politiques de mot de passe et les expirations 2FA, mais rarement les durées de session. Un audit des politiques de session des principaux services Google Workspace dans les organisations françaises révèle fréquemment des configurations par défaut : des semaines de validité de session sans ré-authentification forcée.

La quatrième erreur est l'absence de monitoring de l'exfiltration de cookies. Les EDR modernes détectent les accès aux fichiers sensibles connus (SAM, LSASS pour les hashes), mais la détection des accès aux magasins de cookies des navigateurs est moins systématiquement configurée. Chrome stocke ses cookies dans %APPDATA%LocalGoogleChromeUser DataDefaultNetworkCookies — un accès à ce fichier par un processus autre que Chrome devrait être une alerte prioritaire.

Ce qui fonctionne vraiment — les contre-mesures réalistes

La première contre-mesure est la réduction de la durée de vie des sessions. Pour Google Workspace, l'administrateur peut configurer une durée de session web allant de 1 heure à 2 semaines dans la console Admin. Pour les organisations traitant des données sensibles, 8 heures est un bon compromis entre sécurité et confort utilisateur. Microsoft Entra propose des politiques équivalentes via les Conditional Access Policies.

La deuxième contre-mesure est le Device Trust. Google Workspace Enterprise et Microsoft Entra ID permettent de restreindre les sessions à des appareils enregistrés et gérés. Un cookie volé depuis un appareil non managé ne peut pas être réutilisé depuis un autre appareil non inscrit dans le Device Trust. C'est la contre-mesure la plus efficace contre le reverse proxy de DarkCore — l'attaquant peut bien router son trafic via l'IP de la victime, si son appareil n'est pas dans le registre des appareils de confiance, la session est rejetée.

La troisième contre-mesure est la Continuous Access Evaluation (CAE) pour Google Workspace et l'équivalent CAEP pour Microsoft. Ces mécanismes permettent de révoquer les sessions en temps réel en cas de changement de contexte (IP modifiée, appareil signalé compromis) sans attendre l'expiration naturelle du cookie. C'est une évolution architecturale importante du modèle de sécurité des sessions web.

La quatrième contre-mesure est la détection EDR des accès aux magasins de cookies. Les règles YARA ou Sigma correspondantes existent — les équipes SOC doivent les activer et les monitorer activement. Un processus autre que le navigateur accédant au fichier Cookies de Chrome est une alerte à haute fidélité.

La cinquième contre-mesure est la formation des utilisateurs, pas sur les mots de passe mais sur les comportements post-infection : comment reconnaître qu'un compte a été utilisé à leur insu (historique de connexions dans Gmail, activité de l'application dans Slack), et comment réagir — révoquer les sessions depuis le panneau de gestion des comptes, changer les mots de passe, alerter l'équipe sécurité.

Ce que les organisations oublient systématiquement

Les sessions des comptes de service et des automatisations sont rarement incluses dans les revues de durée de session. Un script d'automatisation qui tourne avec un cookie de service Google configuré pour durer 3 mois représente une surface d'attaque permanente. Ces comptes non humains (Non-Human Identities) sont aujourd'hui un vecteur d'attaque majeur — CrowdStrike estime qu'ils représentent plus de 45 % des identités dans les environnements cloud modernes, avec des niveaux de sécurité en moyenne inférieurs aux comptes humains.

Les applications tierces autorisées à accéder aux comptes Google ou Microsoft via OAuth sont une autre surface négligée. Un attaquant qui compromet un accès OAuth valide à une application tierce peut maintenir un accès persistant aux emails et fichiers d'un utilisateur même après révocation du cookie de session principal — tant que l'autorisation OAuth n'est pas explicitement révoquée. L'audit régulier des applications OAuth autorisées dans l'organisation devrait être un exercice trimestriel systématique.

Mon avis d'expert

Le MFA est nécessaire mais il ne suffit plus, et le marché l'a compris avant beaucoup d'équipes sécurité. La promesse implicite du MFA — « si votre mot de passe est volé, vous êtes quand même protégé » — reste vraie. Mais elle masque une vulnérabilité structurelle : après l'authentification, le modèle de confiance revient à un simple cookie. Ce token, c'est le nouveau mot de passe. Et il est souvent moins bien protégé que l'original.

Ce que je vois sur le terrain, c'est que les organisations investissent massivement sur la couche d'authentification (MFA, passwordless, passkeys) mais très peu sur la gestion du cycle de vie des sessions post-authentification. Les durées de session par défaut sont laissées telles quelles. Le Device Trust n'est pas activé parce que ça complique le BYOD. La CAE n'est pas configurée parce que personne ne sait que ça existe. Résultat : une infrastructure d'authentification excellente qui débouche sur une gestion des sessions médiocre.

La bonne nouvelle : les outils existent. Google Workspace et Microsoft 365 offrent tous les paramètres nécessaires. Ce n'est pas une question de budget — c'est une question de configuration. Et configurer correctement les durées de session et le Device Trust prend une journée, pas six mois. C'est peut-être l'audit de sécurité avec le meilleur ROI du moment.

Conclusion : changer l'angle de protection

DarkCore n'est pas une révolution — c'est une commoditisation. Le vol de cookies de session existe depuis des années. Ce qui change en 2026, c'est que ces capacités sont désormais packagées dans des produits clés en main, accessibles à des opérateurs peu qualifiés, distribués à grande échelle. Le volume des infections va augmenter. Les sessions volées disponibles sur les marchés cybercriminels vont augmenter. Les accès non autorisés à des comptes email et messagerie d'entreprise vont augmenter.

La réponse n'est pas de remplacer le MFA — il reste une couche de défense nécessaire. La réponse est d'adresser la vulnérabilité structurelle qu'il ne couvre pas : la durée de vie des sessions post-authentification. Réduire les durées de session, déployer le Device Trust, activer la Continuous Access Evaluation, monitorer les accès aux magasins de cookies via l'EDR — ce sont des actions concrètes, réalisables, qui réduisent substantiellement la surface d'exploitation disponible pour des outils comme DarkCore.

Les équipes qui attendent qu'une faille soit annoncée pour agir auront toujours un temps de retard. Les équipes qui configurent leur posture de sécurité de manière proactive — durées de session courtes, Device Trust, monitoring des cookies — transforment une attaque autrement silencieuse en un incident détectable et limité dans le temps.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique — gestion des sessions, Device Trust, audit des applications OAuth autorisées.

Prendre contact