
Firebase · Supabase · Express.js · Drainer-as-a-Service · février 2026
Avertissement : il s'agit d'une analyse, et non d'une attaque
Tout ce qui est présenté dans cet article est le résultat de analyse passive et données accessibles au public. Aucun système n'a été piraté. Aucune authentification n'a été contournée. Dans chaque cas, ce sont les erreurs de configuration commises par les escrocs eux-mêmes qui ont exposé leur infrastructure, les données de leurs victimes et leurs identités opérationnelles à quiconque daignait y jeter un œil. Toutes les clés API se trouvaient dans des fichiers JavaScript publics. Chaque base de données était grande ouverte, conformément à la conception même des opérateurs. Nous rapportons ces faits non pas pour attaquer, mais pour démontrer que les personnes qui volent vos cryptomonnaies ne parviennent même pas à mettre leurs propres outils en sécurité.
Thèse centrale : les « script kiddies » et leurs outils volés
Il existe un mythe tenace dans l'imaginaire collectif selon lequel les escrocs en ligne seraient des « hackers », c'est-à-dire des génies de l'informatique capables de s'introduire dans des systèmes avec habileté et sophistication. Ce n'est pas vrai.
Les escrocs spécialisés dans les cryptomonnaies d'aujourd'hui sont des « script kiddies » utilisant des kits d'outils achetés. Ils achètent des formules « Drainer-as-a-Service » pour un montant compris entre 200 et 500 dollars, les déploient sur des hébergements gratuits ou bon marché, et prient pour que leurs victimes ne s'en aperçoivent pas. Ils n'écrivent pas de code. Ils ne comprennent rien aux réseaux. Et ils ne comprennent certainement rien à la sécurité.
Nous le savons car, en février 2026, THE ENABLERS REGISTRY a analysé 4 réseaux frauduleux indépendants — et dans chaque cas, nous aurions pu :
- Lire toutes les données des victimes de vol (phrases de récupération, adresses e-mail, adresses IP, types de portefeuilles)
- Modifié ou supprimé la base de données de l'escroc
- Identification de l'opérateur par le biais de clés API exposées, d'adresses e-mail et d'empreintes d'infrastructure
- Reconstitution de l'attaque contre l'escroc — en exploitant les mêmes failles qu’ils avaient laissées ouvertes
Pas besoin d'exploits. Pas de failles « zero-day ». Pas de « piratage ». Juste en ouvrant la porte d'entrée qu'ils avaient laissée ouverte.
Cas n° 1 : L'API fantôme — [REDACTED]
Express.js sur Apache : aucune sécurité réelle
| Paramètre | Valeur |
|---|---|
| Domaine | [REDACTED] |
| Adresse IP | 108.181.185.225 |
| Pile serveur | Apache/2.4.58 (Ubuntu) → Express.js (Node.js) |
| Bannière SSH | SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.11 |
| Émetteur TLS | Let's Encrypt (E7), valable de janvier à avril 2026 |
| Registraire DNS | IANA #146 (ns39/ns40.[REDACTED]) |
| Courriel (MX) | [REDACTED] |
| Locataire Microsoft | [REDACTED] |
| Ports ouverts | 22 (SSH), 80 (HTTP → 301), 443 (HTTPS) |
« L'authentification » — Une blague
L'API est fournie avec un jeton « Bearer » codé en dur : thisisakeyforsecureserver. Mais voici le clou de l'histoire — le jeton n'est en réalité pas vérifié:
Validation sans entrée
Toutes les charges utiles d'injection que nous avons testées ont été acceptées sans avertissement :
Empreinte de performance
Temps de réponse constant d'environ 7,5 secondes pour les requêtes POST, quelle que soit la taille de la charge utile (acceptation de charges utiles comprises entre 10 octets et 10 Mo), ce qui laisse supposer un transfert d'e-mails ou un relais de webhooks en arrière-plan. Les requêtes GET sont traitées en 0,6 s. 10 requêtes parallèles sont traitées en 9,1 s — aucune limitation de débit n'est appliquée.
Risque de désanonymisation
Identifiant du tenant Microsoft 365 NETORGFT19090185 est un lien direct vers le compte de l'organisation qui a enregistré ce domaine. Si l'on ajoute à cela les enregistrements d'enregistrement chez IANA #146 et une adresse IP dédiée (non masquée par un CDN), cet opérateur est facilement identifiable par la voie judiciaire. L'enregistrement SPF (include:[REDACTED]) confirme que, dans le cadre de l'hébergement de messagerie de IANA #146, toutes les métadonnées des e-mails sont accessibles sur présentation d'une assignation à comparaître.
Cas n° 2 : Firebase à ciel ouvert — [REDACTED]
Firestore sans aucune règle de sécurité
| Paramètre | Valeur |
|---|---|
| Domaine de hameçonnage | [REDACTED] (typosquat de « [REDACTED] ») |
| Domaine alternatif | [REDACTED] |
| Projet Firebase | web3ledger-210ab |
| Clé API | AIzaSyCv8e-Gl7nK1RPpfNkJt-WjSZiaoe4AsL8 |
| ID de l'application | 1:1054258933515:web:9fb193fcd0093023f7fc0e |
| Ensemble JS | /static/js/main.7a5ec2fa.js |
| Règles Firestore | Accès libre — lecture/écriture sans authentification |
| Nombre total de victimes | 12 enregistrements dans users collection |
| Collections trouvées | users, transactions |
Données sur les victimes — Entièrement accessibles à tous
Une seule requête GET non authentifiée adressée à l'API REST de Firestore a renvoyé chaque phrase de récupération volée:
Parmi ces 12 enregistrements figurait une entrée révélatrice : quelqu’un avait déjà testé le système avec fbi@fbi.gov comme l'indique l'e-mail. Soit l'escroc a testé son propre système (ce qui est utile pour l'identification), soit quelqu'un d'autre l'avait déjà sondé.
Le déroulement de l'attaque
Le site de hameçonnage imite l'interface du portefeuille [REDACTED]. La victime clique sur « Connecter le portefeuille » → saisit sa phrase de récupération → le frontend React envoie directement les données à Firestore → l'escroc récupère ces informations dans cette même base de données ouverte. Pas de serveur backend du tout. L'ensemble de l'opération fonctionne grâce à l'offre gratuite de Google.
Risque de désanonymisation
Identifiant du projet Firebase web3ledger-210ab et l'ID de l'application 1:1054258933515 sont associé à un compte Google. Google conserve les relevés de facturation, les journaux d'adresses IP et les données relatives à la création des comptes pour tous les projets Firebase. Une simple demande émanant des forces de l'ordre adressée à Google suffit à révéler l'identité de l'opérateur. De plus, le fait que les règles Firestore soient totalement ouvertes signifie que nous aurions pu enregistrer des données dans leur base de données, a averti les victimes en temps réel ou a effacé l'intégralité de la collection.
Cas n° 3 : CRUD complet avec Supabase — [REDACTED]
Sécurité au niveau des lignes désactivée, GraphQL entièrement ouvert
| Paramètre | Valeur |
|---|---|
| Domaine de hameçonnage | [REDACTED] (typosquat de « [REDACTED] ») |
| Projet Supabase | gzqsadraigchwdhblavp |
| Clé Anon | Publié dans /assets/index-b025f4a6.js (748 Ko) |
| Table de base de données | seeds — lire, insérer, mettre à jour, supprimer |
| GraphQL | Introspection complète + mutations activées |
| Fonctions en périphérie | send-wallet-import-email, send-email |
| Service de messagerie électronique | API de renvoi (RESEND_API_KEY dans l'environnement) |
| Dossiers des victimes | ID 130 à 131 (le 129 ayant été supprimé auparavant) |
| Langue de l'interface utilisateur | Russe (« Portefeuille principal », « Votre portefeuille est en cours de chargement... ») |
Accès complet à la base de données — lecture, écriture, suppression
La clé « anon » de Supabase, qui se trouve dans le fichier JavaScript minifié, permet accès CRUD complet à la seeds tableau :
Les identifiants commencent à 130 — ce qui signifie que les enregistrements 1 à 129 ont été précédemment supprimés par l'opérateur. Au moins 131 phrases de départ sont passées par ce système.
Fonctions Edge : l'historique des e-mails
Deux fonctions Supabase Edge sont actives. Nous avons procédé à une ingénierie inverse du send-email le format d'entrée attendu de la fonction en testant différentes charges utiles :
La clé API de renvoi (RESEND_API_KEY) est stockée dans les variables d'environnement de Supabase. Resend conserve les enregistrements de vérification de l'expéditeur et les données de facturation — une autre voie directe permettant d'identifier l'opérateur.
Risque de désanonymisation
La localisation russe de l'interface utilisateur (« Основной кошелек », « Ваш кошелек загружается... ») indique un Opérateur parlant russe. Le projet Supabase (gzqsadraigchwdhblavp) est associé à un compte comportant des relevés de facturation. Le service de renvoi d'e-mails dispose de l'adresse e-mail du destinataire. L'introspection GraphQL révèle le schéma complet de la base de données. Nous avons démontré un accès en écriture complet — nous aurions pu remplacer chaque phrase de récupération volée par un message d'avertissement destiné aux victimes, ou supprimé l'intégralité de la table. L'opérateur n'aurait alors aucun moyen de récupérer les données.
Cas n° 4 : Système de drainage à l'échelle industrielle — [REDACTED]
19 000 phrases de récupération en 5,8 jours
| Paramètre | Valeur |
|---|---|
| Domaine du front-end | [REDACTED] (« PolySniper | Les paris d'initiés de Frontrun ») |
| API C2 | api.yfhikblkhghdyteiuyf54.run |
| Adresses IP C2 | 172.67.168.147, 104.21.26.231 (IANA #1910) |
| Back-end | Express.js (Node.js) v1.0.0 |
| Responsable des inscriptions (interface utilisateur) | IANA #3765 Co. |
| Responsable des inscriptions (C2) | [REDACTED] (IANA #303) |
| Temps de disponibilité | ~139 heures (début : ~10 février 2026 à 21 h 00 UTC) |
| Kit de vidange CDN | [REDACTED] (601 Ko de code JS obfusqué) |
| Bot [REDACTED] | Actif, intégré pour les notifications |
| Limite de débit | 10 requêtes/60 s (seule limite détectée) |
Échelle mise en évidence par des identifiants séquentiels
L'erreur la plus grave : identifiants de tâche séquentiels. Chaque soumission d'une phrase de récupération génère un identifiant incrémental, ce qui permet à quiconque de calculer le volume total :
Architecture multi-chaînes
Le serveur C2 génère des clés sur l'ensemble des chaînes principales en utilisant des chemins de dérivation de profondeur 100 :
Infrastructure de campagne
11 domaines confirmés répartis entre 2 groupes d'opérateurs, identifiés par leurs identifiants de bundle :
| Identifiant du bundle | Domaines | Statut |
|---|---|---|
88ef78f5... | [REDACTED] | EN DIRECT |
4446ea5d... | [REDACTED], [REDACTED] | EN DIRECT |
| Kit [REDACTED] | [REDACTED], [REDACTED], [REDACTED], [REDACTED], soljup.onspace.build | Mixte |
Analyse des charges utiles JavaScript
Trois charges utiles JS obfusquées alimentent le drainer :
- wallet-connect.js (46 Ko) — Gère l'interface utilisateur de connexion au portefeuille, intercepte la saisie de la graine. Obscurcissement par rotation d'un tableau de chaînes de caractères.
- wallet-specific-modals.js (134 Ko) — Contient Liste complète des mots anglais du BIP39 et Liste de mots Monero (1 626 mots). Protection contre le débogage via le remplacement des appels à `console.log` et `trace`. Prise en charge des fenêtres modales multi-portefeuilles.
- [REDACTED]/index.js (601 Ko) — Code obscurci en Unicode avec des noms de variables en chinois. Logique de « drainer » spécifique à Solana. Encodeur Base58, primitives de dérivation de clés cryptographiques. Version 3.0.0.
Risque de désanonymisation
Le CORS: * l'en-tête et l'absence de moyens d'authentification Tout le monde peut soumettre des demandes et suivre l'évolution des numéros d'identification des tâches en temps réel. Grâce à l'intégration du bot [REDACTED], le compte [REDACTED] de l'opérateur reçoit des notifications — et les métadonnées de [REDACTED] peuvent faire l'objet d'une assignation à comparaître. IANA #3765 (bureau d'enregistrement pour le frontend) est un bureau d'enregistrement réputé pour sa sécurité que nous avons qui a déjà fait l'objet d'une enquête, mais [REDACTED] (bureau d'enregistrement de domaines .C2) répond aux demandes des forces de l'ordre. Le [REDACTED] Le kit de drainage dessert plus de 255 domaines — une compromission de [REDACTED] exposerait l'ensemble de l'opération DaaS et tous ses clients.
Comparaison : 4 opérations, même modèle
| Système métrique | mn19indexpre Express.js | web3ledgar Firebase | web3safe-pal Supabase | aipolypredictor Égouttoir C2 |
|---|---|---|---|---|
| Authentification | Aucun (jeton ignoré) | Aucun | Clé « Anon » en JS | Aucun (CORS : *) |
| Données lisibles | Messages/relais | Toutes les phrases de récupération | Toutes les phrases de récupération | Références des offres d'emploi / échelle |
| Données inscriptibles | Oui (illimité) | Oui | Oui (CRUD complet) | Oui (envoyer) |
| Validation des données saisies | Zéro | Zéro | Zéro | Minimal |
| Limitation du débit | Aucun | Aucun | Aucun | 10 requêtes/60 s |
| Désanonymisable | locataire MS365 | Compte Google | Renvoyer + Facturation Supabase | PDR + [REDACTED] |
| Nombre estimé de victimes | Inconnu | 12 | 131+ | 19,000+ |
| Langue de l'opérateur | Inconnu | Anglais | Russe | Inconnu |
Pourquoi les escrocs ne sont pas des hackers
Les preuves sont accablantes. Dans les quatre opérations, on observe le même schéma :
- Acheter des kits de égouttoirs prêts à l'emploi (200 à 500 dollars)
- Déploiement sur des offres gratuites (Firebase, Supabase)
- Ne modifiez pas les configurations par défaut
- Utilisez des jetons codés en dur qu'ils ne vérifient pas
- N'activez jamais le RLS, ne restreignez jamais le CORS
- Révéler leur identité dans les métadonnées
- Utilisez des identifiants séquentiels qui reflètent leur échelle
- Écrire des outils d'exfiltration personnalisés
- Utilisez des canaux cryptés et authentifiés
- Générer des identifiants aléatoires, alterner les infrastructures
- Mettre en place un contrôle d'accès adéquat
- Utilisation de Tor et de chaînes de proxys, paiements anonymes
- Dissocier l'identité opérationnelle de l'hébergement
- Mettre en œuvre des techniques anti-analytiques
Le client type de « Drainer-as-a-Service » est un un spécialiste de l'ingénierie sociale muni d'une carte de crédit, et non des techniciens. Ils savent comment enregistrer un nom de domaine et insérer du code dans un panneau d'hébergement. En revanche, ils ne savent pas :
- Configurer les règles de sécurité de Firestore (cela prendrait 2 minutes)
- Activer la sécurité au niveau des lignes dans Supabase (cela prendrait 5 minutes)
- Valider et nettoyer les données saisies (ce qui prendrait 30 minutes)
- Utilisez des UUID plutôt que des entiers séquentiels (cela ne prendrait qu'une ligne de code)
- Limiter le CORS à leurs propres domaines (cela ne prendrait qu'une ligne de configuration)
Ce ne sont pas des adversaires sophistiqués. Ce sont des personnes qui ne savent pas configurer une base de données.
Indicateurs de compromission (IOC)
Domaines
Adresses IP
Clés API et identifiants de projet
Conclusion : L'empereur est nu
À retenir
Toutes les opérations frauduleuses que nous avons analysées pourraient être entièrement compromis, désanonymisés et mis hors service en n'utilisant rien d'autre qu'un navigateur web, curl et la documentation accessible au public. Dans tous les cas, les pirates ont laissé leurs bases de données grand ouvertes, leurs clés API dans des fichiers JavaScript publics, leurs identités dans les métadonnées, et les données de leurs victimes accessibles à quiconque prenait la peine de les consulter.
La leçon est simple : Les escrocs ne sont pas des pirates informatiques. Ce sont des voleurs à l'étalage qui ont acheté un kit de crochetage sur AliExpress et qui ont oublié de fermer leur porte d'entrée à clé. Les outils qu'ils utilisent sont sophistiqués… parce que quelqu'un d'autre les a conçus. Les auteurs de ces actes sont eux-mêmes des amateurs qui exposent systématiquement leur propre infrastructure, les données de leurs victimes et leur propre identité à toute personne disposant de connaissances techniques élémentaires.
Si vous avez saisi votre phrase de récupération sur l'un de ces sites, partez du principe que votre portefeuille a été piraté et transférez immédiatement vos fonds.
Toutes les constatations ont été signalées aux prestataires de services concernés (Google/Firebase, Supabase, IANA #1910, bureaux d'enregistrement de noms de domaine) et consignées à l'intention des forces de l'ordre. Les IOC ci-dessus ont été ajoutés à la THE ENABLERS REGISTRY : liste des sites à supprimer.