ADCS攻击面挖掘与利用（下） | 高级攻防03

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.cncorp-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.cncorp-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.cncorp-CA01-CA" -getreg "policyEditFlags"

手动创建利用证书请求：

certreq –new usercert.inf certrequest.req#usercert.inf[NewRequest]KeyLength=2048KeySpec=1RequestType = PKCS10Exportable = TRUE ExportableEncrypted = TRUE[RequestAttributes]CertificateTemplate=USER

利用req请求上步得到.cer含公钥证书，其他字段可翻阅官方文档:

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

将.cer导入机器后连同私钥导出为.pfx，同样顺利通过ptt认证。

2.访问权限

前面提到，证书模板和证书颁发机构是AD中的安全对象，这意味着安全描述符同样可用来指定哪些主体对他们具有特定的权限，详细内容可阅读ACL相关文档。

在对应设置中安全选项可用于对用户的权限进行相关设置，我们关注5种权限:

模板访问权限配置错误:

例如我们已经拿下整个域想借助证书模板进行权限维持，那我们可对一个无害正常模板进行相关ACL添加：

• NT AUTHORITYAuthenticated Users -> WriteDacl

• NT AUTHORITYAuthenticated 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

添加CORPzhangsan用户对其GenericAll的权限：

此时，我们可以滥用权限创建一个新的恶意证书模板来使用进行前面相关的域权限提升方法。

CA访问权限配置错误：

CA本身具有一组安全权限用于权限管理。

我们主要关注ManageCA ，ManageCertificates两种权限：

利用面一：隐藏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：

此时可参考前面：

“EDITF_ATTRIBUTESUBJECTALTNAME2”

证书提权滥用拿到域控制权：

利用面三：自己审批证书注册。

在证书模板设置时，部分 运维会出于安全考虑将模板发布要求设置为CA证书管理员审批，管理员就会在certsrv.msc上进行确认：

当拥有ManageCertificates权限时，可调用ICertAdminD::ResubmitRequest去给需要审核的滥用证书进行批准放行。

3. 其他利用

Golden Certificates：

使用偷来的证书颁发机构(CA)证书以及私钥来为任意用户伪造证书，这些用户可以对活动目录进行身份验证，因为签署颁发证书的唯一密钥就是CA的私钥。

当我们获取到CA服务器时，通过mimikatz或SharpDPAPI项目提取任何不受硬件保护的CA证书私钥。

SharpDPAPI4.exe certificates /machine

使用openssl转化格式后，利用ForgeCert或pyForgeCert进行证书构造，故含私钥的CA为“黄金证书”。

NTLM Relay to ADCS HTTP Endpoints：

该利用方式是因为http的证书注册接口易受NTLM Relay攻击所导致的。NTLM相关利用文章有很多，例如CVE-2018-8581、CVE-2019-1040、Printerbug等，这里不再介绍。

PetitPotam可以指定域内的一台服务器，使其对指定目标进行身份验证。当目标为低版本(16以下)时，可以做到匿名触发。

通过调用MS-EFSRPC相关函数到域控，使域控发送请求我们的监听，我们将获取到的NTLM Relay到ADCS的Web注册页面。

通过域控机器用户NTLM凭据向Web服务注册证书，成功得到域控机器账户的Encode Base64证书。

利用kekeo进行ask tgt成功拿到DC$权限进行Dcsync。

ADCS相关利用手段在实战场景中权限提升、权限维持非常便捷。针对ADCS的防御方案在白皮书也有详细提到，这里就不详细写了。

部分解决方案有提到微软的三层架构：

核心思想就是，你是什么用户就访问怎样的资产，无法向下级访问，且向上访问会告警。那么CA 、ADCS服务器的本地管理员组、PKI 和证书模板所拥有者都应该处于0层。

https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdfhttps://docs.microsoft.com/en-us/windows/win32/ad/how-access-control-works-in-active-directory-domain-serviceshttps://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/https://www.anquanke.com/post/id/245791