Suga被灌了3天垃圾账号，发现一场藏在"欢迎邮件"里的洗钱暗战

3月12日，Suga团队的后台数据出现了一条异常记录：一个新用户注册后，什么都没做。没创建组织，没部署项目，账号就那么晾着。产品经理的本能是排查转化漏斗，但连续两天，这类"僵尸账号"每天新增2-3个，名字像PfVQXvYTXjwSbEeJBjXYy这种随机字符串。

团队起初没当回事。做SaaS的，谁没遇到过爬虫或者安全测试？「第一反应是有人在做负责任的渗透测试，」团队后来复盘，「这种我们欢迎，还会发感谢邮件。」

到3月14日，数字跳到6个。PostHog（用户行为分析工具）弹出另一条警报：忘记密码页面的访问量异常飙高。两条曲线叠在一起，事情开始变味。

每分钟3封邮件，受害者根本来不及反应

回放用户会话才发现套路：机器人用真实邮箱+垃圾名字注册，60秒内跳转忘记密码页，请求重置。每个"用户"在1分钟内收到Suga发来的3封邮件——欢迎信、邮箱验证、密码重置。

「我们只是同时被攻击的数百个网站之一。」团队意识到。这些邮件本身无害，但受害者邮箱正在被数千封"欢迎注册"淹没。真正的杀招藏在噪音里：攻击者同步重置受害者的网银密码、盗刷信用卡、申请贷款。银行的安全警报和确认邮件，被埋在SaaS产品的欢迎信海洋里，受害者根本看不见。

机器人还尝试用随机邮箱轰炸忘记密码页，推测是在匹配已有用户。最讽刺的细节是打字速度：机器人输入表单时故意慢得像人类，每个字符间隔1秒，试图绕过行为检测。

一个存在了20年的攻击手法，为什么现在还在用

Subscription bombing（订阅轰炸）不是新东西。2000年代初，垃圾邮件过滤技术不成熟，这种手法更依赖 brute force（暴力破解）。现在复活，是因为现代身份验证流程反而制造了新的攻击面。

关键漏洞在于：绝大多数网站的注册表单，只验证邮箱格式，不验证所有权。攻击者不需要控制受害者的邮箱，只需要知道地址，就能让第三方网站替自己"合法地"发送邮件。每封邮件都是真实的、来自可信域名的、绕过垃圾邮件过滤的。

Suga团队算了一笔账：假设攻击者同时向500个网站投放，每个网站发3封邮件，受害者在5分钟内收到1500封邮件。而银行的安全警报，可能就在这1500封的某个位置。

更隐蔽的变种是"延迟轰炸"——不一次性灌满，而是分散在数周内，让受害者逐渐习惯"又收到一封欢迎信"，降低警觉。

Suga的防御方案：把验证成本转嫁给攻击者

发现问题后，Suga做了三件事。

第一，注册流程加一道邮箱所有权验证。不是简单的点击确认，而是要求用户在验证邮件中完成一个微小操作——比如输入邮件里的一段短码。这增加了攻击者的自动化成本。

第二，忘记密码页加频率限制和CAPTCHA（人机验证）。同一IP或邮箱短时间内多次请求，直接触发冷却期。机器人那"1秒1字符"的伪装，在行为分析模型面前反而成了特征——人类打字有节奏变化，机器人太均匀了。

第三，监控"注册-激活"时间差。正常用户从注册到首次核心操作（创建项目/部署）通常有明确路径，僵尸账号的时间分布是离散的、无规律的。这套规则现在自动标记异常账号供人工复核。

团队特别提到一个反直觉的发现：完全阻止机器人注册，不如让它们注册但无法触发邮件。攻击者的目标是制造邮件噪音，如果注册后收不到验证信，这个"武器"就失效了。所以Suga选择在发送环节设卡，而非注册环节。

每个SaaS都是这场攻击的共谋，也是解药

Subscription bombing的可怕之处在于分布式责任。单个网站的3封邮件无害，但数百个网站的3封邮件叠加，就成了完美的犯罪掩护。没有一家网站觉得自己有问题——「我们只是按流程发了欢迎信。」

Suga团队在复盘报告里写了一句挺扎心的话：「我们曾以为邮箱验证是防自己平台的垃圾账号，现在发现是防别人平台的金融诈骗。」

目前这套防御机制运行两周，异常注册量下降94%。但团队清楚，这只是猫鼠游戏的一回合。攻击者已经在测试新的绕过方式，比如用真实姓名生成器替代随机字符串，模拟更可信的注册行为。