Un vendeur pirate baptisé en chinois 漏基, « Fuite de données », propose un fichier titré Google. 3 téraoctets de contacts et d’achats, vendus 0,1 bitcoin.
Le Service de Veille ZATAZ a repéré un pirate, nommé en chinois 漏基, « Fuite de données », qui vend un fichier baptisé Google. L’annonce intrigue par son volume, 3 To, et par son prix, 0,1 BTC. Ce n’est pas une base SQL classique, mais une suite d’enregistrements de type JSON, proches de fiches client issues d’un export CRM. Les champs évoquent des identifiants, noms, emails, téléphones, langue préférée et un montant total d’achats. Vous avez dit bizarre ? Comme c’est bizarre !
Un « Google » de 3 To, trop gros pour être anodin
Le fichier mis en vente porte un nom accrocheur, Google, comme un leurre sémantique destiné à attirer l’acheteur, sans prouver un lien avec l’entreprise. Ce qui frappe d’abord, c’est la masse annoncée : 3 To. Pour donner un ordre d’idée, en prenant 1 To comme 1 000 Go, cela fait environ 3 000 Go, soit près de 3 000 000 Mo. À ce niveau, on ne parle plus d’un simple fichier commercial, mais d’un corpus qui peut contenir des millions d’objets, selon leur taille unitaire.
Des équivalents concrets aident à situer l’ampleur. À raison d’environ 5 Go par film en HD, 3 To représentent autour de 600 films. En photo JPEG de 5 Mo, on atteint environ 600 000 images. En documents bureautiques d’environ 1 Mo, on monte à près de 3 millions de fichiers. Même en logs, à 200 Mo par jour, l’ordre de grandeur frôle 15 ans d’archives. Ces conversions ne disent rien de la qualité des données, mais elles cadrent le signal : exfiltrer 3 To suppose, dans beaucoup de scénarios, une extraction soutenue, une source volumineuse, et une organisation capable de stocker puis de diffuser.
Dans un cadre professionnel, 3 To peuvent être « courant » pour un SOC qui collecte des flux, proxy, EDR et journaux, mais c’est énorme dès qu’il s’agit de données personnelles. À l’échelle d’une organisation, un tel volume évoque plutôt une base clients massive, des sauvegardes serveur, des archives internes, ou un entrepôt de données mal cloisonné. C’est précisément cette ambiguïté qui nourrit la tension : le volume est assez grand pour être sérieux, assez vague pour permettre la surenchère.
Ce que révèlent les champs, et pourquoi c’est exploitable
Le service de veille ZATAZ peut décrire un format qui ressemble davantage à une exportation de CRM qu’à une base relationnelle : des enregistrements de type dictionnaires ou JSON, avec des champs parfois absents, parfois remplis de valeurs « None ». L’élément le plus parlant est l’Id : un identifiant unique de 18 caractères qui commence par « 001… », un format typique d’ID CRM, souvent associé à des objets de type compte. Le champ Name apparaît en majuscules, parfois composite, avec des anomalies qui trahissent l’absence de normalisation, comme des noms fusionnés de plusieurs personnes, des valeurs poubelles du type « N/A N/A », ou des répétitions.
News & Réseaux Sociaux ZATAZ
Chaque vendredi midi, recevez gratuitement les actualités de la semaine.
Le vendeur met aussi en avant TotalSales__, un total d’achats numérique. Dans les extraits, un outlier extrême atteint 391 275,42, ce qui pose la question d’une devise, d’une erreur de séparation décimale, d’une agrégation multi-comptes ou d’un compte entreprise. À l’inverse, certains enregistrements affichent TotalSales__ à None, ce qui force tout analyste à trancher entre « zéro » et « inconnu », une différence majeure en scoring et en ciblage.
Le tableau se complète avec AgeRange__ et BirthdateDDMM. La tranche d’âge est souvent manquante, et la date de naissance est partielle, au format JJ/MM sans année, utile pour du marketing d’anniversaire, mais insuffisante pour calculer un âge réel. La présence de dates très fréquentes comme « 01/01 » ressemble à une valeur par défaut quand l’information manque. PreferredLanguage__ apparaît parfois, avec des langues comme ENGLISH, ITALIAN, FRENCH, JAPANESE, mais l’association avec certains numéros peut sembler incohérente, un signal possible de saisie approximative ou de valeur par défaut.
Deux champs concentrent un problème technique majeur : PersonEmails et MobilePhone__ contiennent des listes, mais stockées en texte, sous forme de chaînes qui ressemblent à « [‘[email protected]’, None] ». Cette sérialisation complique la déduplication, la validation et les requêtes, et elle favorise les erreurs de parsing. Les numéros de téléphone montrent des formats hétérogènes, parfois aberrants, trop courts, avec des espaces, ou dupliqués dans la même fiche. Les emails, eux, couvrent des fournisseurs grand public et des domaines d’entreprise, avec des indices de partage d’adresse entre plusieurs personnes, ce qui peut être un simple foyer… ou une donnée mal rattachée.
Sur la période, Le Service de veille ZATAZ note que CreatedDate couvre, dans l’extrait observé, de 2017-10-11 à 2024-04-22 en UTC. Ce marqueur est important : il suggère une continuité de collecte, et donc une valeur d’usage pour un attaquant, qui peut cibler des contacts « récents » et adapter ses scripts de fraude.
Le prix annoncé, 0,1 BTC, ajoute une couche de crédibilité apparente. D’après les équivalences mentionnées, cela représente environ 7 000 $ à 7 500 $ (environ 5 600 € à 5 900 euros) et environ 12 000 $ à 12 300 $ CAD. Même en restant prudent sur les taux, l’ordre de grandeur place l’offre dans une zone où l’acheteur attend un retour opérationnel, pas une simple collection de doublons.
Le point clé n’est pas le nom Google, mais la combinaison PII + contexte. Identifiant unique, nom, email, téléphone, langue, date partielle et historique d’achats suffisent à industrialiser l’hameçonnage ciblé, la prise de rendez-vous frauduleuse, ou la fraude au faux support, avec des messages rédigés dans la bonne langue et calibrés sur un profil d’achat.
Maintenant, savoir d’où proviennent ces données est une autre histoire, que le pirate n’a pas encore expliquée.
