用真正 Binance 链接发动的「验证码」短信诈骗

30 天复查 — 原始记录

核验于 2026-09-29。这些域名的两台 WHOIS 服务器说法并不一致，而这个差异正是上面那处更正。

注册商的 WHOIS 只返回一个单词，根本没有记录。以下就是 whois.ownregistrar.com 对这三个域名各自返回的全部响应正文：

Terminated

没有字段，没有状态码，完全不是 RFC 规定的形状。「Terminated」是 OwnRegistrar 自家的产品用词，而不是一种注册局状态——EPP 里并不存在这个状态。我们当初引用它时，把它当成了对注册局状态的描述，而它不是。

注册局的 WHOIS 才返回真实记录。来自 whois.verisign-grs.com，三个域名形状完全一致：

Domain Name: COM73184.COM
Registrar: OwnRegistrar, Inc.          Registrar IANA ID: 1250
Registrar Abuse Contact: abuse@ownregistrar.com  +1.2124016235
Creation Date:      2026-08-21T21:45:28Z
Updated Date:       2026-08-26T09:10:06Z
Registry Expiry:    2027-08-21T21:45:28Z
Domain Status: clientDeleteProhibited
Domain Status: clientHold
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Name Server: A.DNSPOD.COM
Name Server: C.DNSPOD.COM
DNSSEC: unsigned

cdn378129.com   注册 2026-08-20T13:31:11Z   到期 2027-08-20T13:31:11Z   更新 2026-08-26T09:10:06Z
bnbshort.com    注册 2026-08-22T08:14:03Z   到期 2027-08-22T08:14:03Z   更新 2026-08-26T09:10:05Z
com73184.com    注册 2026-08-21T21:45:28Z   到期 2027-08-21T21:45:28Z   更新 2026-08-26T09:10:06Z

这份记录里有三件事，是「已终止」这个说法掩盖掉的。

clientHold 才是没有 DNS 的原因。委派关系仍然完好——两台 DNSPod 名称服务器依旧列在记录里。注册商是把域名从区文件中摘掉，而不是删除注册，因此解析失败，注册本身却还在继续。它距离重新可解析，只差一次状态变更。而操作者自己做不到这件事：clientUpdateProhibited 与 clientTransferProhibited 把他们锁在自己的域名之外。

这种停用的形状，是刻意设计成比这场攻击活动活得更久的。clientRenewProhibited 加上 clientDeleteProhibited 意味着这些域名既不能续费、也不能被提前释放：它们会一直冻结到到期，然后掉落。把它们删掉反而是更弱的处置，因为被删除的域名大约 75 天后就会回到可注册池。冻结到到期，这三个域名在 2027 年 8 月 20 至 22 日之前都不会流向市场。做这个决定的人选了更强的那一个选项。

处置发生在我们核验的四天之前。三条 Updated Date 全部落在一秒之内——2026-08-26 UTC 的 09:10:05 与 09:10:06。我们把结果记在 8 月 30 日，并暗示那就是它发生的时间。实际上它是脚本化的、对三个域名一次性施加的，而且在我们去看的时候已经过了四天。

仍未解决的部分

小程序 appId xoqXxUSMRccLCrZNRebmzj——那个比每一个域名都活得更久的组件，也是这篇write-up讲的是机制而不是三个地址的原因。威胁指标中点名的两个 mp-cms 页面，对任何未经身份验证的请求都回以 HTTP 202，那是机器人拦截，而不是一个页面。它是否还活着，只能从已登录的 Binance App 内部观察，因此我们无法就这条通路是否已被关闭下任何结论。三十天过去，它仍是那个悬而未决的问题——也是真正要紧的那一个。

一位用户向我们转发了两条相隔约两小时收到的短信。两条都像是 Binance 安全通知，也都带有一个链接，其域名确实且可以验证为 Binance 自有。

我们拆解了整条链路。其终点并不是伪造的登录页面，而是一段脚本：如果它在您已登录时通过 Binance 应用触达您，就会赎回您的储蓄，把您持有的每一笔余额转换成 Bitcoin，并向攻击者硬编码的地址提交提现。它从不向您索要密码、验证码或助记词，因为这些都不需要。

本文记录了完整链路，因为通常所说的“检查域名”在这里保护不了您。域名是真的。

消息

这是最早的两条。在下文全部写完后的三十六小时，又有两条来自同一个 Binance Mini Program 的消息抵达 — 它们见于它又回来了，而且什么都没变。

已经有两点值得注意。

