Inondation de seeds : pourquoi PhishDestroy agit au grand jour
Sites de « hameçonnage »
Nous ne le cachons pas. Lorsque PhishDestroy détecte un site de hameçonnage actif visant à récupérer les phrases de récupération de portefeuilles cryptos, nous l'inondons de phrases de récupération au format valide. Voici exactement ce que nous faisons, pourquoi nous le faisons et pourquoi nous n'en avons pas honte.
Le problème : un site de hameçonnage est actuellement en ligne
Imaginez que vous tombiez sur une page de hameçonnage visant un portefeuille de cryptomonnaies, qui diffuse des annonces Google Ads payantes. Elle a l'air authentique. Elle génère du trafic. De vrais utilisateurs y accèdent toutes les quelques minutes, saisissent leurs phrases de récupération et perdent tout.
Vous le signalez à Google. Vous le signalez au registraire. Vous envoyez un signalement d'abus à l'hébergeur. Et puis on attend.
Pendant ce temps, l'escroc fait une nouvelle victime : la 47e. Puis la 48e. Puis la 49e.
Le processus standard de signalement des abus s'étend sur une période de 5 à 10 jours ouvrés. Les sites de hameçonnage actifs causent des préjudices financiers irréversibles en quelques heures. Cet écart n'est pas un bug du système : il s'agit d'une vulnérabilité structurelle que les escrocs exploitent délibérément.
Qu'est-ce que l'inondation des graines ?
Le « seed flooding » est une technique de lutte contre le hameçonnage qui consiste à format valide mais vide/sans valeur Les phrases de récupération des portefeuilles de cryptomonnaies sont automatiquement saisies dans un formulaire de hameçonnage à un rythme contrôlé.
Pourquoi ça marche : l'anatomie d'un kit de phishing bon marché
La grande majorité des sites de hameçonnage liés aux cryptomonnaies actuellement actifs sont des kits de « copier-coller » basés sur services tiers en version gratuite. C'est là leur principale faiblesse. Pour une analyse plus approfondie, voir notre enquête approfondie.
| Module | Limite du forfait gratuit | Conséquences des inondations |
|---|---|---|
| EmailJS | environ 200 soumissions par mois | Épuisé en quelques heures, interrompt l'envoi des e-mails |
| Formspree | 50 soumissions par mois | Mise hors service presque immédiatement |
| Web3Forms | 250 soumissions par mois | Rapidement neutralisé |
| API du bot Telegram | Limité à un certain nombre par seconde | Submergé par des boucles de délai d'attente |
| Offre gratuite Firebase | Quotas de lecture/écriture | Flambée des coûts des bases de données ou exclusion du marché |
Nous avons directement constaté que des infrastructures de hameçonnage cessaient de fonctionner une fois que le flux de données de départ avait saturé leur canal de notification. L'escroc ignore pourquoi le système a cessé de fonctionner. Il cesse simplement de recevoir des données.
Notre approche technique : Cloudflare Workers, et non les botnets
Nous utilisons Cloudflare Workers. Les requêtes proviennent du réseau périphérique de Cloudflare. Aucune adresse IP résidentielle n'est détournée. Aucun botnet n'est impliqué. Aucun serveur tiers n'est surchargé. Seul le système de collecte de données de l'escroc est affecté.
Le débit de crue
Limitation du débit : Une stricte 2 submissions per 10 seconds. Il ne s'agit pas d'une attaque DDoS. Il s'agit d'une contamination lente, délibérée et ciblée, d'une ampleur telle que même des taux modestes par site prennent toute leur importance lorsqu'ils concernent des dizaines de cibles simultanées.
Notre objectif n'est pas de mettre les serveurs hors service. Nous rendons la journée de travail des escrocs insupportable et rendons leur base de données inutilisable, sans aucun impact collatéral sur les infrastructures légitimes.
Études de cas concrets : la contamination contrôlée dans la pratique
Les opérations ci-dessous sont tirées mot pour mot de nos journaux de production. Les noms de domaine et les identifiants des fournisseurs d’accès ne sont masqués que lorsque leur publication risquerait de faciliter la fraude ; les captures de trafic HTTP sont présentées telles quelles. Les deux cibles étaient actives au moment de l’intervention, présentaient un trafic entrant confirmé provenant de publicités payantes et avaient été classées de manière indépendante comme hameçonnage par ≥ 2 fournisseurs externes sur VirusTotal avant que nous ne prenions la moindre mesure.
Doctrine opérationnelle
Chaque opération de « seed-flooding » s’inscrit dans le cadre de ces cinq principes. Il n’y a aucune exception : une opération qui ne répond pas à ces cinq critères n’est pas menée.
Cas n° 1 — Formspark Exfil Endpoint, quota mensuel épuisé
checkblochn.pages.dev NeutraliséProfil de la menace : Le leurre de récupération de portefeuille (« Dapp Node Sync ») exfiltre les phrases de récupération BIP-39 de 12 mots vers un point de terminaison Formspark contrôlé par l'attaquant, dans le cadre de l'offre gratuite. Trafic publicitaire payant confirmé provenant de deux plateformes publicitaires dès le début de l'engagement.
messageChronologie opérationnelle (UTC, anonymisée par rapport au moment T-zéro de l'engagement)
submit-form.com/32BrdUqfX Extrait de la page JS ; forme de la charge utile reconstituée par rétro-ingénierie. analyse2 req / 10 s, un seul Worker Cloudflare, chaîne UA identifiée, origine signée.200 OK avec formspark-quota: 64. Valeur de référence enregistrée.formspark-quota passe par zéro → le point d'extrémité cesse de transmettre les données sans avertissement. grille d'égouttageformspark-quota: −18. Un employé chargé de la gestion des inondations a été licencié.Soumission en ligne (la graine est un leurre symbolique — 12 mots aléatoires selon la norme BIP-39, sans aucun rapport avec un portefeuille réel)
Réponse — T+01:02 (valeur de référence, quota restant)
Réponse — T+06:12 (quota épuisé ; le point de terminaison continue jusqu'à 200 mais ne transmettra pas)
Un impact visible. De T+06:08 jusqu'au retrait définitif à T+19:30 — a une fenêtre de 13 heures et 22 minutes — chaque véritable victime qui a réussi à checkblochn.pages.dev et, une fois la procédure de récupération terminée, ont transmis leur phrase de récupération à un point de terminaison qui a renvoyé 200 OK mais ne transférait plus la charge utile vers la boîte de réception de l'opérateur. La page de hameçonnage est apparu de fonctionner dans le navigateur de la victime (sans erreur ni signal d'alerte), ce qui est souhaitable : une réaction instinctive du type « ça n'a pas marché » pousse souvent les utilisateurs à saisir à nouveau les mêmes identifiants sur le prochain site frauduleux qu'ils trouvent. Ici, l'interaction a pris fin alors que l'opérateur était à l'aveugle.
Une fenêtre de protection de 13 heures pour chaque visiteur suivant d’un site sur lequel la publicité payante était encore activement diffusée. Cette fenêtre s’est refermée lorsque Cloudflare Pages a donné suite à notre signalement d’abus en parallèle — exactement comme prévu. Le flux massif n’a pas remplacé le retrait légal ; il a simplement couvert cet intervalle. jusqu'à ce que La saisie légale a été effectuée.
Cas n° 2 — EmailJS Relay, identifiants publiés par l'opérateur
allsyncapp.pages.dev Opération en coursProfil de la menace : un leurre de « synchronisation » de portefeuille qui envoie par e-mail la phrase de récupération saisie par la victime à la boîte mail de l'opérateur via EmailJS — un service SaaS légitime dédié aux e-mails transactionnels. La page de hameçonnage intègre les informations de l’opérateur service_id, template_id et user_id en JavaScript côté client, car sans ces identifiants, le navigateur de la victime ne peut pas effectuer la requête POST qui déclenche l'envoi de l'e-mail. Ces identifiants font donc partie de la surface d'attaque publique que l'opérateur a volontairement exposée.
Soumission capturée — contenu de la requête POST tel qu'il apparaît sur la page de hameçonnage elle-même
Extraction d'identifiants (expression régulière sur une seule ligne dans le code source de la page de hameçonnage)
Point doctrinal essentiel. Ce cas est instructif précisément parce que nous n'avons découvert aucun point d'arrivée. L'opérateur publie les trois identifiants nécessaires pour que EmailJS envoie la graine vers leur boîte mail. Tout navigateur affichant la page de phishing les possède. Notre Worker fait exactement ce que fait le navigateur de la victime : il envoie un formulaire dont la structure et les identifiants correspondent exactement à ceux indiqués par la page elle-même. La différence réside dans la charge utile : des mots BIP-39 aléatoires au lieu des véritables identifiants du portefeuille.
Évolution de la maladie. Une fois le plafond mensuel atteint, EmailJS renvoie 402 Payment Required ou 429 Too Many Requests et le modèle n'est pas envoyé. La boîte mail de l'escroc reste silencieuse. Parallèlement, l'équipe Trust & Safety d'EmailJS reçoit une plainte officielle contenant les identifiants du service, du modèle et de l'utilisateur, ainsi qu'un lien vers notre dossier de preuves publié — ce qui, selon les précédents, entraîne la suspension du compte EmailJS de l'opérateur. résilié, sans limitation de débit. L'opérateur doit créer un nouveau compte EmailJS, régénérer les identifiants, modifier la page de hameçonnage déployée et invalider tous les liens de diffusion existants — un processus qui prend plusieurs heures à chaque rotation.
Comparaison des profils d'attaque : ce que n'est pas le « seed flooding »
On nous reproche régulièrement de mener des « attaques » contre des sites de hameçonnage. Cette interprétation s'effondre dès lors que l'on compare le profil réel du trafic à celui des activités avec lesquelles il est confondu.
| Dimension | Inondation des semences (la nôtre) | DDoS / Inondation de trafic de couche 7 | Abus lié à l'envoi de spam | Opération d'infiltration de la police |
|---|---|---|---|---|
| Objectif | Protection des victimes — atteindre le quota d'exfiltration de l'escroc avant la prochaine victime | Attaque par déni de service visant l'infrastructure | Bénéfice commercial / diffusion du message | Collecte de preuves, tromperie contrôlée |
| Débit | 0,1 – 0,3 requêtes/s — ci-dessous Conditions générales d'utilisation du fournisseur | 103 – 108 req/s — axé sur la saturation | En rafale / automatisé à haut débit | Une interaction unique, en général |
| Cible | Un pirate informatique ayant utilisé une technique d'exfiltration à partir d'un seul terminal a publié | Couche serveur web / réseau d'une organisation victime | Formulaires de contact de sites fiables | Infrastructure ou profil suspect |
| Impact sur les infrastructures | Aucun — les compteurs des fournisseurs fonctionnent conformément au comportement prévu dans les conditions d'utilisation | Interruption du service, congestion en amont | Surcharge de la boîte de réception, dérive des CAPTCHA, charge de modération | Cela dépend de l'opération |
| Utilisateurs légitimes concernés | Zéro — les formulaires de hameçonnage n'ont aucun utilisateur légitime | Tous | Employés responsables des formulaires / modérateurs | Prévention intégrée dès la conception |
| Identité d'origine | Intitulé « PhishDestroy Cloudflare Workers » — vérifiable | Botnets, sources usurpées, réflexion | Proxies jetables | Infrastructures classifiées |
| Modèle d'autorisation | Le point final est invité: le formulaire demande explicitement cette information ; les identifiants sont diffusés publiquement sur la page | Aucun — c'est le volume des demandes lui-même qui constitue le préjudice | Contourne l'utilisation prévue, ignore les signaux anti-abus | Base légale |
| Action judiciaire parallèle | Signalements d'abus enregistrés avant début d'une inondation, avec les numéros d'identification des cas | N/A | N/A | Intégré au fonctionnement |
Une requête de type « seed-flood » consiste en une seule requête POST HTTPS d’environ 140 octets, émanant d’un Worker Cloudflare portant notre origine signée, à un débit bien inférieur à celui que le fournisseur lui-même considère comme acceptable, et ciblant un point de terminaison dont l’opérateur a choisi d’intégrer les identifiants dans une page web publique. C’est-à-dire que le l'ensemble de l'artefact observable. Tous les éléments structurels qui font d’une requête une « attaque » — accès non autorisé, intention d’épuiser les ressources, saturation volumétrique, tiers affectés, origine dissimulée — sont absents. L’analyse juridique qui suit n’est pas un argumentaire fantaisiste ; il s’agit de la naturel interprétation de la loi une fois que les faits sont clairement exposés.
Analyse juridique — Est-ce légal ? Est-ce éthique ?
La saisie de données dans un formulaire web accessible au public — même s'il s'agit de fausses données — n'est pas illégale en soi dans la plupart des contextes. Nous n'accédons pas à des systèmes privés, n'exploitons pas de failles de sécurité sans autorisation et n'interceptons pas de communications. L'escroc a tendu un piège. Nous le remplissons de pierres.
PhishDestroy ne fournit aucun conseil juridique. Cette question relève d'une véritable zone grise qui varie selon les juridictions. Nous exerçons nos activités en pleine connaissance de cette complexité.
Qu'advient-il de la base de données de l'escroc ?
Cela ne sert plus à rien — des milliers d’entrées nécessitent une vérification manuelle, le rapport signal/bruit s’effondre. Ou bien ça casse — Firebase Spark et les instances MongoDB partagées sont soumises à des limites strictes. Le fait de les atteindre entraîne des conséquences.
Les deux résultats sont satisfaisants
Que la base de données devienne inutile ou se brise complètement — Les phrases de récupération des véritables victimes ne parviennent jamais à l’attaquant sous une forme exploitable. Chaque phrase de récupération non traitée correspond à un portefeuille qui ne peut pas être vidé.
Quand faut-il activer l'inondation des semis ?
| Critère | Vérifier | Pourquoi est-ce important ? |
|---|---|---|
| Trafic actif confirmé | Obligatoire | Les plateformes publicitaires ou les outils de mesure d'audience permettent de vérifier que de vrais utilisateurs accèdent au site |
| Analyse de l'anatomie du phishing | Obligatoire | Modules d'exfiltration de la version gratuite identifiés avant que nous ne lancions une attaque par inondation |
| Signalements d'abus enregistrés | Obligatoire | Nous suivons toujours la voie légale en parallèle |
| Aucune interruption de service dans le cadre du SLA | Déclencheur typique | Aucune réponse de la part du registraire/hébergeur dans un délai raisonnable |
| Site proposant des annonces publicitaires à fort volume / payantes | Déclencheur immédiat | La publicité payante nous permet d'agir sans attendre que les procédures administratives suivent leur cours |
Une vision plus large
L'écosystème des cryptomonnaies perd des milliards de dollars par an au phishing. La défense a toujours adopté une approche réactive. PhishDestroy a pour objectif d'introduire ingérence proactive dans ce cycle.
Nous n'agissons pas dans l'opacité. Nous publions notre méthodologie. Nous expliquons nos techniques. Nous documentons les kits de phishing que nous analysons. La communauté de la sécurité mérite de pouvoir évaluer les méthodes de lutte contre le phishing, et non pas simplement d'utiliser un service de type « boîte noire ».
Ce que vous pouvez faire
- À l'attention de Navigation sécurisée de Google, PhishTank, ainsi que le registraire de nom de domaine
- Envoyez-le-nous — nous donnons la priorité aux menaces actives générant un trafic important
- Vérifier notre base de données anatomique pour comprendre ce que vous voyez
- Sensibiliser — la plupart des victimes ne savent pas à quoi ressemble une page de hameçonnage visant à leur soutirer leur phrase de récupération avant qu'il ne soit trop tard
Si vous estimez qu'il est immoral de remplir les poches des criminels — c'est votre point de vue, et vous avez tout à fait le droit de le défendre. Nous avons clairement exprimé notre position.
Enquêtes connexes
