Allégation d’exposition de données de Grastin.ru en 2022

La description de l’archive rattache l’organisation à Grastin et à grastin.ru, indique que la source couvre une période allant d’août 2021 à novembre 2022 et mentionne des noms, des numéros de téléphone, des adresses postales et des adresses e-mail parmi les catégories de données. Les métadonnées CDX d’Internet Archive confirment également que grastin.ru disposait d’un site web actif pendant cette période. Les métadonnées publiques ne suffisent pas, à elles seules, à prouver l’authenticité de cette archive privée, à montrer que l’exploitant de Grastin l’a confirmée ou à établir le jour exact où les données ont été exposées. Cette fiche n’est donc pas présentée comme une annonce de violation de données vérifiée auprès de l’organisation concernée. isVerified reste à false, et l’affirmation issue de la source locale est distinguée des informations publiques limitées concernant l’entité.

La date n’est connue qu’au mois près. Les métadonnées internes indiquent novembre 2022 comme date de la violation de données. La valeur enregistrée, 1er novembre 2022, est une représentation technique de ce mois; elle n’affirme pas qu’un incident s’est produit le premier jour. Ces mêmes métadonnées indiquent que les enregistrements couvrent une période allant d’août 2021 à novembre 2022. Cet intervalle peut correspondre à des commandes, à l’activité de clients ou à des livraisons et ne permet pas, à lui seul, de déterminer le jour où un jeu de données a été collecté ou distribué. Les recherches publiques menées dans un périmètre limité n’ont trouvé aucune annonce officielle, aucun avis d’une autorité de régulation ni aucun rapport d’incident fiable confirmant ce jeu de données précis. breachDatePrecision vaut donc month, aucune source faisant autorité ne précise le jour exact, et toute modification ultérieure de la date devrait nécessiter un nouvel examen fondé sur des preuves primaires plus solides.

La source est une archive 7z complète de 35 580 567 octets. Son empreinte SHA-256 est scellée et le test d’intégrité complet de l’archive 7z a réussi. Les trois fichiers ordinaires qu’elle contient ont tous été extraits, leur taille a été mesurée et leur empreinte a été calculée indépendamment. Il s’agit d’un fichier générique de métadonnées Breached_Info, d’un fichier de métadonnées Info contenant des descriptions de Grastin et des affirmations de la source, ainsi que d’un fichier de données CSV de 266 121 201 octets. L’archive ne contient aucune archive imbriquée et son contenu source n’a pas été modifié. Le CSV compte 1 581 126 lignes physiques. La présence de sept sauts de ligne dans des champs CSV entre guillemets porte le nombre d’enregistrements logiques de données, hors en-tête, à 1 581 118. L’analyse stricte du CSV n’a détecté aucune erreur de syntaxe, aucun nombre de colonnes incorrect ni aucun enregistrement incomplet. Des octets stables et une structure lisible prouvent l’intégrité de la source, mais ne font pas de chaque déclaration historique contenue dans l’archive un fait publiquement vérifié.

Le mappage des adresses e-mail repose uniquement sur l’en-tête explicite rédigé par la source. Les six colonnes sont buyer, phone, address, email, region et month, dans cet ordre. Seule la quatrième colonne, email, est sélectionnée. Le champ buyer contient 332 cellules entières qui satisfont aux règles syntaxiques strictes d’une adresse e-mail, mais sa signification déclarée est celle d’un acheteur ou d’un nom, et non d’une adresse e-mail; ces valeurs sont donc délibérément exclues. Les textes contenant des arobas dans le champ address, ainsi que les valeurs des champs phone, region et month, sont également exclus de l’import des adresses e-mail. Les exemples ou les passages rédigés dans le fichier de métadonnées Info ne sont pas traités comme des champs d’adresse e-mail de compte. Aucun champ supplémentaire n’a été sélectionné pour se rapprocher du nombre de 653 907 annoncé dans le catalogue, aucune valeur invalide n’a été corrigée et aucun compteur n’a été ajusté pour atteindre un objectif.

Deux lecteurs compilés indépendants, écrits en Go, ont validé sans erreur les 1 581 118 enregistrements logiques de données et le schéma à six colonnes. Tous deux ont compté 704 204 occurrences d’adresses e-mail valides dans la colonne email explicite, 1 233 cellules non vides rejetées et 875 681 cellules vides. Après déduplication des occurrences et normalisation canonique stricte des adresses e-mail en ASCII, il reste 654 125 adresses uniques triées. Les deux outils ont produit le même flux d’occurrences de 14 499 807 octets, avec la même empreinte SHA-256. Ils ont également obtenu des résultats identiques pour la sortie canonique : 13 386 578 octets, 654 125 lignes et une même empreinte SHA-256. Le second validateur vérifie le schéma, les agrégats et l’ensemble canonique existant sans matérialiser une seconde sortie canonique. Cette méthode indépendante réduit le risque qu’une erreur dans une seule implémentation d’analyseur ou dans un tampon d’enregistrements conduise à autoriser l’import.

Les métadonnées internes annoncent 653 907 enregistrements d’adresses e-mail, tandis que l’extraction stricte depuis le champ explicite fournit 654 125 adresses canoniques uniques, soit un écart de 218. Cet écart est conservé plutôt que masqué. Le nombre annoncé dans les métadonnées n’est pas réinterprété comme un nombre de personnes distinctes, d’adresses valides ou de l’ensemble des lignes. totalRecords représente les 1 581 118 enregistrements logiques de données du CSV, sourcePhysicalRecordCount consigne le nombre déclaré de 1 581 126 lignes physiques, et canonicalEmailCount indique uniquement les 654 125 adresses vérifiées dans la colonne email explicite. affectedCountLowerBound utilise la même borne inférieure technique du nombre d’adresses, mais ne constitue pas un décompte de personnes distinctes. Une personne peut contrôler plusieurs adresses, et une adresse peut être partagée, abandonnée ou réattribuée. Le nombre de personnes concernées étant inconnu, pwnCount reste à null.

Cette opération LeakData n’inscrit que des adresses e-mail dans les relations Mongo. Les noms, les numéros de téléphone, les adresses postales, les régions et les valeurs de mois ne sont pas importés par ce traitement. Le traitement du fichier Info est différé sous le statut NON_AUTHORITATIVE_METADATA_SAMPLE, tandis que celui du fichier générique Breached_Info est clos sous le statut RESOLVED_NO_EMAIL, car il ne contient aucun champ d’adresse e-mail. La couverture du mappage reste PARTIAL; ce libellé n’affirme pas que chaque élément de texte de l’archive ou l’ensemble de l’événement historique a été vérifié. La fiche est marquée comme sensible et conserve son statut d’allégation non vérifiée émanant d’un tiers. La présence d’une adresse dans l’ensemble canonique ne prouve pas qu’une personne a utilisé les autres champs, que l’enregistrement est toujours à jour ou que Grastin a confirmé cette archive précise. Si des preuves officielles plus solides viennent ultérieurement modifier l’identité, le périmètre, la date ou les décomptes, les métadonnées devraient être révisées dans le cadre d’un examen distinct et traçable des preuves.