Seed Flooding: Why PhishDestroy Openly
“Attacks” Phishing Sites
We don’t hide it. When PhishDestroy detects an active phishing site harvesting crypto wallet seed phrases, we flood it with valid-format seed phrase entries. Here’s exactly what we do, why we do it, and why we’re not ashamed of it.
The Problem: A Phishing Site Is Live Right Now
Imagine you spot a crypto wallet phishing page running paid Google Ads. It looks legitimate. It’s got traffic. Real users are landing on it every few minutes, entering their seed phrases, and losing everything.
You report it to Google. You report it to the registrar. You submit an abuse report to the hosting provider. And then you wait.
Meanwhile, the scammer collects victim number 47. Then 48. Then 49.
The standard abuse reporting pipeline operates on timescales of 5–10 business days. Active phishing sites cause irreversible financial damage in hours. This gap is not a bug in the system — it’s a structural vulnerability scammers exploit deliberately.
What Is Seed Flooding?
Seed flooding is a counter-phishing technique where valid-format but empty/worthless cryptocurrency wallet seed phrases are automatically submitted into a phishing form at a controlled rate.
Why This Works: The Anatomy of a Cheap Phishing Kit
The vast majority of active crypto phishing sites are copy-paste kits built on free-tier third-party services. This is their biggest vulnerability. For a deeper breakdown see our full investigation.
| Module | Free Tier Limit | Effect of Flooding |
|---|---|---|
| EmailJS | ~200 submissions/month | Exhausted in hours, stops email delivery |
| Formspree | 50 submissions/month | Disabled almost immediately |
| Web3Forms | 250 submissions/month | Rapidly neutralized |
| Telegram Bot API | Rate-limited per second | Flooded into timeout loops |
| Firebase Free Tier | Read/write quotas | Database costs spike or lock out |
We have directly observed phishing infrastructure go dark after seed flooding exhausted its notification pipeline. The scammer doesn’t know why it stopped working. They just stop receiving data.
Our Technical Approach: Cloudflare Workers, Not Botnets
We use Cloudflare Workers. Requests originate from Cloudflare’s own edge network. No residential IPs misused. No botnets. No third-party servers burdened. Only the scammer’s data collection system is affected.
The Flooding Flow
Rate limiting: A strict 2 submissions per 10 seconds. Not a DDoS. A slow, deliberate, targeted contamination at a scale that makes even modest per-site rates meaningful across dozens of simultaneous targets.
We are not trying to take down servers. We are making the scammer’s workday miserable and their database worthless — with zero collateral impact on legitimate infrastructure.
Live Case Studies: Controlled Contamination in Practice
The operations below are drawn verbatim from our production logs. Domains and provider identifiers are redacted only where publication would aid evasion; HTTP wire captures are unmodified. Both targets were active at time of intervention, had confirmed inbound traffic from paid advertising, and had been independently classified as phishing by ≥ 2 external vendors on VirusTotal prior to any action on our part.
Operational Doctrine
Every seed-flooding operation executes within the same five-principle envelope. There are no exceptions; an engagement that cannot satisfy all five is not run.
Case 1 — Formspark Exfil Endpoint, Monthly Quota Exhausted
checkblochn.pages.dev NeutralizedThreat pattern: wallet-recovery lure (“Dapp Node Sync”) exfiltrating 12-word BIP-39 seed phrases to an attacker-controlled Formspark endpoint on free tier. Confirmed paid-ad traffic from two ad platforms at engagement start.
messageOperational Timeline (UTC, anonymised to engagement T-zero)
submit-form.com/32BrdUqfX extracted from page JS; payload shape reverse-engineered. analysis2 req / 10 s, single Cloudflare Worker, identified UA string, signed origin.200 OK with formspark-quota: 64. Baseline captured.formspark-quota crosses zero → endpoint silently stops forwarding. drainer blindformspark-quota: −18. Flood worker terminated.Submission on the wire (the seed is an expressive decoy — 12 random BIP-39 words unrelated to any real wallet)
Response — T+01:02 (baseline, quota remaining)
Response — T+06:12 (quota exhausted, endpoint continues to 200 but will not forward)
Observable impact. From T+06:08 until final takedown at T+19:30 — a 13 hour and 22 minute window — every real victim who reached checkblochn.pages.dev and completed the recovery flow submitted their seed phrase to an endpoint that returned 200 OK but no longer forwarded the payload to the operator’s inbox. The phishing page appeared to succeed in the victim’s browser (no error, no red flag), which is desirable: a reflexive “it didn’t work” reaction often causes users to re-enter the same credentials on the next fake site they find. Here, the interaction terminated with the operator blind.
A 13-hour protective window for every subsequent visitor to a site that paid-advertising was still actively pushing. The window closed when Cloudflare Pages responded to our parallel-track abuse report — exactly as designed. The flood did not replace the lawful takedown; it covered the interval until the lawful takedown landed.
Case 2 — EmailJS Relay, Operator-Published Identifiers
allsyncapp.pages.dev Active OperationThreat pattern: wallet “sync” lure that emails the victim’s entered seed to the operator’s mailbox via EmailJS — a legitimate transactional-email SaaS. The phishing page bundles the operator’s service_id, template_id and user_id in client-side JavaScript, because without those identifiers the victim’s browser cannot complete the POST that triggers the email. Those identifiers are therefore part of the public attack surface the operator has voluntarily exposed.
Captured submission — payload shape verbatim from the phishing page’s own POST
Identifier extraction (single-line regex on the phishing page source)
Key doctrinal point. This case is instructive precisely because no endpoint was discovered by us. The operator publishes the three identifiers required to make EmailJS send the seed to their mailbox. Any browser rendering the phishing page possesses them. Our Worker does what the victim’s browser does — submits a form with the exact shape and identifiers the page itself instructs. The difference is the payload: random BIP-39 words instead of real wallet credentials.
Outcome pattern. Once the monthly cap is reached, EmailJS returns 402 Payment Required or 429 Too Many Requests and the template does not send. The scammer’s mailbox goes quiet. In parallel, EmailJS Trust & Safety receives a formal complaint with the service/template/user identifiers and a link to our published evidence package — which, in historical precedent, results in the operator’s EmailJS account being terminated, not rate-limited. The operator must acquire a new EmailJS account, regenerate identifiers, edit the deployed phishing page, and invalidate every existing distribution link — a multi-hour workflow for each rotation.
Attack-Profile Comparison: What Seed Flooding Is Not
A repeated accusation is that we run “attacks” on phishing sites. That framing collapses the moment you place the actual traffic profile next to the profile of the activities it is being confused with.
| Dimension | Seed Flooding (ours) | DDoS / L7 flood | Spam submission abuse | LE sting operation |
|---|---|---|---|---|
| Purpose | Victim protection — fill scammer’s exfil quota before next victim | Infrastructure denial of service | Commercial gain / message propagation | Evidence gathering, controlled deception |
| Throughput | 0.1 – 0.3 req/s — below provider ToS | 103 – 108 req/s — saturation-oriented | Burst / automated high-volume | Single interaction typically |
| Target | Single exfil endpoint attacker has published | Web server / network tier of a victim org | Contact forms of legitimate sites | Suspect infrastructure or persona |
| Infrastructure impact | None — provider counters tick within ToS-budgeted behaviour | Service outage, upstream congestion | Inbox bloat, CAPTCHA drift, moderation load | Depends on operation |
| Legitimate users affected | Zero — phishing forms have no legitimate users | All of them | Form-owner employees / moderators | Avoidance designed-in |
| Originating identity | Named PhishDestroy Cloudflare Workers — auditable | Botnets, spoofed sources, reflection | Disposable proxies | Classified infrastructure |
| Authorisation model | Endpoint is invited: form explicitly requests this input, identifiers are publicly distributed in the page | None — request volume itself is the harm | Bypasses intended use, ignores anti-abuse signals | Statutory authority |
| Parallel lawful action | Abuse reports filed before flood starts, with case IDs | N/A | N/A | Embedded in the operation |
A seed-flood submission is a single HTTPS POST of ~140 bytes, originating from one Cloudflare Worker carrying our signed origin, at a fraction of the rate the provider itself publishes as acceptable, targeting an endpoint whose identifiers the operator chose to embed in a public web page. That is the entire observable artefact. Every structural element that makes a request an “attack” — unauthorised access, resource exhaustion intent, volumetric saturation, affected third parties, concealed origin — is absent. The legal analysis that follows is not creative advocacy; it is the natural reading of statute once the factual profile is stated plainly.
Legal Analysis — Is It Legal? Is It Ethical?
Submitting data to a public-facing web form — even fake data — is not inherently illegal in most frameworks. We are not accessing private systems, exploiting unauthorized vulnerabilities, or intercepting communications. The scammer built a trap. We are filling it with rocks.
PhishDestroy is not providing legal advice. This exists in a genuine gray area that varies by jurisdiction. We operate with full awareness of this complexity.
What Happens to the Scammer’s Database?
It becomes useless — thousands of entries require manual verification, signal-to-noise ratio collapses. Or it breaks — Firebase Spark and shared MongoDB instances have hard limits. Hitting them has consequences.
Both Outcomes Are Good
Whether the database becomes useless or breaks entirely — real victims’ seed phrases never reach the attacker in a useful form. Every unprocessed seed phrase is a wallet that doesn’t get drained.
When Do We Activate Seed Flooding?
| Criterion | Check | Why It Matters |
|---|---|---|
| Active traffic confirmed | Required | Ad platforms or traffic tools confirm real users are landing on the site |
| Phishing anatomy analyzed | Required | Free-tier exfil modules identified before we flood |
| Abuse reports filed | Required | We always pursue the legitimate track simultaneously |
| No takedown within SLA | Typical trigger | No response from registrar/hosting in acceptable time |
| High-volume / paid ads site | Immediate trigger | Paid advertising means we act without waiting for the bureaucratic track |
The Bigger Picture
The crypto ecosystem loses billions of dollars per year to phishing. The defense side has historically been reactive. PhishDestroy exists to introduce proactive interference into this cycle.
We are not operating in darkness. We publish our methodology. We explain our techniques. We document the phishing kits we analyze. The security community deserves to evaluate counter-phishing methods, not just consume a black-box service.
What You Can Do
- Report to Google Safe Browsing, PhishTank, and the domain registrar
- Submit it to us — we prioritize high-traffic active threats
- Check our anatomy database to understand what you’re looking at
- Share awareness — most victims don’t know what a seed phrase phishing page looks like until it’s too late
If you think feeding empty wallets to criminals is unethical — that’s your position, and you’re welcome to hold it. We’ve made ours clear.
Related Investigations
