電話是從幫助台內部打來的

4 月 24 日,BleepingComputer 報導了一個出於經濟動機的攻擊集群,Palo Alto 的 Unit 42 把它追蹤為 CL-CRI-1116,也叫 BlackFile,也叫 UNC6671;CrowdStrike(個別地、但很可能是同一夥人,至少是表親)稱之為 Cordial Spider。分類學一團亂。行為則不然。

下面是那行為,按它發生在你身上的順序:

1. 你接到一通電話。來電顯示是公司內部 IT,或者夠接近——偽造的 VoIP,或具有欺騙性的 CNAM(電話網路在號碼旁顯示的人類可讀名稱,事實證明它的驗證並不算特別嚴格)。電話另一端的人友善而略帶歉意。他非常抱歉打擾你。你的帳號有個小問題。
2. 為了解決你帳號上的小問題,他希望你登入一個公司頁面,他會用簡訊把連結傳給你,有時則直接口頭引導你過去。頁面看起來很對。它有公司商標。措辭也對。它不是那個對的頁面。
3. 你輸入密碼。頁面要求輸入你驗證器的一次性驗證碼。你也輸入了。
4. 頁面說了聲謝謝,可能還顯示一個轉圈圈的載入圖示。你掛了電話。
5. 攻擊者在他自己的某台筆電上、在某個其他地方,用你剛輸入的密碼和你剛輸入的六位數代碼,在接下來的九十秒內登入你真正的 SSO 入口,然後——這是優雅的部分——在你的帳號上註冊他自己的 MFA 裝置。
6. 他現在就是你了。他口袋裡有一個永久的第二要素。你的第二要素也仍然有效,所以沒人會注意到。
7. 他打開 Salesforce、打開 SharePoint,搜尋檔名或內容裡帶有「confidential」或「SSN」字樣的檔案,把能下載的全都下載走。一週後,你的 CEO 會收到一封來自某個 Gmail 信箱、寫著七位數贖金的信。有時,根據 BleepingComputer 的報導,員工還會收到 swatting 威脅,這是大多數勒索集團懶得提供的一種「客戶服務」水準。

總之。

攻擊究竟發生在哪裡

值得精確地搞清楚這條鏈條的每一段在哪裡執行,因為整條鏈並不在同一個地方。

電話走的是電話。電話是電話的形狀。任何瀏覽器、任何筆電、任何你能更新修補的作業系統,都對電話本身做不了什麼,因為電話不在筆電上。(你可以訓練人員,可以在休息室張貼提醒,可以讓真正的幫助台在每次合法通話後再寄一封後續信件,這些都有幫助。但電話,正如業內所說,是一個「人形」的問題。)

偽造的登入頁面在瀏覽器裡執行。具體來說,它在那位員工此刻在工作筆電上恰好打開的任何一個瀏覽器、她最後使用的任何一個設定檔裡執行,帶著她碰巧隨身攜帶的任何工作階段、Cookie 和儲存的密碼自動填入。這一段是個「電腦形」的問題。

針對真正帳號的 MFA 註冊,在攻擊者的筆電上執行,在他的瀏覽器裡,對著合法的 SSO 入口。這完全不是使用者瀏覽器的問題;這是個關於 SSO 入口在某人擁有密碼和當前 OTP 時,如何處理 MFA 註冊的問題。你的 IdP(運行 SSO 的身分提供者——Okta、Entra ID、Google Workspace,任何一家判定你密碼正確的)把「我有密碼和一個新鮮的 OTP」當成足以新增另一個要素的證明。這是政策上的選擇,也是大多數企業預設出貨時所採用的政策,因為換一種做法就意味著使用者在更換手機時把自己鎖在門外。

對 Salesforce 和 SharePoint 的資料外帶同樣在攻擊者的筆電上執行,對著你真實的 SaaS,使用他剛鑄好的第二要素。嚴格意義上,這一段並不是「對員工瀏覽器的攻擊」。這只是攻擊者像普通人一樣登入,因為這時他就是普通人。在最後三步裡,你員工的瀏覽器只是袖手旁觀。

