Allégation d’exposition de données de GhostMarket.net en 2009

Les métadonnées internes de l’archive reprennent le nom de l’entité sous les formes GhostMarket et GhostMarket.net, indiquent un périmètre source de 3 331 enregistrements de comptes et ne fournissent que l’année 2009 dans le champ de date de violation de données. Un examen limité des métadonnées publiques des archives du Guardian étaye également le contexte d’activité d’un forum de criminalité en ligne associé au nom GhostMarket en 2009. La source publique ne prouve pas le jour exact auquel cette archive précise a été obtenue, ne confirme pas que l’opérateur de GhostMarket.net a attesté l’authenticité de ce jeu de données et n’établit pas que toutes les lignes archivées proviennent d’un même événement. Cette fiche n’est donc pas présentée comme un avis de violation de données vérifié émanant directement de l’entité concernée. isVerified reste à false, et la description distingue délibérément les éléments de preuve scellés issus de l’archive du contexte public plus large.

La date est enregistrée avec une précision limitée à l’année. La valeur du 1er janvier 2009 dans la base de données n’est qu’une représentation technique de l’année 2009; elle n’affirme pas que l’événement s’est produit le 1er janvier. Les métadonnées internes désignent 2009 comme la « date de violation de données », tandis que l’en-tête de l’export SQL porte une date de génération en juillet 2009. La date de génération d’une copie de base de données peut indiquer quand un export a été produit, mais elle ne permet pas, à elle seule, d’établir une date d’exposition. Les références à 2009 dans les métadonnées publiques corroborent la période d’activité de l’entité, sans dater l’exposition des données privées à un jour précis. Pour ces raisons, breachDatePrecision vaut year, le jour exact reste inconnu et la représentation au 1er janvier fait l’objet d’une réserve explicite. Une future source primaire pourrait justifier un réexamen distinct de la date.

La source est une archive 7z complète de 3 728 860 octets. Son empreinte SHA-256 est scellée et un test complet d’intégrité 7z a réussi. Les quatre fichiers ordinaires qu’elle contient ont tous été extraits et identifiés indépendamment par leur taille et leur empreinte SHA-256. Il s’agit d’un fichier de métadonnées générique Breached_Info, d’un fichier de métadonnées Info contenant du contexte sur GhostMarket et des échantillons, d’une représentation CSV de la table des utilisateurs de phpBB et d’une copie MySQL contenant huit tables phpBB. Aucune archive imbriquée n’a été trouvée et le contenu de la source n’a pas été modifié. Les fichiers explicatifs ont été évalués à l’aide de compteurs exempts d’informations permettant d’identifier une personne (PII) et de libellés structurels, plutôt que d’être traités comme des données de comptes à importer en masse. Cette distinction évite de présenter la lisibilité d’un fichier comme une justification suffisante pour importer tous les jetons qu’il contient.

Pour déterminer la correspondance des champs e-mail, seules les indications explicites du schéma font autorité. Le DDL MySQL désigne directement phpbb_users.user_email et phpbb_banlist.ban_email comme des champs e-mail. D’autres colonnes dont le nom contient « email », notamment user_email_hash, user_emailtime, user_allow_viewemail et user_allow_massemail, représentent une empreinte, un horodatage ou des indicateurs de préférence et ne sont pas importées comme des adresses. Quatre-vingt-douze valeurs occupant l’intégralité d’un champ ailleurs dans les noms d’utilisateur, les objets de messages, les publications, les identifiants de messagerie instantanée et les valeurs de configuration ressemblent à des adresses e-mail canoniques, mais ces champs ne désignent pas des adresses e-mail de comptes et sont exclus. Aucun ajustement au décompte du catalogue, aucun réglage visant un décompte cible et aucune collecte sans restriction de jetons bruts n’ont été utilisés pour choisir la correspondance. Seuls les champs e-mail déclarés dans le DDL ont été acceptés.

