Microsoft Teams 偽裝 IT 支援 ＋ AD CS 濫用：
從遠端協助到網域控制器憑證竊取
為什麼現在很紅：如果有人在 Microsoft Teams 上說他是你公司的 IT，要你開啟 Quick Assist 讓他遠端協助，你會怎麼做？Microsoft 調查了兩起這樣的攻擊：攻擊者冒充 IT 支援，拿到電腦控制權後，利用不安全的 Active Directory Certificate Services 設定取得高權限帳號的登入憑證，甚至是網域控制器本身的憑證。其中一起因為自動遏制漏掉一個帳號，攻擊者成功將資料複製到外部伺服器。
- 一句話結論
- Microsoft 報告調查了兩起攻擊事件，攻擊者透過 Microsoft Teams 冒充公司的 IT 或 help desk，從外部 tenant 傳送訊息與通話，讓對方以為是公司內部支援。攻擊者說服員工開啟 Quick Assist（Windows 內建的遠端協助工具）並讀出連線代碼，取得工作站的直接控制權。攻擊者接著在 Downloads 資料夾中放入壓縮檔，解壓縮到看似 Windows 更新的新資料夾，使用可攜式的 Python、Bun 或 Java runtime 執行內容。Microsoft 未將攻擊活動歸因於任何已知組織。
- 他要的是什麼
- 我在 Teams 上跟你說我是 IT，我的 tenant 名稱看起來很像支援團隊，你就相信了。你幫我開 Quick Assist，我就能直接操作你的電腦。我丟一個壓縮檔到你的 Downloads，解壓縮，用 Python 或 Bun 跑我的工具。如果你們的 AD CS 有 ESC1 範本，我就請一張高權限帳號的憑證；如果有 ESC8，我用 PetitPotam 強制你的網域控制器來認證，relay 到 AD CS，拿網域控制器本身的憑證。拿到憑證後，我就能一直用，即使你改密碼、重灌機器都沒用。如果你的自動遏制漏掉一個帳號，那就是我的後門。
- 你今天做一件事
- 今天檢查所有 AD CS 憑證範本，找出 ESC1（請求者可指定帳號）與 ESC8（web enrollment 未啟用 EPA）的風險。用 Defender for Identity 的姿態檢查來標記這些問題。限制外部 Teams tenant，只允許已核准的組織。訓練員工：任何非預期的支援請求都要透過已知的內部管道確認，不要輕易交出 Quick Assist 代碼。檢視憑證簽發記錄，撤銷任何不當憑證，但記得檢查已簽發的 Kerberos ticket。檢視自動遏制的例外清單，確保每個排除的帳號都有明確的手動處理流程。 直接去做 →
- 哪些能信
- 13 可證明1 推論2 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- Windows 工作站（Quick Assist 為 Windows 內建工具）、AD CS 伺服器、網域控制器、檔案伺服器
- 網路服務商
- 社交工程（Teams 冒充 IT 支援）、ESC1（可指定帳號的憑證範本）、ESC8（NTLM relay 至 AD CS web enrollment）、PetitPotam（強制網域控制器認證）、DCSync（複製 AD 密碼資料）、Rclone（檔案複製）
- 漏洞出現的地方
- 攻擊者需要能向目標員工傳送 Teams 訊息與通話（從外部 tenant）、內網存取 AD CS 與網域控制器
- 馬上自我檢測
檢查 AD CS 憑證範本是否允許請求者指定帳號（ESC1）或過多使用者可註冊 確認 AD CS web enrollment 是否啟用 HTTPS 與 Extended Protection for Authentication (EPA) 檢視 Defender for Identity 的姿態檢查，標記 ESC1 與 ESC8 風險 檢查是否有非預期的憑證簽發記錄 檢視 Teams 通話與 Quick Assist 連線記錄，確認是否有可疑的外部 tenant 或非預期的遠端協助- 漏洞修補方式
- 限制外部 Teams tenant 能聯繫員工的範圍，只允許已核准的組織 訓練員工：任何非預期的支援請求必須透過已知的內部管道確認 檢視並修正 AD CS 憑證範本，移除不需要的註冊權限 在 AD CS web enrollment 端點啟用 HTTPS 與 EPA，在可能的情況下關閉 NTLM 啟用憑證稽核；如果已簽發不當憑證，撤銷它，但記得撤銷不會取消已簽發的 Kerberos ticket 檢視自動遏制的例外清單，確保每個排除的帳號都有手動處理流程
有 15 分鐘再看：其餘 2 點
- 兩起攻擊的核心是濫用不安全的 AD CS 設定。案例 1：攻擊者發現 ESC1 類型的憑證範本（請求者可指定帳號），低權限使用者可請求代表高權限帳號的憑證。第一波攻擊針對 3 個使用者與 1 台工作站，產生 3 個高權限帳號的憑證；Defender 自動遏制切斷這些身分並中斷 session，但其中一個高權限帳號被排除在自動回應之外，仍可使用。90 分鐘後第二波攻擊 16 個使用者與第二台工作站，產生 8 個高權限帳號的憑證，超過 1,000 次後續的 SMB 檔案存取或登入嘗試被阻擋。攻擊者在取得憑證後數秒內登入網域控制器並執行 DCSync（複製 AD 密碼資料），但遏制已啟動，限制了複製量。攻擊者持續使用被排除的帳號，到達檔案伺服器，執行重新命名的 Rclone 將資料從 share 複製到外部 SFTP 伺服器；Microsoft 未說明外洩資料量。
- 案例 2：攻擊者使用 PetitPotam 強制網域控制器向攻擊者控制的機器認證，將該 NTLM 登入 relay 至 AD CS web enrollment 端點（ESC8 濫用），無需密碼即請求代表網域控制器本身的憑證。攻擊者使用該憑證與 Kerberos (PKINIT) 取得網域控制器的 ticket-granting ticket，將一次性的 relayed 登入轉為持久身分。Defender 觸發 ESC8 警報，客戶隔離工作站，Microsoft 表示無後續活動。兩案差異在於遏制：案例 1 自動遏制阻擋了大部分攻擊但漏掉一個帳號，案例 2 隔離單一工作站即阻止攻擊。Microsoft 建議：確認非預期的支援請求、限制外部 Teams tenant、檢視憑證範本、在 web enrollment 啟用 HTTPS 與 EPA、啟用憑證稽核、將排除在自動遏制之外的帳號視為需要手動處理的風險。
Microsoft 調查兩起攻擊事件，攻擊者透過 Teams 冒充 IT 支援，誘騙員工開啟 Quick Assist 交出電腦控制權，再利用不安全的 AD CS 設定取得高權限帳號的登入憑證，其中一起取得網域控制器本身的憑證。攻擊手法結合社交工程（Teams 冒充）、不安全的憑證範本（ESC1）與 NTLM relay 至 AD CS（ESC8），其中一起因局部遏制失敗而導致資料外洩。
本篇目錄
發生了什麼
來源：本文整理自 The Hacker News 於 2026 年 11 月 2 日發布的報導，引述 Microsoft 的調查報告。原文連結，原文發布日期為 Mon, 02 Nov 2026 16:38 +0530。
想像你收到一則 Microsoft Teams 訊息，對方說他是公司的 IT 支援，要幫你處理一個問題。你看到對方的 tenant 名稱看起來很像支援團隊，就相信了。對方請你開啟 Quick Assist（Windows 內建的遠端協助工具）並讀出連線代碼，你照做了。從這一刻起，攻擊者就能直接操作你的電腦。
Microsoft 調查了兩起這樣的攻擊事件。攻擊者透過 Teams 冒充 IT 支援，取得員工電腦的控制權後，利用不安全的 Active Directory Certificate Services (AD CS) 設定，取得高權限帳號的登入憑證，甚至是網域控制器本身的憑證。
其中一起攻擊導致公司資料被複製到外部伺服器。
攻擊者沒有利用 Teams 本身的漏洞。他們依靠社交工程與不安全的 AD CS 設定，Microsoft 未將攻擊活動歸因於任何已知組織。
攻擊如何開始
兩起攻擊的起點相同。攻擊者在 Teams 上傳送訊息與通話給員工，冒充公司的 IT 或 help desk，從外部 tenant 操作，但 tenant 名稱看起來很像支援團隊，讓對方以為是公司內部。
他們說服每個使用者開啟 Quick Assist（Windows 內建的遠端協助工具）並讀出連線代碼。這讓攻擊者取得工作站的直接、動手操作的控制權。
接著，攻擊者在 Downloads 資料夾中放入一個壓縮檔，解壓縮到一個新資料夾，名稱看似 Windows 更新，使用可攜式的 Python、Bun 或 Java runtime 執行內容。檔案名稱本身是弱訊號，因為其中一個複本被重新命名，但仍保留了真實 runtime 的版本細節。
憑證給攻擊者帶來什麼
AD CS 是 Windows 角色，簽發使用者與電腦登入時出示的憑證。來自設定不當的範本的憑證，讓持有者能以憑證中指定的帳號身分登入。
Microsoft 表示，這樣的憑證在帳號密碼被重設或第一台機器被重灌後仍然有效，所以這兩個步驟都無法終止攻擊者的存取。
案例 1：高權限憑證，與遏制的缺口
第一起攻擊中，攻擊者發現一個有 ESC1 弱點的憑證範本。在這種範本中，請求者可以指定憑證將代表的帳號，所以低權限使用者可以請求代表高權限帳號的憑證。
第一波與第二波攻擊
第一波通話針對 3 個使用者與 1 台工作站，產生 3 個高權限帳號的憑證。Microsoft Defender 的自動攻擊遏制切斷這些身分並中斷其活動 session。但其中一個高權限帳號被排除在自動回應之外，所以仍可使用。
約 90 分鐘後，更大的第二波攻擊針對 16 個使用者與第二台工作站，產生 8 個高權限帳號的憑證。Microsoft 表示，超過 1,000 次後續嘗試透過 SMB 存取檔案或登入被阻擋。
DCSync 與資料外洩
在取得憑證後數秒內，攻擊者登入網域控制器並執行 DCSync，這是一個複製 Active Directory 密碼資料的工具。操作已經開始時遏制才生效，限制了可以複製多少資料。Microsoft 未說明攻擊者取得多少憑證資料。
被排除的帳號是缺口。攻擊者持續使用它，到達檔案伺服器，執行重新命名的 Rclone（檔案複製工具）將資料從 share 複製到外部 SFTP 伺服器。Microsoft 未說明多少資料被取走。
局部遏制的教訓
這個案例顯示，用 Microsoft 的話說，「局部身分遏制可以減少攻擊活動，但仍留下一條可行的高權限路徑」。
案例 2：網域控制器的憑證
第二起攻擊以相同方式開始，但因為該 ESC1 範本弱點不存在而採取不同方向。攻擊者改用一個叫 PetitPotam 的技術，強制網域控制器向攻擊者控制的機器認證。
該 NTLM 登入被 relay 到 AD CS 的 web enrollment 頁面，這是一種叫 ESC8 的濫用，不需要密碼。攻擊者使用 relayed 登入請求代表網域控制器本身的憑證。使用該憑證與 Kerberos (PKINIT)，攻擊者取得網域控制器的 ticket-granting ticket，將一次性的 relayed 登入轉為持久身分。
遏制成功
這次回應成功。Defender 觸發 ESC8 警報，客戶隔離工作站，Microsoft 表示無後續活動。
兩案的差異
兩案的差異在於遏制。在第一起中，自動遏制阻擋了大部分攻擊，但被排除的帳號仍然開放。在第二起中，隔離單一工作站即阻止了攻擊。
防禦者該怎麼做
沒有修補程式，因為這些都不是軟體漏洞。Microsoft 的建議著重於設定與回應。
員工訓練與 Teams 限制
- 員工應透過已知的內部管道確認任何非預期的支援請求，再分享螢幕或交出遠端控制
- 限制哪些外部 Teams tenant 能聯繫員工，只允許已核准的組織
- 只允許已核准的遠端支援工具
AD CS 設定
- 檢視登入憑證範本，找出讓請求者指定帳號的範本，或過多使用者可註冊的範本，移除不需要的註冊權限
- 在 web enrollment 端點上要求 HTTPS 並啟用 Extended Protection for Authentication (EPA)，在可能的情況下關閉 NTLM。Microsoft 的 KB5005413 涵蓋這一點，Defender for Identity 的姿態檢查會標記暴露於 ESC1 與 ESC8 的範本與端點
憑證稽核與撤銷
- 啟用憑證稽核。如果已簽發不當憑證，撤銷它，但記得撤銷不會取消已簽發的 Kerberos ticket；分別檢視活動 ticket
遏制的例外
- 將任何排除在自動遏制之外的帳號視為刻意決定，並指派手動動作替代
已知與未知的事實
已知
- Microsoft 未將攻擊歸因於任何已知組織
- Microsoft 未給出攻擊發生的日期
- 這些手法並不新。研究人員在 2021 年命名 ESC1 與 ESC8 憑證弱點，PetitPotam 強制技術也在同年揭露。Microsoft 本身在 2026 年稍早已記錄了 Teams help desk 到遠端存取的進入手法
報告增加的內容
這份報告增加的是：這兩種技術在真實攻擊中相遇，以及關於被排除帳號的教訓。
較新的 Windows 較不暴露於 ESC8
較新的 Windows 對 ESC8 步驟較不暴露。Microsoft 在 Windows Server 2025 預設為 AD CS 開啟 EPA，而 Server 2022 與 2019 需要手動啟用。
指標與偵測
Microsoft 的報告列出跨 Teams、端點與身分訊號的 Defender 警報，以及四個 advanced hunting 查詢，Microsoft 稱之為「調查的起點」而非單獨的證明。它也發布三個與初始存取 script 相關的檔案雜湊：
- SHA-256
85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17（JavaScript 初始存取 script） - SHA-256
f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001（Python 初始存取 script） - SHA-256
06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7（Python 初始存取 script）
你可以學到什麼
站在攻擊者的角度：我在 Teams 上跟你說我是 IT，我的 tenant 名稱看起來很像支援團隊，你就相信了。你幫我開 Quick Assist,我就能直接操作你的電腦。我丟一個壓縮檔到你的 Downloads，解壓縮，用 Python 或 Bun 跑我的工具。如果你們的 AD CS 有 ESC1 範本，我就請一張高權限帳號的憑證；如果有 ESC8，我用 PetitPotam 強制你的網域控制器來認證，relay 到 AD CS，拿網域控制器本身的憑證。拿到憑證後，我就能一直用，即使你改密碼、重灌機器都沒用。如果你的自動遏制漏掉一個帳號，那就是我的後門。
- 01社交工程仍然有效：即使沒有技術漏洞，冒充 IT 支援並要求遠端存取仍能成功。外部 tenant 可以讓名稱看起來像內部支援。
- 02Quick Assist 是合法工具也是攻擊工具：Windows 內建的遠端協助工具讓攻擊者能完全控制工作站，不需要安裝額外軟體。
- 03AD CS 的不安全設定是持久存取的來源：ESC1（請求者可指定帳號）與 ESC8（NTLM relay 至 web enrollment）都是已知 5 年的弱點，但仍在真實攻擊中被利用。
- 04憑證比密碼更持久：憑證在密碼重設與機器重灌後仍然有效，所以不能只依靠這些步驟來終止攻擊者存取。
- 05撤銷憑證不會取消 Kerberos ticket：即使撤銷憑證，已簽發的 Kerberos ticket 仍然有效，需要分別檢視。
- 06局部遏制比沒有遏制好，但不夠：案例 1 中自動遏制阻擋了大部分攻擊，但被排除的一個帳號讓攻擊者能繼續。
- 07排除在自動遏制之外的帳號是風險：每個排除的帳號都應該有明確的手動處理流程，不能只是排除而不處理。
- 08隔離單一工作站可以阻止攻擊：案例 2 中隔離工作站成功阻止攻擊，顯示快速回應的價值。
- 09較新的 Windows 預設較安全：Windows Server 2025 預設為 AD CS 開啟 EPA，較不暴露於 ESC8；舊版本需要手動啟用。
- 01ESC1AD CS 憑證範本弱點，請求者可指定憑證將代表的帳號，讓低權限使用者可請求高權限憑證。2021 年揭露。
- 02ESC8AD CS 濫用手法，將 NTLM 登入 relay 至 AD CS web enrollment 端點，無需密碼即可請求憑證。2021 年揭露。
- 03PetitPotam強制網域控制器向攻擊者控制的機器認證的技術，常與 ESC8 結合使用。2021 年揭露。
- 04Quick AssistWindows 內建的遠端協助工具，攻擊者透過社交工程讓使用者開啟並讀出連線代碼，取得完全控制權。
- 05DCSync複製 Active Directory 密碼資料的工具，攻擊者在取得高權限憑證後執行。
- 06Rclone檔案複製工具，攻擊者用來將資料從檔案伺服器複製到外部 SFTP 伺服器。
- 07Extended Protection for Authentication (EPA)AD CS web enrollment 的安全設定，可防止 NTLM relay 攻擊（ESC8）。Windows Server 2025 預設開啟。
- 08局部遏制（Partial Containment）自動遏制阻擋大部分攻擊但漏掉部分帳號的情況，案例 1 的教訓。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 檢查 AD CS 憑證範本是否有 ESC1 風險看到什麼代表什麼：使用 Defender for Identity 姿態檢查，或手動檢視範本是否允許請求者指定帳號（Subject Alternative Name 可由請求者提供）、過多使用者可註冊。
- 檢查 AD CS web enrollment 是否啟用 EPA看到什麼代表什麼：確認 web enrollment 端點是否啟用 HTTPS 與 Extended Protection for Authentication。參考 KB5005413。
- 限制外部 Teams tenant看到什麼代表什麼：在 Teams 管理中心設定外部存取，只允許已核准的組織。
- 訓練員工確認支援請求看到什麼代表什麼：任何非預期的支援請求都要透過已知的內部管道（電話、內部 ticketing 系統）確認，再交出 Quick Assist 代碼或分享螢幕。
- 檢視憑證簽發記錄看到什麼代表什麼：啟用 AD CS 憑證稽核，檢視是否有非預期的憑證簽發，特別是高權限帳號或網域控制器。
- 檢視自動遏制的例外清單看到什麼代表什麼：確認每個排除在 Defender 自動遏制之外的帳號都有明確的手動處理流程。
- 檢查 Windows Server 版本與 EPA 設定看到什麼代表什麼：Windows Server 2025 預設開啟 EPA；Server 2022 與 2019 需要手動啟用。
如果你管理 Active Directory
- 今天檢查 AD CS 憑證範本：找出 ESC1（請求者可指定帳號）風險，移除不需要的註冊權限
- 啟用 EPA：在 AD CS web enrollment 端點啟用 HTTPS 與 Extended Protection for Authentication（參考 KB5005413）
- 限制外部 Teams tenant：只允許已核准的組織
- 訓練員工：任何非預期的支援請求都要透過內部管道確認
- 啟用憑證稽核：檢視憑證簽發記錄，撤銷不當憑證，檢查已簽發的 Kerberos ticket
- 檢視自動遏制的例外：確保每個排除的帳號都有手動處理流程
- 升級到 Windows Server 2025（如可行）：預設開啟 EPA，降低 ESC8 風險
兩起真實攻擊，一起因為被排除的帳號而導致資料外洩。今天就檢查你的 AD CS 設定。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 9 分鐘。
來源
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M3 社交工程防禦 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。