筆電就是入口

10 月 30 日，Binance 揭露了一起「資安事件」，涉及約 63 億美元的資產。The Hacker News 報導，Chainalysis 在事發當時估計竊案金額為 59.12 億美元，將近此前紀錄上最大加密貨幣竊案的四倍。已有將近 30 億美元在鏈上遭到凍結，大部分是 Tether 和 Circle 凍結的穩定幣。Binance 表示會補償所有損失。

Binance 對事件起點的說明只有一句話：「初步調查顯示，這起資安事件可能涉及一名 DevOps 工程師遭入侵的筆電」，攻擊者藉此進入一個服務容器，並提交了未經授權的提領。Binance 表示，沒有發現任何錢包私鑰外洩的證據。它沒有說明那台筆電是怎麼被入侵的。

五十個簽章與三分鐘

鏈上紀錄顯示了這份存取權的價值。UTC 時間 20:20，攻擊者提交了一筆交易，裡面帶著 50 個授權，每一個都由 Binance 的熱錢包簽署，分別對應 50 個連續的交易序號，好讓其中一個剛好對上錢包的下一個序號。每一個都指向一個只聽命於攻擊者的清掃合約。其中一個對上了。大約三分 24 秒後，熱錢包把全部餘額轉給了攻擊者：167,464 ETH 和 63 種代幣，其中包括 16.15 億 USDT。

Blockaid 執行長 Ido Ben-Natan 告訴 Cointelegraph，初步證據指向「金鑰濫用」：簽章系統被引導去簽署攻擊者的交易，根本不需要偷走任何金鑰。金鑰一直待在原處。只是有人拿著那名工程師的存取權，請系統使用了它們。

TRM Labs「以高度信心」將這次攻擊歸咎於 TraderTraitor，也就是 FBI 認定為 2025 年 2 月 Bybit 15 億美元竊案元凶的北韓組織。Chainalysis 同樣指向北韓。Binance 則沒有點名任何人。

這個組織如何進到筆電裡

TraderTraitor 紀錄最完整的一次入侵，說明了它的手法。在 Bybit 一案中，Safe 自己的初步報告和 Mandiant 的調查結果 依序描述了經過：

1. 2025 年 2 月 4 日，一名 Safe 開發者在自己的 Mac 上執行了一個名為 MC-Based-Stock-Invest-Simulator-main 的 Docker 專案。Mandiant 認為這名開發者是被說服去執行的。
2. 這個專案連線到 getstockprice[.]com，一個兩天前才註冊的網域，開發者的 macOS 工作站隨之遭到入侵。
3. 攻擊者取走了開發者的 AWS 工作階段權杖，因此能在不經過多因素驗證的情況下使用開發者的 AWS 存取權。
4. 他們憑著這份存取權，竄改了 Bybit 簽署人所使用的 Safe 介面，簽署人隨後核准了一筆清空冷錢包的交易。

Mandiant 指出，這個組織在先前的竊案中也用過類似、以股票為主題的 Docker 專案。手法從來沒變：給開發者一個專案，讓它以開發者的身分執行，再拿走那台電腦碰得到的東西。一台 DevOps 筆電碰得到的東西很多。上面通常有存著有效工作階段權杖的 ~/.aws、通往正式叢集的 ~/.kube/config、跳板機的 SSH 金鑰，以及 gh 的登入，而工程師啟動的任何行程都讀得到這些。

現在執行專案的是代理

過去的誘餌需要一位能被說服去執行某樣東西的開發者。這一步正變得越來越容易省略。就在 Binance 揭露入侵的同一天，BleepingComputer 報導了 Air Security 對一個名為 SolanaUpdateTools/solana-starter-kit 的 GitHub 儲存庫所做的分析。它有 286 顆星，而且根據 Air 的說法，AI 編碼代理搜尋 Solana 入門套件時，它排在第一名。裡面唯一的檔案就是 README。它承諾提供完整的應用程式範本，只給了一個安裝步驟：貼上一行指令，這行指令會從片段拼出一個位於 developer-update[.]app 的 URL，下載一支腳本，並在記憶體中執行。

