ADCS 攻擊面挖掘與利用

作者：Imanfeng@360高級攻防實驗室
原文鏈接：http://noahblog.#/active-directory-certificate-services-attack-and-exploit/

0x00 前言

在 BlackHat21 中 Specterops 發布了 Active Directory Certificate Services 利用白皮書，盡管 ADCS 并不是默認安裝但在大型企業域中通常被廣泛部署。本文結合實戰講述如何在域環境中利用 ADCS 手法拿下域控，哪些對象 ACL 可用于更好的權限維持并涉及 ADCS 的基礎架構、攻擊面、后利用等。

0x01 技術背景

1. 證書服務

PKI公鑰基礎結構

在 PKI (公鑰基礎結構)中，數字證書用于將公密鑰對的公鑰與其所有者的身份相關聯。為了驗證數字證書中公開的身份，所有者需要使用私鑰來響應質詢，只有他才能訪問。

Microsoft 提供了一個完全集成到 Windows 生態系統中的公鑰基礎結構 (PKI) 解決方案，用于公鑰加密、身份管理、證書分發、證書撤銷和證書管理。啟用后，會識別注冊證書的用戶，以便以后進行身份驗證或撤銷證書，即 Active Directory Certificate Services (ADCS)。

ADCS關鍵術語

根證書頒發機構 (Root Certification Authority)
證書基于信任鏈，安裝的第一個證書頒發機構將是根 CA，它是我們信任鏈中的起始。
從屬 CA (Subordinate CA)
從屬 CA 是信任鏈中的子節點，通常比根 CA 低一級。
頒發 CA (Issuing CA)
頒發 CA 屬于從屬 CA，它向端點（例如用戶、服務器和客戶端）頒發證書，并非所有從屬 CA 都需要頒發 CA。
獨立 CA (Standalone CA)
通常定義是在未加入域的服務器上運行的 CA。
企業 CA (Enterprise CA)
通常定義是加入域并與 Active Directory 域服務集成的 CA。
電子證書 (Digital Certificate)
用戶身份的電子證明，由 Certificate Authority 發放（通常遵循X.509標準）。
AIA (Authority Information Access)
權威信息訪問 (AIA) 應用于 CA 頒發的證書，用于指向此證書頒發者所在的位置引導檢查該證書的吊銷情況。
CDP (CRL Distribution Point)
包含有關 CRL 位置的信息，例如 URL (Web Server)或 LDAP 路徑 (Active Directory)。
CRL (Certificate Revocation List)
CRL 是已被撤銷的證書列表，客戶端使用 CRL 來驗證提供的證書是否有效。

ADCS服務架構

微軟官方 ADCS 服務架構中的兩層 PKI 環境部署結構示例如下：

ORCA1：首先使用本地管理員部署單機離線的根 CA，配置 AIA 及 CRL，導出根 CA 證書和 CRL 文件

由于根 CA 需要嵌入到所有驗證證書的設備中，所以出于安全考慮，根 CA 通常與客戶端之間做網絡隔離或關機且不在域內，因為一旦根 CA 遭到管理員誤操作或黑客攻擊，需要替換所有嵌入設備中的根 CA 證書，成本極高。
為了驗證由根 CA 頒發的證書，需要使 CRL 驗證可用于所有端點，為此將在從屬 CA (APP1) 上安裝一個 Web 服務器來托管驗證內容。根 CA 機器使用頻率很低，僅當需要進行添加另一個從屬/頒發 CA、更新 CA 或更改 CRL。

APP1：用于端點注冊的從屬 CA，通常完成以下關鍵配置

將根 CA 證書放入 Active Directory 的配置容器中，這樣允許域客戶端計算機自動信任根 CA 證書，不需要在組策略中分發該證書。
在離線 ORCA1上申請 APP1 的 CA 證書后，利用傳輸設備將根 CA 證書和 CRL文件放入 APP1 的本地存儲中，使 APP1 對根 CA 證書和根 CA CRL 的迅速直接信任。
部署 Web Server 以分發證書和 CRL，設置 CDP 及 AIA。

LDAP屬性

ADCS 在 LDAP 容器中進行了相關屬性定義 CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=，部分前面提到過

Certificate templates

ADCS 的大部分利用面集中在證書模板中，存儲為 CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ，其 objectClass 為 pKICertificateTemplate，以下為證書的字段

