YGGtorrent hacké : 6,6 millions de comptes exposés dans une fuite massive

Le 26 février 2026, une fuite de données massive a frappé YGGtorrent, le plus grand tracker torrent francophone. Le bilan est lourd : 6,6 millions de comptes utilisateurs, des centaines de milliers de transactions financières, le code source complet de la plateforme et 19 Go de données sensibles exfiltrées. L'attaque, documentée en détail par les auteurs du leak, révèle une chaîne de compromission particulièrement méthodique qui exploite des failles d'infrastructure basiques.

Au-delà du cas YGGtorrent, cette affaire illustre des problèmes de sécurité fondamentaux : services exposés sans authentification, mots de passe en clair dans des fichiers de configuration, et absence de segmentation réseau. Des erreurs que l'on retrouve encore trop souvent en production, y compris dans des infrastructures bien plus critiques.

L'ampleur de la fuite : 19 Go de données sensibles

La compromission de YGGtorrent ne se limite pas à une simple fuite de base de données. L'attaquant a eu accès à l'intégralité de l'infrastructure, permettant une exfiltration systématique de toutes les couches du système.

Comptes utilisateurs : 6,6 millions d'enregistrements

La base de données principale contient 6 629 484 comptes avec les informations suivantes pour chaque utilisateur :

• Adresses email associées aux comptes
• Hash de mots de passe en SHA-512 pour les comptes récents, et en MD5 pour les comptes legacy (migration incomplète)
• Adresses IP de connexion
• Logs d'activité détaillés

La présence de hash MD5 non migrés est particulièrement préoccupante. MD5 est considéré comme cassé depuis des années, et les outils comme Hashcat peuvent craquer des millions de hash MD5 par seconde sur un GPU moderne. Même les hash SHA-512, sans salage adéquat, restent vulnérables aux attaques par dictionnaire.

Données financières : 249 703 commandes

Le volet financier de la fuite est tout aussi significatif :

• 249 703 commandes enregistrées dans le système de paiement
• 148 485 transactions complétées
• Un chiffre d'affaires estimé entre 5 et 8,5 millions d'euros pour l'année 2025
• Revenu de décembre 2025 : 341 422 €
• Revenu de janvier 2026 : 490 289 €
• 13+ clés API de processeurs de paiement compromises
• 36+ domaines proxy utilisés pour l'obfuscation des paiements

Données internes et code source

• 25 000+ messages privés du staff sur le forum XenForo
• 1,3 million d'actions de modération
• 89 000+ commandes WooCommerce avec PII clients
• 4 173 645 utilisateurs tracés via des logs de navigation (fichier scooby.csv) enregistrant fuseau horaire, langues du navigateur et timestamps
• Code source complet du tracker, de l'API et de plusieurs projets de réécriture en cours
• 170+ cycles de build détectés pour les projets de réécriture

La chaîne d'attaque : du scan Shodan au contrôle total

L'aspect le plus instructif de cette fuite est la documentation détaillée de la chaîne de compromission. Chaque étape exploite une faille basique mais critique, formant une escalade méthodique du scan initial au contrôle total de l'infrastructure.

Étape 1 : Reconnaissance via Shodan

Le point d'entrée n'est pas une vulnérabilité zero-day sophistiquée. L'attaquant a simplement utilisé Shodan pour rechercher des serveurs associés à YGGtorrent via leur hash de favicon. Cette technique de fingerprinting permet d'identifier des serveurs liés à une organisation même s'ils ne sont pas directement publics.

# Recherche Shodan par hash de favicon
# Le hash du favicon identifie les serveurs
# partageant la même identité visuelle

# Résultat : découverte d'un serveur de staging
# IP : 188.253.108.198 (serveur non-production exposé)

Cette recherche a révélé un serveur de staging à l'adresse 188.253.108.198, exposé sur Internet sans aucune restriction d'accès. Un serveur de pré-production qui n'aurait jamais dû être accessible publiquement.

Étape 2 : Exploitation SphinxQL sans authentification

Sur ce serveur de staging, le moteur de recherche SphinxQL était exposé sur le port 9306 sans aucune authentification. SphinxQL est un moteur de recherche full-text souvent utilisé pour indexer de grandes bases de données. Sa syntaxe est compatible SQL, ce qui le rend facilement exploitable.