Air 取得的酬載會安裝 NetSupport Manager，一套合法的遠端存取工具，並設定成每次登入都連線到攻擊者。接著它會顯示一則假錯誤：開發者功能「因負載過高暫停」，請 72 小時後再試。照著 README 做的代理會執行這行指令，然後回報伺服器忙碌。開發者看不到任何值得多看一眼的東西。

把這個代理放到一位 DevOps 工程師的筆電上，工程師的 kubeconfig 和 AWS 工作階段就在同一個家目錄裡，這個入門套件就成了 Bybit 案中的那個 Docker 專案，只是省去了社交工程。

同一個專案，放進 Bromure Agentic Coding

Bromure Agentic Coding 在你的 Mac 上以 Ubuntu VM 執行 Claude Code、Codex、Grok、Kimi 和 omp。每台機器都是獨立的 VM，代理碰到的一切都在裡面：複製下來的儲存庫、套件快取、Docker 容器，以及 README 建議的每一個指令。你的 Mac 持有真正的憑證、VM 流量必經的代理伺服器，以及事情經過的紀錄。

專案在 VM 裡執行，而不是以你的身分

在 Bromure 機器裡執行那個股票模擬器的 Docker 專案，或讓代理貼上入門套件的指令。容器在 VM 裡啟動，酬載也是。它拿到的是 Ubuntu 客體系統裡的一個 shell，身分是機器的使用者。它拿不到你的 macOS 帳號，也拿不到你的鑰匙圈。你 Mac 上的 ~/.aws、~/.kube 和 ~/.ssh 也不在那裡：Bromure 在你匯入時於主機上讀取這些檔案，從不把它們掛載進 VM。

它找到的金鑰都是替身

接下來，酬載會去找憑證，而 VM 裡有很多看起來都對的。沒有一個能在別處使用。

• AWS. ~/.aws/config 指向一個輔助程式，它交出真正的存取金鑰 ID，搭配一把假的秘密金鑰，而且完全沒有工作階段權杖。VM 用假的秘密金鑰簽署每個請求，Mac 則在請求送往 *.amazonaws.com 的途中，用真的金鑰重新簽署。把 VM 的 AWS 憑證複製到另一台電腦，每次呼叫都會以 InvalidSignatureException 失敗。Bybit 攻擊者取走的那種工作階段權杖，在 VM 裡根本不以任何形式存在。
• Kubernetes. VM 的 ~/.kube/config 是合成的。kubectl 與 Bromure 的代理伺服器溝通，從不直接連到 API 伺服器。Bearer token 是 brm-k8s-… 替身，用戶端憑證是用過即丟的，而像 aws eks get-token 這樣的 exec 外掛是在 Mac 上執行，而不是在 VM 裡。
• SSH. VM 的 SSH_AUTH_SOCK 是通往 Mac 的橋接。客體系統可以請求簽章，私鑰永遠不會離開主機。ls ~/.ssh/id_* 找不到任何可以複製的東西。你 Mac 自己的 ssh-agent 也從不暴露給任何 VM。
• Git. gh 和 ~/.git-credentials 裡的 GitHub 權杖是替身，代理伺服器只在送往 github.com 的請求上，才把它換成真的。

替身同時也是絆線。如果酬載把替身送到自己的伺服器，代理伺服器會在任何一個位元組離開你的 Mac 之前，以 HTTP 451 擋下請求，暫停 VM，並顯示 This environment may have been compromised，指出是哪個憑證、原本要送往哪台主機。在磁碟和家目錄被清除之前，這台機器不會再啟動。你的設定和金鑰都會保留。

正式環境的金鑰聽你的

替身解決了竊取的問題。Binance 一案帶出第二種風險：攻擊者根本不偷存取權，而是直接在它本來就能運作的地方使用它。VM 裡的酬載可以像代理一樣，透過代理伺服器發出請求。這些請求能做什麼，由 Bromure 的 Guardrails 決定，而且是在 Mac 上強制執行，VM 裡的任何東西都改不了。

