微軟在本週公布了一條九階段的攻擊鏈：一封來自假冒 IT 服務台的 Teams 訊息、一場 Quick Assist 遠端協助工作階段、一個透過已簽章廠商執行檔進行的 DLL 側載、橫跨網路的 WinRM、再由 Rclone 把資料外傳到攻擊者的雲端儲存空間。這九步當中，有八步都需要主機作業系統是一台真正的桌面電腦。一個跑在可隨時丟棄的虛擬機裡的瀏覽器分頁，不是那種東西。

在 2026 年 4 月 20 日，微軟的威脅分析團隊公布了一條九階段攻擊鏈的完整拆解——目前已有多個勒索軟體關聯組織在實戰中使用這條鏈。開場的一步是社交工程：一則訊息從外部租戶落到 Microsoft Teams 裡，來自某位自稱是 IT 的人，請求目標開啟一場遠端支援工作階段，理由是要處理「一個帳號問題」或是「安裝一個安全性更新」。收尾的一步是金錢：Rclone，一款合法的雲端同步工具，把檔案伺服器的內容串流到攻擊者控制的物件儲存空間，與此同時勒索軟體再把留在本地的東西加密掉。

微軟的原話值得直接引用：「威脅行為者正越來越頻繁地濫用外部 Microsoft Teams 協作，假冒 IT 或服務台人員，說服使用者授予遠端協助存取權。」 這裡的新意不在社交工程——假冒服務台這件事，幾乎和服務台本身一樣古老——而在於投遞面。Teams 是那款裝在每一台公司桌面電腦上、隨時處於登入狀態、開機就自動啟動、而且有一套通知 API 讓外部訊息看起來跟內部訊息一模一樣的協作程式。在 2026 年，它是一條比電子郵件更好的釣魚管道。

這條鏈，從頭到尾。

以下是這九個階段在一台 Windows 機器上實際上在做什麼。編號是微軟給的；用大白話寫的描述是我們的。

微軟所記錄的那條鏈。第 1 階段是一則從公司聊天工具裡、由陌生人送來的訊息。第 2 到第 9 階段，則是在 Windows 主機上依序進行的一連串操作——Quick Assist、PowerShell 偵查、由一支已合法簽章的 Adobe 或 Autodesk 執行檔載入的 DLL、橫跨網域加入機器的 Windows Remote Management，以及用 Rclone 把檔案伺服器外傳。勒索軟體的加密，是在資料已經外流之後才發生。

這條鏈既有效率又無趣——這就是 2026 年一份好的勒索軟體作案手法該有的樣子。這裡沒有任何零時差漏洞。Quick Assist 是微軟自家隨 Windows 一起出貨的遠端支援工具。PowerShell 是微軟自家的系統管理 shell。DLL 側載——把一個攻擊者控制的函式庫放在一支合法簽章的程式旁邊，讓那支已簽章的程式去載入惡意程式碼——這手法已經有二十年歷史。WinRM 是網域系統管理員理應用來管理整個 Windows 機群的方式。Rclone 是一款開源雲端同步工具，從 Homebrew 就可以安裝。整場攻擊，是由受支援的、有簽章的、IT 部門自己祝福過的原語所組成的。這也正是傳統端點工具難以偵測它的原因：每一個個別步驟看起來都像是 IT 團隊刻意在做的事。

正面主張：在第一步就把這條鏈斷頭。

現在請想像一下，如果這條鏈的第一步，不是一則通知彈出在原生 Windows 桌面用戶端上，而是一則通知彈出在一個瀏覽器分頁裡，同一條鏈會變成什麼樣子。在一個 Bromure 瀏覽器分頁裡。在一台可隨時丟棄的 Linux 虛擬機裡——它沒有持久磁碟、沒有加入網域、沒有任何 Windows 執行檔、沒有 WinRM 監聽器、沒有 Rclone、沒有能被側載注入的 Adobe Reader、和主機也沒有共享的檔案系統，而且在視窗關閉時它就會被銷毀。

第 1 階段仍然會落地。那個外部 Teams 租戶仍然可以送出那則 DM。使用者仍然會看到那則訊息。社交工程的壓力依然在。Bromure 沒有任何機制可以阻止一個自稱是服務台的陌生人，在聊天視窗裡敲下「我需要在你的電腦上安裝一個安全性更新，我要開啟一場 Quick Assist 工作階段」這樣的字。