常規設置：證書的有效期
請求處理：證書的目的和導出私鑰要求
加密：要使用的加密服務提供程序 (CSP) 和最小密鑰大小
Extensions：要包含在證書中的 X509v3 擴展列表
主題名稱：來自請求中用戶提供的值，或來自請求證書的域主體身份
發布要求：是否需要“CA證書管理員”批準才能通過證書申請
安全描述符：證書模板的 ACL，包括擁有注冊模板所需的擴展權限

證書模板頒發首先需要在 CA 的 certtmpl.msc 進行模板配置，隨后在 certsrv.msc 進行證書模板的發布。在 Extensions 中證書模板對象的 EKU (pKIExtendedKeyUsage) 屬性包含一個數組，其內容為模板中已啟用的 OID (Object Identifiers)

這些自定義應用程序策略 (EKU oid) 會影響證書的用途，以下 oid 的添加才可以讓證書用于 Kerberos 身份認證

描述	OID
Client Authentication	1.3.6.1.5.5.7.3.2
PKINIT Client Authentication	1.3.6.1.5.2.3.4
Smart Card Logon	1.3.6.1.4.1.311.20.2.2
Any Purpose	2.5.29.37.0
SubCA	(no EKUs)

Enterprise NTAuth store

NtAuthCertificates 包含所有 CA 的證書列表，不在內的 CA 無法處理用戶身份驗證證書的申請

向 NTAuth 發布/添加證書：
certutil –dspublish –f IssuingCaFileName.cer NTAuthCA

要查看 NTAuth 中的所有證書：
certutil –viewstore –enterprise NTAuth

要刪除 NTAuth 中的證書：
certutil –viewdelstore –enterprise NTAuth

域內機器在注冊表中有一份緩存：

HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates

當組策略開啟“自動注冊證書”，等組策略更新時才會更新本地緩存。

Certification Authorities & AIA

Certification Authorities 容器對應根 CA 的證書存儲。當有新的頒發 CA 安裝時，它的證書則會自動放到 AIA 容器中。

來自他們容器的所有證書同樣會作為組策略處理的一部分傳播到每個網絡連通的客戶端，當同步出現問題的話 KDC 認證會拋 KDC_ERR_PADATA_TYPE_NOSUPP 報錯。

Certificate Revocation List

前面在 PKI 服務架構中提到了，證書吊銷列表 (CRL) 是由頒發相應證書的 CA 發布的已吊銷證書列表，將證書與 CRL 進行比較是確定證書是否有效的一種方法。

CN=<CA name>,CN=<ADCS server>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=

通常證書由序列號標識，CRL 除了吊銷證書的序列號之外還包含每個證書的吊銷原因和證書被吊銷的時間。

2. 證書注冊

證書注冊流程

ADCS 認證體系中的證書注冊流程大致如下：

客戶端創建公鑰/私鑰對；
將公鑰與其他信息 (如證書的主題和證書模板名稱) 一起放在證書簽名請求 (CSR) 消息中，并使用私鑰簽署；
CA 首先判斷用戶是否允許進行證書申請，證書模板是否存在以及判斷請求內容是否符合證書模板；
通過審核后，CA 生成含有客戶端公鑰的證書并使用自己的私鑰來簽署；
簽署完的證書可以進行查看并使用。

證書注冊方式

\1. 證書頒發機構 Web 注冊

在部署 CA 時勾選證書頒發機構 Web 注冊，即可在 http://CA-Computer/certsrv 身份認證后進行證書申請。

\2. 客戶端 GUI 注冊

域內機器可以使用 certmgr.msc (用戶證書)，certlm.msc (計算機證書) GUI 請求證書

\3. 命令行注冊

域內機器可以通過 certreq.exe 或Powershell Get-Certificate 申請證書，后面有使用示例

\4. DCOM調用

基于 DCOM 的證書注冊遵循 MS-WCCE 協議進行證書請求，目前大多數 C#、python、Powershell的 ADCS 利用工具都按照 WCCE 進行證書請求。

證書注冊權限

在 Active Directory 中權限控制是基于訪問控制模型的，其包含兩個基本部分：

訪問令牌，其中包含有關登錄用戶的信息
安全描述符，其中包含保護安全對象的安全信息

在 ADCS 中使用兩種安全性定義注冊權限 (主體可以請求證書) ，一個在證書模板 AD 對象上，另一個在企業 CA 本身上。

在頒發 CA 機器上使用 certtmpl.msc 可查看所有證書模板，通過安全擴展可以對證書模板的用戶訪問權限查看。

可以在頒發 CA 機器上使用 certsrv.msc 查看 CA 對于用戶的訪問權限設置。

0x02 證書使用

1. 證書認證

