Identifiants d’entreprise retrouvés sur le dark web : qualifier la fuite, réagir dans l’ordre, prévenir la suivante

De quoi parle-t-on quand des identifiants « fuitent sur le dark web » ?

Un service de surveillance, un partenaire ou un chercheur signale que des adresses de votre domaine figurent dans une fuite. Derrière cette formule se cachent des réalités très différentes.

On rencontre trois grandes familles de données :

• Les bases issues d’une fuite chez un tiers. Un site ou un service a été compromis, et sa base de comptes circule : adresse e-mail, mot de passe en clair ou haché, parfois d’autres champs. Si un collaborateur s’y est inscrit avec son adresse professionnelle, elle apparaît.
• Les combolists. Ce sont des compilations de couples identifiant et mot de passe agrégés depuis de nombreuses fuites, souvent anciennes, revendues ou republiées sans cesse. Elles servent surtout aux attaques par réutilisation de mots de passe.
• Les journaux d’infostealers. Un infostealer est, selon la définition de l’ANSSI, un code malveillant conçu pour collecter des informations sur le poste de la victime, notamment les authentifiants enregistrés dans les navigateurs et les cookies de session. Chaque poste infecté produit un journal qui associe des adresses de services, des identifiants, des mots de passe et des cookies.

L’ANSSI note dans son Panorama de la cybermenace 2025 un recours récurrent à ces logiciels dans les attaques ayant conduit à des fuites de données, et souligne qu’il est difficile d’y réagir quand l’entreprise ne maîtrise pas le vecteur d’infection, notamment en l’absence de cloisonnement entre usages professionnels et personnels.

Ce que ce guide traite, et ce qu’il ne traite pas

L’article sur la reconnaissance OSINT décrit comment un attaquant collecte ces identifiants. Ce guide se place de l’autre côté : la fuite est constatée, il faut décider quoi faire et dans quel ordre.

Comment qualifier la fuite avant d’agir ?

Réinitialiser en urgence des dizaines de comptes pour une liste ancienne mobilise des équipes pour rien ; traiter un journal d’infostealer de la semaine comme une simple hygiène de mots de passe laisse un attaquant connecté. Cinq questions permettent de trier.

1. Quelle est la nature de la donnée ?

Une ligne de combolist contient un identifiant et un mot de passe, sans contexte. Un journal d’infostealer y ajoute l’adresse du service concerné (portail VPN, messagerie web, application SaaS), des cookies de session, parfois des informations sur la machine : il dit à l’attaquant où se connecter et lui fournit parfois une session déjà ouverte.

2. Quelle est sa fraîcheur ?

La date de publication d’une fuite n’est pas sa date de collecte. Une combolist « nouvelle » recycle souvent des données anciennes. Pour un journal d’infostealer, la date d’infection du poste, lorsqu’elle figure dans le journal, est l’information décisive. Comparez-la à la date du dernier changement de mot de passe du compte : si le mot de passe a changé depuis, le risque porte surtout sur la réutilisation ailleurs.

3. Le compte est-il encore actif ?

Un compte désactivé réduit le risque, si la désactivation est effective partout, y compris dans les applications qui gèrent leurs propres comptes. Un compte actif, a fortiori à privilèges, fait monter la priorité.

4. Le service est-il protégé par une authentification multifacteur ?

Sans authentification multifacteur, un mot de passe valide suffit pour se connecter. Avec elle, le mot de passe seul ne suffit plus, mais la protection dépend du facteur : la CNIL rappelle que le code reçu par SMS est déconseillé par les autorités compétentes. Surtout, aucune authentification ne protège une session déjà ouverte : le CERT-FR souligne que le vol de cookies de session peut permettre de contourner l’authentification multifacteur, ce que confirme la technique T1539 de MITRE ATT&CK.

5. Le poste infecté est-il personnel ou professionnel ?

Un journal d’infostealer révèle un poste compromis. S’il est géré par l’entreprise, il entre dans la réponse à incident. S’il est personnel, l’entreprise ne peut ni l’analyser ni le nettoyer elle-même : tout ce qui a été saisi dessus est à considérer comme exposé.

Quel risque pour quel type de fuite ?

Le tableau sert à trier une alerte, pas à remplacer l’analyse.

Dans quel ordre réagir ?

