CVE-2026-54121 Certighost：AD CS 網域提權漏洞、PoC 與防禦分析

更新日期：2026 年 7 月 28 日。CVE-2026-54121 是 Microsoft Active Directory Certificate Services（AD CS）的權限提升漏洞，研究者將它命名為 Certighost。問題出在 Enterprise CA 處理特定跨網域控制站憑證註冊流程時，可能把請求者指定的主機當成目錄身分查詢來源。公開研究顯示，低權限網域使用者在符合條件的 AD CS 環境中，可誘使 CA 簽出代表 Domain Controller 的驗證憑證，再透過 PKINIT 取得該機器帳號的 Kerberos 身分。

先講結論：Microsoft 已在 2026 年 7 月安全更新修補此問題。官方 CVSS v3.1 為 8.8（High），Microsoft 的產品嚴重度則標為 Critical；兩者是不同的分類尺度。公開 PoC 已能展示從低權限帳號、憑證申請到 DC 身分驗證的完整研究鏈，但截至本文查核的 CISA 2026 年 7 月 27 日 KEV 目錄，尚未收錄 CVE-2026-54121，也沒有 Microsoft 或 CISA 公開證實它已在野遭利用。「已有公開 PoC」與「已有在野利用證據」必須分開描述。

60 秒摘要：防守團隊現在該做什麼

• 漏洞類型：CWE-285 Improper Authorization，影響 AD CS 的憑證註冊與目錄物件解析信任邊界。
• 攻擊起點：依 Microsoft CVSS，攻擊者需要低權限（PR:L），不需受害者互動，攻擊可跨網路進行。公開 PoC 使用一個低權限網域使用者，並建立或重用可控制的 machine account。
• 核心問題：請求者可透過 cdc 與 rmd 影響 CA 的 chase fallback。修補前，CA 可能向攻擊者控制的 SMB/LSA 與 LDAP 服務查詢身分資料，卻沒有先確認該主機真的是 DC。
• 最嚴重影響：研究者在特定實驗室設定中取得可映射到 Domain Controller 的 CA 簽章憑證，透過 PKINIT 取得 Kerberos 身分，進一步展示 DCSync。這代表潛在的整個網域失陷。
• 最佳處置：在所有 Enterprise CA 與相關 Windows Server 上部署 Microsoft 2026 年 7 月或後續累積更新，並以 fixed build／KB 驗證，不要只看「Windows Update 已完成」。
• 獵捕重點：關聯新建電腦帳號、Machine template 憑證要求、CA 對非核准 DC 的 SMB/LDAP 連線，以及 DC machine principal 的異常 PKINIT／TGT 要求。
• 證據狀態：PoC 與研究者 binary diff 已公開；Microsoft 尚未公開原始碼 diff 或專屬 IOC；目前沒有官方在野利用確認。

風險判讀：只要組織部署 Enterprise CA，就應把這項更新視為 Tier 0 身分基礎設施修補。若沒有 AD CS，作業系統版本命中 CVE 清單不等於 Certighost 攻擊鏈可以成立；若有 AD CS，也不能因 PoC 需要前置條件就延後更新。

CVE 基本資料與證據狀態

Microsoft 的 CVE 頁面在 7 月 14 日發布時標示 Publicly disclosed: No、Exploited: No、Exploitation Less Likely。這些欄位反映公告當下的評估；研究者於 7 月 24 日公開文章與 PoC 後，「未公開」顯然已不是現在的客觀狀態。因此，防守團隊應分別記錄「供應商公告當下的 exploitability assessment」與「目前公開 exploit material 是否存在」，不要把舊欄位當成永遠不變的結論。

影響範圍與修補版本

CVE CNA 與 NVD 列出多個 Windows 10／Windows Server 版本。對企業實務而言，最重要的不是看到作業系統名稱就直接報警，而是先盤點哪些主機安裝 AD CS、哪些是 Enterprise CA、哪些憑證範本允許 machine principal 註冊，以及 CA 能對哪些網段發起 SMB 或 LDAP 連線。

以上 build 與 KB 來自 Microsoft Security Update Guide 可機讀資料及 Microsoft CNA 記錄。舊版 Windows Server 2012／2012 R2 已進入延伸支援情境，組織須同時確認自身 ESU 資格與更新通道。正式更新均標示需要重新啟動。若 CA 是虛擬機，也不要把 VM snapshot 當成憑證服務的完整備份或事件應變替代品；CA database、私鑰、設定與稽核資料應依 PKI 備份程序處理。