Kerberos認證

Kerberos 是域環境中主要的認證協議，其認證流程大致如下：

AS_REQ：client 用 client_hash 、時間戳向 KDC 進行身份驗證；
AS_REP：KDC 檢查 client_hash 與時間戳，如果正確則返回 client 由 krbtgt 哈希加密的 TGT 票據和 PAC 等相關信息；
TGS_REQ：client 向 KDC 請求 TGS 票據，出示其 TGT 票據和請求的 SPN；
TGS_REP：KDC 如果識別出 SPN ，則將該服務賬戶的 NTLM 哈希加密生成的 ST 票據返回給 client；
AP_REQ：client 使用 ST 請求對應服務，將 PAC 傳遞給服務進行檢查。服務通過 PAC 查看用戶的 SID 和用戶組等并與自身的 ACL 進行對比，如果不滿足則作為適當的 RPC 狀態代碼返回；
AP_REP：服務器驗證 AP-REQ，如果驗證成功則發送 AP-REP，客戶端和服務端通過中途生成的 Session key 等信息通過加解密轉換驗證對方身份。

PKINIT認證

在 RFC 4556 中定義了 PKINIT 為 Kerberos 的擴展協議，可通過 X.509 證書用來獲取 Kerberos 票據 (TGT)。

PKINIT 與 Kerberos 差別主要在 AS 階段：

PKINIT AS_REQ：發d送內容包含證書，私鑰進行簽名。KDC 使用公鑰對數字簽名進行校驗，確認后返回使用證書公鑰加密的 TGT 并且消息是使用 KDC 私鑰簽名；
PKINIT AS_REP：客戶端使用 KDC 公鑰進行簽名校驗，隨后使用證書私鑰解密成功拿到 TGT。

詳細的協議流程規范：http://pike.lysator.liu.se/docs/ietf/rfc/45/rfc4556.xml

NTLM憑據

在2016年，通過證書獲取 NTLM 的功能就被集成在 kekeo 和 mimikatz 中，核心在于當使用證書進行 PKCA 擴展協議認證的時候，返回的 PAC 中包含了 NTLM 票據。

即使用戶密碼改了，通過證書隨時可以拿到 NTLM。獲取能用來進行 Kerberos 身份認證的證書需要滿足一下幾個條件：

\1. 證書模板OID

前面我們提到了，目前已知應用程序策略 (oid) 只有包含了 Client Authentication、PKINIT Client Authentication、Smart Card Logon、Any Purpose、SubCA 時，對應的證書才能充當 PKINIT 身份認證憑據。

\2. 證書請求權限

用戶擁有向 CA 申請證書的權限；
用戶擁有證書模板申請證書的權限。

2. 證書獲取

導出機器證書

通過 certlm.msc 圖形化或 certutil.exe 進行證書導出。

當私鑰設置為不允許導出的時候，利用 Mimikatz 的 crypto::capi 命令可以 patch 當前進程中的 capi ，從而利用 Crypto APIs 導出含有私鑰的證書。

導出用戶證書

通過 certmgr.msc 圖形化或 certutil.exe 進行用戶證書導出。

遇到私鑰限制同樣可嘗試 crypto::capi 導出證書。

本地檢索證書

在實戰中會遇到證書、私鑰文件就在文件夾內并不需要導出，其后綴文件主要有以下幾種

后綴	描述
.pfx\ .p12\ .pkcs12	含公私鑰，通常有密碼保護
.pem	含有base64證書及私鑰，可利用openssl格式轉化
.key	只包含私鑰
.crt\ .cer	只包含證書
.csr	證書簽名請求文件，不含有公私鑰
.jks\ .keystore\ .keys	可能含有 java 應用程序使用的證書和私鑰

可結合自身需求通過開源工具或自研武器來滿足檢索文件后綴的需求。

0x03 證書濫用

本節圍繞 ADCS 從證書模板的濫用到權限維持濫用進行講解

1. 證書模板

CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 濫用

該錯誤配置在企業 ADCS 中是最為常見的，需滿足的條件為：

頒發 CA 授予低權限用戶請求權限 (默認)
模板中 CA 管理員審批未啟用 (默認)
模板中不需要授權的簽名 (默認)
模板允許低權限用戶注冊
模板定義了啟用認證的 EKU
證書模板允許請求者在 CSR 中指定一個 subjectAltName

如果滿足上列條件，當攻擊者在請求證書時可通過 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 字段來聲明自己的身份，從而可獲取到偽造身份的證書，Certify 為白皮書配套的 ADCS 利用工具。