Quand la qualification conclut à un risque réel, l’ordre des actions compte. Changer le mot de passe sans révoquer les sessions laisse l’attaquant connecté ; nettoyer le poste avant de couper les accès lui laisse le temps de revenir.

1. Préserver les traces. Avant toute modification, exportez les journaux de connexion du compte et notez l’état de sa configuration (méthodes d’authentification, règles de transfert de messagerie). La fiche « Piratage de compte » de Cybermalveillance.gouv.fr recommande de conserver les preuves avant de déconnecter les sessions inconnues. Ne testez pas le mot de passe fuité en vous connectant avec : vous brouilleriez les journaux.
2. Réinitialiser le mot de passe du compte, puis de tous les comptes qui partagent ce mot de passe ou figurent dans le même journal. Le NIST SP 800-63B impose de forcer le changement dès qu’il existe un indice de compromission.
3. Révoquer les sessions et les jetons. C’est l’étape la plus souvent oubliée. Dans Microsoft Entra ID par exemple, la documentation de Microsoft précise que la révocation empêche d’obtenir de nouveaux jetons, mais que les jetons d’accès restent valides jusqu’à leur expiration (une heure par défaut) et que l’annuaire ne peut pas révoquer directement les sessions émises par une application. Chaque application SaaS sensible doit donc être traitée à part.
4. Contrôler ce que l’attaquant a pu installer. Nouvelles méthodes d’authentification enregistrées, appareils ajoutés, règles de transfert ou de suppression dans la messagerie, applications tierces autorisées, clés d’API créées : ce sont les moyens de revenir après la réinitialisation.
5. Rechercher les connexions suspectes sur la période qui va de la date d’infection, ou de la fuite, à aujourd’hui : adresses IP et pays inhabituels, hébergeurs, déplacements impossibles, connexions sans second facteur, téléchargements massifs. MITRE recommande précisément de journaliser les authentifications et de surveiller ces anomalies.
6. Examiner le poste infecté. Un poste professionnel est isolé, analysé puis réinstallé : supprimer le seul fichier malveillant ne garantit pas qu’il n’en reste rien. Pour un poste personnel, on demande au collaborateur de le faire remettre en état, de changer ses mots de passe personnels, et on bloque l’accès aux ressources de l’entreprise depuis ce poste en attendant.
7. Évaluer les obligations de notification, sur la base de ce que l’enquête a établi (voir ci-dessous).
8. Documenter la chronologie, les comptes traités et les mesures prises : cette trace sert l’obligation de documentation du RGPD et le retour d’expérience.

Quand la fuite devient-elle une violation de données personnelles ?

Le RGPD définit la violation de données à caractère personnel comme une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données personnelles ou l’accès non autorisé à de telles données.

L’apparition d’une adresse professionnelle dans une combolist ne suffit pas à caractériser une violation chez l’entreprise : la fuite a souvent eu lieu chez un tiers. La question change de nature si l’enquête établit, ou ne permet pas d’exclure, qu’un attaquant s’est connecté avec ce compte à une messagerie, un CRM ou un espace documentaire contenant des données personnelles. Dans ce cas :

• l’article 33 impose de notifier la violation à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes ;
• l’article 34 impose d’informer les personnes concernées lorsque le risque est élevé ;
• dans tous les cas, la violation est documentée en interne (article 33, paragraphe 5).

La CNIL admet une notification initiale complétée ensuite, et conseille, en cas de doute, de notifier : elle indiquera s’il faut informer les personnes. D’autres obligations sectorielles ou contractuelles peuvent s’ajouter ; le délégué à la protection des données et le juriste doivent être associés dès que l’hypothèse d’un accès à des données personnelles est sérieuse.

Exemple type : deux alertes, deux réponses

Exemple type. Une entreprise de services reçoit le même jour deux alertes de surveillance sur son domaine.

La première signale plusieurs dizaines d’adresses dans une combolist récente. Les mots de passe proviennent d’une fuite ancienne d’un site grand public, et tous les comptes en ont changé depuis. L’équipe ajoute ces mots de passe à sa liste de refus, rappelle la règle de non-réutilisation et clôt l’alerte.

La seconde porte sur un seul compte : un journal d’infostealer daté de dix jours, issu d’un ordinateur familial. Il contient l’adresse du portail de messagerie, le mot de passe en cours et des cookies de session pour l’outil de gestion commerciale. L’authentification multifacteur par SMS de la messagerie n’a pas protégé l’outil commercial, dont la session restait ouverte.