两条消息的验证码不同 — 780641 和 366812 — 但链接完全相同。真正的一次性验证码会绑定到真正的请求。这些验证码只是装饰，每次发送时生成，让消息看起来像您以前收到过的内容。

第二条消息使用的是口语粤语，而不是标准书面中文。有人特意为香港读者做了本地化。我们稍后会再谈这一点，因为载荷本身也经过本地化，这揭示了该活动瞄准的人群。

为什么“检查域名”会失效

报告此事的人熟悉 DNS 和域名基础设施，却仍差点点击。这一点值得认真对待，因为他们做了正确的检查，而且每一项都通过了：

• 主机是s.binance.com。它是binance.com的子域名，后者才是真实的可注册域名。
• 它并非国际化域名同形异义攻击。每个字符都是纯 ASCII。逐字母比较，它就是真实字符串。
• 对binance.com进行 WHOIS 查询会返回 Binance 自己的注册信息。没有仿冒注册商，没有近期创建日期，也没有任何异常。
• TLS 在有效证书上终止连接。那个挂锁是真的。

这些都属实，却全都没有帮助，因为攻击者根本不需要控制 Binance 域名。s.binance.com是 Binance 自己的链接缩短器。攻击者把载荷放在别处，再利用 Binance 的基础设施指向它。

与您能识破的版本比较

下面是同一套借口的普通形式 — 这是另一条报告给我们的消息，也是大多数此类活动至今仍采用的形态：

那一条可以识破。字符串binance.com就明明出现在链接中 — 但它位于@ 符号之前，而在 URL 中，从协议到@之间的全部内容都是凭据，不是主机名。浏览器会把它理解为：连接到主机0691[.]app，并提供用户名“binance.com”。真正的目的地是一个四位数字的临时域名。品牌只是放在用户名字段里的诱饵。

懂得这条规则的人一眼就能看出。如今许多消息和邮件客户端也会直接标记或重写这种模式。它属于混淆，而混淆可以被讲解、检测和过滤。它面对那位同时报告了这两种消息的人也同样无效。

这条s.binance.com消息属于另一类问题，应当按另一类问题处理。它没有任何伪装之处：

• 没有 @ 符号伎俩。主机就是主机。
• 没有同形异义字、punycode 或西里尔字母仿冒。
• 可见字符串里没有任何拼写错误。
• 没有可疑注册商、刚注册的域名或自签名证书。
• 链接过滤器没有可据以判断的特征，因为真正的 Binance 用户完全可能向您发送这样的链接。

它并非模仿Binance 的可信度，而是借用了真品 — 域名、证书、应用交接，以及会渲染“Protect Your Account”字样的界面。欺骗直到您已经进入应用后才开始，而那时已没有地址栏可供检查。

这正是这一例值得专文分析、而第一例不值得的原因。@ 符号消息可以靠知识识破，这一条却不能，因为您会做的每项检查都返回“真实” — 而且它的确是真实的，直到受信任的应用把请求通道交给一个当天早晨才注册的域名。

链路解码

短链接返回一个普通 HTTP 重定向：

HTTP/2 302
location: https://app.binance.com/en/mp-cms/app/3cb3235
          ?_dp=<base64>
          &description=Protect+Your+Account
          &title=Binance
          &utm_campaign=app_mini_program_share_link
          &utm_source=mini_program

仍是 Binance，仍是真实的。值得注意的是活动标签：app_mini_program_share_link和mini_program。这是一个Binance Mini Program share link — 也就是从 Binance 应用内分享迷你应用时得到的产物。没有任何东西遭到入侵。攻击者发布或滥用了一个迷你程序，并按分享功能原本的设计方式使用它。

还要注意description=Protect Your Account。社会工程话术随 URL 一起传递，因此由 Binance 自己的界面渲染那些令人安心的字样。

_dp参数是 base64。解码后为：

bnc://app.binance.com/mp/app
    ?appId=xoqXxUSMRccLCrZNRebmzj
    &startPagePath=L3BhZ2VzL2Jyb3dzZXIvaW5kZXg
    &startPageQuery=<base64>
    &sceneValue=1300

bnc://是 Binance 应用的自定义 URL 方案。在已安装该应用的手机上，它会把控制权交给应用，而不是打开浏览器标签页。

startPagePath同样是 base64，解码得到/pages/browser/index — 即该迷你程序的应用内浏览器页面。因此，这个深层链接是在告诉 Binance 应用：打开这个迷你程序，并进入它的浏览器页面。它应加载的地址第三次以 base64 编码，位于startPageQuery中：