La faille critique : la fonction CALL SNIPPETS avec l'option load_files=1 activée. Cette configuration permet de lire n'importe quel fichier du système accessible par le processus Sphinx.

-- Exploitation de SphinxQL pour lire des fichiers système
-- La fonction CALL SNIPPETS avec load_files=1
-- permet la lecture arbitraire de fichiers

-- Principe : CALL SNIPPETS charge un fichier local
-- et le retourne comme résultat de requête
-- Équivalent à une Local File Inclusion (LFI)

C'est une erreur de configuration classique mais dévastatrice. SphinxQL n'aurait jamais dû être exposé sans authentification, et l'option load_files aurait dû être désactivée en production.

Étape 3 : Credentials en clair dans Sysprep

Grâce à la lecture de fichiers via SphinxQL, l'attaquant a énuméré les fichiers de configuration du serveur. Il a découvert un fichier Sysprep unattend.xml contenant le mot de passe administrateur en clair.

Les fichiers Sysprep sont utilisés pour le déploiement automatisé de Windows. Ils contiennent fréquemment des credentials en clair pour la configuration initiale du système. C'est un vecteur d'attaque bien documenté, notamment dans les CTF et les audits d'infrastructure Windows, mais qui reste encore trop souvent exploitable en environnement réel.

<!-- Exemple de structure Sysprep vulnérable -->
<!-- Les credentials en clair dans unattend.xml -->
<!-- sont un vecteur d'attaque classique -->

<!-- Le fichier devrait être supprimé après -->
<!-- le déploiement initial du système -->

<!-- Remédiation : supprimer unattend.xml, -->
<!-- rotater tous les mots de passe, -->
<!-- utiliser un vault pour les secrets -->

Étape 4 : Lateral movement via SMB

Avec les credentials administrateur récupérés, l'attaquant a accédé au partage SMB C$ du serveur. Le partage administratif C$ donne accès à l'intégralité du système de fichiers Windows, une porte ouverte vers toute la configuration du serveur.

Sur ce partage, l'attaquant a découvert des credentials FileZilla stockés en clair dans les fichiers de configuration du client FTP. Ces credentials pointaient vers les serveurs de production, complétant ainsi le lateral movement du staging vers la production.

Étape 5 : Persistance et exfiltration

Une fois sur les serveurs de production, l'attaquant a déployé plusieurs mécanismes de persistance :

• Webshells sur les serveurs web
• Comptes administratifs de backup créés dans les applications
• Clés SSH ajoutées pour un accès persistant

L'exfiltration a porté sur 4 serveurs compromis et totalise environ 19 Go de données : dumps de bases de données, code source, informations de wallets crypto et fichiers de configuration.

Analyse des failles : des erreurs évitables

Ce qui frappe dans cette attaque, c'est que chaque étape exploite une erreur de configuration basique. Aucun zero-day, aucun exploit sophistiqué. La chaîne complète repose sur :

1. Exposition de services internes

Un serveur de staging accessible depuis Internet, avec un moteur SphinxQL ouvert sur le port 9306 sans authentification. La règle est simple : tout service interne doit être derrière un VPN ou un firewall, sans exception.

# Vérifier les ports exposés sur un serveur
# Depuis l'extérieur :
nmap -sV -p- votre-serveur.com

# Ports à ne JAMAIS exposer publiquement :
# 9306 - SphinxQL
# 3306 - MySQL
# 5432 - PostgreSQL
# 6379 - Redis
# 27017 - MongoDB
# 445 - SMB
# 9200 - Elasticsearch

# Firewall : bloquer tout sauf HTTP/HTTPS/SSH
# iptables ou nftables selon la distribution

2. Secrets en clair dans les fichiers de configuration

Mot de passe admin dans Sysprep, credentials FTP dans FileZilla. Ces données sensibles auraient dû être dans un gestionnaire de secrets (Vault, AWS Secrets Manager) ou au minimum chiffrées et supprimées après utilisation.

3. Absence de segmentation réseau

Le passage du staging à la production via SMB et des credentials FTP révèle une absence totale de segmentation. Les environnements de staging et de production partageaient les mêmes credentials et les mêmes réseaux, permettant un lateral movement trivial.

4. Hash de mots de passe obsolètes

La présence de hash MD5 non migrés montre un manque de maintenance de la dette technique sécuritaire. Une migration progressive vers bcrypt ou Argon2id aurait dû être implémentée depuis longtemps, par exemple au moment du login de chaque utilisateur.