Certify.exe find /vulnerable

使用 certutil.exe -TCAInfo 判斷 CA 狀態及當前用戶請求的權限情況

利用 Certify 的 set altname 來偽造 administrator 身份嘗試得到證書

Certify.exe request /ca:"CA01.corp.qihoo.cn\corp-CA01-CA" /template:”ESC1“ /altname:administrator

成功通過申請后可得到含有公私鑰的 pem 證書文件，使用 openssl 進行格式轉化

/usr/bin/openssl pkcs12 -in ~/cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out ~/cert.pfx

20.11后的 Rubeus 進行了 PKINIT 證書支持，使用 cert.pfx 作為 administrator 身份申請 TGT，成功獲得 administrator 的票據

Rubeus4.exe asktgt /user:Administrator /certificate:cert.pfx /password:123456 /outfile:cert.kribi /ptt

Any EKU OR no EKU

與第一種利用需滿足的條件前四點相同的用戶證書非機器證書，主要差別在 EKU 的描述：

頒發 CA 授予低權限用戶請求權限 (默認)
模板中 CA 管理員審批未啟用 (默認)
模板中不需要授權的簽名 (默認)
模板允許低權限用戶注冊
證書模板中定義了 no EKU 或 any EKU

可使用 certutil.exe 檢查模板的 pKIExtendedKeyUsage 字段是否為空

certutil -v -dstemplate

通過 Certify 成功定位到惡意模板

該利用方式并不是能直接通過 Kerberos 認證來偽造用戶。Any Purpose (OID 2.5.29.37.0) 可以用于任何目的，包括客戶端身份驗證，如果沒有指定eku，即 pkiextendedkeyusag 為空那么該證書就相當于從屬 CA 的證書，可以用于任何情況給其他用戶來頒發證書。

前面說過 CA 證書不在 NtAuthCertificates 內的話，是無法為身份認證作用來頒發證書的，所以該利用手段無法直接偽造用戶，但可以用來簽發用于其他應用，例如 ADFS ，它是 Microsoft 作為 Windows Server 的標準角色提供的一項服務，它使用現有的 Active Directory 憑據提供 Web 登錄，感興趣的可以自己搭環境試一試。

注冊代理證書濫用

CA 提供一些基本的證書模板，但是標準的 CA 模板不能直接使用，必須首先復制和配置。部分企業出于便利性通過在服務器上設置可由管理員或注冊代理來直接代表其他用戶注冊對應模板得到使用的證書。

實現該功能需要兩個配置模板：

頒發“注冊代理”的證書模板
滿足代表其他用戶進行注冊的證書模板

模板一為頒發“注冊代理”證書

頒發 CA 授予低權限用戶請求權限 (默認)
模板中 CA 管理員審批未啟用 (默認)
模板中不需要授權的簽名 (默認)
模板允許低權限用戶注冊
證書模板中定義了證書請求代理 EKU (1.3.6.1.4.1.311.20.2.1)

模板二為允許使用“注冊代理”證書去代表其他用戶申請身份認證證書

頒發 CA 授予低權限用戶請求權限 (默認)
模板中 CA 管理員審批未啟用 (默認)
模板中不需要授權的簽名 (默認)
模板允許低權限用戶注冊
模板定義了啟用認證的 EKU
模板模式版本1或大于2并指定應用策略，簽發要求證書請求代理 EKU
沒有在 CA 上對登記代理進行限制 (默認)

申請注冊代理證書并連同私鑰導出為 esc3_1.pfx

利用 Certify 通過 esc3_1.pfx 代表 administrator 申請 esc3_2.pfx 的身份認證證書，得到的證書同樣可以進行 ptt 利用

Certify.exe request /ca:"CA01.corp.qihoo.cn\corp-CA01-CA" /template:ESC3_2 /onbehalfof:administrator /enrollcert:esc3_1.pfx /enrollcertpw:123456

可看到證書頒發給了 administrator

EDITF_ATTRIBUTESUBJECTALTNAME2 濫用

一些企業因業務需求會把頒發 CA + EDITF_ATTRIBUTESUBJECTALTNAME2 來啟用 SAN (主題備用名)，從而允許用戶在申請證書時說明自己身份。例如 CBA for Azure AD 場景中證書通過 NDES 分發到移動設備，用戶需要使用 RFC 名稱或主體名稱作為 SAN 擴展名來聲明自己的身份。

至此利用手段與第一種一樣均可偽造身份，區別在于一個是證書屬性，一個是證書擴展。