url=https%3A%2F%2Faccounts.authenticated.binancc.cdn378129.com%2Fauth8%2F

就在这里。仔细阅读主机：

accounts . authenticated . binancc . cdn378129 . com
└──────────── decoration ────────────┘ └── real ──┘

可注册域名是cdn378129[.]com。其左侧的所有内容都是攻击者任选的文本 — 包括binancc，其中有两个 c，这与其说是品牌拼写错误，不如说是故意设计、扫一眼便会漏过的近似拼写。况且在手机的 webview 中，该字符串大部分都位于屏幕之外。

因此，恶意域名从未出现在消息中。它经过 base64 编码，藏在一个查询参数里；该参数又位于另一个 base64 载荷内；这个载荷又位于真实的 Binance URL 内，并隐藏在真实的 Binance 链接缩短器之后。

基础设施只有数小时历史

以下公开记录均在撰写本文时核查：

• cdn378129[.]com的注册时间为 13:31 UTC，日期为 20 日（2026 年八月），注册商为 OwnRegistrar, Inc.，DNS 委托给 DNSPod。
• 它的 Let's Encrypt 证书所载notBefore为同日 12:35 UTC。Let's Encrypt 会将该字段回溯约一小时，因此证书大约在注册后四分钟签发。该证书只覆盖这一个主机名，别无其他。
• 该主机解析到 107.189.17.50，该地址位于分配给 FranTech Solutions 旗下 RouterHosting LLC 的地址段内。
• 该域名未签名 — 没有 DNSSEC。

一个注册不到一天的可注册域名、一张数分钟后签发的证书，以及一个单一用途的主机名。从 SMS 中看不到这些，从s.binance.com中也看不到 — 而这恰恰就是通过缩短器路由的目的。

页面实际做了什么

我们在隔离沙箱中获取了该端点，但没有执行它。第一个意外在于那里没有什么：

• 没有表单。一个<form>元素也没有。
• 没有输入字段。一个<input>也没有。
• 没有密码提示、一次性验证码提示、助记词提示或钱包连接按钮。

人们被训练去依赖的每一种直觉 — 不要在陌生页面输入密码、绝不要输入助记词、留意自己正在签署的内容 — 在这里全都不起作用，因为该页面从不向您索要任何东西。

它实际包含的是一段经过混淆的脚本，其配置明文放在顶部：

var WITHDRAW_COIN     = "BTC";
var ATTACKER_ADDRESS  = "bc1qnwhg6za5m0adlny6t4xx6qa2heyrntsvk8pw4f";
var WITHDRAW_NETWORK  = "BTC";
var FEE_RESERVE       = 0.00007;
var MIN_COIN_AMOUNT   = 0.01;

而混淆器没能隐藏的错误字符串直接点明了机制：

"bridge interface not found (window.bn.miniProgram missing)"
"bridge did not appear within "
"bridge request timed out after 10s"

window.bn.miniProgram是Binance 应用注入迷你程序 webview 的 JavaScript 桥。脚本等待它出现，然后通过它发出请求。这就是整套伎俩：它不需要您的凭据，也不需要绕过同源策略，因为应用会把受信任的请求通道交给迷你程序浏览器所显示的任何页面 — 而迷你程序浏览器已经被告知要显示攻击者的页面。

提现流水线

还原字符串表后，可以得到载荷按逻辑顺序调用的 Binance 私有端点：

1. /bapi/accounts/v1/private/account/get-user-base-info — 识别受害者。页面会按姓名向您问候：“欢迎回来，…”。
2. /bapi/kyc/v2/private/certificate/user-kyc/get-current-kyc-status-lite — 检查验证状态，因为提现取决于此。
3. /bapi/asset/v3/private/asset-service/asset/get-wallet-asset — 枚举账户中的每一笔余额。
4. /bapi/earn/v1/private/lending/daily/redeem — 赎回灵活储蓄，让正在产生收益的资金变为可用。
5. /bapi/margin/v1/private/new-otc/get-quote和…/execute-quote — 把其他所有资产转换成 Bitcoin，跳过低于最低金额的余额，并预留少量手续费。
6. /bapi/capital/v4/private/capital/withdraw/apply — 提交提现到硬编码地址。

在此过程中，屏幕会显示一小段令人安心的状态序列，直接取自页面自身的标记：

正在加载您的账户 · 我们正在安全地收集您的详细信息 · 欢迎回来，… · 正在检查授权… · 正在重新登录 Binance