• Require approval to use，依憑證設定：Kubernetes context、AWS 金鑰或 SSH 金鑰在一個工作階段中第一次被使用時，代理伺服器會攔住請求，在你的 Mac 上詢問你。你可以選擇 5 分鐘、一小時或整個工作階段，或是 Don't allow。對 AWS 來說，這項檢查涵蓋每一次簽署呼叫。在你核准之前就伸手去碰正式叢集的酬載，只會在你螢幕上跳出一個對話框，在有人回應之前什麼都拿不到。
• 寫入政策，依服務設定。新機器對 Kubernetes、AWS、容器登錄庫、git 代管平台和資料庫，一開始都是 Prompt before write：讀取直接放行，每一次寫入都會停在一個顯示確切操作的對話框上。Block destructive 拒絕刪除和終止，Read-only 則拒絕一切變更。只需要讀取正式環境日誌的機器可以設為唯讀，在裡面執行的任何東西都無法變更正式環境。
• Outbound connections，每台機器各自的防火牆。把 Unmatched traffic 設為 Deny，只允許專案需要的主機。入門套件從 developer-update[.]app 的下載、Bybit 專案對 getstockprice[.]com 的呼叫，以及 NetSupport 連回攻擊者的連線，全都落入預設規則而遭到拒絕。

每一次憑證使用、簽章、封鎖和放行，都會記錄在機器的 Security Timeline 中，AWS 簽署呼叫和 SSH 簽章逐筆記錄。Binance 現在正透過一台「遭入侵的電腦」重建攻擊路徑。在 Bromure 中，VM 拿你的憑證做了什麼的紀錄保存在 Mac 上，在攻擊者控制的那台 VM 之外。

讓入門套件遠離正式環境

Bromure 機器建立起來不費事，所以存取權可以分散到不同機器上。憑證是依機器設定的。用來試用新入門套件、帶回家寫的程式測驗或陌生人儲存庫的機器，完全不給正式環境憑證，並配上預設拒絕的防火牆。kubeconfig 和 AWS 角色則留在負責部署工作的機器上，兩者都要求核准。對於不想保留的東西，bromure-cli vm run --rm 會建立一台停止時就刪除的機器。

這樣一來，酬載就算佔領了入門套件的 VM，也找不到任何值得拿的東西：沒有真正的祕密、沒有叢集，也沒有通往你未允許之主機的路徑。部署用的機器從未執行過它的程式碼。

看它上演兩次

我們的教學系列 A Tale of Two Agents 以這起攻擊為靈感。Theo 是虛構交易所 Coinvance 的 DevOps 工程師，他請編碼代理完成獵才顧問寄來的回家作業測驗，而 README 要代理先執行一支安裝腳本。同一個錯誤在分割畫面上演兩次：左邊，代理跑在他的筆電上；右邊，跑在 Bromure 裡。

1. 回家作業（1:24）。在筆電上，腳本把他真正的雲端金鑰、kubeconfig 與部署權杖當成「遙測資料」送出去。在 Bromure 裡，它只找到替身憑證，而當替身憑證被送往錯誤的主機，Bromure 會暫停 VM 並詢問他。
2. 橫向移動（1:18）。有人用 Theo 的 Kubernetes 存取權修改提領服務。右邊，Security Timeline 把被封鎖的請求一路追溯到代理的推理，工作區一鍵即可清除。
3. 二十分鐘（1:02）。左邊，熱錢包被掏空。右邊，沒有任何金鑰需要輪替。

Theo 與 Coinvance 皆為虛構，這幾集並非描述 Binance 實際發生的經過。每一集都有八種語言的旁白。

開發者的電腦是正式環境的一部分

Binance 的提領服務正因「安全改造」而停機，預計 48 小時內恢復，而它的完整分析會進一步說明那台筆電是怎麼被碰到的。Bybit 早已讓所有人看清這個模式。想要一家公司正式系統的攻擊者，會去找營運這些系統的工程師的電腦，而在大多數這樣的電腦上，正式環境的存取權就放在家目錄裡的幾個檔案中。

你的編碼代理讓這個缺口變得更大。它在一個又一個任務中複製、安裝並執行陌生人的程式碼，貼上 README 指令的速度比你還快。在 Bromure Agentic Coding 中，程式碼在只有替身的 VM 裡執行，而正式環境的存取權留在 Mac 上，擋在一個你必須回應的對話框後面。

關於一個完全不需要攻擊者伺服器的權杖竊取行動，請閱讀被竊的權杖不需要伺服器。關於一個從下載檔案接受命令的代理，請閱讀下達命令的是那個下載檔。