事件時間線

先理解 AD CS、憑證 mapping 與 PKINIT

AD CS 是 Microsoft 的企業 PKI 實作。Enterprise CA 與 Active Directory 整合，依 certificate template 的規則替使用者、電腦或服務簽發 X.509 憑證。憑證把公開金鑰與身分資料綁在一起；私鑰留在申請者手上，CA 的簽章則讓信任這個 CA 的系統相信該身分綁定。

PKINIT 是 Kerberos 初始驗證使用公開金鑰的機制。當 KDC 能把憑證中的 SID、SAN、UPN 或其他 mapping 資料映射到 AD principal，持有相對應私鑰的一方就能要求 Kerberos TGT。這也是為什麼「拿到一張錯誤身分的憑證」不是單純 PKI 資料品質問題：如果那張憑證代表高權限 machine principal，它會跨越 CA 到 Kerberos 的信任邊界。

Domain Controller 的電腦帳號不是一般工作站帳號。它在目錄複寫與網域運作中具有高信任權限。研究者展示的最嚴重結果，是 CA 簽出可映射到 DC 的憑證後，攻擊者以 PKINIT 取得 DC machine principal 的 Kerberos 身分，再使用目錄複寫權限取得敏感帳號資料。這是「低權限網域帳號到 Tier 0」的跨界，因此即使 CVSS 基礎分數是 8.8，Microsoft 仍把產品嚴重度列為 Critical。

漏洞原理：不受信任的 chase target 變成身分權威

研究者把問題定位在 AD CS Enterprise policy module 的 principal 載入路徑。在某些跨 Domain Controller 的憑證註冊場景，CA 會進行第二次目錄查詢，也就是研究文章所稱的 chase fallback。兩個 request attributes 會影響這次查詢：

• cdc（Client DC）：告訴 CA 應該聯絡哪一台主機。
• rmd（Remote Domain）：告訴 CA 應該查找哪一個 principal。

修補前的關鍵錯誤，是 CA 接受 request-supplied cdc，卻沒有先向真正的 Active Directory 驗證該主機是不是合法 DC。CA 會對指定主機建立 SMB/LSA 與 LDAP 通訊，再把對方回傳的目錄資料帶入憑證身分建立流程。攻擊者控制的主機不只「接到回連」，還可能回答目標 DC 的 sAMAccountName、objectSid 與 dNSHostName。

低權限 principal
  → 送出 certificate request（含 cdc / rmd）
  → CA 依 cdc 對外進行 SMB/LSA、LDAP chase
  → 攻擊者控制的服務回覆「目標 DC」身分資料
  → CA 將回覆帶入 certificate identity
  → KDC 將憑證映射成 DC machine principal
  → 可能取得具目錄複寫能力的 Kerberos 身分

因此，根因不能簡化成「LDAP injection」或「CA 會向外連線」。真正的安全問題是路由資訊與身分權威混淆：由請求者控制的 chase routing data，最後決定 CA 信任哪個目錄回覆，而回覆又影響 CA 簽署的身分。CWE-285 的「不當授權」描述雖然正確，卻不足以呈現這條跨越 AD CS、LDAP 與 Kerberos 的資料流。

攻擊前提：不是只有「一個普通帳號」這麼簡單

公開 PoC 將入口描述為低權限網域使用者，但成功鏈仍有多個前提。負責風險評估的人應逐項驗證，而不是在「預設一定可打」與「需要前提所以不用修」之間二選一。

1. 存在可達的 AD CS Enterprise CA：攻擊者必須能找到並送出合適的憑證要求。
2. 存在能觸發相關 principal resolution／chase 的註冊路徑：不是所有憑證要求都會走相同 fallback。
3. 攻擊者有低權限網域身分：Microsoft CVSS 為 PR:L，而非 PR:N。
4. 攻擊者能控制可通過驗證的 principal：研究環境利用預設 ms-DS-MachineAccountQuota=10 建立 machine account；若組織已降低 quota，攻擊者仍可能尋找既有可控制電腦帳號，但條件會不同。
5. CA 能回連攻擊者控制的 SMB/LDAP 服務：研究鏈需要 CA 對指定位置發起網路連線。Tier 0 網路 egress 分段可增加阻力與可見性，但不是正式修補的替代品。
6. 範本與 policy 支援可用的驗證身分：template name flags、SAN policy、CA 與 DC 的拓撲，都可能影響 PoC 版本是否直接成功。