“正在重新登录 Binance”这句话承担了很多作用。它解释了停顿，解释了应用为何正忙，也让您预期接下来会有一个身份验证步骤。

真正巧妙的是假验证码

这里有一点我们过了一会儿才意识到。SMS 中的假验证码不是诱饵，链接才是。验证码起到的是心理接种作用。

从真实交易所账户提现通常需要真正的确认 — 邮件链接、身份验证器验证码或推送批准。这项确认是受害者与损失之间最后一道防线，本应令人警觉。

但受害者已经收到一个并未请求的 Binance 验证码，消息本身也已告诉他们：未请求的验证码就是这个样子。此时，他们正处于标题为“正在检查授权”的流程中，屏幕还按姓名问候了他们。当真正的确认到来时，读起来不像警报，反而像他们自以为正在执行的安全检查的下一步。

目标人群

载荷随附的翻译表恰好只有两种非英语语言区域：zh和ko。它读取navigator.language并自行本地化。再结合以香港粤语写成的诱饵，可见这是一场面向中文和韩语用户的活动，而不是一场碰巧触及某位此类用户的英语广播。

我们用两个相互独立的区块浏览器检查目的地址时，该地址完全没有交易 — 既没有已确认交易，mempool 中也没有等待中的交易。据链上记录所示，该地址当时尚未收到任何一位受害者的资金。

我们起初把这看作令人鼓舞的迹象。这种解读是错的，而且一位亲历者告诉了我们这一点。空的收款地址并不意味着没有人中招，只意味着资金没有到达最后一步。在此之前的每一步仍可能已经执行 — 而且至少在一个有资金的账户上确实执行了。请参阅下文的空地址究竟隐藏了什么。

它确实说明还有时间，而这正是要快速发布、而不是谨慎发布的原因。

真正能保护您的措施

检查域名无法抵御这种攻击。以下措施可以：

• 为您的交易所设置防钓鱼码，并检查它。Binance 允许您定义一个会出现在其真实消息中的标识，包括 SMS。上面的消息没有该标识。缺失本身就是线索，也是普通人可以使用的最可靠线索。
• 把“如果不是您本人，请点这里”视为攻击，而不是补救措施。合法安全通知会让您自行打开应用。紧迫感和链接本身就是载荷。
• 绝不要从消息进入交易所。请从主屏幕打开应用。仅这一项习惯就能挫败整条链路，因为只要您不点击，其中任何环节都无法继续。
• 设置提现地址白名单。启用白名单并为新地址设置延迟后，向新地址提交提现的脚本便无处可转出资金。
• 阅读确认信息实际写了什么。真正的提现确认会列明币种、金额和目的地址。如果某个屏幕告诉您它正在“让您重新登录”，那段文字实际对应的是一笔提现。
• 警惕会打开应用的链接。直接跳进应用的链接绕过了浏览器，也随之绕过了地址栏和您原本会收到的所有安全浏览警告。

如果您点开了

1. 直接打开交易所应用，首先检查提现历史和待处理提现。取消任何不是您发起的项目。
2. 检查灵活储蓄头寸是否被赎回，以及余额是否被转换成 Bitcoin。两者都发生在提现之前，因此都是更早的警报。
3. 不要依赖登录历史 — 它会显得一切正常。载荷在您已经打开的会话内运行，因此不会创建新的登录事件。以这种方式被清空的账户，在事发当时的登录活动中不会显示任何异常。
4. 专门检查转换历史，而不是交易历史。Convert 不会出现在现货订单下。寻找不明交易的人会看到空列表，并断定什么都没发生。
5. 撤销活动会话和设备，然后更改密码并轮换双因素验证。
6. 启用提现地址白名单。
7. 报告此事。Binance 通过其支持中心接收诈骗报告；包含短链接、迷你程序标识符和目的地址的报告，远比截图更便于采取行动。

指标

以下内容均已去武器化，发布目的是让防御者能够阻止并关联这些指标 — 不是让任何人访问它们。

WAVE 2 (2026-08-22)
Shorteners     hxxps://s.binance[.]com/DwOKKciE
               hxxps://s.binance[.]com/hOD42AgF
Mini program   appId xoqXxUSMRccLCrZNRebmzj  (mp-cms e3efa5b, scene 1300)
Final host     accounts.authentication.binance.com73184[.]com  /auth-1334/
Registrable    com73184[.]com   registered 2026-08-21 21:45:28 UTC
SOL address    H2RMUS1nhiqtwToUfLzCdUB94rmHrFDzyrnJaNKiMGr2

