Marchés de logs d'infostealer : comment les identifiants d'entreprise volés finissent en vente

Les marchés clandestins qui négocient en masse la production des infostealers continuent de croître tout au long de 2026, et le schéma qui les sous-tend est devenu familier aux équipes de réponse à incident : une machine est infectée, un log de tout ce que le navigateur et le système d'exploitation avaient discrètement stocké est empaqueté, et ce paquet est proposé à la vente ou à l'échange en quelques heures. Ce qui n'était qu'un recoin de niche des forums cybercriminels est devenu une économie fonctionnelle, avec ses annonces, ses notations, ses formules d'abonnement et ses inventaires interrogeables. La raison pour laquelle cela dépasse le seul cadre du underground est simple : une part significative des intrusions par ransomware cette année n'a pas commencé par un e-mail de phishing menant au chiffrement. Elle a commencé par l'achat d'un log qui contenait déjà une session d'entreprise fonctionnelle.

Ce n'est délibérément pas un nouvel article sur la façon dont un infostealer arrive sur une machine — ce terrain est couvert ailleurs. Celui-ci porte sur ce qui se passe après que le malware a fait son travail : le marché en aval qui transforme un simple ordinateur portable infecté en point d'accès négociable pour quiconque est prêt à payer.

C'est l'économie de ce modèle qui le rend durable. Un log coûte très peu à l'acheteur au regard de ce qu'une session d'entreprise fonctionnelle peut ouvrir, et les vendeurs ne manquent pas d'approvisionnement : les infostealers tournent en continu en arrière-plan, exfiltrant discrètement tout ce que le navigateur a mis en cache, que la victime remarque un problème ou non. C'est précisément ce volume qui explique pourquoi les marketplaces proposent aujourd'hui recherche, filtrage et accès par abonnement plutôt que des dumps ponctuels : il y a assez de stock pour en faire un produit.

Ce que contient réellement un stealer log

Un « log » est la sortie empaquetée d'une seule infection par infostealer, et il est généralement bien plus riche qu'un simple couple identifiant / mot de passe. Les acheteurs y cherchent :

• des cookies de navigateur, dont des cookies de session actifs pour des plateformes SaaS d'entreprise, la messagerie, des portails VPN et des outils internes ;
• des mots de passe enregistrés, extraits directement des gestionnaires de mots de passe des navigateurs ;
• des données de saisie automatique — noms, adresses, fragments de cartes bancaires et historique de formulaires ;
• des identifiants d'applications locales et des fichiers de configuration référençant des systèmes internes ;
• des données d'empreinte système (version de l'OS, logiciels installés, nom d'hôte) qui aident l'acheteur à juger si la machine appartient à une cible de valeur.

Les annonces sont fréquemment organisées par domaine d'entreprise, par pays ou selon la présence de plateformes SaaS spécifiques dans le cookie jar, ce qui permet à un acheteur de rechercher directement « les logs contenant une session pour ce fournisseur d'identité » plutôt que de fouiller des dumps bruts.

Pourquoi cela contourne discrètement le MFA

L'authentification multifacteur est conçue pour empêcher quelqu'un de deviner ou de hameçonner un mot de passe. Elle ne fait pas grand-chose contre une session volée déjà authentifiée. Lorsqu'un infostealer récupère un cookie de session actif ou un jeton SaaS, cet artefact représente une connexion qui a déjà franchi le MFA sur la machine de l'utilisateur légitime. Le rejouer ailleurs permet de reprendre la session sans jamais présenter de second facteur, parce que du point de vue du fournisseur d'identité, l'authentification a déjà eu lieu.

C'est la raison structurelle pour laquelle le vol de sessions et de cookies est devenu plus attractif pour les attaquants que le credential stuffing classique :

• des identifiants réduits à un mot de passe imposent encore de contourner le MFA à la connexion ;
• un jeton de session valide, souvent non ;
• les plateformes SaaS d'entreprise maintiennent fréquemment les sessions actives pendant des heures ou des jours, ce qui offre à un log acheté une réelle fenêtre d'exploitation ;
• les acheteurs peuvent filtrer l'inventaire d'une marketplace pour ne retenir que les logs contenant des sessions liées à des fournisseurs d'identité, des VPN ou des suites collaboratives qu'ils savent monétiser.