// Migration progressive de hash au login
// Pattern recommandé pour upgrader les hash legacy

function verifyAndUpgradePassword(
    string $password,
    string $storedHash,
    int $userId
): bool {
    // Détecter le type de hash
    $isMd5 = (strlen($storedHash) === 32);
    $isSha512 = (strlen($storedHash) === 128);

    if ($isMd5) {
        // Vérifier ancien hash MD5
        if (md5($password) !== $storedHash) {
            return false;
        }
        // Migrer vers Argon2id
        upgradeHash($userId, $password);
        return true;
    }

    // Hash moderne : vérification standard
    return password_verify($password, $storedHash);
}

function upgradeHash(int $userId, string $password): void
{
    $newHash = password_hash(
        $password,
        PASSWORD_ARGON2ID,
        [
            'memory_cost' => 65536,
            'time_cost' => 4,
            'threads' => 3,
        ]
    );
    // UPDATE users SET password_hash = ? WHERE id = ?
}

Leçons pour les administrateurs système

Cette compromission est un cas d'école qui rappelle des principes fondamentaux trop souvent négligés :

• Inventaire des assets : chaque serveur exposé doit être recensé et audité régulièrement. Les serveurs de staging oubliés sont une cible privilégiée
• Zero Trust Network : ne jamais faire confiance au réseau interne. Chaque service doit authentifier ses clients, même en intranet. Une architecture Zero Trust aurait bloqué le lateral movement
• Gestion des secrets : aucun mot de passe en clair dans les fichiers de configuration. Utiliser un vault, rotater les credentials régulièrement, et supprimer les fichiers de déploiement après utilisation
• Segmentation réseau : staging et production doivent être isolés. Pas de credentials partagés, pas de routes directes entre les environnements
• Migration des hash : MD5 et SHA-512 sans sel ne sont plus acceptables. Migrer vers bcrypt ou Argon2id avec une stratégie progressive
• Monitoring des accès : des alertes sur les connexions SMB inhabituelles, les requêtes SphinxQL anormales ou les accès SSH depuis de nouvelles clés auraient pu détecter l'intrusion rapidement

Impact et conséquences

Pour les 6,6 millions d'utilisateurs concernés, les risques sont multiples :

• Credential stuffing : les combinaisons email/mot de passe seront testées sur d'autres services (Gmail, Facebook, Amazon, etc.)
• Phishing ciblé : les adresses email associées à un tracker torrent peuvent être utilisées pour du chantage ou du phishing contextualisé
• Exposition légale : les adresses IP associées à l'activité de téléchargement sont dans la nature
• Fraude financière : les 89 000 clients WooCommerce dont les PII ont fuité sont exposés au vol d'identité

Pour les opérateurs de la plateforme, la fuite du code source et des clés API de processeurs de paiement signifie que l'intégralité de l'infrastructure doit être considérée comme compromise et reconstruite from scratch.

Checklist de vérification pour vos serveurs

En réaction à ce type d'incident, voici une checklist immédiate à exécuter sur vos propres infrastructures :

# 1. Scanner les ports exposés
nmap -sV votre-serveur.com

# 2. Vérifier qu'aucun service DB n'est exposé
ss -tlnp | grep -E '3306|5432|6379|9306|27017|9200'

# 3. Chercher les fichiers Sysprep/unattend
find / -name "unattend.xml" -o -name "sysprep.xml" 2>/dev/null

# 4. Chercher les credentials en clair
grep -rn "password\|passwd\|secret\|api_key" /etc/ 2>/dev/null

# 5. Vérifier les partages SMB
smbclient -L localhost -N 2>/dev/null

# 6. Auditer les clés SSH autorisées
find /home -name "authorized_keys" -exec wc -l {} \;

# 7. Lister les webshells potentiels
find /var/www -name "*.php" -newer /var/www -mtime -7 2>/dev/null

La sécurité d'une infrastructure ne vaut que par son maillon le plus faible. Dans le cas de YGGtorrent, un serveur de staging oublié avec un service non authentifié a suffi pour compromettre l'intégralité d'une plateforme de plusieurs millions d'utilisateurs. Un rappel brutal que les bases de la sécurité système — le firewalling, la gestion des secrets et la segmentation réseau — restent les fondations incontournables de toute infrastructure sérieuse.