WAVE 1 (2026-08-20)
Shortener      hxxps://s.binance[.]com/speZiskQ
Mini program   appId xoqXxUSMRccLCrZNRebmzj  (sceneValue 1300)
Deep link      bnc://app.binance.com/mp/app?...startPagePath=/pages/browser/index
Final host     accounts.authenticated.binancc[.]cdn378129[.]com
Path           /auth8/
Registrable    cdn378129[.]com   registered 2026-08-20 13:31 UTC
Registrar      OwnRegistrar, Inc.        DNS: DNSPod
IP             107.189.17.50   (RouterHosting LLC / FranTech Solutions)
TLS            Let's Encrypt, single-SAN, issued same day
BTC address    bc1qnwhg6za5m0adlny6t4xx6qa2heyrntsvk8pw4f

证据失效了，而且这场活动无人拦下

域名注册大约一天后，我们重新检查了链路中的每个链接。现在所有链接都呈现 404s 状态 — 包括短链接和末端载荷。

人的本能是松一口气。这种本能是错的，而理解原因是本文最有价值的部分。

没有任何东西被下架

看看还有什么仍在运行：

Domain status     ok            (not clientHold, not serverHold)
WHOIS updated     unchanged since the moment of registration
DNS               still resolves to 107.189.17.50
Web server        nginx still running, still answering
Certificate       still valid, unrevoked, good until November
Payload           gone
BTC address       still zero transactions, mempool included

注册商暂停域名会改变域名状态并使其停止解析。主机服务商暂停服务会让服务器停止响应。两者都没有发生。我们看到的是一台仍在运行的服务器、一个仍在解析的名称，以及一张仍有人付费维持的证书 — 只是文件被手动删除了。

这不是下架，而是运营者在收尾。投递链接同时失效，可能是平台撤销了它，也可能是同一运营者停用了它；从外部无法区分，而这本身就是问题。

没有任何一方承认过这一切

没有案件编号，没有公告。没有已停用迷你程序的公开说明，没有注册商行动，没有黑名单条目，也没有任何一方的声明。我们没有找到任何一方对整件事的公开确认。

因此，这场活动并未被阻止，而是由运营它的人按自己的时间表结束；其基础设施完好无损，在全球每一家注册商和主机服务商处的信誉也完全未受影响。

为什么这让报告几乎不可能

公众可以使用的每一条报告渠道都假定内容仍在线：

• 黑名单分类器会获取 URL来作出判断。它只看到一个普通的 nginx 404，于是拒绝收录。
• 注册商滥用处理部门收到“此域名曾提供钓鱼内容”的报告时，如果 URL 如今不返回任何内容，就会以内容已删除、无需行动为由关闭工单。
• 主机服务商的滥用处理部门也会这样做。

所有这些尚可采取行动的窗口，在分析仍在撰写时就已关闭。这并不是批评滥用处理部门 — 验证仍在进行的攻击是可处理的，裁定已经消失的攻击则不是。这是在描述一个结构性缺口：报告系统的运行速度慢于它本应捕获的攻击。

证据会挥发，而这正是全部伎俩

这一点值得仔细思考。只存活二十四小时的钓鱼行动，产生的证据也只有二十四小时的保质期。攻击者无需摧毁任何东西、掩盖任何痕迹或智胜任何人，只需熬过报告延迟 — 一个仅花十美元、注册四分钟后便被武器化的域名，可以轻松做到这一点。

此后，局面对每一方都同样僵持且无益。我们无法向滥用处理部门证明，因为其验证步骤是一次抓取；他们无法验证，因为已经没有内容可抓取；接收者无法报告，因为消息中的链接如今无处可去，看起来像个错误；运营者则可以下周换一个新域名和新的迷你程序身份再做一遍，既未付出代价，也未留下记录。

这就是为什么真正重要的是技术，域名从来不重要。机制没有任何一处改变。迷你程序浏览器页面仍接受目的地作为参数；该页面加载的任何内容仍可访问桥；分享功能仍会在带有效证书的真实域名上生成链接。一个新标识符和一个无人听说过的主机名，一个下午便能重现本文所述的一切。

如果您收到其中一条

实际结论是：先留存，再报告。最初一小时内存在的内容，就是将会存在的全部内容。