L’équipe exporte les journaux, réinitialise le mot de passe, révoque les sessions dans l’annuaire puis dans l’outil commercial, où les sessions sont gérées séparément. Les journaux montrent une connexion depuis un hébergeur étranger trois jours plus tôt, suivie d’un export de fiches clients. Le délégué à la protection des données est saisi, la violation est notifiée à la CNIL dans le délai, et l’accès aux applications depuis des postes non gérés est bloqué.

Ce scénario est construit à partir de situations courantes, pas à partir d’une organisation identifiable.

Comment prévenir la prochaine fuite ?

Une fuite n’est pas toujours évitable. L’objectif est qu’un identifiant fuité ne suffise plus à entrer, et qu’on le sache vite.

1. Généraliser une authentification multifacteur résistante à l’hameçonnage sur les accès exposés. Le NIST SP 800-63B ne considère pas comme résistants à l’hameçonnage les codes à usage unique ni l’authentification hors bande, comme le SMS ; seule l’authentification cryptographique qui lie la preuve au service légitime l’est. C’est le principe des clés de sécurité de type FIDO, que MITRE ATT&CK recommande aussi contre le vol de sessions.
2. Aligner la politique de mots de passe sur le NIST SP 800-63B. Comparer chaque nouveau mot de passe à une liste de refus qui inclut les mots de passe issus de fuites antérieures ; exiger une longueur suffisante (15 caractères au moins quand le mot de passe est le seul facteur) plutôt que des règles de composition, que le NIST interdit désormais ; ne pas imposer de changement périodique, mais forcer le changement dès qu’une compromission est suspectée.
3. Interdire l’enregistrement des mots de passe professionnels dans le navigateur, a fortiori sur les postes non gérés. La technique T1555.003 de MITRE ATT&CK décrit l’extraction de ces mots de passe par des logiciels comme Lumma Stealer ou RedLine, et recommande de peser ce risque. L’alternative est un gestionnaire de mots de passe choisi et administré par l’entreprise.
4. Cloisonner les usages. Réserver l’accès aux ressources sensibles aux postes gérés, par des règles d’accès conditionnel, et traiter le télétravail sur poste personnel comme une exception encadrée.
5. Raccourcir les sessions. Une durée de vie de session plus courte réduit la valeur d’un cookie volé : MITRE ATT&CK le recommande, et le CERT-FR consacre une partie de ses contre-mesures à la politique de sécurité des sessions authentifiées.
6. Surveiller en continu les fuites qui concernent votre domaine, pour passer de la découverte fortuite à la détection. C’est le rôle d’une surveillance du dark web intégrée à la surveillance OSINT de votre exposition, et le lien avec la sécurité des identités est direct : un identifiant fuité n’a de valeur que si l’annuaire l’accepte encore.

Dans nos missions, nous constatons souvent que l’identifiant encore exploitable ne vise pas la messagerie, généralement protégée, mais un service resté à l’écart de l’authentification multifacteur : un portail VPN ancien, une application métier avec ses propres comptes, une console d’administration.

Limites de l’exercice

Les données sont invérifiables. Une fuite peut être fabriquée, gonflée ou republiée sous un nouveau nom. Le contenu d’une alerte se confronte toujours à vos propres sources : annuaire, journaux de connexion, dates de changement de mot de passe.

Les faux positifs sont fréquents. Adresses qui n’ont jamais existé, comptes de test, homonymes sur un domaine proche, doublons d’une même fuite republiée : une partie des alertes ne correspond à aucun risque. À l’inverse, une absence d’alerte ne prouve rien : rien ne garantit que toutes les fuites deviennent visibles.

La collecte a un cadre légal. On n’achète pas une fuite pour savoir ce qu’elle contient : cela finance l’écosystème criminel, et cet achat peut tomber sous le coup du recel, que l’article 321-1 du Code pénal définit comme le fait de détenir ou de transmettre une chose en sachant qu’elle provient d’un crime ou d’un délit. Les identifiants collectés restent par ailleurs des données personnelles des collaborateurs : leur surveillance suppose une finalité définie, une collecte limitée au domaine de l’entreprise et une durée de conservation encadrée.

La surveillance ne remplace pas la prévention. Elle raccourcit le délai de réaction, mais la protection durable tient à l’authentification résistante à l’hameçonnage, au cloisonnement des postes et à des sessions courtes.