Concrètement, le seul déploiement du MFA ne referme pas cette brèche : la durée de vie des sessions, le device binding et la détection de réutilisation comptent tout autant.

Détecter l'exposition avant qu'elle ne devienne un incident

Les équipes sécurité ne peuvent pas surveiller directement chaque annonce de marketplace, mais elles peuvent bâtir leur détection autour des artefacts qui entrent en circulation. Deux approches portent l'essentiel de l'effort :

• Corrélation sur les domaines et les identités. Vérifiez en continu les domaines d'entreprise et les adresses e-mail des collaborateurs face à des flux d'indicateurs liés à des identifiants et à des infrastructures compromis connus. Une recherche de domaine via threat-intel/domain peut révéler si le domaine de connexion ou de SSO d'une entreprise apparaît aux côtés d'infrastructures de commande et de contrôle d'infostealers ou de kits de phishing qui, en amont, moissonnent les sessions.
• Empreintes de charges et d'artefacts. Lorsqu'un binaire, un script ou une pièce jointe suspecte est récupéré sur un poste, calculez son empreinte et vérifiez sa réputation avant de le supposer inoffensif. La recherche threat-intel/file-hash est le moyen le plus rapide de confirmer qu'une charge soupçonnée d'être un stealer a déjà été observée et classifiée ailleurs, ce qui raccourcit le délai entre « quelque chose cloche sur ce portable » et « c'est un infostealer confirmé, traitez chaque session de cette machine comme compromise ».

Aucun de ces contrôles ne remplace la détection sur les postes, mais tous deux donnent à une équipe sécurité un signal externe, mis à jour en continu, qui complète ce que la journalisation interne montrerait seule.

Réponse à incident en cas de suspicion de vente de log

Dès qu'il existe une suspicion raisonnable que le log d'une machine est entré en circulation — qu'elle vienne d'une alerte interne, d'une correspondance en threat intelligence ou d'une notification externe — la réponse doit aller plus vite que le marché :

• Révoquez les sessions en masse. Ne vous arrêtez pas au seul compte à l'origine de l'alerte. Forcez la révocation des sessions sur le fournisseur d'identité et sur toutes les plateformes SaaS connectées pour l'utilisateur concerné, et envisagez un balayage plus large si le vecteur d'infection laisse penser que d'autres machines sont probablement compromises.
• Faites tourner les identifiants, pas seulement les mots de passe. Les mots de passe enregistrés dans le navigateur, les clés d'API stockées dans le navigateur et tout secret d'application locale présent sur la machine concernée doivent être considérés comme grillés.
• Revérifiez la confiance accordée à la machine. Si l'enrôlement MFA ou l'enregistrement de l'appareil sur le compte paraît inhabituel, ne présumez pas que l'état actuel de la machine est légitime : réenrôlez depuis un poste connu comme sain.
• Guettez la réutilisation. Après révocation, surveillez spécifiquement les journaux d'authentification à la recherche de tentatives de rejeu des anciens artefacts de session ou de réutilisation des identifiants renouvelés, car un log déjà vendu peut circuler auprès de plusieurs acheteurs avant de se périmer.

Lors du premier passage, la rapidité compte plus que l'exhaustivité : une révocation partielle réalisée dans la première heure vaut mieux qu'une révocation complète menée le lendemain, parce que le marché n'attend pas la fenêtre de gestion des changements de qui que ce soit. Des playbooks structurés de réponse à incident pour exactement ce type d'intrusion centrée sur l'identité sont détaillés plus en profondeur dans solutions/incident-response.

Passage à l'action

Les marchés de stealer logs vont vite, et la valeur d'un log donné décroît dès l'expiration des sessions ou la rotation des identifiants — ce qui signifie que le travail du défenseur consiste à refermer cette fenêtre avant qu'un acheteur ne l'exploite. L'enrichissement continu d'IOC sur les domaines et les empreintes de fichiers liés aux infrastructures d'infostealers donne aux équipes sécurité le signal précoce nécessaire pour révoquer les sessions et faire tourner les identifiants avant qu'un log acheté ne devienne un point d'ancrage pour un ransomware. Branchez cet enrichissement directement dans votre chaîne de détection et de réponse à incident via l'API isMalicious.