結構性盲點，而非偵測不力
問題不在於端點偵測與回應（EDR）工具「調得不夠好」。根本原因在於，EDR 的設計前提是：威脅會以處理程序、可執行檔與系統呼叫的形式出現，因而投入全部精力去監控這些層面。然而，今天的企業工作場景早已大量集中在瀏覽器裡——郵件、雲端文件、身分驗證、客戶資料全在分頁（tab）之內。當攻擊者鎖定的不是機器，而是瀏覽器中的那一場 session，EDR 的觀測面本來就沒有覆蓋到那裡。
近期 BleepingComputer 刊出的分析把這個缺口講得相當直接：瀏覽器型攻擊往往不產生任何端點上的可疑跡象——沒有惡意軟件、沒有權限提升、沒有異常的處理程序樹（process tree），甚至連一次合法的登入都不會被標記為可疑，因為它本來就是合法的。這是一個結構性的偵測缺口，不是單純的設定問題。
值得先說明出處：該分析來自 NordLayer，一家銷售網絡與存取安全產品的廠商。換言之，「EDR 存在盲點、瀏覽器層控制可以補上」這個論述，帶有明確的商業利益。也因為如此，讀者需要知道它並非一則新聞事件——文中沒有 CVE、沒有公開披露的事件報告，也沒有研究機構的新發現。它是一份對已知問題的框定與整合，而不是一個新的研究結果。不過，文中所述的幾類手法——session 與 OAuth token 竊取、惡意擴充功能活動、以及能夠繞過一次性密碼的 adversary-in-the-middle（AiTM）釣魚——本身在資安社群中早有獨立且廣泛的紀錄，因此這篇分析的價值不在於提出新分類，而在於把既有資料整理成一個可用的視角。
三條讓端點遙測「看不見」的路徑
第一，也是後果最嚴重的一條：session 與 token 竊取。攻擊者取得有效的登入憑證——例如 OAuth 授權的 token 或 session cookie——之後重播（replay），整個過程對 EDR 而言完全合法。AiTM 釣魚之所以值得特別注意，正是因為它同時竊取了使用者當下的 OTP，使多因素驗證在事後也失去意義。這條路徑的關鍵啟示是：單靠裝置狀態（device posture）已不足以建立信任——身分層級的關聯分析與瀏覽器層遙測，才是偵測這類事件的必要條件。
第二，惡意瀏覽器擴充功能。擴充功能執行在瀏覽器的信任邊界內，端點的程式允許清單（native-app allowlist）管不到它，EDR 也看不到它對頁面內容做了什麼。值得注意的是，擴充功能清單在多數企業中經常不完整，或根本缺乏治理機制——沒有盤點，也就不會有人在審視這些擴充功能究竟能取用哪些資料。與其說這是偵測問題，不如說是治理問題：盤點、允許清單與權限審核，才是把這條路徑堵上的起點，而不是指望更強的 EDR。
第三，使用者層面的操控。攻擊者把合法的瀏覽器介面、通知與流程當作誘餌，使用者交出驗證時，一切看起來都是正常的。這類手法不需要繞過任何控制，也不依賴技術漏洞——它針對的是流程與人的環節。
實務檢查清單：把瀏覽器納入可見範圍
對 IT 與資安團隊而言，與其期待 EDR 擴充到瀏覽器內部，不如主動補上瀏覽器層與身分層的控制。以下是不分產品、可直接對照內部現況的檢查清單：
- 擴充功能盤點與審核：建立企業瀏覽器擴充功能清單，只允許經核准的擴充功能安裝，並定期審視其權限與更新。
- 強化 Cookie 與 session 設定：確保
SameSite、HttpOnly、Secure屬性到位，並在身分提供者（IdP）層設定較短的 token 有效期與登出即撤銷（revocation）。 - 身分層異常偵測：將登入地點、裝置、時段等訊號與 SIEM 關聯，而不只依賴端點遙測。
- 企業資料隔離：避免企業資料出現在個人瀏覽器 profile，必要時導入瀏覽器隔離（browser isolation）或資料外洩防護（DLP）控制。
- 日誌補強：確認 EDR 以外，還有瀏覽器與 IdP 層的事件可供稽核。
- 驗證渠道：對任何要求轉帳或提供憑證的對話，一律改用獨立驗證渠道確認。
業界整體的方向，其實早已與此一致：從依賴一次性密碼，轉向抗釣魚驗證（FIDO2、passkeys），甚至進一步透過 device-bound session credentials 把 session 綁定在裝置上，讓單純重播 cookie 不再奏效。需要釐清的是，瀏覽器層的控制與這條趨勢是互補而非替代的關係——前者縮小盲點，後者則從根本上改變 session 被重播的前提，兩者解決的問題不同。
對金融與受監管行業的一般意義
這篇分析並未點名特定地區的金融機構，也沒有援引任何監管要求；對香港與亞太區的財金行業團隊而言，它的啟示是普遍性的：當大量敏感流程已經跑在瀏覽器裡，而端點遙測對此結構性失明，那麼「我們有部署 EDR」就不再等同於「我們看得見攻擊」。真正需要回答的問題是：瀏覽器裡發生的事，現在有誰在看？
這一點，才是該分析留給所有企業 IT 團隊最實際的功課。
結構性盲點，而非偵測不力
問題不在於端點偵測與回應（EDR）工具「調得不夠好」。根本原因在於，EDR 的設計前提是：威脅會以處理程序、可執行檔與系統呼叫的形式出現，因而投入全部精力去監控這些層面。然而，今天的企業工作場景早已大量集中在瀏覽器裡——郵件、雲端文件、身分驗證、客戶資料全在分頁（tab）之內。當攻擊者鎖定的不是機器，而是瀏覽器中的那一場 session，EDR 的觀測面本來就沒有覆蓋到那裡。
近期 BleepingComputer 刊出的分析把這個缺口講得相當直接：瀏覽器型攻擊往往不產生任何端點上的可疑跡象——沒有惡意軟件、沒有權限提升、沒有異常的處理程序樹（process tree），甚至連一次合法的登入都不會被標記為可疑，因為它本來就是合法的。這是一個結構性的偵測缺口，不是單純的設定問題。
值得先說明出處：該分析來自 NordLayer，一家銷售網絡與存取安全產品的廠商。換言之，「EDR 存在盲點、瀏覽器層控制可以補上」這個論述，帶有明確的商業利益。也因為如此，讀者需要知道它並非一則新聞事件——文中沒有 CVE、沒有公開披露的事件報告，也沒有研究機構的新發現。它是一份對已知問題的框定與整合，而不是一個新的研究結果。不過，文中所述的幾類手法——session 與 OAuth token 竊取、惡意擴充功能活動、以及能夠繞過一次性密碼的 adversary-in-the-middle（AiTM）釣魚——本身在資安社群中早有獨立且廣泛的紀錄，因此這篇分析的價值不在於提出新分類，而在於把既有資料整理成一個可用的視角。
三條讓端點遙測「看不見」的路徑
第一，也是後果最嚴重的一條：session 與 token 竊取。攻擊者取得有效的登入憑證——例如 OAuth 授權的 token 或 session cookie——之後重播（replay），整個過程對 EDR 而言完全合法。AiTM 釣魚之所以值得特別注意，正是因為它同時竊取了使用者當下的 OTP，使多因素驗證在事後也失去意義。這條路徑的關鍵啟示是：單靠裝置狀態（device posture）已不足以建立信任——身分層級的關聯分析與瀏覽器層遙測，才是偵測這類事件的必要條件。
第二，惡意瀏覽器擴充功能。擴充功能執行在瀏覽器的信任邊界內，端點的程式允許清單（native-app allowlist）管不到它，EDR 也看不到它對頁面內容做了什麼。值得注意的是，擴充功能清單在多數企業中經常不完整，或根本缺乏治理機制——沒有盤點，也就不會有人在審視這些擴充功能究竟能取用哪些資料。與其說這是偵測問題，不如說是治理問題：盤點、允許清單與權限審核，才是把這條路徑堵上的起點，而不是指望更強的 EDR。
第三，使用者層面的操控。攻擊者把合法的瀏覽器介面、通知與流程當作誘餌，使用者交出驗證時，一切看起來都是正常的。這類手法不需要繞過任何控制，也不依賴技術漏洞——它針對的是流程與人的環節。
實務檢查清單：把瀏覽器納入可見範圍
對 IT 與資安團隊而言，與其期待 EDR 擴充到瀏覽器內部，不如主動補上瀏覽器層與身分層的控制。以下是不分產品、可直接對照內部現況的檢查清單：
- 擴充功能盤點與審核：建立企業瀏覽器擴充功能清單，只允許經核准的擴充功能安裝，並定期審視其權限與更新。
- 強化 Cookie 與 session 設定：確保
SameSite、HttpOnly、Secure屬性到位，並在身分提供者（IdP）層設定較短的 token 有效期與登出即撤銷（revocation）。 - 身分層異常偵測：將登入地點、裝置、時段等訊號與 SIEM 關聯，而不只依賴端點遙測。
- 企業資料隔離：避免企業資料出現在個人瀏覽器 profile，必要時導入瀏覽器隔離（browser isolation）或資料外洩防護（DLP）控制。
- 日誌補強：確認 EDR 以外，還有瀏覽器與 IdP 層的事件可供稽核。
- 驗證渠道：對任何要求轉帳或提供憑證的對話，一律改用獨立驗證渠道確認。
業界整體的方向，其實早已與此一致：從依賴一次性密碼，轉向抗釣魚驗證（FIDO2、passkeys），甚至進一步透過 device-bound session credentials 把 session 綁定在裝置上，讓單純重播 cookie 不再奏效。需要釐清的是，瀏覽器層的控制與這條趨勢是互補而非替代的關係——前者縮小盲點，後者則從根本上改變 session 被重播的前提，兩者解決的問題不同。
對金融與受監管行業的一般意義
這篇分析並未點名特定地區的金融機構，也沒有援引任何監管要求；對香港與亞太區的財金行業團隊而言，它的啟示是普遍性的：當大量敏感流程已經跑在瀏覽器裡，而端點遙測對此結構性失明，那麼「我們有部署 EDR」就不再等同於「我們看得見攻擊」。真正需要回答的問題是：瀏覽器裡發生的事，現在有誰在看？
這一點，才是該分析留給所有企業 IT 團隊最實際的功課。