Deux programmes de lecture compilés indépendants ont analysé l’ensemble des 34 014 lignes SQL réparties sur 505 instructions INSERT sans erreur de structure. Tous deux ont produit la même séquence de 3 281 occurrences d’adresses e-mail valides, les mêmes 71 823 octets et la même empreinte SHA-256. Tous les compteurs étaient à zéro : incohérences dans le nombre de champs par ligne, instructions non terminées, défaillances du scanner et erreurs d’analyse syntaxique. Après suppression des occurrences en double et application d’une validation stricte des adresses e-mail en ASCII, il restait 3 271 adresses canoniques uniques, triées. La colonne explicite user_email du CSV des utilisateurs de phpBB a produit indépendamment 3 280 occurrences et exactement le même ensemble canonique de 3 271 adresses. Les fichiers canoniques issus du CSV et du SQL sont identiques octet par octet. Le CSV n’est pas importé une seconde fois; il est conservé comme preuve d’une représentation équivalente, afin qu’un compte ne soit pas inscrit deux fois simplement parce que la même table figure dans deux formats sources.

Le fichier de métadonnées Info contient deux jetons bruts ressemblant à des adresses e-mail. Un seul appartient à l’ensemble explicite des adresses e-mail de comptes. L’autre apparaît dans les métadonnées ou dans un texte d’exemple et ne peut pas être rattaché à un champ e-mail de compte faisant autorité. Le fichier Info n’est donc pas retenu comme source d’adresses e-mail et est enregistré avec une dette de type NON_AUTHORITATIVE_METADATA_SAMPLE. Le fichier générique Breached_Info ne contient ni champ e-mail ni arobase. La représentation CSV est associée à la classification DUPLICATE_REPRESENTATION_SET_EQUAL. La couverture de la correspondance reste intentionnellement PARTIAL, car ces classifications ne prétendent pas couvrir intégralement chaque élément textuel de l’archive ni l’ensemble de l’événement historique. Les adresses retenues sont néanmoins entièrement étayées par le DDL explicite et par la concordance des ensembles canoniques obtenus indépendamment.

La source comprend des noms d’utilisateur, des adresses IP, des empreintes de mots de passe, des publications de forum et des tables de messages privés; ces catégories sont donc mentionnées pour préciser le périmètre de la fiche. Cette opération LeakData importe uniquement des adresses e-mail. Les mots de passe, les adresses IP, les noms d’utilisateur, le contenu des publications et celui des messages privés ne sont pas inscrits dans les relations Mongo par ce traitement. totalRecords consigne les 3 331 lignes de comptes de la source. canonicalEmailCount et affectedCountLowerBound valent 3 271, mais ce nombre ne correspond pas à un décompte de personnes distinctes. Une personne peut contrôler plusieurs adresses, et une adresse peut être partagée ou inactive. Le nombre exact de personnes concernées reste inconnu; pwnCount a donc la valeur null. Le chiffre de 3 271 correspond uniquement à la borne inférieure du nombre d’adresses canoniques uniques vérifiées dans des champs e-mail explicites.

Vous devez garder à l’esprit trois distinctions. Premièrement, les métadonnées publiques étayent l’identité GhostMarket et son contexte en 2009, mais aucune confirmation de ce jeu de données précis émanant directement de l’entité concernée n’a été trouvée. Deuxièmement, la réussite d’un test d’intégrité de l’archive prouve la stabilité des octets et la lisibilité de la structure, pas la véracité de toutes les affirmations historiques contenues dans les fichiers. Troisièmement, la présence d’une adresse dans l’ensemble canonique ne prouve pas que la personne a utilisé tous les autres champs de l’archive ni qu’un compte est resté actif. La fiche est marquée comme sensible, conserve son statut non vérifié et est traitée selon des règles limitées aux adresses e-mail, qui bloquent le traitement en cas d’échec. Si des éléments de preuve primaires plus solides établissent ultérieurement une date plus précise, un périmètre différent ou une autre identité organisationnelle, les métadonnées devront être révisées dans le cadre d’un examen distinct des preuves.