所以,如果你想找一根可以從頭到尾阻止 BlackFile 的技術槓桿——並沒有這種東西。這場攻擊分散在一支電話、一個偽造頁面、一項 IdP 政策,以及一台攻擊者筆電上。

存在的——也是瀏覽器廠商唯一能可信地說上話的鏈段——是第二步,即偽造的登入頁面。這個頁面必須在某處被算繪。無論它在哪裡被算繪,員工都會在裡面輸入真實的憑證和真實的 OTP。所以問題只是:你想讓這件特別的事發生在什麼樣的容器裡?

頁面必須在某處被算繪

對。所以頁面在某個瀏覽器裡被算繪。是哪一個?

如果你什麼都不做,它就會在那位員工恰好正在用的任何瀏覽器裡算繪——個人筆電上的 Chrome、公司筆電上的 Edge、手邊那台 iPad 上的 Safari。不管是哪一個瀏覽器,它都已經被使用一段時間了。它有一個用了一段時間的設定檔。這個設定檔裡很可能已經存有真正的公司 SSO 入口的 Cookie,因為這位員工每天早上上班都要登入。它有儲存的密碼。它會貼心地給出一個自動填入建議——內容剛好就是真正的公司密碼——只是在釣魚網域上,自動填入會正確地不觸發(瀏覽器在這一點上還算可靠),所以使用者只能手動輸入,而這她也很在行,因為她已經做過一萬次。

偽造的頁面並不需要那些 Cookie 中的任何一個。偽造的頁面只需要使用者的手指繼續做「頁面要求輸入密碼時手指會做的事」。偽造的頁面收走密碼。偽造的頁面收走 OTP。偽造的頁面就完事了。

不過有個問題一直縈繞在我心裡。為什麼員工的個人瀏覽器——帶著它那個用了很久的設定檔,以及她登入過的每一個網站的合集——會一開始就成為偽造企業登入頁面被算繪的地方?這個頁面聲稱自己是公司的。使用者人在工作。從使用者的角度看,她正在做工作上的事。為什麼「公司登入頁面」會和「表妹的 Spotify 分享連結」「2018 年的某個 Etsy 帳號」在同一個軟體環境裡算繪?

我想,這就是關鍵問題。

把「受管理瀏覽器」的論點縮到最小

下面是 Bromure 對這次攻擊,小而窄、又誠實的版本論點。

IT 部門可以把 Bromure 部署為指定的企業瀏覽器。它不是筆電上的唯一瀏覽器——使用者仍然可以保留 Chrome 和 Safari 用於個人瀏覽——而是唯一一個被設定過、被加入管理、並且被顯眼地標示為「企業 SaaS 該住在這裡」的瀏覽器。Bromure 在設定裡有一個 Enterprise 分頁,它的全部職責就是這件事:一個 HTTP 代理欄位,以及一個給內部根憑證的位置。兩項設定。它就只做這些,而且故意只做這些。組織把這兩樣設定一次,把預設定好(信任公司 CA、並通過公司代理路由)的 Bromure 設定檔交給員工,讓這個設定檔顯眼地成為企業 SaaS 落腳的地方。

(我們並沒有聲稱 Enterprise 分頁是一個完整的 MDM 控制平面。它就是兩個文字方塊。兩個挑得好的文字方塊,有時就夠了。)

在 Bromure 內部,每個分頁都是它自己的一次性 Linux 虛擬機,有自己短暫的設定檔。所以當公司的 Salesforce 分頁打開時,它會在一台知道公司代理、信任公司 CA 的受管理虛擬機中打開。當員工另外打開她表妹的 Spotify 分享連結時,那個分頁會在一台不同的虛擬機、用一個完全沒有這些設定的不同設定檔中打開。

現在,電話仍然以完全相同的方式進來。使用者仍然被引導到一個連結。變化的是這些:

