Jeu de données associé au forum Horse & Hound en 2017

Il n’est pas présenté comme un incident de sécurité vérifié. Aucune communication de Horse & Hound reliant l’archive examinée à un incident précis n’a été trouvée; la valeur isVerified=false est donc requise. Le 1er janvier 2017 n’est que la représentation technique d’une date connue au mois près et ne signifie pas qu’un incident s’est produit ce jour précis. Le nombre de personnes distinctes concernées est inconnu; pwnCount reste donc à null.

Le rattachement à un événement repose sur deux catalogues publics distincts. Sur une même ligne, BreachEra répertorie Horse and Hound, horseandhound.co.uk, l’année 2017, un périmètre de 95 337 enregistrements et les catégories de données suivantes : adresses e-mail, adresses IP, noms d’utilisateur et mots de passe. Leak-Lookup indique 95 338 enregistrements pour le même domaine et répertorie des colonnes de nom d’utilisateur, d’adresse e-mail, d’adresse IP, de mot de passe et de sel dans son schéma statistique. L’écart d’un enregistrement entre ces catalogues s’explique entièrement par un enregistrement de préambule, distinct des données, dans la source scellée. Aucune donnée n’a été sélectionnée ni aucun périmètre élargi dans le seul but de se rapprocher du total d’un catalogue.

L’archive examinée, HorseAndHound_BF.7z, fait 4 529 396 octets et est scellée avec l’empreinte SHA-256 ee05e8…5352. Un test d’intégrité 7z complet a réussi. Son fichier principal se nomme Forums-secure.horseandhound.co.uk_vb_January_2017.txt, fait 8 868 144 octets et possède l’empreinte SHA-256 b69419…7ca2. La source contient 95 338 enregistrements physiques : un préambule et 95 337 enregistrements de données. Une note générique de distribution distincte de 441 octets ne comporte aucun champ d’adresse e-mail au niveau des lignes; elle a été classée comme métadonnée sans adresse e-mail et écartée du traitement, plutôt que d’être utilisée pour élargir la source.

La source principale n’est pas un fichier CSV ordinaire doté d’un en-tête explicite. Ses enregistrements ressemblent à une représentation vBulletin dont les champs sont séparés par des deux-points, avec un nombre de champs variable, car les noms d’utilisateur peuvent eux-mêmes contenir des deux-points. L’examen a utilisé l’unique empreinte hexadécimale de mot de passe de 32 caractères présente dans chaque enregistrement de données comme repère structurel, puis a effectué ses mesures sur le champ au format d’une adresse e-mail situé deux positions avant ce repère. La structure permet d’appliquer cette règle à chacun des 95 337 enregistrements de données. Toutefois, la fonction du champ est déduite plutôt qu’explicitement indiquée par un en-tête; la politique de sécurité impose donc un seuil d’admission plus élevé.

Deux analyseurs indépendants, compilés en Go et reposant sur des implémentations distinctes, ont traité le même ensemble complet de fichiers contenus dans l’archive. Ils ont produit des flux d’occurrences et de valeurs canoniques identiques octet par octet. Tous deux ont comptabilisé 94 917 occurrences acceptées, 94 876 résultats canoniques uniques, 41 occurrences en double, 390 valeurs non vides rejetées et 30 emplacements vides. La couverture du champ sélectionné est d’environ 99.56 pour cent, tandis que le champ alternatif au format d’une adresse e-mail le plus probant ne contient que 90 candidats. Ces mesures étayent fortement l’inférence, mais mapping-admission v3 exige au moins 100 000 occurrences acceptées pour un mappage déduit.

Les 94 917 occurrences observées sont inférieures de 5 083 à ce minimum obligatoire. Le contrôle d’admission a donc refusé le mappage avec le motif INFERENCE_OCCURRENCES_TOO_SMALL. Le seuil n’a pas été abaissé, aucun autre champ n’a été ajouté pour correspondre au total d’un catalogue, et les 94 876 résultats canoniques n’ont pas été publiés comme un nombre de personnes concernées. Cette fiche de métadonnées ne signifie pas qu’une relation d’adresse e-mail a été importée : canonicalEmailCount est à null, importedRecordCount=0, et le traitement reste en attente. Aucun paquet READY, aucune tâche d’importation ni aucune relation d’adresse e-mail Mongo ne peuvent être créés à moins que le mappage ne soit admis ultérieurement.

Une comparaison globale en direct a été effectuée uniquement à des fins d’audit. Parmi les valeurs canoniques déduites, 73 670 existaient déjà dans l’index global des adresses e-mail et 21 206 n’y figuraient pas; les correspondances étaient réparties sur 798 identifiants de violation de données. Cette répartition n’a pas permis d’identifier une fiche existante à laquelle attribuer la source Horse & Hound, et aucune tâche d’importation antérieure n’était rattachée par la même clé de source, le même SHA d’archive, le même SHA canonique ou le même nom de fichier. Un recoupement ne prouve pas, à lui seul, qu’une adresse appartient à ce forum. Il montre uniquement que la même valeur canonique apparaît dans d’autres jeux de données.

Les métadonnées Wayback CDX, vérifiées sans télécharger le contenu des pages archivées, confirment l’existence de captures réussies du sous-domaine du forum sécurisé au cours de l’année 2017. Le domaine officiel actuel de Horse & Hound corrobore également l’identité du service. En revanche, aucune entrée correspondant exactement n’a été trouvée dans source publique sur la fuite de données ou NiamonX, et aucune déclaration d’incident émanant de l’entité concernée n’a été identifiée. Ces vérifications négatives ne prouvent pas l’absence d’incident; elles délimitent ce qui a pu être vérifié. Cette fiche reste donc prudente dans l’attribution, ne prétend pas couvrir l’intégralité de l’événement et devrait être réévaluée si une communication de l’entité concernée ou un schéma explicite de la source devient disponible.