Les fuites de données de vos collaborateurs sont affichées de deux manières distinctes, selon que leur potentiel d'exploitation soit confirmé ou non :
- 🆕 Fuites de données au potentiel d'exploitation confirmé
- Fuites de données au potentiel d'exploitation à confirmer
- Comprendre les résultats
- Pourquoi un ancien collaborateur apparaît-il dans l’onglet Fuite de données ?
- Pourquoi une alerte concerne-t-elle un poste de travail qui ne nous appartient pas ?
- Pourquoi la date de notification d’une fuite ne correspond-elle pas toujours à la date de compromission ?
- Pourquoi certaines fuites de données affichent-elles une source inconnue ?
- Que faire en cas d'alerte de fuite de données ?
1. 🆕 Fuites de données au potentiel d'exploitation confirmé
Ce sont les fuites de données les plus critiques, c'est-à-dire qu'un attaquant pourrait directement les utiliser s'il parvenait à les obtenir. Au regard de leur criticité, une vulnérabilité dédiée est créée pour chacune d'elle dans les résultats du Scan Externe Stoïk.
1.b. 🆕 Que signifie la vulnérabilité "Valid user credentials found in a dataleak/MO365/Fortinet" ?
Notre Scan Externe vous signale si les credentials trouvés par notre onglet Fuite de données sont toujours actifs.
Concrètement, les identifiants clients divulgués sur le Dark Web sont désormais testés automatiquement sur l'URL concernée afin de vérifier leur validité, grâce à un développement interne de Stoïk utilisant une IA générative
Si la validité est confirmée, une vulnérabilité "élevée" est crée lors de l'analyse du Scan Externe Stoïk, invitant les utilisateurs à mettre à jour leurs identifiants.
Le nom d'utilisateur et l'URL sont alors affichés sur Stoïk Protect (le mot de passe peut être partagé sur demande express à protect@stoik.io).
En tant que vulnérabilité "élevée", les analystes CERT de Stoïk vous notifient proactivement par mail si une alerte de ce type apparaît.
2.b. Comment Stoïk confirme-t-elle le potentiel d'exploitation de la fuite ?
Les fuites de données testées par Stoïk proviennent principalement de deux sources :
- Fuites issues de bases de mots de passe (Combolists) :
Ces bases sont des ensembles d’identifiants (emails, mots de passe) récupérés sur plusieurs fuites passées et agrégés sans contexte clair. Exemple :xavier@stoik.io / M0t2Pa$$ / supersite.com
Ces combolists ne permettent pas toujours de savoir sur quel site exact les identifiants ont fuité. Il est donc difficile de tester les identifiants sur le service mentionné. Dans ce cas, Stoïk effectue un test automatique des identifiants sur des services critiques et répandus comme Microsoft 365 (O365) ou VPN Fortinet (si ce service est utilisé par l’assuré).
💡 Nous ne testons pas l'identifiant directement sur le site mentionné, sauf s’il est connu avec certitude comme dans les logs stealers (voir ci-dessous). - Fuites issues de logiciels malveillants (Stealers) :
Les stealers sont des malwares installés sur des machines compromises, qui récupèrent localement les identifiants utilisés. Ces fuites sont beaucoup plus précises : elles incluent en général le triptyque :Email / Mot de passe / URL exacte de connexion. Exemple :xavier@stoik.io / M0t2Pa$$ / https://supersite.com/loginpage.php
Lorsque l’URL est clairement identifiée, les identifiants sont testés directement sur le site correspondant, en plus de Microsoft 365 (O365) et VPN Fortinet. Cette précision permet de réduire fortement les faux positifs et de cibler efficacement les risques de compromission active.
En résumé :
| Type de fuite | Données disponibles | Vérifications effectuées par Stoïk |
|---|---|---|
| Combolist | Email + mot de passe (ou nom d'un site) | O365 + Fortinet uniquement |
| Stealer logs | Email + mot de passe + URL précise | URL concernée + O365 + Fortinet |
Si l'URL concernée est Fortinet ou O365, la vulnérabilité affichée prend le nom "(...) found in Fortinet/Microsoft Office 365 dataleak". Sinon, la vulnérabilité affichée prend le nom "(...) found in a dataleak", et l'URL est précisée dans le détail de la vulnérabilité.
Par défaut, si les résultats recherchés dans ce tableau ne donnent rien, aucune vulnérabilité n'est créée mais la fuite est quand même affichée dans l'onglet "Fuite de données".
2. Fuites de données au potentiel d'exploitation à confirmer
2. a. Comprendre les résultats
L'onglet Surface Externe > Résultats > Fuites de données recense l'ensemble des fuites de données détectées sur vos collaborateurs, que leur potentiel d'exploitation soit déjà avéré ou non.
⚠️ La date indiquée correspond généralement au moment où notre outil a détecté la fuite de données, et non à la date réelle de la fuite.
En cliquant sur une fuite de donnée en particulier, vous avez accès au détail des résultats. Voici deux exemples d'interprétation des résultats :
- "IP" et "Mot de passe" : Pour cet exemple, comprenez que pour l'adresse email craig.maxwell@my-company.com, le mot de passe en clair (mot de passe) et l'IP ont fuité lors de la fuite de données Adobe Data Breach 2024 pour le domaine my-company.com.
- "Mot de passe" et "Mot de passe chiffré" : Pour cet exemple, comprenez que pour l'adresse email emma.gaucher@my-company.com, le mot de passe en clair ("mot de passe") et le hash ("mot de passe chiffré") ont fuité sur plusieurs sites de source inconnue d'où le mot "combolists".
2.b. Pourquoi un ancien collaborateur apparaît-il dans l’onglet Fuite de données ?
Si vous constatez l’apparition d’une alerte concernant un compte associé à un collaborateur qui n’est plus dans l’entreprise, il y a plusieurs raisons logiques à cela.
- Origine : Il ne s’agit pas d’un compte Active Directory ou d’une adresse e-mail d’entreprise directement active dans votre SI, mais plutôt d’un compte utilisateur tiers utilisant une adresse de votre domaine, par exemple :jean-michel@votre-entreprise.com enregistré sur un site externe, comme https://random.saas.Ce type de compte peut tout à fait appartenir à :
- Un ancien employé qui avait créé un compte SaaS avec son adresse professionnelle
- Un compte encore actif dans une application SaaS, dont l’adresse mail professionnelle reste valide
- Un compte externe créé sans vérification d’adresse email, ce qui est possible sur certaines plateformes
- Raison de la détection : L’alerte est générée par Stoïk car
- L’adresse mail du compte est liée à votre nom de domaine
- Le mot de passe associé à ce compte est apparu dans une fuite de données publique
Ainsi, même s’il s’agit d’un ancien collaborateur ou d’un compte non géré par votre SI, ce compte peut :
- Être toujours facturé à votre entreprise (cas courant pour les abonnements SaaS)
- Avoir accès à des données internes, si aucune révocation n’a été faite
- Représenter un risque de compromission indirecte (réutilisation du mot de passe, attaque par rebond)
- Identifiez si le compte est encore actif dans l’application concernée
- Révoquez ou désactivez le compte si vous avez la main dessus
- Contactez l’éditeur SaaS pour demander la suppression si besoin
- Mettez à jour vos procédures de départ collaborateur pour inclure la révocation systématique des comptes tiers
2.c. Pourquoi une alerte concerne-t-elle un poste de travail qui ne nous appartient pas ?
Il peut arriver que vous receviez une alerte de cybersécurité sur un poste de travail non répertorié dans votre parc informatique. Cela peut paraître surprenant, mais plusieurs cas de figure expliquent cette situation.
Poste personnel d’un collaborateur
- Origine : Un collaborateur peut, volontairement ou par habitude, accéder à des ressources professionnelles depuis un appareil personnel (ordinateur personnel, tablette, etc.).
- Raison de la détection : L’alerte est générée par Stoïk car ce poste n’est pas sécurisé ni supervisé par vos équipes IT et peut donc représenter un point d’entrée vulnérable pour des attaques (ransomware, vol de données).
- Recommendation : Dans cette situation, invitez votre collaborateur à limiter cet usage, ou à sécuriser son appareil (chiffrement, antivirus, mot de passe fort, etc.). Il est fortement recommandé de revoir la politique d’usage des équipements personnels (BYOD) si ce n’est pas déjà fait.
Poste d’un prestataire ou sous-traitant
- Origine : Il est possible qu’un prestataire (support IT externe, consultant, freelance, etc.) accède à vos données ou systèmes depuis son propre poste de travail.
- Raison de la détection : L’alerte est générée par Stoïk car elle implique vos services ou votre domaine. En effet, le poste est considéré comme à risque s’il est compromis ou mal protégé.
- Recommendation : Dans cette situation, vérifiez si ce prestataire est toujours actif dans l’entreprise. Si ce n’est pas le cas, révoquez ses accès. Sinon, assurez-vous que des bonnes pratiques de sécurité sont bien en place de son côté.
Poste partagé ou public (hôtel, borne, cybercafé…)
- Origine : Dans certains cas rares, l’accès à vos services peut avoir lieu depuis un terminal public ou partagé : borne d’hôtel, PC de salle de réunion, etc.
- Raison de la détection : L’alerte est générée par Stoïk car ces machines sont hautement exposées à des malwares ou keyloggers. En effet, les connexions y sont rarement chiffrées ou privées.
- Recommendation : Dans cette situation, il est essentiel de rappeler à vos collaborateurs de ne jamais utiliser de poste public pour accéder à des ressources critiques, ou à minima, d’utiliser un VPN et des connexions chiffrées.
Conclusion : même si le poste concerné ne vous appartient pas directement, l’alerte est pertinente si une activité liée à votre domaine ou votre organisation est détectée.
Toute activité inhabituelle peut signaler : une utilisation non encadrée, une compromission potentielle, une mauvaise gestion des accès tiers.
2.d. Pourquoi la date de notification d’une fuite ne correspond-elle pas toujours à la date de compromission ?
Il est fréquent que des utilisateurs s’interrogent sur le décalage entre la date d’une fuite de données (ou d’un mot de passe volé) et la date de réception de l’alerte Stoïk. Voici les raisons :
Le mot de passe n’est pas immédiatement rendu public
Les identifiants volés par des infostealers (logiciels malveillants capables d’aspirer les mots de passe depuis les navigateurs, gestionnaires ou caches systèmes) ne sont pas toujours partagés instantanément sur les forums ou places de marché que nous surveillons.
En pratique, les informations dérobées sont d’abord revendues dans des cercles privés ou groupes restreints, puis elles deviennent accessibles publiquement qu’après plusieurs semaines voire plusieurs mois. C’est à ce moment-là que notre système les détecte et vous alerte.
Une vérification technique préalable limite les faux positifs
Nous avons récemment déployé une nouvelle technologie de validation automatique des identifiants compromis.
Concrètement, Stoïk teste directement les identifiants (login + mot de passe) trouvés dans les bases de fuites, et ce n’est que si le couple fonctionne encore sur le site concerné que nous envoyons une alerte. Ce système de validation garantit que l’alerte est pertinente, même si la fuite est ancienne.
Lire 👉 1.b. Pour aller plus loin
🆕 Attention, ce système est encore en cours de déploiement. Cette fonctionnalité de validation automatique est une évolution récente, issue de nos développements internes. Elle est mise progressivement en production afin d’assurer une qualité optimale du service. Il est donc possible que certaines alertes soient issues d’un traitement plus récent, même si la fuite date d’avant cette mise à jour.
En résumé :
- Un décalage entre date de fuite et alerte est normal dans le cycle de vie d’un identifiant compromis.
- Cela ne remet pas en cause la validité de l’alerte : si vous êtes notifié, c’est que l’identifiant est encore fonctionnel.
- Mieux vaut être averti tard que jamais : ces fuites peuvent exposer votre entreprise à des usages malveillants prolongés, notamment en cas de réutilisation de mot de passe.
2.e. Pourquoi certaines fuites de données affichent-elles une source inconnue ?
- Origine : Il est possible que vous voyiez apparaître des fuites de données sans indication claire de leur origine dans votre interface Stoïk Protect. Dans ce cas, la source est indiquée comme “Combolist”, ce qui signifie qu’elle est inconnue ou non vérifiable.
Une combolist est une compilation massive d’identifiants (adresses email, mots de passe, parfois autres données) agglomérés depuis diverses fuites. Ces fichiers sont repackagés par des cybercriminels, puis revendus ou partagés sur des forums sans toujours mentionner l’origine des données.
- Raison de la détection : L’alerte est générée par Stoïk car même si la source exacte est inconnue, le risque est réel. En effet, l’identifiant (email + mot de passe) fonctionne encore sur certains services, il peut donc être exploité pour une attaque par réutilisation de mot de passe (credential stuffing) ou donner accès à un SaaS utilisé dans votre entreprise.
3. Que faire en cas d'alerte de fuite de données ?
- Changez immédiatement le mot de passe concerné.
- Si vous ne reconnaissez pas le service, vérifiez les usages internes de l’adresse mail mentionnée.
- Activez l’authentification multifacteur (MFA) si ce n’est pas déjà fait.