企業CA授予低權限用戶請求權限（默認）
模板中CA管理員審批未啟用（默認）
模板中不需要授權的簽名（默認）
CA +EDITF_ATTRIBUTESUBJECTALTNAME2

通過遠程注冊表判斷 CA 是否開啟 SAN 標識

certutil -config "CA01.corp.qihoo.cn\corp-CA01-CA" -getreg "policy\EditFlags"

手動創建利用證書請求

certreq –new usercert.inf certrequest.req
#usercert.inf
[NewRequest]

KeyLength=2048
KeySpec=1
RequestType = PKCS10
Exportable = TRUE 
ExportableEncrypted = TRUE

[RequestAttributes]
CertificateTemplate=USER

利用 req 請求上步得到 .cer 含公鑰證書，其他字段可翻閱官方文檔

certreq -submit -config "CA01.corp.qihoo.cn\corp-CA01-CA" -attrib "SAN:upn=administrator@corp.qihoo.cn" certrequest.req certrequest.cer

將 .cer 導入機器后連同私鑰導出為 .pfx ，同樣順利通過 ptt 認證。

2. 訪問權限

前面提到，證書模板和證書頒發機構是 AD 中的安全對象，這意味著安全描述符同樣可用來指定哪些主體對他們具有特定的權限，詳細內容可閱讀 ACL 相關文檔。

在對應設置中安全選項可用于對用戶的權限進行相關設置，我們關注5種權限

權限	描述
Owner	對象所有人，可以編輯任何屬性
Full Control	完全控制對象，可以編輯任何屬性
WriteOwner	允許委托人修改對象的安全描述符的所有者部分
WriteDacl	可以修改訪問控制
WriteProperty	可以編輯任何屬性

模板訪問權限配置錯誤

例如我們已經拿下整個域想借助證書模板進行權限維持，那我們可對一個無害正常模板進行相關 ACL 添加

NT AUTHORITY\Authenticated Users -> WriteDacl
NT AUTHORITY\Authenticated Users -> WriteProperty

當我們重新回到域內通過密碼噴灑等手段再次拿到任意一個用戶憑據后，即可將該無害模板變成我們可以利用的提權模板

msPKI-Certificates-Name-Flag -edit-> ENROLLEE_SUPPLIES_SUBJECT (WriteProperty)
msPKI-Certificate-Application-Policy -add-> 服務器身份驗證 (WriteProperty)
mspki-enrollment-flag -edit-> AUTO_ENROLLMENT (WriteProperty)
Enrollment Rights -add-> Control User (WriteDacl)

隨后利用惡意模板進行 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 提權利用，可拿到 administrator 的證書憑據即可 ptt ，相比 Certify ，certi 是可以在域外使用的。

PKI 訪問權限配置錯誤

如果低特權的攻擊者可以對 CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= 控制，那么攻擊者就會直接控制 PKI 系統 (證書模板容器、證書頒發機構容器、NTAuthCertificates對象、注冊服務容器等)。

將 CN=Public Key Services,CN=Services,CN=Configuration 添加 CORP\zhangsan 用戶對其 GenericAll 的權限

此時我們可以濫用權限創建一個新的惡意證書模板來使用進行前面相關的域權限提升方法。

CA 訪問權限配置錯誤

CA 本身具有一組安全權限用于權限管理

我們主要關注 ManageCA ，ManageCertificates 兩種權限

權限	描述
Read	讀取 CA
ManageCA	CA 管理員
Issue and manage certificates	證書管理
Request certificates	請求證書，默認擁有

利用面一：隱藏 CA 申請記錄

在拿到域管權限或擁有 PKI 操作權限后創建一個惡意證書模板

使用 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 姿勢獲取到 administrator 的 pfx 證書用于權限維持 (用戶狀態異常無法利用該證書)

我們出于隱蔽考慮可刪除模板并利用擁有 ManageCA 權限的 zhangsan 調用 COM 接口 ICertAdminD2::DeleteRow 從 CA 數據庫中刪除申請的證書痕跡

運維人員是無法從證書控制臺觀察到我們的證書申請記錄并無法吊銷證書。只要 administrator 用戶不過期，證書不過期即可一直使用，即使用戶密碼更改。

利用面二：修改 CA 屬性用于證書提權

當我們擁有 ManageCA 權限下調用 ICertAdminD2::SetConfigEntry 來修改 CA 的配置數據，例如Config_CA_Accept_Request_Attributes_SAN 的bool型數據從而開啟 CA 的 EDITF_ATTRIBUTESUBJECTALTNAME2