Data Leak Detection — Recherche dans les données ayant fuité // MODULES

Data Leak Detection — Recherche dans les données ayant fuité

Moteur de recherche sur le corpus de documents ayant fuité que la plateforme indexe — dumps, combolists, journaux d’infostealer, déversements de forums et pièces transmises par le client lui-même. La requête est fédérée : une seule demande part vers tous les serveurs d’index configurés et les réponses reviennent fusionnées en un résultat unique.

Vue d’ensemble

Chaque document entre dans l’index découpé en fragments. La recherche confronte le terme au texte du fragment (poids 3), au nom du fichier (poids 2) et aux métadonnées de section et de titre, avec tolérance aux fautes de frappe, puis renvoie jusqu’à trois extraits où le terme est mis en évidence au milieu de la phrase — l’analyste lit le contexte sans ouvrir le fichier.

Trois agrégations accompagnent le résultat et servent à la fois de filtre et de diagnostic : par type de fichier, par catégorie et par source d’origine. C’est ainsi que l’on découvre, par exemple, qu’un même CNPJ apparaît dans quinze tableurs issus d’une source et dans un seul e-mail issu d’une autre.

Le fonctionnement interne

Fédération et pagination. La plateforme découvre les serveurs d’index par la configuration d’environnement et les interroge tous. Les agrégations sont additionnées clé par clé, les résultats sont réordonnés par pertinence sur l’ensemble déjà fusionné, et paginés seulement ensuite. Si un serveur tombe, les autres répondent et la défaillance est consignée — la recherche n’est pas otage du nœud le plus lent.

Cloisonnement fail-closed. Le filtre par organisation est toujours appliqué à quiconque n’est pas administrateur global, même si le champ « organisation » manque encore dans une partie des documents indexés. L’effet est délibéré : un document dépourvu de ce champ ne correspond à rien et n’apparaît pas. Le choix d’ingénierie a été de remplacer l’ancien comportement — qui levait le filtre en l’absence du champ et renvoyait tout — par un comportement qui pèche par défaut. Dans une recherche de données ayant fuité, un faux négatif est un désagrément ; une fuite croisée entre clients est un incident.

Empreinte inter-sources. Un même fichier circule sur plusieurs canaux. La plateforme conserve les sha256, sha1 et md5 de chaque document, avec un compteur d’occurrences et les dates de première et de dernière apparition. Cela répond à une question que la recherche plein texte ne traite pas : ce dump est-il inédit, ou s’agit-il de celui de mars reconditionné ?

Attribution avec niveau de confiance déclaré. Chaque empreinte peut recevoir des attributions — acteur, campagne, canal d’origine (Telegram, forum, paste site, marketplace, journal de stealer, dark web, clear web, flux partenaire, dépôt manuel), URL et pseudonyme de l’auteur de la publication, ainsi que la justification. La confiance comporte trois niveaux et le critère de chacun est explicite : faible pour une heuristique automatique, moyenne pour une corrélation entre sources, élevée seulement après relecture humaine appuyée sur plusieurs signaux. Le nom du relecteur et la date figurent dans l’enregistrement.

Fonctionnalités

  • Sélecteurs structurés : e-mail, domaine, URL, IPv4, IPv6, téléphone, adresse Bitcoin, adresse Ethereum, CPF et CNPJ (les identifiants fiscaux brésiliens des personnes physiques et des entreprises)
  • Extraction de texte depuis PDF, DOCX, XLSX, PPTX, HTML, EML et depuis les archives ZIP, RAR et 7z
  • Recherches enregistrées, partageables au sein de l’organisation ; modification par leur auteur ou par l’administrateur de l’organisation
  • Export en JSON ou CSV, plafonné à 100, 500, 1 000 ou 5 000 résultats
  • Audit de six événements — recherche, consultation, téléchargement, export, enregistrement et suppression d’une recherche — avec l’IP, la requête, les filtres, le nombre de résultats et le temps de réponse

Cas d’usage

  • Vérifier si des identifiants d’entreprise sont apparus dans un déversement récent, et sur quel canal
  • Suivre l’exposition du CPF ou du CNPJ de clients dans des bases mises en vente
  • Déterminer, grâce au compteur d’occurrences, si un dump annoncé comme inédit circulait déjà
  • Réunir la preuve d’origine nécessaire à une notification d’incident ou à une demande de retrait

Ce que le module ne fait pas

  • Une recherche enregistrée ne déclenche pas d’alerte. Elle conserve la requête pour la réutiliser, elle ne la planifie pas. La surveillance continue avec notification relève de Threat Monitoring, qui interroge ce même corpus.
  • Il n’interroge ni HaveIBeenPwned, ni DeHashed, ni aucun service tiers équivalent.
  • Il n’écrit pas dans l’annuaire d’entreprise : il ne force aucun changement de mot de passe et ne désactive aucun compte dans Active Directory ou Entra ID.
  • Il n’attribue jamais automatiquement une paternité avec un niveau de confiance élevé — ce niveau exige une signature humaine.
  • Il ne conserve pas le texte extrait dans la base relationnelle ; celui-ci réside dans l’index de recherche.

Intégrations

  • OpenSearch multi-serveurs (index ooda_leaks_*)
  • Airflow, pour les documents devant passer par l’OCR avant d’entrer dans l’index
  • OODA Threat Monitoring (recherche récurrente sur ce corpus) et OODA EASM (corrélation entre une fuite et les actifs du périmètre)

SLA et garanties

Index fédéré avec fusion des agrégations · cloisonnement par organisation fail-closed · chaque requête auditée

Étapes suivantes