這些條件的價值在於協助優先排序和偵測，不是用來合理化延後更新。AD CS 本身就是 Tier 0；攻擊者一旦拿到任意網域帳密，會主動盤點 template、CA、machine quota 與網路路徑。組織應假設公開工具會持續改善兼容性，而 7 月 28 日 PoC 已經出現針對不同 CA 拓撲與 SAN policy 的修正。

公開 PoC 靜態分析：它實際完成哪些階段

本文檢查的 PoC 是 aniqfakhrul/CVE-2026-54121，main branch 固定於 commit 96e910181962fbd216596f4204b2e17435673094。我們只做靜態程式審查，沒有執行腳本、沒有啟動 rogue services、沒有送出任何憑證要求，也沒有對公網或第三方環境測試。

PoC 不是單一封包或簡單的 certificate request。它包含 LDAP client、machine account 建立、Netlogon 驗證、簡化的 rogue LDAP／SMB server、RPC 憑證申請、PKINIT 與 Kerberos credential 處理。這也帶來一個重要限制：某個 scanner 能送出帶 cdc 的要求，不代表它已證明取得 DC 憑證；同樣地，看到新 machine account 也不能單獨證明 Certighost 成功。

7 月 28 日版本把 Netlogon ParameterControl 的 E bit 與 K bit 一起設定，以處理 CA 安裝在 DC 上時的 server-trust account 驗證；它也在允許 request-supplied SAN 的 CA 上，讓 request SAN 使用目標 DC DNS name，避免 PKINIT 身分不一致。這些改動說明研究工具仍在快速演進。防守方不能把「第一版 PoC 在我的拓撲失敗」當作緩解措施。

修補分析：July build 如何關閉信任邊界

Microsoft 沒有公開 Windows 原始碼 diff。以下函式名稱與流程來自 H0j3n、Aniq Fakhrul 對 June vulnerable build 與 July patched build 的 binary diff／反編譯分析，應被標示為研究者驗證結果，不是 Microsoft 原始碼引述。

修補後的信任順序（概念化）

讀取 cdc
  → 驗證它是安全的 hostname，而非任意 IP／filter input
  → 向真正 AD 查詢相同 dNSHostName 的 DC computer object
  → 要求 SERVER_TRUST_ACCOUNT 且唯一命中
  → 通過後才允許 chase
  → 再比對 resolved SID／identity

這個修補不是只擋某個 PoC 字串，而是恢復兩個必要不變量：第一，chase target 必須是 Active Directory 已註冊的真正 DC；第二，經 chase 解析出的物件身分必須符合預期，不能由回覆方任意替換。研究者也觀察到 July binary 中有 Feature_3185813818 gate。管理者不應自行把 feature flag 當成通用驗證介面；最可靠做法仍是部署官方更新並核對 OS build／KB。

臨時緩解：關閉 chase fallback 的限制

研究者提出，在無法立即安裝 July update 時，可清除 AD CS policy 的 EDITF_ENABLECHASECLIENTDC，停用可選的 chase fallback，並重新啟動 Certificate Services。研究文章提供的防禦命令如下：

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

這是研究者在受控 lab 驗證的 mitigation，不是 Microsoft 正式 patch 的替代品。停用 chase 可能讓依賴跨 DC fallback 的合法註冊失敗。套用前應在與正式環境相同的 staging CA 測試，記錄原始 EditFlags，確認憑證註冊、auto-enrollment、Network Device Enrollment Service 或其他整合沒有依賴該路徑。若之後又在未修補 CA 重新啟用 flag，風險會回來。

網路層面可限制 CA 對 TCP 445／389 的 egress，只允許核准 DC 或必要基礎設施；身分層面可降低 ms-DS-MachineAccountQuota、收斂 template enrollment ACL，並審查誰能建立 computer objects。這些控制能縮小攻擊面與增加偵測機會，但都不能替代安裝安全更新，因為它們沒有修正 CA 內部錯誤的信任決策。

偵測與威脅獵捕：用多個訊號重建攻擊鏈

目前沒有 Microsoft 發布的 Certighost 專屬 IOC 清單。這類攻擊也不一定留下固定檔名或 hash；最有效方法是把 AD account management、CA database／audit、網路 egress 與 Kerberos 驗證資料串成時間線。

1. 檢查稽核政策與資料是否真的存在