但它會在第 2 階段停下來。這個瀏覽器分頁沒辦法啟動 Quick Assist，因為 Quick Assist 是一個原生 Windows 執行檔，而這個分頁是一個 Chromium 視窗，跑在一台沒有安裝 Quick Assist、無法安裝 Quick Assist、也沒有任何 IPC 管道可以連到另一端那台跑著 Bromure 的裝置上的 Windows 機器的 Linux 虛擬機裡。而因為整條鏈是嚴格依序進行的——每一個後續階段都需要前一階段留下的成果——在第二步就被斷頭，也就意味著第 3 到第 9 階段永遠都發生不了。

同一條鏈，在兩種使用者習慣下分別看起來的樣子。上方：Teams 以原生桌面用戶端的形式跑在主機作業系統上——每一階段都有它所需要的東西。下方：在 Bromure 分頁裡開啟 teams.microsoft.com 的 Teams——第一階段落在這個短命的虛擬機裡，它之後的每一階段，都是這個虛擬機結構上做不到的事。

這張圖有一種讀法很誘人，但太強了：「用 Bromure，就對勒索軟體免疫了。」這不是我們要主張的。我們的主張窄得多，而這個比較窄的版本，既更誠實，也更有用。

這條邊界實際上是什麼。

這裡真正在做事的東西，不是什麼聰明的、針對 Teams 的過濾器。它是 Bromure 執行網頁內容的方式本身的一項結構性特性。在 Bromure 裡，每一個分頁都跑在它自己、可隨時丟棄的 Linux 虛擬機裡，這台虛擬機位於你的 Mac 上。使用者看到的瀏覽器是 Chromium，跑在那個 Linux 客端裡。這個分頁的邊界是那台虛擬機。主機的邊界是 hypervisor。當你關閉分頁時，虛擬機就被銷毀。當你開啟一個新分頁時，一台新的虛擬機會從一份乾淨的磁碟映像檔被建立出來。

這條邊界落在哪裡。那個假冒服務台的人，能夠在聊天視窗裡敲字（第 1 階段）。在那之後的每一階段，都需要在 macOS 主機上做動作——啟動一個原生執行檔、寫入一個能持久保存的檔案系統、橫跨區網做橫向移動。Hypervisor 邊界，就介於攻擊者和所有這些東西之間。聊天視窗在這邊；攻擊者想用的那整套服務台工具組，在另一邊。

當攻擊者在第 2 階段說「接受我的 Quick Assist 工作階段」時，他們要求使用者去觸發的那個機制，在邊界的另一側根本不存在。Linux 客端裡沒有 Quick Assist。沒有任何方式可以讓一個網頁——即使是使用者完全信任的網頁——從客端伸手到主機裡去啟動一個 macOS 或 Windows 原生執行檔。這裡沒有這樣的橋樑；如果有，這整個架構就完全失去意義了。攻擊者的這條鏈，仰賴一套能力——啟動原生應用程式、寫入可持久保存的檔案系統、在已簽章的廠商執行檔旁邊載入 DLL、開啟 WinRM 工作階段、讀取主機憑證——而這台分頁虛擬機，在設計上一個也沒有。

這並不是我們為了應付 Teams 服務台威脅特別加上的功能。它和讓 Bromure 在瀏覽器零時差漏洞、惡意擴充功能、以及一般的資訊竊取器面前依然有用的，是同一個屬性。這條鏈裡，只有第 1 階段在乎使用者點了什麼。在那之後的每一階段，都需要使用者的桌面。把瀏覽器放到一台不同於桌面的電腦上，這條鏈就不再是關於使用者的決定，而開始變成關於這台機器的架構。

這件事解決不了什麼。

如果同一位使用者還裝了 Microsoft Teams 的原生桌面用戶端——macOS 上的 Microsoft Teams.app，或者 Windows 的桌面用戶端，兩者都跑在 Bromure 外面，都以同一個使用者帳號登入——那麼那則外部租戶的 DM 會落到主機上。到這一步，我們就回到了圖上那第 A 列的情境。第 1 階段成了一則原生通知。第 2 階段，是使用者在他真正的桌面上接受一場 Quick Assist 工作階段。分頁虛擬機從頭到尾都沒有進入這個故事。Bromure 沒辦法保護那些不跑在 Bromure 裡的東西。

