Discord 私信钓鱼手法分析
事件背景
5 月 16 日凌晨，当我在寻找家人的时候，从项目官网的邀请链接加入了官方的 Discord 服务器。在我加入服务器后立刻就有一个"机器人"(Captcha.bot)发来私信要我进行人机验证。这一切看起来相当的合理，我也点击了这个验证链接进行查看。
钓鱼手法分析
我访问"机器人"(Captcha.bot)发来的链接后，确实让我进行了人机验证。但验证通过后，页面却要求唤起我的小狐狸(MetaMask)钱包。唤起的钱包界面看起来挺真实的，如下图，但我注意到了钱包地址栏显示 about:blank——这立刻引起了我的警惕。
于是我随意输入了密码，通过审查元素确认这个小狐狸(MetaMask)界面是由虚假站点 https://captcha.fm/ 弹出的，并不是真实的钱包界面。接着我开始调试这个钱包。
输入任意密码后，虚假钱包界面跳转到"Security Check"页面，要求我输入助记词进行验证。注意，输入的密码和助记词会被加密发送到恶意站点的服务端。
通过分析域名可以发现，恶意域名 captcha.fm 解析到了 172.67.184.152 和 104.21.59.223，托管在 Cloudflare 上，只能反手一个举报了。
分析恶意账号
下载保存好恶意站点的源码后，我将情报发给了项目方团队，并开始分析这次钓鱼攻击的账号。由于我刚加入服务器，就收到了下面这个地址发来的验证消息。经分析，这个账号是一个伪装成 Captcha.bot 机器人的普通 Discord 账号。当我加入官方服务器后，这个假 Captcha.bot 立刻通过私发消息对我进行钓鱼引导——看上去是自动化识别新加入用户，自动构造链接并私发钓鱼链接。
我在相关频道里面搜索了 Captcha.bot，发现有好几个假 Captcha.bot，于是将这几个账号一并同步给了项目方团队。项目方团队很给力，也很及时地进行了处理（此时已是凌晨了），把这几个假 Captcha.bot 删除了，并一起讨论了可能的防范方式。
再次收到钓鱼链接
事情还没结束。第二天早上另一位慢雾的小伙伴（感谢 @Victory 提供素材）加入官方 Discord 服务器后，再次收到了恶意账户发来的私信——里面包含着一个钓鱼链接。不同的是，这次的钓鱼者直接伪装成官方的账户发送私信。
这次钓鱼者讲的故事是"在链接中导入助记词进行身份验证"，没有采用假小狐狸(MetaMask)界面的手法来欺骗用户，而是直接在页面上引导用户输入助记词——这套钓鱼手法就没那么逼真了（手法太粗糙）。
钓鱼网站的域名和 IP 是 app.importvalidator.org / 47.250.129.219，用的是阿里云的服务，同样反手一个举报。
钓鱼防范方式
各种钓鱼手法和事件层出不穷，用户需要学会识别各种钓鱼手法避免被骗，项目方也要加强对用户安全意识的教育。
用户在加入 Discord 后应当第一时间在隐私设置中关闭"允许服务器成员直接向你发送私信"选项。同时，用户也需要提高安全意识，学会识别伪装 MetaMask 的攻击手法——如上文所述，查看是否有地址栏是一个简单有效的判断标准：插件钱包发起的是没有地址栏的。另外，网页唤起 MetaMask 请求签名时，要仔细阅读签名的内容，如果无法判断签名是否恶意，就直接拒绝。无论何时何地，都不要在网页上导入私钥或助记词。尽可能使用硬件钱包——硬件钱包一般不支持直接导出助记词或私钥，可以大幅提高私钥被盗的门槛。
项目方团队也要时刻关注社区用户的反馈，及时在社区 Discord 服务器中清理恶意账户，并在用户刚加入 Discord 服务器时主动推送防钓鱼安全教育。
写在最后
Discord 钓鱼的本质是社交工程——攻击者利用新用户"刚加入社区、对服务器规则不熟悉"的认知窗口，在用户尚未来得及产生安全警惕时完成钓鱼。这是一种典型的"信任缝隙"攻击：官方社区的信任感被嫁接给了伪装者，用户对官方认证机制的熟悉被逆向利用。
这类攻击之所以持续有效，根本原因是：Web3 的安全实践中存在大量合规流程与用户体验之间的摩擦点。人机验证本应该保护用户，但当攻击者把自己包装成人机验证本身时，这个"标准化流程"就成了最理想的钓鱼载体。对抗这类攻击，单靠项目方的清理是远远不够的，用户自身的"零信任"意识才是最后一道防线。
参考链接：