• 在做任何其他事情前截取消息屏幕，包括发送者。
• 如果您有能力，请在不跟随跳转的情况下记录重定向链 — 只从一台未安装该应用的机器请求响应头。第一跳的location响应头是整条链中最有价值的单项证据，也是最先消失的东西。
• 不要在安装了该应用的设备上打开它。那不是测试，那就是攻击。
• 记下时间。域名注册与第一条消息之间的间隔本身就是证据，即使内容消失后它仍然存在。

正因如此，我们捕获的一切都写在本文中：请求链、解码后的深层链接、载荷调用的端点，以及它打算汇款到的地址。这些内容如今都无法再获取。本文现在就是记录；如果为了更周全的确认再等一天，这篇分析将会一无所有。

空地址究竟隐藏了什么

此后，有人向我们讲述了一个受第一轮影响的账户。其记录显示，这个载荷的转换阶段确实执行过。他们要求保持匿名，因此下文刻意省略了所有可能识别其身份的数字 — 余额、持仓、地址、订单号。没有一项是必要的。证据在于事件的形态，而不在于规模。

以下是他们的叙述，并与我们此前独立测得的数据交叉核对。我们不会描述他们是谁、身在何处或持有什么，也绝不会这样做。

我们弄错的部分

我们曾报告收款地址没有交易，并据此认为该活动没有成功。这项推断并不成立。在这个账户上，载荷的转换阶段已经完成：分布在两个独立钱包中的全部余额，在一次账户持有人没有执行、也完全不记得的操作中，被转换为一种资产。失败的是提现 — 资金仍留在账户内。

因此，空的收款地址并不意味着没有人中招，只意味着交易所的提现控制在最后一步生效，而此前的一切都已经运行。这是截然不同的两个事实，而我们发布了那个更令人安心的版本。

与载荷完全吻合的三项细节

我们通过静态分析从混淆脚本中提取了MIN_COIN_AMOUNT = 0.01；那是在这个账户遇袭两天后。在该账户中：

• 第二个钱包中恰好 0.01的余额被转换 — 精确位于阈值上。
• 另外两项持仓都低于 0.01，因此未被触碰。
• 两个钱包都在同一次操作中被清空，这与读取每一笔余额、而非只读取主钱包的枚举步骤一致。

一项从代码中恢复的常量，加上一个真实账户，其剩余资产恰好位于该常量两侧。这正是我们撰写本文时所缺少的确认。

为什么这不可能由人工完成

两个钱包分支以完全相同的锁定汇率转换，时间相隔约一秒。锁定汇率只针对某一瞬间报价，因此两个分支汇率相同，意味着它们是在同一批次中一起报价的。

手动完成此操作，需要选择币对、预览并在倒计时内确认 — 而且每个钱包都要分别进行。在相隔一秒的时间内，跨两个不同钱包以同一报价汇率完成两次完整的手动转换，是人力不可能做到的。这个时间特征表明是机器执行，而且在账户自身记录中清晰可见。

改变应对建议的发现

这是最值得记住的一点，而且它推翻了我们和其他所有人经常给出的建议。

攻击不会留下登录事件。转换运行时没有登录。几分钟前有一次完全正常的登录，来自账户持有人自己的设备和自己的地址，因为事实本来就是如此。随后，载荷在那个已经通过身份验证的会话内部通过应用的桥执行。

因此，标准指引 — 检查登录历史中是否有您不认识的会话 — 对遭遇过此事的账户会返回完全正常的结果。没有任何会话可供识别，因为那个会话本来就是他们自己的。

第二个陷阱在于受害者接下来查看哪里。转换不会出现在交易历史中，因为 Convert 不是订单簿上的交易。有人在现货订单中查找那笔清空账户的不明交易，只会看到空列表，并合理地认为自己记错了。它确实有记录，但只在转换历史中 — 那是另一个没有人想到要打开的页面。

这两个陷阱叠加后，账户可能受到大幅干预，而谨慎的人会查看的每个位置看起来都正常。这不是受害者不够尽责，而是账户能够告诉他们的信息存在缺口；也正是本文开篇所说的同一缺口：能够裁定事实的平台侧记录 — 哪个迷你程序发起了订单 — 确实存在，但账户持有人看不到。

我们在上文作出的修改

本文前面的恢复步骤现在要求检查转换历史，而非交易历史，并明确指出登录活动会显得一切正常。此前两处说法都是错的，而且会让人带着不该有的安心感离开。

它又回来了，而且什么都没变

以上内容写作时，我们假定活动已经结束。大约三十六小时后，又有两条消息到达。借口相同、缩短器相同，验证码不同：

我们在最初一小时内再次捕获了整条链路。其中一行比本文其他所有内容都更重要：

