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(子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_SUBJECT
的WebServer
模板)然后修改以包含身份验证OID时,情况并非如此。
滥用
要查找易受攻击的证书模板,您可以运行:
要利用这个漏洞冒充管理员,可以运行:
然后,您可以将生成的证书转换为.pfx
格式,并再次使用它来使用Rubeus或certipy进行身份验证:
Windows 二进制文件 "Certreq.exe" 和 "Certutil.exe" 可用于生成 PFX:https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
可以通过运行以下 LDAP 查询来枚举 AD Forest 配置架构中的证书模板,特别是那些不需要批准或签名、具有客户端身份验证或智能卡登录 EKU,并启用了 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
标志的证书模板:
配置错误的证书模板 - ESC2
解释
第二种滥用场景是第一种的变体:
企业 CA 向低权限用户授予注册权限。
禁用了经理批准的要求。
省略了授权签名的需求。
证书模板上的过于宽松的安全描述符授予了低权限用户的证书注册权限。
证书模板被定义为包含 Any Purpose EKU 或没有 EKU。
Any Purpose EKU 允许攻击者为任何目的获取证书,包括客户端认证、服务器认证、代码签名等。可以使用与 ESC3 中使用的相同技术来利用这种情况。
没有 EKUs 的证书,作为下级 CA 证书,可以被滥用为任何目的,也可以用于签署新证书。因此,攻击者可以利用下级 CA 证书指定新证书中的任意 EKUs 或字段。
然而,为域认证创建的新证书如果下级 CA 未被**NTAuthCertificates
对象信任,则将无法正常工作,这是默认设置。尽管如此,攻击者仍然可以创建具有任何 EKU 和任意证书值的新证书。这些可能会被潜在地滥用**于各种目的(例如代码签名、服务器认证等),并且可能对网络中的其他应用程序(如 SAML、AD FS 或 IPSec)产生重大影响。
要枚举符合 AD Forest 配置模式中此场景的模板,可以运行以下 LDAP 查询:
配置错误的注册代理模板 - 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 上未应用注册代理的限制。
滥用
您可以使用 Certify 或 Certipy 来滥用这种情况:
允许获得注册代理证书的用户,允许注册代理进行注册的模板,以及注册代理可以代表的帐户,可以受到企业CA的限制。这可以通过打开certsrc.msc
快捷方式,右键单击CA,单击属性,然后导航到“注册代理”选项卡来实现。
然而,值得注意的是,CA的默认设置是“不限制注册代理”。当管理员启用对注册代理的限制时,将其设置为“限制注册代理”,默认配置仍然非常宽松。它允许所有人访问并在所有模板中进行注册。
可脆弱的证书模板访问控制 - ESC4
解释
证书模板上的安全描述符定义了特定AD主体对模板拥有的权限。
如果攻击者具有足够的权限来更改一个模板并实施在前面章节中概述的任何可利用的配置错误,则可能促成特权升级。
适用于证书模板的显着权限包括:
**所有者:**授予对对象的隐式控制,允许修改任何属性。
**完全控制:**允许完全控制对象,包括修改任何属性的能力。
**WriteOwner:**允许将对象的所有者更改为攻击者控制下的主体。
**WriteDacl:**允许调整访问控制,可能授予攻击者完全控制。
**WriteProperty:**授权编辑任何对象属性。
滥用
类似于先前的特权升级的一个示例:
ESC4是指用户对证书模板具有写权限。例如,这可以被滥用以覆盖证书模板的配置,使模板容易受到ESC1的影响。
如上路径所示,只有JOHNPC
拥有这些权限,但我们的用户JOHN
具有新的AddKeyCredentialLink
边缘到JOHNPC
。由于这个技术与证书有关,我也实施了这个攻击,这被称为Shadow Credentials。这里是Certipy的shadow auto
命令的一小部分,用于检索受害者的NT哈希。
Certipy 可以使用一条命令覆盖证书模板的配置。默认情况下,Certipy会覆盖配置以使其容易受到 ESC1 的攻击。我们还可以指定 -save-old
参数来保存旧的配置,这在攻击后恢复配置时会很有用。
脆弱的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
:
这个操作基本上使用了远程注册表访问,因此,另一种方法可能是:
工具如Certify和Certipy能够检测到这种错误配置并利用它:
要更改这些设置,假设拥有域管理员权限或等效权限,可以从任何工作站执行以下命令:
要在您的环境中禁用此配置,可以使用以下命令删除标志:
在 2022 年 5 月安全更新之后,新发布的证书将包含一个安全扩展,其中包含了请求者的 objectSid
属性。对于 ESC1,此 SID 是从指定的 SAN 派生的。然而,对于ESC6,SID 反映了请求者的 objectSid
,而不是 SAN。
要利用 ESC6,系统必须容易受到 ESC10(弱证书映射)的影响,该映射将SAN 优先于新的安全扩展。
易受攻击的证书颁发机构访问控制 - ESC7
攻击 1
解释
证书颁发机构的访问控制是通过一组权限来维护的,这些权限管理着 CA 的操作。可以通过访问 certsrv.msc
,右键单击 CA,选择属性,然后导航到安全选项卡来查看这些权限。此外,可以使用 PSPKI 模块来枚举权限,例如:
这提供了关于主要权限的见解,即**ManageCA
和ManageCertificates
**,分别对应“CA管理员”和“证书管理员”的角色。
滥用
在证书颁发机构拥有**ManageCA
权限使主体能够使用PSPKI远程操纵设置。这包括切换EDITF_ATTRIBUTESUBJECTALTNAME2
**标志,以允许在任何模板中指定SAN,这是域提升的关键方面。
通过使用PSPKI的Enable-PolicyModuleFlag cmdlet,可以简化此过程,允许在没有直接GUI交互的情况下进行修改。
拥有**ManageCertificates
**权限可促使批准待处理请求,有效地规避“CA证书管理员批准”保障。
Certify和PSPKI模块的组合可用于请求、批准和下载证书:
攻击 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
**访问权限。
SubCA
模板可以使用 -enable-template
参数在 CA 上启用。默认情况下,SubCA
模板已启用。
如果我们已经满足了这次攻击的先决条件,我们可以开始通过基于SubCA
模板请求证书。
这个请求将被拒绝,但我们会保存私钥并记录请求ID。
通过我们的 Manage CA
和 Manage Certificates
,然后我们可以使用 ca
命令和 -issue-request <request ID>
参数来 发出失败的证书 请求。
最后,我们可以使用 req
命令和 -retrieve <request ID>
参数检索已发放的证书。
NTLM Relay to AD CS HTTP Endpoints – ESC8
解释
在安装了AD CS的环境中,如果存在一个易受攻击的 web 登记端点,并且至少发布了一个允许域计算机登记和客户端认证的证书模板(例如默认的**Machine
模板),那么任何启用 spooler 服务的计算机都有可能被攻击者入侵**!
AD CS支持几种基于HTTP的登记方法,通过管理员安装的附加服务器角色提供。这些用于基于HTTP的证书登记的接口容易受到NTLM中继攻击的影响。攻击者可以从受损的计算机上冒充通过入站NTLM进行身份验证的任何AD帐户。在冒充受害者帐户的同时,攻击者可以访问这些 web 接口,以请求使用User
或Machine
证书模板的客户端认证证书。
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 PersistenceNTLM中继攻击的另一个限制是攻击者控制的计算机必须由受害者帐户进行身份验证。攻击者可以等待或尝试强制进行此身份验证:
pageForce NTLM Privileged Authentication滥用
Certify的cas
列举了已启用的HTTP AD CS端点:
msPKI-Enrollment-Servers
属性被企业证书颁发机构(CAs)用来存储证书颁发服务(CES)端点。可以通过利用工具Certutil.exe来解析并列出这些端点:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
滥用Certify
利用 Certipy
Certipy默认根据中继的帐户名称是否以$
结尾来基于Machine
或User
模板发出证书请求。可以通过使用-template
参数来指定替代模板。
然后可以使用类似 PetitPotam 的技术来强制进行身份验证。在处理域控制器时,需要指定-template DomainController
。
无安全扩展 - 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
:
随后,Jane
的 userPrincipalName
被修改为 Administrator
,故意省略了 @corp.local
域部分:
这种修改不违反约束条件,因为 Administrator@corp.local
作为 Administrator
的 userPrincipalName
仍然保持不同。
随后,请求标记为易受攻击的 ESC9
证书模板,请求者为 Jane
:
这里注意到证书的 userPrincipalName
反映了 Administrator
,没有任何“object SID”。
然后将 Jane
的 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
时,具有 GenericWrite
权限的帐户A可以被利用来危害任何帐户B。
例如,拥有对 Jane@corp.local
的 GenericWrite
权限,攻击者旨在危害 Administrator@corp.local
。该过程与ESC9相似,允许使用任何证书模板。
首先,使用Shadow凭据利用 GenericWrite
获取 Jane
的哈希。
随后,Jane
的 userPrincipalName
被更改为 Administrator
,故意省略了 @corp.local
部分,以避免违反约束。
以下是以Jane
身份请求启用客户端认证的证书,使用默认的User
模板。
Jane
的userPrincipalName
然后被恢复为其原始值Jane@corp.local
。
使用获得的证书进行身份验证将产生Administrator@corp.local
的NT哈希,由于证书中缺少域详细信息,需要在命令中指定域。
滥用案例 2
使用包含 UPN
位标志 (0x4
) 的 CertificateMappingMethods
,具有 GenericWrite
权限的帐户 A 可以 compromise 任何缺少 userPrincipalName
属性的帐户 B,包括机器帐户和内置域管理员 Administrator
。
在这里,目标是通过 Shadow Credentials 获得 Jane
的哈希,利用 GenericWrite
来 compromise DC$@corp.local
。
Jane
的userPrincipalName
然后设置为DC$@corp.local
。
一个用于客户端认证的证书被请求,使用默认的User
模板作为Jane
。
Jane
的userPrincipalName
在此过程后被恢复为原始值。
要通过Schannel进行身份验证,使用Certipy的-ldap-shell
选项,指示身份验证成功为u:CORP\DC$
。
通过LDAP shell,诸如 set_rbcd
的命令可以启用基于资源的受限委派(RBCD)攻击,可能危及域控制器。
这个漏洞还涉及到任何缺少 userPrincipalName
的用户账户,或者其 userPrincipalName
与 sAMAccountName
不匹配的情况,因为默认的 Administrator@corp.local
具有较高的 LDAP 权限,并且默认情况下没有 userPrincipalName
,因此成为主要目标。
将 NTLM 中继到 ICPR - ESC11
解释
如果 CA 服务器未配置 IF_ENFORCEENCRYPTICERTREQUEST
,则可以通过 RPC 服务进行未签名的 NTLM 中继攻击。参考链接。
您可以使用 certipy
枚举是否已禁用 Enforce Encryption for Requests
,certipy 将显示 ESC11
漏洞。
滥用场景
需要设置一个中继服务器:
注意:对于域控制器,我们必须在 DomainController 中指定 -template
。
或者使用 sploutchy 的 impacket 分支:
使用YubiHSM访问ADCS CA的Shell访问 - ESC12
解释
管理员可以设置证书颁发机构将其存储在外部设备上,如"Yubico YubiHSM2"。
如果USB设备通过USB端口连接到CA服务器,或者如果CA服务器是虚拟机,则需要一个身份验证密钥(有时称为"密码")供密钥存储提供程序生成和使用YubiHSM中的密钥。
此密钥/密码以明文形式存储在注册表中的 HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword
。
参考 这里。
滥用场景
如果CA的私钥存储在物理USB设备上,当您获得shell访问时,就有可能恢复密钥。
首先,您需要获取CA证书(这是公共的),然后:
最后,使用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:
滥用场景
查找一个用户权限,可以使用 certipy find
或 Certify.exe find /showAllPermissions
。
如果 John
有权限注册 VulnerableTemplate
,则用户可以继承 VulnerableGroup
组的特权。
只需指定模板,就可以获得具有 OIDToGroupLink 权限的证书。
通过证书解释被动语态下的森林妥协
通过被入侵的CA打破森林信任
跨森林注册的配置相对简单。资源森林的根CA证书由管理员发布到账户森林,资源森林的企业CA证书被添加到每个账户森林的NTAuthCertificates
和AIA容器中。澄清一下,这种安排赋予了资源森林中的CA对其管理的所有其他森林完全控制。如果这个CA被攻击者入侵,则资源和账户森林中所有用户的证书可能被他们伪造,从而打破了森林的安全边界。
授予外部主体的注册特权
在多森林环境中,需要谨慎处理发布证书模板的企业CA,这些模板允许经过身份验证的用户或外部主体(属于企业CA所属森林之外的用户/组)注册和编辑权限。 在跨域认证时,AD会将经过身份验证的用户SID添加到用户的令牌中。因此,如果一个域拥有一个允许经过身份验证的用户注册权限的企业CA模板,一个来自不同森林的用户可能会注册该模板。同样,如果模板明确授予外部主体注册权限,则会创建一个跨森林访问控制关系,使一个森林的主体能够在另一个森林中注册模板。
这两种情况都会导致从一个森林到另一个森林的攻击面增加。证书模板的设置可能被攻击者利用,以在外部域中获取额外权限。
最后更新于