用真正 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——那個比每一個網域都活得更久的元件，也是這篇分析講的是機制而不是三個位址的原因。威脅指標中點名的兩個 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 方案，或接受目的地參數的應用程式內瀏覽器，這就是您應當自行檢查的鏈路。