• 那個連結被點開時,它會在某一台 Bromure 虛擬機裡打開。預設情況下,它不會在和員工真實 Salesforce 工作階段相同的那台虛擬機裡打開。(Bromure 的設定檔不會悄悄合併。一個載入在「拋棄式連結」設定檔裡的頁面,沒辦法讀取「公司 Salesforce」設定檔的 Cookie,因為它們活在不同的虛擬機裡,帶著不同的網路堆疊和不同的硬碟。)
• 使用者仍然可能把真實的公司憑證和真實的 OTP 輸進那個頁面。**Bromure 不會阻止打字。**這是誠實的部分。
• 那個頁面捕獲到的工作階段權杖(或者依釣魚套件的不同,有時只是 Cookie)生活在一個使用者即將關閉的設定檔裡、一台即將被擦掉的虛擬機裡,和任何企業資源都沒有特權關係。在這個意義上,被截到的權杖品質很低——它只是從一個分頁裡帶出來的紀念品。

關於這最後一點,我想小心一些,因為這正是容易吹過頭的那種話。

在已被記載的 BlackFile 鏈條裡,被截獲的權杖實際上並沒有被拿來登入真正的 Salesforce——攻擊者用的是憑證和 OTP,從他自己的筆電上登入到真正的 SSO 入口,然後註冊他自己的 MFA 裝置。被截獲的 Cookie 反正也不會被回放到真正的公司工作階段上,因為它們是釣魚網域的 Cookie,而不是真正網域的。Bromure 按虛擬機隔離真正派上用場的地方,是偽造頁面之後的那一段:任何分頁端的搗蛋(把權杖偷走送到攻擊者端點、試圖讀取其他 Cookie 的後續腳本、丟下額外載荷的轉址鏈)都會被關在一台虛擬機裡,這台虛擬機的檔案系統、網路與行程樹,都和筆電的其他部分以及真正的公司瀏覽器工作階段被徹底隔開。偽造的頁面就是偽造的頁面。它只是被允許在一個盒子裡做偽造的頁面而已。

特別是這個可見提示,它在這張圖裡承擔了大量的工作,值得大聲說出來。一個受管理的瀏覽器部署,如果它唯一的功能只是「公司的 Salesforce / SharePoint / Workday 分頁,在視覺上,跟隨便點開的連結分頁明顯不一樣」,光這一點本身就已經是非小事的防禦。因為典型的 BlackFile 受害者,是某個星期四下午 4:45 接到電話的、疲憊的人。這個可見的區別不是 UI 的小花樣;它就是整場比賽。

這不會解決的事

我想繼續在這件事上保持誠實,因為這裡的失敗模式,是某個廠商先告訴你「我們的產品本來就能擋下這次攻擊」,你仔細一讀,發現他描述的是另一種攻擊。

**它不會讓電話停下來。**電話在電話上。Bromure 不在電話上跑,看不到電話,也不對電話有任何意見。如果使用者接起電話,被一個友善的聲音說服她帳號上有個小問題,她就會去看一個偽造的登入頁面。我們能改變的是頁面在哪個瀏覽器裡算繪。我們改變不了她到底要不要去看。

**它不會讓打字停下來。**如果使用者把真實的憑證和真實的 OTP 輸進偽造頁面,不管頁面是在哪裡被算繪的,這些憑證和 OTP 現在都在攻擊者手上。頁面跑在一台一次性虛擬機裡,這個事實沒辦法讓使用者剛剛輸入的內容自動消失。

**它不會阻止 MFA 註冊。**MFA 註冊這一段在攻擊者的筆電上發生,對著合法的 IdP。Bromure 沒有在攻擊者的筆電上跑,Bromure 也不是 IdP。這裡的緩解措施在 IdP 那一側,而且非常無聊:打開「新 MFA 註冊要求強化驗證」、把註冊行為限制在公司網路或受管理裝置上、對新增要素註冊發出告警,並且接受這個代價——使用者在換手機時會把自己鎖在門外。這是今天每一個 Okta 與 Entra ID 管理員都可以做出的設定選擇,而許多管理員並沒有這麼做,而這——說得客氣點——才是這個故事裡更應該讓 CISO 失眠的部分,而不是瀏覽器的部分。