Microsoft Learn 說明 Audit Certification Services 可產生 4886（收到憑證要求）、4887（核准並簽發）、4888（拒絕）與 4874（request attributes 改變）等事件，但這個 subcategory 並非所有環境預設啟用。先確認 CA 的 Advanced Audit Policy、CA audit filter、事件保存期限與 SIEM 收集狀態。沒有事件不等於沒有活動，也可能只是沒有開啟或已超過 retention。

2. 從 machine account 建立與變更開始

• 4741 代表在 Domain Controller 上建立 computer account；檢查 Subject 帳號、來源、Account Name、DNS Host Name、SPN 與建立時間。
• 4742 代表 computer account 被修改；關注 DNS hostname、SPN、UAC 或其他異常變更，並對 Tier 0 電腦帳號設定更嚴格的基線。
• 篩選平時不負責 join domain 的一般使用者突然建立 machine account，或短時間建立後沒有正常 domain-join 後續活動的帳號。
• 不要把所有 4741 都視為攻擊。合法佈署、VDI、auto-scaling 與 IT 維運都可能建立電腦帳號，必須與 change ticket 和資產清單比對。

3. 查 CA database 與憑證要求

保留 CA database 的 Request ID、Requester Name、Certificate Template、Request Attributes、Disposition、serial number、NotBefore／NotAfter 與憑證 extensions。使用 CA MMC、ICertView 或經驗證的 certutil -view 流程，尋找 Machine template 中異常的 cdc、rmd 或 SAN 組合，並關聯同一 requester 是否剛建立 machine account。注意 certutil -view 對反斜線 escape 有已知查詢陷阱；調查人員應保留原始匯出，不只截圖。

4. 監看 CA 的 SMB／LDAP egress

建立 Enterprise CA 可通訊 DC 的 allowlist，監看 certsrv.exe 所在主機對非核准位置的 TCP 445、389，必要時也納入 636 與 RPC 關聯。Certighost 研究鏈的高價值訊號，是 CA 在處理異常憑證要求的同一時間窗，主動連往一般工作站、使用者 VLAN、測試網段或沒有 DC computer object 的位址。單純一筆 445 連線仍不足以定罪，因為 CA 主機也可能執行其他管理或檔案服務；程序、目的地主機角色與 CA Request ID 的關聯才重要。

5. 關聯 PKINIT 與後續 Tier 0 行為

4768 代表 Kerberos TGT request。部分新版事件 schema 可帶 certificate information，但欄位是否存在取決於 OS、事件版本與稽核設定。尋找 DC machine principal 在非預期來源要求 TGT、certificate issuer／serial 與剛簽發憑證相符，或短時間接續敏感 LDAP／目錄複寫活動。不要聲稱所有 4768 都含完整憑證資訊，也不要只因 machine account 使用 PKINIT 就判定惡意。

事件應變：若懷疑已被利用

1. 保全證據：匯出 CA database、CA Security log、CertificateServicesClient／相關 operational logs、DC Security logs、網路流量與 EDR telemetry。記錄時區與 clock skew。
2. 限制攻擊路徑：在不破壞必要 PKI 服務的前提下，限制 CA 對非核准 SMB／LDAP 目的地；對可疑來源主機進行隔離。
3. 識別憑證：依 requester、template、attributes、serial、SID／SAN 與時間窗口找出可疑 certificate requests，保存原始憑證後再依 PKI 程序撤銷並發布 CRL。
4. 處理 principal：調查新建或遭控制的 machine account、建立者帳號、來源工作站、SPN 與 Kerberos tickets。不要只刪除帳號而失去時間線。
5. 判斷是否跨入 Tier 0：若證實代表 DC 的憑證已用於 PKINIT、取得 TGT 或目錄複寫，應按 domain compromise 升級事件；需要評估 krbtgt、DC machine secrets、CA 金鑰與整個信任鏈，而非只修補一台 CA。
6. 修補與復原：在保存證據後部署 Microsoft 更新，驗證 fixed build、重啟狀態與 CA 功能。重新檢查 template、machine quota、CA egress 與稽核政策。

是否需要輪替 CA key、重建 CA 或執行雙次 krbtgt 密碼輪替，取決於實際證據與受影響範圍。這些動作具有廣泛營運影響，不應由單一 scanner alert 自動觸發；應由 AD、PKI 與事件應變負責人共同決策。

修補與強化優先順序

