种子泛滥：为何PhishDestroy公然
“攻击”钓鱼网站
我们对此毫不隐瞒。当PhishDestroy检测到一个正在收集加密货币钱包助记词的活跃钓鱼网站时，我们会向该网站大量提交格式正确的助记词条目。以下正是我们采取的具体措施、这样做的原因，以及为何我们对此毫不羞愧。
问题：一个网络钓鱼网站目前正在运行
假设你发现了一个通过谷歌付费广告推广的加密货币钱包钓鱼页面。该页面看起来非常真实，且流量不小。每隔几分钟就会有真实用户访问该页面，输入他们的助记词，最终血本无归。
向谷歌举报。向域名注册商举报。向主机服务商提交滥用报告。 然后你就等着吧。
与此同时，诈骗犯又骗了第47个受害者。接着是第48个。然后是第49个。
标准的滥用行为举报流程通常需要5至10个工作日才能完成。而活跃的网络钓鱼网站却能在数小时内造成无法挽回的经济损失。这种时间差并非系统缺陷——而是诈骗分子蓄意利用的结构性漏洞。
什么是种子浸种？
种子泛洪是一种反网络钓鱼技术，其原理是 格式有效但内容为空/无意义 加密货币钱包的助记词会以受控的速度自动提交到一个钓鱼表单中。
为何有效：一款廉价网络钓鱼工具包的构成解析
绝大多数活跃的加密货币钓鱼网站都是基于 免费级别的第三方服务. 这是他们最大的弱点。如需更详细的分析，请参阅 我们的全面调查.
| 模块 | 免费套餐限额 | 洪涝的影响 |
|---|---|---|
| EmailJS | ~每月约200份投稿 | 几小时内耗尽配额，暂停电子邮件投递 |
| Formspree | 每月50份投稿 | 几乎立即失效 |
| Web3Forms | 每月250份提交 | 迅速被中和 |
| Telegram 机器人 API | 每秒速率受限 | 陷入超时循环 |
| Firebase 免费套餐 | 读/写配额 | 数据库成本飙升或被拒之门外 |
我们曾直接观察到，当种子泛洪耗尽其通知管道后，网络钓鱼基础设施便停止运行。诈骗者并不知道为何系统停止工作，他们只是不再收到数据。
我们的技术方案：Cloudflare Workers，而非僵尸网络
我们使用 Cloudflare Workers. 请求源自 Cloudflare 自身的边缘网络。未滥用任何家庭 IP 地址。没有僵尸网络。未给第三方服务器造成负担。仅诈骗者的数据收集系统受到影响。
洪流
速率限制： 严格的 2 submissions per 10 seconds. 这并非DDoS攻击。而是一种缓慢、蓄意且有针对性的污染行为，其规模之大，使得即使针对每个目标的感染率较低，在同时针对数十个目标的情况下，这些感染率也具有显著意义。
我们并不是要让服务器瘫痪。我们只是要让诈骗分子的工作日变得痛苦不堪，并使他们的数据库变得一文不值——同时完全不会对合法的基础设施造成任何连带影响。
实时案例研究：实践中的受控污染
以下操作记录完全摘自我们的生产日志。仅在公开信息可能助长规避行为的情况下，才对域名和提供商标识符进行了遮蔽；HTTP 数据包捕获内容未作任何修改。两个目标在干预时均处于活跃状态，已确认存在来自付费广告的入站流量，并且均被独立归类为 网络钓鱼 作者： VirusTotal上有≥2家外部供应商 在我们采取任何行动之前。
作战学说
每次种子淹没行动都遵循相同的五项原则框架。没有例外；任何无法满足这五项原则的行动都不会实施。
案例 1 — Formspark Exfil 端点，月配额已用尽
checkblochn.pages.dev 被中和威胁模式： 钱包恢复诱饵（“Dapp Node Sync”）将12个单词的BIP-39助记词窃取至攻击者控制的Formspark免费层端点。已确认在用户开始互动时，流量来自两个广告平台的付费广告。
message行动时间线（UTC，已匿名化至行动T-0时刻）
submit-form.com/32BrdUqfX 从页面 JS 中提取；对有效载荷结构进行了逆向工程分析。 分析2 req / 10 s，单个 Cloudflare Worker，已识别用户代理字符串，已签名源站。200 OK 与 formspark-quota: 64. 基线已捕获。formspark-quota 超过零 → 端点会静默停止转发。 排水百叶窗formspark-quota: −18. 洪水救援人员被解雇。提交内容已发送（该种子是一个具有表现力的诱饵——12个与任何真实钱包均无关的随机BIP-39单词）
响应 — T+01:02（基准值，剩余配额）
响应 — T+06:12（配额已用尽，端点仍返回200状态码，但不会转发请求）
可观察到的影响。 从 T+06:08 起直至 T+19:30 最终下线——a 13小时22分钟的时间窗口 ——每一位联系上我们的真实受害者 checkblochn.pages.dev 并完成了恢复流程，将助记词提交至一个端点，该端点返回了 200 OK 但不再将有效载荷转发到操作员的收件箱中。该钓鱼页面 出现 能在受害者的浏览器中成功运行（无错误提示，无警示标志），这正是我们所期望的：用户若下意识地产生“没成功”的反应，往往会在随后访问的下一个假冒网站上再次输入相同的凭据。在此，交互过程 以“操作员盲”结束.
对于每个后续访问该网站的访客，系统都会提供一个长达13小时的保护期，而该网站当时仍在积极投放付费广告。当Cloudflare Pages对我们的并行滥用报告作出响应时，该保护期便结束了——这完全符合设计预期。这股流量洪峰并未取代合法的下架操作，而是填补了这一时间间隔 直到 合法的击倒成功了。
案例 2 — EmailJS Relay，由运营商发布的标识符
allsyncapp.pages.dev 主动操作威胁模式： 一种利用钱包“同步”作为诱饵的骗局，通过 EmailJS — 一款合法的交易邮件SaaS服务。该钓鱼页面捆绑了运营商的 service_id, template_id 以及 user_id 在客户端 JavaScript 中，因为如果没有这些标识符，受害者的浏览器就无法完成触发邮件发送的 POST 请求。 因此，这些标识符属于该运营商自愿暴露的公共攻击面的一部分。
捕获的提交数据——直接复制自钓鱼页面自身POST请求中的有效载荷内容
标识符提取（在钓鱼页面源代码中使用单行正则表达式）
关键教义要点。 这个案例之所以具有启发性，恰恰是因为 我们未发现任何端点. 该运算符 发布 这是让 EmailJS 将种子发送至其邮箱所需的三个标识符。任何渲染该钓鱼页面的浏览器都拥有这些标识符。我们的 Worker 执行与受害者浏览器相同的操作——提交一个表单，其格式和标识符完全符合页面本身的指示。区别在于有效载荷：使用随机的 BIP-39 单词，而非真实的钱包凭据。
结果模式。 一旦达到月度上限，EmailJS 将返回 402 Payment Required 或 429 Too Many Requests 而该模板无法发送。诈骗者的邮箱便不再有任何动静。与此同时，EmailJS 信任与安全团队会收到一份正式投诉，其中包含服务/模板/用户标识符以及我们已发布的证据包链接——根据以往先例，这将导致该运营商的 EmailJS 账户被 终止，不受速率限制。运营商必须注册一个新的 EmailJS 账户，重新生成标识符，编辑已部署的钓鱼页面，并使所有现有分发链接失效——每次轮换都需要耗费数小时。
攻击特征对比：什么是“种子泛洪”不是
人们经常指责我们对钓鱼网站发动“攻击”。但只要将实际的流量特征与那些被混为一谈的活动特征并列比较，这种说法便不攻自破。
| 维度 | 种子浸种（我们的） | DDoS / L7 洪水攻击 | 滥用垃圾信息提交功能 | LE卧底行动 |
|---|---|---|---|---|
| 目的 | 受害者保护——在下一个受害者出现前，先让诈骗犯完成其“数据外泄”配额 | 基础设施拒绝服务 | 商业利益 / 信息传播 | 证据收集、有控制的欺骗 |
| 吞吐量 | 0.1 – 0.3 次请求/秒 — 下面 服务提供商服务条款 | 103 – 108 req/s — 以饱和度为导向 | 突发 / 自动大批量处理 | 单次交互通常 |
| 目标 | 一名通过单一终端窃取数据的攻击者已发布 | 受害组织的Web服务器/网络层 | 正规网站的联系表单 | 可疑的基础设施或身份 |
| 对基础设施的影响 | 无 — 服务提供商的计数器运行情况符合《服务条款》规定的预算范围 | 服务中断，上游拥塞 | 收件箱信息过载、验证码失效、审核工作量 | 取决于操作 |
| 受影响的合法用户 | 零——网络钓鱼表单没有合法用户 | 所有这些 | 表单所有者的员工/版主 | 设计中的规避机制 |
| 原始身份 | 名为“PhishDestroy Cloudflare Workers”的漏洞——可审计 | 僵尸网络、伪造来源、反射攻击 | 一次性代理 | 机密基础设施 |
| 授权模型 | 端点是 受邀: 表单明确要求提供此输入，标识符在页面中公开显示 | 无——请求量本身就是危害 | 绕过预期用途，无视反滥用信号 | 法定授权 |
| 并行合法行动 | 已提交的滥用报告 之前 flood 开始，附带案例 ID | 不适用 | 不适用 | 融入运营之中 |
“种子洪水”攻击是指一次约140字节的HTTPS POST请求，该请求源自一个携带我们签名源站的Cloudflare Worker，其发送速率仅为服务商自身公布的可接受速率的一小部分，且目标端点的标识符是由运营商选择嵌入到公共网页中的。这就是 整个可观察的遗物. 使请求构成“攻击”的每一个结构性要素——未经授权的访问、耗尽资源的意图、流量饱和、受影响的第三方、隐藏来源——均不存在。下文的法律分析并非主观臆断，而是 自然的 在事实情况已明确陈述后，对法规的解读。
法律分析——这合法吗？这合乎道德吗？
在大多数框架中，向面向公众的网页表单提交数据——即使是虚假数据——本身并不违法。我们既没有访问私有系统，也没有利用未经授权的漏洞，更没有拦截通信。 骗子设下了一个陷阱。我们正往里面塞石头。
PhishDestroy 并不提供法律建议。这确实处于一个法律灰色地带，且因司法管辖区而异。我们在充分意识到这一复杂性的前提下开展运营。
诈骗分子的数据库会怎样？
它变得毫无用处 — 成千上万条记录需要人工核验，信噪比急剧下降。或者 它坏了 — Firebase Spark 和共享的 MongoDB 实例都有硬性限制。一旦触及这些限制，将会产生相应后果。
这两种结果都不错
数据库是否会变成 没用 或 完全中断 — 真实受害者的助记词绝不会以可利用的形式落入攻击者手中。每一个未经处理的助记词，就意味着一个不会被清空的钱包。
我们何时启动种子淹水？
| 标准 | 检查 | 为何这很重要 |
|---|---|---|
| 已确认存在活跃流量 | 必填 | 广告平台或流量工具可确认访问该网站的确实是真实用户 |
| 网络钓鱼的构成分析 | 必填 | 在流量洪峰来临前识别出免费套餐的數據外洩模块 |
| 已提交的滥用报告 | 必填 | 我们始终同时坚持走合法途径 |
| 在SLA范围内未发生下线情况 | 典型的触发条件 | 域名注册商/主机服务商未在合理时间内作出回应 |
| 高流量/付费广告网站 | 即时触发 | 付费广告意味着我们无需等待官僚程序即可采取行动 |
更广阔的视野
加密生态系统遭受损失 每年数十亿美元 针对网络钓鱼。历史上，防御方一直处于被动应对的状态。PhishDestroy 的出现旨在引入 主动干扰 进入这个循环。
我们并非在暗箱操作。我们会公开我们的方法论，详细说明我们的技术，并对分析过的网络钓鱼工具包进行记录。安全社区理应能够评估反网络钓鱼方法，而不仅仅是被动接受一种“黑盒”服务。
您可以采取的措施
- 向……汇报 Google 安全浏览, PhishTank，以及域名注册商
- 请将它提交给我们 — 我们优先处理流量大的活跃威胁
- 检查 我们的解剖学数据库 以便理解你所看到的内容
- 分享意识 ——大多数受害者直到为时已晚，才意识到种子短语钓鱼页面长什么样
如果你认为把空空如也的钱包交给罪犯是不道德的——那是你的立场，你大可坚持这一观点。 我们的立场已经说得很清楚了。