**嚴格意義上,它也無法擋下即時的 AiTM 代理攻擊。**另一類釣魚套件(Evilginx、Modlishka、Caffeine,以及那些每次出租 2,500 美元的 AiTM-as-a-service,如今已成為針對 Microsoft 365 的主流攻擊模式)採用即時轉發路線:使用者輸入的頁面會即時把請求代理到合法的 IdP;IdP 發出的工作階段 Cookie 走到代理那裡,代理再把它遞給攻擊者。如果你想像一下 BlackFile 風格的電話把使用者引向那種頁面——這並不是 BlackFile 目前被描述的樣子,但這一類攻擊正朝那個方向發展——那麼被截獲的 Cookie 就是合法 IdP 發出的真正的工作階段 Cookie,問題就變成它能不能從別的地方被回放。那是另一篇文章了,而且是更難的一篇,誠實的回答涉及工作階段綁定相關的控制(DBSC、mTLS 綁定的權杖),而這些大多是 IdP 的工作,只有一部分是瀏覽器的工作。我們不打算對那一塊揮魔杖。

受管理的 Bromure 實際上做的、範圍窄一點的事是:讓偽造頁面在一個未受管理的、短暫存在的、並且和受管理企業環境視覺上有明顯區別的地方算繪。它把套件可能在頁面之後玩的把戲(擴充功能安裝、對宿主檔案系統的寫入、持續性)的爆炸半徑,限制在一台正要消失的虛擬機之內。在 BlackFile 被描述出的那條鏈上,它本身並無法阻止攻擊者繼續去註冊自己的 MFA 裝置——那是 IdP 的工作。我們緩解的是這條鏈上四台機器中的一台,而那是我們唯一在跑的那一台。

為什麼,從長期來看,這是唯一的路

總之。哎,你想想看。退一步看。

BlackFile 真正讓人印象深刻的地方,是它是一門效率驚人的生意。他們挑零售與飯店業,因為零售與飯店業有大量員工、分散的班次、夜班排班,有真正會主動打給員工的 IT 幫助台團隊,以及一大群壓力極大、絕對不想成為「收銀台癱瘓原因」的員工。他們挑語音釣魚,因為語音釣魚能規模化(電話另一端的一個人,一個小時可以打十幾個目標,而成功率以這個產業的標準來說已經高到誇張),也因為電話是這條鏈上你沒辦法打補丁的那一段。他們去抓憑證和 OTP,是因為憑證和 OTP 在 2026 年仍然是大多數企業的正門——儘管已經過了十年的演講在解釋為什麼不該如此。

瀏覽器能影響的鏈段很小。它是四台機器中的一台。你不應該因為一款瀏覽器宣稱從頭到尾擊敗了 BlackFile 而去買它。你應該買一款瀏覽器,是因為它能把它能做好的那一件事做好——把企業工作階段留在一個受管理的、可辨識的地方,把「隨便點開的連結」工作階段留在一個一關閉就不復存在的地方——然後再把它和那些無聊、不性感的 IdP 側控制配合起來,真正把這個圈合上。

電話還會響。頁面還會載入。問題只是,它究竟在哪裡載入,載入時它身邊有些什麼。事實證明,這一點是你可以改變的。

來源:

• BleepingComputer — New BlackFile extortion gang targets retail and hospitality orgs (2026-04-24)
• CrowdStrike — Cordial Spider adversary profile
• Help Net Security — Attackers use AiTM phishing kit, typosquatted domains to hijack AWS accounts (2026-03-10)(用以引用更廣的 AiTM-as-a-service 市場背景,而非具體指 BlackFile)