同理：如果組織的 IT 政策是在租戶層級封鎖外部 Teams DM——這也是微軟的報告所建議的——那麼在兩種世界裡，第 1 階段都根本不會抵達使用者，這裡的架構討論也就無足輕重。這才是正確的第一道修補。Bromure 是針對以下情境的一道防線：第一道修補沒被套用、或使用者用的是個人裝置、或政策留了例外、或攻擊者找到了一個沒強制執行這條政策的租戶。

這個瀏覽器習慣改變了什麼

在 Bromure 分頁裡以 teams.microsoft.com 開啟 Teams，會把第 1 階段搬進你 Mac 上的一台短命 Linux 虛擬機裡。即使你點下了那個冒牌服務台送來的「接受支援」連結，他們想用的那個工具也不會在這個點擊落下的地方。這個要求會失敗，因為那個能力根本不存在。

原生用戶端不會改變的事

如果你已經裝了 Teams 桌面程式、而且已經登入，那則 DM 就會送到那裡，主機會完全像微軟所描述的那樣暴露出來。移除桌面用戶端，或是把它限縮到一台專用的工作機上，這是 Bromure 讓你有條件做出的行為改變——而不是它強加給你的。

Bromure 擋不住的事

一位被說服在 Bromure 分頁裡的表單中輸入公司密碼的使用者，仍然會把那組密碼丟出去。瀏覽器的反釣魚掃描會嘗試攔下那個表單，但一個決心夠強的社交工程目標，可以破解任何這類守門機制。憑證釣魚和 VM 邊界防禦，是兩個不同的問題。

這個主張誠實的樣子

對一位工作習慣是在瀏覽器裡用 Teams 的使用者而言，Bromure 把一個九步的入侵變成了一場一步就結束的對話。對一位工作習慣是用原生用戶端的使用者而言，Bromure 對這場攻擊一點改變也沒有。寫出這篇文章、而不是一篇更短、更高聲的文章，整個重點正在這裡。

為什麼這個瀏覽器習慣值得守。

大多數公司聊天工具——Teams、Slack、Discord、Zoom——同時以原生桌面應用程式和同一個網址下的網頁應用程式兩種形式出貨。對大多數人在裡面做的絕大部分事情來說：讀訊息、寫訊息、搜尋、附加檔案、接聽通話，網頁版的功能已經完整。網頁版不會開機自動啟動。網頁版不會在主機上維持一支可以被攻擊者探測的常駐程序。網頁版也不會帶著一條更新管道——而這條管道在過去，本身就曾是供應鏈攻擊事件的媒介。而且，只有當這個瀏覽器是 Bromure 時，網頁版還有另一個獨特的性質：它住在一台和使用者真正那台機器沒有共享檔案系統的電腦裡。

這裡的主張不是說每一位使用者都應該明天就把 Teams 桌面程式解除安裝。而是：網頁優先這個選項一直都在、多年來已經默默地可接受，而在微軟於 4 月 20 日描述的這件事之後——對任何並不特別需要桌面用戶端獨有功能的使用者來說——它實質上已經成為更安全的那個選項。Bromure 讓這個選擇變得有意義。一場在一般 Chrome 視窗裡跑的網頁 Teams 工作階段，仍然是一場和你 Mac 上每一支其他程式共享檔案系統的工作階段。一場在 Bromure 分頁裡跑的網頁 Teams 工作階段，則不是。

一個故事，以及它改變了什麼。

微軟這份九步報告不會是同類型中的最後一份。這個形狀——外部社交管道 → 遠端存取工具 → 偵查 → 已簽章執行檔的常駐化 → 橫向移動 → 外傳——就是目前大多數由人工操作的勒索軟體入侵的形狀，不管它們是從哪一款聊天工具開始的。協作用戶端，是新的電子郵件收件匣。「點擊以接受支援工作階段」，是新的「點擊以啟用巨集」。在那之後真人敲鍵盤做的事，才是攻擊本身。

如果使用者的日常工作在一台聊天用戶端和檔案伺服器共用同一個作業系統的機器上進行，那麼攻擊者只需要在那個作業系統裡踏進一隻腳，就能做完剩下的八步。如果使用者的日常工作在一個跑在聊天用戶端逃不出去的虛擬機裡的瀏覽器中進行，那麼攻擊者就需要一整套不同的原語才能完成這份工作——而這些原語，是當前這一代勒索軟體劇本裡沒有的。

那不是免疫。那是在第一步就斷頭。裝上 Bromure，盡可能用它裡面的 teams.microsoft.com 來取代原生用戶端，處理你工作聊天中可以這樣做的那部分，然後讓下一條九步鏈，去變成攻擊者的問題吧。