Microsoft Teams 偽裝 IT 支援 ＋ AD CS 濫用：從遠端協助到網域控制器憑證竊取

發生了什麼

來源：本文整理自 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，拿網域控制器本身的憑證。拿到憑證後，我就能一直用，即使你改密碼、重灌機器都沒用。如果你的自動遏制漏掉一個帳號，那就是我的後門。

如果你管理 Active Directory

1. 今天檢查 AD CS 憑證範本：找出 ESC1（請求者可指定帳號）風險，移除不需要的註冊權限
2. 啟用 EPA：在 AD CS web enrollment 端點啟用 HTTPS 與 Extended Protection for Authentication（參考 KB5005413）
3. 限制外部 Teams tenant：只允許已核准的組織
4. 訓練員工：任何非預期的支援請求都要透過內部管道確認
5. 啟用憑證稽核：檢視憑證簽發記錄，撤銷不當憑證，檢查已簽發的 Kerberos ticket
6. 檢視自動遏制的例外：確保每個排除的帳號都有手動處理流程
7. 升級到 Windows Server 2025（如可行）：預設開啟 EPA，降低 ESC8 風險

兩起真實攻擊，一起因為被排除的帳號而導致資料外洩。今天就檢查你的 AD CS 設定。