Inondazione di seed: perché PhishDestroy agisce apertamente
Siti di “attacchi” di phishing
Non lo nascondiamo. Quando PhishDestroy rileva un sito di phishing attivo che raccoglie le frasi seed dei portafogli di criptovalute, lo inondiamo di inserimenti di frasi seed in formato valido. Ecco esattamente cosa facciamo, perché lo facciamo e perché non ce ne vergogniamo.
Il problema: un sito di phishing è attivo proprio in questo momento
Immagina di individuare una pagina di phishing dedicata a un portafoglio di criptovalute che utilizza annunci a pagamento su Google Ads. Sembra autentica. Ha un buon traffico. Ogni pochi minuti, utenti reali vi accedono, inseriscono le loro frasi seed e perdono tutto.
Lo segnali a Google. Lo segnali al registrar. Invii una segnalazione di abuso al provider di hosting. E poi si aspetta.
Nel frattempo, il truffatore mette a segno la vittima numero 47. Poi la 48. E poi la 49.
Il processo standard di segnalazione degli abusi richiede dai 5 ai 10 giorni lavorativi. I siti di phishing attivi causano danni finanziari irreversibili nel giro di poche ore. Questo divario non è un errore del sistema, ma una vulnerabilità strutturale che i truffatori sfruttano deliberatamente.
Che cos’è l’inondazione dei semi?
Il "seed flooding" è una tecnica anti-phishing in cui formato valido ma vuoto/privo di significato Le frasi seed dei portafogli di criptovalute vengono inserite automaticamente in un modulo di phishing a una frequenza controllata.
Perché funziona: l’anatomia di un kit di phishing a basso costo
La stragrande maggioranza dei siti attivi di phishing nel settore delle criptovalute è costituita da kit “copia-incolla” basati su servizi di terze parti con piano gratuito. Questa è la loro principale vulnerabilità. Per un’analisi più approfondita, si veda la nostra indagine completa.
| Modulo | Limite del piano gratuito | Effetti delle inondazioni |
|---|---|---|
| EmailJS | circa 200 contributi al mese | Esaurito in poche ore, interrompe l'invio delle e-mail |
| Formspree | 50 invii al mese | Si è guastato quasi immediatamente |
| Web3Forms | 250 contributi al mese | Neutralizzato rapidamente |
| API del bot di Telegram | Limite di velocità al secondo | Intrappolati in cicli di timeout |
| Piano gratuito di Firebase | Quote di lettura/scrittura | Aumento vertiginoso dei costi delle banche dati o esclusione dall'accesso |
Abbiamo osservato direttamente come le infrastrutture di phishing smettessero di funzionare dopo che il seed flooding aveva saturato la loro pipeline di notifiche. Il truffatore non sa perché il sistema abbia smesso di funzionare. Semplicemente, smette di ricevere dati.
Il nostro approccio tecnico: Cloudflare Workers, non botnet
Utilizziamo Cloudflare Workers. Le richieste provengono dalla rete periferica di Cloudflare. Nessun IP residenziale viene utilizzato in modo improprio. Nessuna botnet. Nessun server di terze parti viene sovraccaricato. L'unico sistema interessato è quello di raccolta dati del truffatore.
Il flusso di inondazione
Limitazione della velocità: Un rigoroso 2 submissions per 10 seconds. Non si tratta di un attacco DDoS. Si tratta di una contaminazione lenta, deliberata e mirata, su una scala tale da rendere significativi anche i tassi per singolo sito, per quanto modesti, su decine di obiettivi simultanei.
Non stiamo cercando di mettere fuori uso i server. Stiamo rendendo la giornata lavorativa dei truffatori un vero incubo e rendendo il loro database inutile — senza alcun impatto collaterale sulle infrastrutture legittime.
Casi di studio reali: la contaminazione controllata nella pratica
Le operazioni riportate di seguito sono tratte alla lettera dai nostri registri di produzione. I domini e gli identificativi dei provider sono stati oscurati solo nei casi in cui la loro pubblicazione avrebbe favorito l’evasione; le registrazioni del traffico HTTP non sono state modificate. Entrambi gli obiettivi erano attivi al momento dell’intervento, presentavano traffico in entrata proveniente da pubblicità a pagamento e erano stati classificati in modo indipendente come phishing di ≥ 2 fornitori esterni su VirusTotal prima che noi intraprendiamo qualsiasi azione.
Dottrina operativa
Ogni operazione di inondazione dei semi si svolge nel rispetto degli stessi cinque principi fondamentali. Non ci sono eccezioni: un’operazione che non soddisfi tutti e cinque i principi non viene eseguita.
Caso 1 — Formspark Exfil Endpoint, quota mensile esaurita
checkblochn.pages.dev NeutralizzatoModello di minaccia: Esca per il recupero del portafoglio (“Dapp Node Sync”) che sottrae le frasi seed BIP-39 composte da 12 parole e le invia a un endpoint Formspark controllato dall’autore dell’attacco, nell’ambito del piano gratuito. È stato confermato che, all’inizio dell’interazione, il traffico proveniva da annunci a pagamento su due piattaforme pubblicitarie.
messageCronologia operativa (UTC, anonimizzata rispetto al momento T-zero dell'intervento)
submit-form.com/32BrdUqfX estratto dalla pagina JS; forma del payload ricostruita tramite reverse engineering. analisi2 req / 10 s, singolo Cloudflare Worker, stringa UA identificata, origine firmata.200 OK con formspark-quota: 64. Dati di riferimento acquisiti.formspark-quota supera lo zero → l'endpoint interrompe silenziosamente l'inoltro. tenda sgocciolatoioformspark-quota: −18. Licenziamento di un addetto alla gestione delle inondazioni.Invio in tempo reale (il seed è un diversivo espressivo — 12 parole BIP-39 casuali non correlate ad alcun portafoglio reale)
Risposta — T+01:02 (valore di riferimento, quota residua)
Risposta — T+06:12 (quota esaurita; l'endpoint continua a restituire il codice 200 ma non inoltrerà la richiesta)
Impatto tangibile. Da T+06:08 fino alla rimozione definitiva a T+19:30 — a Finestra di 13 ore e 22 minuti — ogni vera vittima che è riuscita a checkblochn.pages.dev e, una volta completata la procedura di recupero, hanno inviato la loro frase di seed a un endpoint che ha restituito 200 OK ma non inoltrava più il contenuto alla casella di posta dell'operatore. La pagina di phishing è apparso per funzionare nel browser della vittima (senza errori né segnali di allarme), il che è auspicabile: una reazione istintiva del tipo “non ha funzionato” spesso induce gli utenti a reinserire le stesse credenziali nel primo sito fasullo che incontrano. In questo caso, l’interazione conclusa con l'operatore all'oscuro.
Una finestra di protezione di 13 ore per ogni visitatore successivo di un sito che la pubblicità a pagamento continuava a promuovere attivamente. La finestra si è chiusa quando Cloudflare Pages ha risposto alla nostra segnalazione di abuso inviata in parallelo — esattamente come previsto. L’ondata non ha sostituito la rimozione legittima; ha semplicemente coperto l’intervallo fino a quando L'intervento legittimo ha avuto successo.
Caso 2 — EmailJS Relay, identificatori pubblicati dall'operatore
allsyncapp.pages.dev Operazione attivaModello di minaccia: esca denominata “sync” per il portafoglio, che invia tramite e-mail il seed inserito dalla vittima alla casella di posta dell’operatore tramite EmailJS — un servizio SaaS legittimo per le e-mail transazionali. La pagina di phishing include il service_id, template_id e user_id nel JavaScript lato client, poiché senza tali identificatori il browser della vittima non può completare la richiesta POST che attiva l'invio dell'e-mail. Tali identificatori fanno quindi parte della superficie di attacco pubblica che l'operatore ha volontariamente esposto.
Dati inviati intercettati — forma del payload riportata fedelmente dal POST della pagina di phishing stessa
Estrazione degli identificatori (espressione regolare su una singola riga nel codice sorgente della pagina di phishing)
Punto dottrinale fondamentale. Questo caso è istruttivo proprio perché non abbiamo individuato alcun endpoint. L'operatore pubblica i tre identificatori necessari affinché EmailJS invii il seed alla loro casella di posta. Qualsiasi browser che visualizzi la pagina di phishing ne è in possesso. Il nostro Worker fa ciò che fa il browser della vittima: invia un modulo con la struttura e gli identificatori esatti indicati dalla pagina stessa. La differenza sta nel payload: parole BIP-39 casuali al posto delle credenziali reali del wallet.
Andamento dei risultati. Una volta raggiunto il limite mensile, EmailJS restituisce 402 Payment Required oppure 429 Too Many Requests e il modello non viene inviato. La casella di posta del truffatore rimane silenziosa. Parallelamente, il team Trust & Safety di EmailJS riceve un reclamo formale contenente gli identificativi del servizio, del modello e dell’utente, oltre a un link al nostro pacchetto di prove pubblicato — il che, in base ai precedenti, comporta la chiusura dell’account EmailJS dell’operatore cessato, senza limiti di frequenza. L'operatore deve creare un nuovo account EmailJS, rigenerare gli identificatori, modificare la pagina di phishing già pubblicata e invalidare tutti i link di distribuzione esistenti — un flusso di lavoro che richiede diverse ore per ogni rotazione.
Confronto tra profili di attacco: cosa non è il "seed flooding"
Un’accusa che ci viene ripetutamente mossa è quella di sferrare “attacchi” contro siti di phishing. Questa interpretazione crolla nel momento stesso in cui si mette a confronto il profilo effettivo del traffico con quello delle attività con cui viene confuso.
| Dimensione | Inondazione dei semi (la nostra) | DDoS / Flood L7 | Abuso di invio di spam | Operazione sotto copertura della LE |
|---|---|---|---|---|
| Scopo | Protezione delle vittime — raggiungere la quota di esfiltrazione del truffatore prima che trovi la prossima vittima | Attacchi denial-of-service alle infrastrutture | Guadagno commerciale / diffusione del messaggio | Raccolta di prove, inganno controllato |
| Larghezza di banda | 0,1 – 0,3 richieste al secondo — di seguito Termini di servizio del fornitore | 103 – 108 req/s — orientato alla saturazione | A raffica / automatizzato ad alto volume | Un'interazione singola, in genere |
| Obiettivo | Un singolo autore di attacchi di esfiltrazione da endpoint ha pubblicato | Livello del server web / della rete di un'organizzazione vittima | Moduli di contatto di siti affidabili | Infrastruttura o profilo sospetti |
| Impatto sulle infrastrutture | Nessuno — i contatori del provider funzionano secondo quanto previsto dai Termini di servizio | Interruzione del servizio, congestione a monte | Posta in arrivo sovraccarica, variazioni nei CAPTCHA, carico di moderazione | Dipende dall'operazione |
| Utenti legittimi coinvolti | Zero — i moduli di phishing non hanno utenti legittimi | Tutti quanti | Dipendenti titolari dei moduli / moderatori | Prevenzione integrata nella progettazione |
| Identità originaria | Denominati "PhishDestroy Cloudflare Workers" — verificabili | Botnet, fonti contraffatte, riflessione | Proxy monouso | Infrastrutture classificate |
| Modello di autorizzazione | L'endpoint è invitato: il modulo richiede espressamente questo dato; gli identificatori sono resi pubblici nella pagina | Nessuno — è proprio il volume delle richieste a costituire il danno | Elude l'uso previsto, ignora i segnali anti-abuso | Base giuridica |
| Azione legale parallela | Denunce di abuso presentate prima inizio dell'inondazione, con gli ID dei casi | N/A | N/A | Parte integrante dell'operazione |
Una richiesta "seed-flood" consiste in un singolo POST HTTPS di circa 140 byte, proveniente da un Cloudflare Worker che riporta il nostro origin firmato, a una frazione della frequenza che lo stesso provider definisce accettabile, e diretto a un endpoint i cui identificatori l'operatore ha scelto di incorporare in una pagina web pubblica. Questo è il intero manufatto osservabile. Manca ogni elemento strutturale che renda una richiesta un “attacco”: accesso non autorizzato, intento di esaurimento delle risorse, saturazione volumetrica, terze parti coinvolte, origine occultata. L’analisi giuridica che segue non è una difesa creativa; è la naturale lettura della legge una volta che il quadro fattuale sia stato esposto chiaramente.
Analisi giuridica — È legale? È etico?
L'invio di dati a un modulo web accessibile al pubblico — anche se si tratta di dati falsi — non è di per sé illegale nella maggior parte dei contesti. Non stiamo accedendo a sistemi privati, né sfruttando vulnerabilità non autorizzate, né intercettando comunicazioni. Il truffatore ha teso una trappola. Noi la stiamo riempiendo di sassi.
PhishDestroy non fornisce consulenza legale. Si tratta di una vera e propria zona grigia che varia a seconda della giurisdizione. Operiamo con piena consapevolezza di tale complessità.
Che fine fa il database del truffatore?
Diventa inutile — migliaia di voci richiedono una verifica manuale, il rapporto segnale-rumore crolla. Oppure si rompe — Firebase Spark e le istanze MongoDB condivise hanno dei limiti massimi. Il loro superamento comporta delle conseguenze.
Entrambi i risultati sono positivi
A prescindere dal fatto che il database diventi inutile oppure si rompe completamente — Le frasi di seed delle vere vittime non arrivano mai all’autore dell’attacco in una forma utilizzabile. Ogni frase di seed non elaborata corrisponde a un portafoglio che non viene svuotato.
Quando si attiva l'inondazione dei semi?
| Criterio | Controlla | Perché è importante |
|---|---|---|
| Traffico attivo confermato | Obbligatorio | Le piattaforme pubblicitarie o gli strumenti di analisi del traffico confermano che sul sito accedono utenti reali |
| Analisi dell'anatomia del phishing | Obbligatorio | Moduli di esfiltrazione del piano gratuito identificati prima che si verifichi un sovraccarico |
| Denunce di abuso presentate | Obbligatorio | Perseguiamo sempre, contemporaneamente, la via legittima |
| Nessun takedown nell'ambito dello SLA | Fattore scatenante tipico | Nessuna risposta da parte del registrar/hosting entro un termine ragionevole |
| Sito con un elevato volume di annunci / annunci a pagamento | Fattore scatenante immediato | La pubblicità a pagamento ci permette di agire senza dover attendere l'iter burocratico |
Il quadro generale
L'ecosistema delle criptovalute subisce una perdita miliardi di dollari all'anno al phishing. La difesa ha storicamente adottato un approccio reattivo. PhishDestroy è stato creato per introdurre interferenza proattiva in questo ciclo.
Non operiamo nell’ombra. Rendiamo pubblica la nostra metodologia. Spieghiamo le nostre tecniche. Documentiamo i kit di phishing che analizziamo. La comunità della sicurezza merita di poter valutare i metodi anti-phishing, non solo di avvalersi di un servizio “black-box”.
Cosa puoi fare
- Inviare a Navigazione sicura di Google, PhishTank, e il registrar del dominio
- Inviacelo — diamo priorità alle minacce attive che generano un traffico elevato
- Controlla il nostro database di anatomia per capire cosa stai guardando
- Diffondere la consapevolezza — la maggior parte delle vittime non sa come si presenta una pagina di phishing che ruba la seed phrase finché non è troppo tardi
Se ritieni che riempire le tasche dei criminali con i soldi dei più bisognosi sia immorale, questa è la tua posizione, e sei libero di sostenerla. Abbiamo espresso chiaramente la nostra posizione.
Indagini correlate