1. P0：更新 Enterprise CA 與相關受影響主機。核對 KB 與 fixed build，安排重啟並做簽發、撤銷、auto-enrollment 與 CRL/AIA 驗證。
2. P0：建立 CA egress allowlist。CA 不應任意連到使用者或伺服器網段的 SMB／LDAP 服務。
3. P1：啟用並集中 AD CS 稽核。確認 4886–4888、4874 等資料可被 SIEM 收集，並保存 CA database。
4. P1：收斂 machine account 建立權。評估把 ms-DS-MachineAccountQuota 降為符合業務需求的值，並以委派流程取代所有一般使用者都能建立電腦帳號。
5. P1：審查 certificate templates。移除不必要 enrollment 權限、危險 EKU／SAN policy，盤點 Machine／Domain Controller 相關範本。
6. P2：建立跨資料源 detection。把 4741／4742、CA request、CA egress、4768 與目錄複寫串成查詢，而非依賴單一 IOC。
7. P2：做受控驗證。不要在正式 CA 執行公開 exploit。用 staging CA 驗證 patch、正常註冊與 detection telemetry。

事實查核：已確認、技術推論與尚未確認

常見問題 FAQ

CVE-2026-54121 是未驗證遠端 RCE 嗎？

不是。Microsoft 的影響類型是 Elevation of Privilege，CVSS 為 PR:L，表示攻擊者需要低權限身分。它可透過網路利用且不需受害者互動，但不能寫成完全未驗證的網際網路 RCE。

只要有 Windows Server 就受 Certighost 直接威脅嗎？

產品清單命中只代表版本在 CVE affected range。完成公開攻擊鏈需要 AD CS Enterprise CA、合適的註冊與 chase 路徑、低權限網域身分、可控制 principal 及 CA 回連能力。盤點時應同時看 OS build 與 AD CS 架構。

降低 ms-DS-MachineAccountQuota 就修好了嗎？

沒有。它可阻止一般使用者直接利用預設 quota 新增 machine account，縮小公開 PoC 的一條路徑，但攻擊者可能控制既有 machine principal。根因在 CA 的授權與身分驗證，仍須安裝安全更新。

看到事件 4741 或 4887 就代表被打了嗎？

不是。4741 是 computer account 建立，4887 是 CA 簽發憑證，兩者都有大量合法用途。要檢查建立者、template、request attributes、CA egress、憑證身分、PKINIT 與後續行為的關聯。

可以在正式環境執行 PoC 驗證嗎？

不建議。PoC 會建立或修改 machine account、啟動 rogue 服務、要求身分憑證並產生 Kerberos artifacts，可能破壞證據、觸發錯誤憑證簽發或影響 Tier 0。應以 patch/build、CA policy、network controls 與 staging lab 驗證。

波波觀點

Certighost 最值得記住的，不是又多了一條「低權限到 Domain Admin」工具指令，而是 PKI 信任鏈中的一個細微路由決策，如何一路變成 Kerberos 身分。CA 的工作是替身分背書；一旦「去誰那裡查身分」能由請求者影響，而 CA 又沒有獨立確認那個來源的權威性，密碼學簽章反而會把錯誤資料變成整個網域都信任的證明。

這類漏洞也再次證明，AD CS 不能被當成普通 Windows role server 管理。它屬於 Tier 0，應有專屬資產清單、變更管理、egress allowlist、長期 audit retention、template review 與事件應變劇本。只部署更新而沒有 CA database、Kerberos 與網路遙測，能阻止下一次利用，卻無法回答「更新前是否已經發生」。

參考來源

• Microsoft Security Update Guide：CVE-2026-54121
• CVE.org：CVE-2026-54121 CNA record
• NVD：CVE-2026-54121
• H0j3n／Aniq Fakhrul：Certighost 技術分析與 binary diff
• aniqfakhrul/CVE-2026-54121：公開 PoC repository
• CISA Known Exploited Vulnerabilities Catalog
• Microsoft Learn：Audit Certification Services
• Microsoft Learn：Event 4741
• Microsoft Learn：Event 4742
• Microsoft Learn：Event 4768
• Microsoft Learn：Viewing the Certificate Services Database
• Microsoft Open Specifications：Windows PKINIT（MS-PKCA）

延伸閱讀：可從本站的 漏洞預警與 CVE 與 Blue Team 與事件應變 專題，持續追蹤漏洞修補、威脅獵捕與事件應變實務。