Wave 1  2026-08-20   appId xoqXxUSMRccLCrZNRebmzj
Wave 2  2026-08-22   appId xoqXxUSMRccLCrZNRebmzj   <-- identical

Mini Program 从未被停用。第一轮的短链接停止解析，而这就是平台侧唯一的变化。其背后的标识符仍然在线、仍可访问，仍愿意打开浏览器页面，并把桥交给提供给它的任何 URL。运营者针对它生成了两个全新的短链接，并将其指向新位置。

其余指纹也完全未变，因此可以排除模仿者：同一个迷你程序页面（/pages/browser/index）、相同的sceneValue、相同的description=Protect Your Account、位于 107.189.17.50 的同一台服务器、同一家注册商、同一个 DNS 提供商。只有三样东西变了 — 短链接、域名和币种。

这回答了前文只能推测的问题。切断投递链接无法阻止运营者，因为投递链接是他们拥有的最廉价组件；切断迷你程序则可以，但没人这样做。

夜间注册，清晨发送

21:45:28Z   domain registered
21:49:06Z   TLS certificate issued        +3m 38s
23:34:00Z   first message                 +1h 48m
00:22:00Z   second message                +2h 36m
00:43:52Z   captured, payload live        +2h 58m

从注册到获得有效证书不到四分钟，从注册到消息抵达真实手机不到两小时。其形态与第一轮完全相同，精确到分钟。没有人在手动完成这些操作。

新域名是一个更高明的谎言

accounts . authentication . binance . com73184 . com
└─────────────── decoration ──────────────┘ └─ real ─┘

可注册域名是com73184[.]com。快速读完整个字符串，它看起来是…binance.com73184.com — 视线会停在binance.com，并把后面的数字当作缓存节点或分片。相比第一轮的binancc，这是直接的改进；后者至少看起来拼错了。

在此期间，载荷经过了修改

它从 24,640 字节增长到 34,335 字节。七个私有端点完全相同 — 同样的枚举、储蓄赎回、转换和提现 — 但新增了四项内容：

• 收款币种从 Bitcoin 改为 Solana。更快、更便宜，也更难撤回。
• 逐资产转换上限，这符合将单笔转换控制在任何可能引起注意的阈值之下的做法。
• 规避速率限制。仍可见的一条字符串是Retried just under limit: — 他们在有意针对平台的节流机制调优，并对结果进行测量。
• 葡萄牙语，加入了已有的中文和韩语。

而且它现在会伪造批准屏幕

这是值得停下来细看的变化。页面用四种语言渲染了一个伪造的 Binance 安全提示：

检测到新登录 · 是您本人吗？ · 设备 · 位置 · IP 地址 · [批准] [拒绝] · 15s 后自动阻止

本文前面在说明推送批准何以可信时曾写道，提示必须显示应用、location 和 IP 地址 — 没有上下文的提示不可能让人作出正确判断。而这里恰恰复刻了这些字段。攻击者拿走了让真正安全提示变得安全的设计，并把它重建成布景。

它还闭合了由 SMS 开启的循环。消息写着如果不是您本人，请访问此链接。访客心怀担忧地到达，并看到担忧者正希望看到的屏幕：一个他们不认识的登录、排列清楚的详细信息，以及一个标有“拒绝”的按钮。点击“拒绝”让人感觉正在夺回控制权。两个按钮都属于攻击者，而十五秒倒计时的作用，就是不让任何人思考到第十六秒。

这一次我们做了什么

所有内容都在最初一小时内被捕获，并以校验和保存；两个载荷并列留存，使两轮之间的差异可以被证明，而不只是凭记忆描述。当网站仍在响应时，报告已发往 Binance 公布的安全地址、注册商、主机服务商和两个反钓鱼信息交换机构。

注册商开启了工单。截至撰写时，两个目的地址 — 第一轮的 Bitcoin 地址和第二轮的 Solana 地址 — 都从未收到过交易。

令人不安的是，上一节的推理没有任何一处错误。第一轮的证据确实失效了，没有任何一方承认此事，技术也原封不动地存活下来。我们没有预料到的是，这一点会如此迅速地得到证明。

第三轮：他们彻底不再需要 Binance

第一批消息后的两天，第三条抵达。借口相同，管道不同：

再读一遍这个主机。它不是 Binance 域名。整条链路中没有s.binance.com，没有通过app.binance.com的重定向，没有bnc://深层链接，也没有任何 Mini Program 标识符。运营者注册了自己的域名，将其命名为容易被误认为 Binance 短链接服务的名称，并直接从该域名提供载荷。

