L’idée de génie (ou presque) : blanchir de l’argent avec des t-shirts imaginaires
Avec 6,6 millions d’utilisateurs — soit l’équivalent de la population de l’Île-de-France —, YGGtorrent avait tout du succès à la française : un service ultra-populaire, une communauté fidèle, et un business model… disons, audacieux. Leur spécialité ? Transformer des dons illicites en achats de t-shirts 100% fictifs, avant de faire disparaître l’argent dans les méandres de Tornado Cash. Une opération si bien rodée qu’on se demande pourquoi la French Tech n’a pas encore copié le concept. Après tout, qui n’a jamais rêvé d’acheter un "t-shirt collector YGG" qui n’existe que dans l’imagination de PayPal et dans les logs de transactions ?
Leur système était presque parfait :
- L’utilisateur "fait un don" pour accéder à des contenus premium.
- PayPal voit un achat sur calcilux.shop ("Votre boutique de t-shirts pour geeks depuis 2025").
- L’argent est converti en crypto via des processeurs "high-risk friendly" (merci, PayGate.to).
- Poof ! Les fonds réapparaissent en Monero, plus propres que la réputation de Disney après un scandale.
Problème : Ils ont oublié un détail. Un tout petit détail. Leur sécurité informatique.
Aucune bonne pratique IAM : un cas d’école en gestion des accès
L’analyse des données exfiltrées révèle une vérité cruelle : la chute de YGGtorrent n’est pas due à une faille technique complexe, mais à des erreurs basiques en Identity and Access Management (IAM). Des erreurs si grossières qu’elles en deviennent presque comiques. Presque.
Le serveur de pré-production (188.253.108.198) était censé être un environnement contrôlé, dédié aux tests. Dans les faits, il servait de poste de travail personnel à l’administrateur Destroy, accumulant droits critiques et credentials sensibles comme on entasserait des chaussettes sales dans un tiroir.
Les problèmes ? Une accumulation de mauvaises pratiques :
- Absence totale de ségrégation des rôles : Un seul utilisateur (Destroy) avait un accès administrateur sur plusieurs systèmes critiques, sans le moindre contrôle.
- Stockage non sécurisé des credentials : Mots de passe, clés SSH, cookies de session et configurations d’accès étaient stockés en clair, comme si on avait écrit "Bienvenue, pirates !" sur un panneau lumineux.
- Authentification laxiste : Des services critiques comme SMB, RDP et SphinxQL étaient accessibles sans authentification forte, voire sans aucune restriction.
Le clou du spectacle ? Un fichier sysprep_unattend.xml contenant le mot de passe administrateur en texte brut :
<xmlCopier>
<AutoLogon>
<Username>Administrator</Username>
<Password>
<Value>&)d(5Hj46B7h5^fQF^c(yKYRP</Value>
<PlainText>true</PlainText>
<!-- "Oui, c’est bien en clair. Non, on ne voit pas le problème." -->
</Password>
</AutoLogon>
</xmlCopier>
Traduction : "Voici nos clés, merci de ne pas tout voler. Enfin, si, allez-y, on vous en prie."
On reprend le message du pirate adressé à l'admin principal : "D'ailleurs Oracle, la moitié des hash sont encore en md5, c'est pas sérieux l'ami."
Analyse technique : comment une faille IAM a tout fait s’effondrer
1. Exploitation d’un service non sécurisé : SphinxQL, la porte grande ouverte
Le serveur de pré-production exposait un service SphinxQL (port 9306) sans authentification. Un service conçu pour la recherche full-text, mais détourné en passerelle vers tous les fichiers sensibles du système. Les attaquants ont ainsi pu lire des fichiers arbitraires, dont celui contenant le mot de passe admin.
Conséquence : Un accès Administrator via SMB, obtenu sans forcer quoi que ce soit. Juste en exploitant une configuration d’authentification dignes d’un projet étudiant.
2. Accès aux identifiants et latéralisation : le jackpot
Une fois le serveur compromis, les pirates ont pu :
- Extraire les mots de passe et cookies stockés dans les navigateurs (Chrome, Brave), protégés uniquement par le compte Windows (soit l’équivalent numérique d’un cadenas à 3 chiffres).
- Récupérer les clés SSH et configurations FileZilla, stockées en clair dans des fichiers de configuration.
- Exploiter les sessions actives (PayPal, ProtonMail, services de paiement) grâce à des cookies non protégés.
Impact direct :
- Accès root au serveur tracker principal (62.112.11.32), hébergeant la base de données de 6,6 millions d’utilisateurs.
- Compromission du serveur de paiement (185.132.134.125), contenant les détails de 89 000 transactions et les clés API des processeurs de paiement.
- Verrouillage des comptes externes (registrars, emails, hébergement), rendant toute récupération impossible.
3. Absence de principe de moindre privilège : tout le monde est admin
Tous les services critiques (SMB, RDP, SphinxQL) étaient accessibles avec des droits administrateur, sans la moindre restriction. Aucun mécanisme ne limitait les mouvements latéraux entre les serveurs. Les comptes utilisateurs — y compris ceux de service — avaient des droits étendus bien au-delà de leurs besoins.
Résultat : Une fois le premier serveur compromis, les attaquants ont pu se déplacer librement dans l’infrastructure, comme dans un open space sans cloison.
Les enseignements IAM de l’incident YGGtorrent
1. La ségrégation des droits : le principe de base qu’ils ont oublié
Chaque utilisateur et service doit avoir des droits strictement limités à ses besoins (c’est ça, le principe de moindre privilège). Ici, Destroy avait les clés du royaume… et les a laissées traîner sur la table de la cuisine. Les comptes administrateurs doivent être réservés à des tâches spécifiques, surveillés, et surtout pas utilisés pour surfer sur des sites de t-shirts douteux.
2. L’authentification : quand "123456" ne suffit plus
Tous les services exposés (SMB, RDP, bases de données) auraient dû exiger une authentification forte (MFA, certificats, mots de passe complexes). À la place, YGG a opté pour la méthode "post-it collé sur l’écran" : des credentials stockés en clair et des sessions non protégées. Un comble pour une plateforme qui blanchissait des millions.
3. Audit et conformité : le travail de fond qu’ils ont zappé
Les configurations dangereuses (comme ce mot de passe en clair) auraient dû être détectées et corrigées automatiquement. Mais quand on passe son temps à inventer des boutiques de t-shirts fictives, on oublie les bases : surveillance des logs, audits réguliers, et rotation des accès.
Synthèse : des erreurs IAM aux conséquences désastreuses
La compromission de YGGtorrent illustre les risques d’une mauvaise gestion des droits et de l’authentification :
- Un seul compte compromis (celui de Destroy) a suffi à faire tomber l’ensemble de l’infrastructure.
- L’absence de ségrégation des rôles a permis une latéralisation sans obstacle.
- Le non-respect des bonnes pratiques IAM a transformé une faille mineure en catastrophe.
En résumé : Ils ont révolutionné le blanchiment d’argent… pour se faire pirater comme des amateurs.
Conclusion : l’IAM, fondement invisible mais indispensable
YGGtorrent restera dans l’histoire comme le "Disney+ du piratage français", mais aussi comme un cas d’école en gestion des accès. Leur erreur ? Avoir cru que leur business model malin pouvait compenser une sécurité défaillante.
Morale de l’histoire :
- Un bon IAM > Un business model génial (désolé, les fans de t-shirts pour chats).
- Isoler ses environnements > Tout mettre dans le même panier (surtout quand le panier a des trous).
- Protéger ses credentials > Les écrire sur des post-it virtuels.
Recommandations pour éviter le même sort :
✅ Déployer une solution IAM pour centraliser et sécuriser la gestion des identités.
✅ Appliquer le principe de moindre privilège (parce que non, tout le monde n’a pas besoin d’être admin).
✅ Former les équipes aux bonnes pratiques (avant qu’il ne soit trop tard).
✅ Automatiser les audits pour détecter les failles avant les pirates.
En cybersécurité comme en blanchiment, les détails font la différence. Et dans leur cas, c’est le détail qui a tout fait s’effondrer — comme un colis de t-shirts contrefaits saisi par les douanes.
Source détaillée de l'attaque : https://yggleak.top/fr/home/ygg-dossier