同一批人

能识别运营者的一切都与前几轮相同：同一台服务器、同一家注册商、同一个 DNS 提供商、同一个 Web 服务器构建版本。只有投递路线是新的。

registered      08:14:03 UTC
certificate     ~08:21 UTC     +7 minutes
first message   ~08:48 UTC     +34 minutes
captured        08:57 UTC      +43 minutes

从注册到有效证书不到七分钟，到消息抵达真实手机不到三十五分钟 — 与前两轮的形态完全相同，精确到分钟。

他们为何放弃一个本来很好用的 Binance 链接

在第二轮和第三轮之间，平台侧恰好只改变了一件事：第二轮的两个短链接中，有一个停止解析。另一个仍然有效，而且两者背后的 Mini Program 仍然在线。

这只是小规模、局部的干预；对此的回应，却是在两天内从零构建一条替代投递渠道。这个含义值得仔细思考。运营者并未把 Binance 托管的路线视为可随意丢弃；相反，一旦它变得不可靠，他们便认为其价值高到值得立即重建 — 这比我们能提出的任何论证都更清楚地说明了该路线的价值。

防御者应当担心的部分

我们用获取其他页面的相同方式获取了第三轮页面。返回的是 94 KB 的混淆脚本 — 大小接近前一载荷的三倍 — 其中没有表单、没有输入元素，而且完全没有网络调用。相隔数秒的两次请求返回了不同字节，因为页面会为每个请求使用新密钥生成。

其中还包含三项混淆器未能隐藏的具名检查：

isWebDriverPresent
isPhantomOverflow
isPhantomETSL

这些检查会检测浏览器自动化 — 正是安全扫描器使用的工具。我们获取到的并不是攻击本身。它是一道判断您是否为真人的关卡。

由于文件中缺少某些内容，我们可以说得更精确。端到端搜索后，这 94 KB 内容中没有任何形式的 URL — 没有http，没有://，没有任何 dot-com，甚至没有提供该文件的网站名称。也没有网络调用：没有 fetch、没有 XMLHttpRequest、没有 WebSocket。它确实有一个写入 cookie 的例程，以及一个为每次请求重新生成的密钥。

因此，顺序是：页面测量浏览器，把结论写进 cookie，然后重新加载。服务器决定接下来发送什么。攻击并非隐藏在文件内部 — 它根本不在文件里，也不可能在。无论下载该页面的人多么仔细地拆解它，他们研究的都是门卫，而不是门后的房间。

这一点应与普通混淆区分开来。第一轮和第二轮面对一次命令行抓取就交出了整个载荷：端点、收款地址和转换逻辑，全都位于返回给请求者的响应中。第三轮什么也不交出；再耐心地使用反汇编器也改变不了这一点，因为要找的东西从未被发送。

我们可以说明这在实践中意味着什么，因为它发生在我们身上。把这场活动提交给自动化分析服务后，返回结果是未发现威胁，尽管网站仍在线并在提供内容。其中一部分是我们自己的错误，我们已在上文说明。但采用隐藏机制的页面会按设计规避扫描器，而扫描器本身仍如实运作：它准确报告了所看到的内容。

由此得出的指引令人不安，但值得直白陈述：自动检查器给出的干净结果，并不能证明链接安全。它只能证明检查器收到的内容看起来安全。只有在无人刻意欺骗时，这两句话才等同。

什么变了，什么没变

投递已离开 Binance 的基础设施，品牌冒充却没有改变 — 该域名存在的唯一目的就是让人误以为属于该品牌，消息仍在冒充账户通知。诱饵、运营者、服务器和时间特征全都相同。

承载第一轮和第二轮的 Mini Program 标识符在撰写本文时仍然在线。它如今已存活过三轮活动。

为什么本文没有链接

上文每个恶意地址都以去武器化形式书写，且没有一个是超链接。这是刻意为之。把仍有效的钓鱼链接作为可点击锚点发布，会把本文变成重定向，为活动借出我们的一小部分信誉，并要求搜索引擎将两者关联。描述攻击不应扩大其触达范围。

我们与 Binance 没有任何关联。发布本文是因为这项技术可以泛化：官方缩短器、进入受信任应用的深层链接，以及把站点级信任交给任意 URL 的 webview 桥，是可以让任何大型消费级应用呈现的模式。如果您的产品提供链接缩短器、自定义 URL 方案，或接受目的地参数的应用内浏览器，这就是您应当自行检查的链路。