ADCS权限提升

证书模板

注册权限

对于证书模板,模板的 DACL 中的以下 ACE 可能会导致主体具有注册权限:

  • ACE 为主体授予证书注册(Certificate-Enrollment)扩展权限。这个 ACE 授予主体RIGHT_DS_CONTROL_ACCESS 访问权限,其中 ObjectType 设置为0e10c968-78fb-11d2-90d4-00c04f79dc5547 。此 GUID 对应于 Certificate-Enrollment 权限

  • ACE 为主体授予证书自动注册 (Certificate-AutoEnrollment)扩展权限。这个 ACE 授予主体RIGHT_DS_CONTROL_ACCESS 访问权限,其中 ObjectType 设置为 a05b8cc2-17bc-4802-a710-e7c15ab866a249 。此 GUID 对应于 Certificate-AutoEnrollment 扩展权限

  • ACE 为主体授予所有扩展(ExtendedRights)权限。这个 ACE 启⽤ RIGHT_DS_CONTROL_ACCESS 访问权限,其中 ObjectType 设置为 00000000- 0000-0000-0000-000000000000 。此 GUID 对应于ExtendedRights 权限

  • ACE 为主体授予完全控制(FullControl/GenericAll)权限。这个 ACE 启用 FullControl/GenericAll 访问权限

使用域控默认powershell模块查询

Import-Module ActiveDirectory
cd AD:
$Acl = Get-Acl 'CN=<证书模板名称>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<test>,DC=<com>'
$Acl.Access.Count
$Acl.Access | where IdentityReference -match '<user>'
# 也可以是查询组对证书模板的ACE
# ActiveDirectory是域控默认安装的模板

查询域用户test1对ESC1证书模板的ACE

也可以使用powerview查询

扩展

应用程序策略

应用程序策略提供证书的特定用途的重要功能,有时也称为扩展的密钥用法或增强型密钥用法

这是一些常用的应用程序策略

作用
对象标识符

客户端身份验证

1.3.6.1.5.5.7.3.2

CA 加密证书

1.3.6.1.4.1.311.21.5

智能卡登录

1.3.6.1.4.1.311.20.2.2

文档签名

1.3.6.1.4.1.311.10.3.12

文件恢复

1.3.6.1.4.1.311.10.3.4.1

密钥恢复

1.3.6.1.4.1.311.10.3.11

Microsoft 信任列表签名

1.3.6.1.4.1.311.10.3.1

合格的部属

1.3.6.1.4.1.311.10.3.10

根列表签名程序

1.3.6.1.4.1.311.10.3.9

可以根据对象标识符(OID)查询对应作用的证书,其Ldap-Display-Name为pKIExtendedKeyUsage

其他OID可以在安装证书机器上使用certtmpl.msc打开证书模板控制台,在证书模板->更多操作->查看对象标识符中查看

可以使用adfind或者powerview等工具进行ldap查询,查询使用特定应用程序策略的证书模板

查询具有客户端身份验证应用程序策略的证书模板:

也可以使用powerview

发布要求

除了证书模板和企业CA访问控制限制之外,还有用于控制证书注册的两个证书模板设置,就是发布要求

当选择"CA证书管理程序批准",申请就会至于挂起状态,其msPKI-Enrollment-Flag属性会被设置为CT_FLAG_PEND_ALL_REQUESTS (0x2)

用户(计算机)申请注册证书之后需要证书管理员在颁发证书之前予以批准或拒绝

可以使用ldap根据是否选择"CA证书管理程序批准"查询证书模板,其Ldap-Display-Name为msPKI-Enrollment-Flag

查询选择了"CA证书管理程序批准"的证书模板

注册代理、授权签名和应用程序策略

"授权签名的数量"和"应用程序策略"是发布要求的第二组限制,前者要求证书请求(CSR)在证书被颁发之前由现有的授权证书进行数字签名;后者定义了颁发证书所需签名证书必须具有的EKU OID

这些设置常见用途为证书申请代理,其授予可以代表其他用户请求证书的实体。CA会向注册代理账户颁发至少包含证书请求代理EKU(OID为1.3.6.1.4.1.311.20.2.1)的证书,一旦颁发,注册代理就可以代表其他用户签署CSR并请求证书

可以使用ldap查询发布要求中证书请求的计数器签名中所需的RA应用程序策略OID,其Ldap-Display-Name为msPKI-RA-Application-Policies,授权签名数量的Ldap-Display-Name为msPKI-RA-Signature

查询证书请求的计数器签名中所需的RA应用程序策略为证书申请代理的证书模板

使用者名称

与证书关联的私钥的持有者称为使用者,这可以是用户、程序或几乎任何对象、计算机或服务

Windows 可根据 Active Directory 域服务 (AD DS) 中存储的使用者信息自动生成使用者名称,或可通过使用者手动提供使用者名称(例如,使用证书注册网页创建和提交证书申请)

在选择"请求中提供"选项后,"使用现有证书中的使用者信息进行自动注册续订请求"选项可用于简化将使用者名称添加到证书续订请求的任务,可使证书注册客户端基于相同的证书模板从现有计算机证书中读取使用者名称和使用者备用名称信息;用于已过期、吊销或在续订期内的计算机证书

在请求中提供的msPKI-Certificate-Name-Flag属性为CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT

使用现有证书中的使用者信息进行自动注册续订请求的msPKI-Certificate-Name-Flag属性为CT_FLAG_OLD_CERT_SUPPLIES_SUBJECT_AND_ALT_NAME

在选择"用Active Diretory中的信息生成之后"可以配置一下选项

使用者名称格式

设置
描述

公用名 msPKI-Certificate-Name-Flag属性为CT_FLAG_SUBJECT_REQUIRE_COMMON_NAME

CA 根据从 AD DS 获取的公用名 (CN) 创建使用者名称。此名称在域中应该唯一,但在企业中可能不唯一。

完全可分辨名称 (DN) msPKI-Certificate-Name-Flag属性为CT_FLAG_SUBJECT_REQUIRE_DIRECTORY_PATH

CA 根据从 AD DS 获取的完全可分辨名称创建使用者名称。这可确保在企业中名称唯一。

在使用者名称中包括电子邮件名msPKI-Certificate-Name-Flag属性为CT_FLAG_SUBJECT_REQUIRE_EMAIL

如果 Active Directory 用户对象中填充了电子邮件名字段,则该电子邮件名将作为使用者名称的一部分包括在公用名或完全可分辨名称中。

此证书不要求名称值。

DNS名称msPKI-Certificate-Name-Flag属性为CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN

从活动目录中请求者用户对象的 DNS 属性作为 主题中的CN 颁发的证书

将这个信息包括在另一个使用者名称中

设置
描述

电子邮件名 msPKI-Certificate-Name-Flag属性为CT_FLAG_SUBJECT_ALT_REQUIRE_EMAIL

如果 Active Directory 用户对象中填充了电子邮件名字段,则将使用该电子邮件名。

DNS 名称 msPKI-Certificate-Name-Flag属性为CT_FLAG_SUBJECT_ALT_REQUIRE_DNS

这是申请证书的使用者的完全限定的域名 (FQDN)。这在计算机证书中最常用。

用户主体名称(UPN) msPKI-Certificate-Name-Flag属性为CT_FLAG_SUBJECT_ALT_REQUIRE_UPN

用户主体名称是 Active Directory 用户对象的一部分,并将使用该名称。

**服务主体名称(SPN)**CT_FLAG_SUBJECT_ALT_REQUIRE_SPN

服务主体名称是 Active Directory 计算机对象的一部分,并将使用该名称。

可用于域身份验证的EKU

描述
OID

Client Authentication

1.3.6.1.5.5.7.3.2

PKINIT Client Authentication*

1.3.6.1.5.2.3.4

Smart Card Logon

1.3.6.1.4.1.311.20.2.2

Any Purpose

2.5.29.37.0

SubCA

(no EKUs)

默认情况下,AD CS 部署中不存在 OID 1.3.6.1.5.2.3.4,因此需要⼿动添加,但它确实适⽤于客户端⾝份验证

权限提升

环境

ESC1-5

ESC6-7

ESC8

ESC1

配置

  • 颁发CA授予低权限用户请求权限(默认)

  • 模板中CA证书管理程序批准未启用(默认)

  • 模板中无需授权签名(默认)

  • 模板允许低权限用户注册

  • 证书模板定义了域身份验证的EKU(经测试五种EKU均成功利用)

  • 证书模板允许请求者在CSR中指定subjectAltName

利用

  • 查找漏洞模板

  • 伪造域管理员Administrator注册证书

  • 将含有公私钥的pem证书整个复制到kali中使用openssl进行格式转化

    在这里输入密码

  • 将生成的cert.pfx证书放进机器,使用Rubeus申请TGT获取票据并传递,klist查看票据已经存在

  • 接下来即可使用dcsync等等攻击

ESC2

配置

与ESC1配置基本相同,主要差别在EKU中,还有少了使用者名称的"在请求中提供"

  • 颁发 CA 授予低权限用户请求权限 (默认)

  • 模板中 CA 管理员审批未启用 (默认)

  • 模板中不需要授权的签名 (默认)

  • 模板允许低权限用户注册

  • 描述为任何目的或者无EKU

  • 使用者名称

利用

在阅读白皮书翻译文章的时候,有一句话提到"但攻击者可以使用它们以请求它们的用户身份向 AD 进行身份验证,这两个 EKU 无疑是对请求它们的用户自身很危险",所以个人认为该方式用于本地权限提升,如果当前域用户在本地管理员组,但是当前令牌并不是完整管理员令牌的(被UAC删除了特权),可以尝试获取证书后申请票据,进行票据传递攻击(域用户在远程是不需要过UAC的)

当然ESC2也可以对其他应用程序造成影响(如 SAML、AD FS 或IPSec)

其实可以选择用于域身份验证的EKU,只是选择了任何目的或者无EKU可以用于其他目的

  • 查找漏洞模板

  • 申请证书

  • 将含有公私钥的pem证书整个复制到kali中使用openssl进行格式转化

    在这里输入密码

  • 将生成的cert.pfx证书放进机器,使用Rubeus申请TGT获取票据

  • 进行票据传递攻击

    特权已经是完整管理员令牌中的特权了

ESC3

ESC3_1配置

  • 颁发 CA 授予低权限用户请求权限 (默认)

  • 模板中 CA 管理员审批未启用 (默认)

  • 模板中不需要授权的签名 (默认)

  • 模板允许低权限用户注册

  • 证书模板中定义了证书请求代理 EKU (1.3.6.1.4.1.311.20.2.1)

  • 使用者名称配置

ESC3_2配置

  • 颁发 CA 授予低权限用户请求权限 (默认)

  • 模板中CA管理员审批未启用 (默认)

  • 模板中不需要授权的签名 (默认)

  • 模板允许低权限用户注册

  • 模板定义了启用认证的EKU

  • 模板模式版本1或大于2并指定应用策略,签发要求证书请求代理EKU

  • 没有在CA上对登记代理进行限制 (默认)

  • 使用者名称配置

ESC3利用

  • 查找漏洞模板

  • 尝试寻找第二个可以被利用的模板

  • 请求第一个模板的证书

  • 将含有公私钥的pem证书整个复制到kali中使用openssl进行格式转化

    在这里输入密码

  • 利用 Certify 通过 esc3_1.pfx 代表 administrator 申请 esc3_2.pfx 的身份认证证书,得到的证书同样可以进行 ptt 利用

  • 将请求到的再去做一次证书

    将含有公私钥的pem证书整个复制到kali中使用openssl进行格式转化

    在这里输入密码

  • 将生成的esc3_2.pfx 证书放进机器,使用Rubeus申请TGT获取票据并传递,klist查看票据已经存在

  • 接下来即可使用dcsync等等攻击

ESC4

证书模板也是AD中的对象,那么它也有安全描述符

对于攻击者,主要关注五种用户主体对证书模板的安全描述符

权限
描述

Owner

对象所有人,可以编辑任何属性

Full Control

完全控制对象,可以编辑任何属性

WriteOwner

允许委托人修改对象的安全描述符的所有者部分

WriteDacl

可以修改访问控制

WriteProperty

可以编辑任何属性

配置

  • 给test2域用户添加了写入的属性

  • 其他配置(随意配置)

利用

  • 查看证书模板,有没有当前用户或低用户权限有写入权限的模板

  • 这里如果没有当前用户注册权限,但是有写入权限可以给用户添加注册权限,这里给test2用户添加注册权限

  • 查看ldap属性,后续更改后要还原证书模板

  • 使用AdMod arrow-up-right更改证书模板,改为ESC1模板的样子

    根据ESC1来说主要更改以下地方:

    • 使用者名称请求中提供,即msPKI-Certificate-Name-Flag属性为CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT,根据微软官方文档arrow-up-right,其值为1

    • 设置一个可以用于身份验证的EKU,例如设置pKIExtendedKeyUsage1.3.6.1.4.1.311.20.2.2(智能卡登录)的

    • 发布要求的"CA证书管理程序批准"和"授权签名数量"去掉

      以上的操作也可以选择powerview操作

  • 使用certify或者域控那边查看更改成功

  • 接下来就是ESC1中的操作了

ESC5

Certificate Templates 证书模板

如果对 CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=fbi,DC=gov有创建子对象CreateChild(及相关)的权限即可创建证书模板

相关权限是指writeDacl,GenericAll

可以使用writeDacl权限给自己加上GenericAll权限

创建证书模板

Enrollment Services 注册服务

如果对Enrollment Services下的某个CA有写入属性和管理CA(或者写入属性+颁发和管理证书)权限即可颁发证书。管理CA,颁发和管理证书都是扩展熟悉,可以使用PSPKI查询;如果使用powerview查看只能看见对这个CA有ExtendedRight权限

当然拥有writeDacl,GenericAll权限也可以

颁发证书

前面两个拒绝访问应该是尝试创建证书模板的拒绝访问,不影响颁发证书

Public Key Services

如果对 CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=拥有writeDacl及GenericAll权限就可以尝试控制整个ADCS,其实也就是将上面两个条目的利用结合起来

如果权限继承属性设置没有让子代继承需要修改继承属性即可继续攻击,否则无权限操作

可以交互式登录用户之后使用ADexplorer修改(可以不用输入账号密码)

修改之后在尝试创建漏洞证书模板及颁发证书

ESC6

这涉及到 CA 的 EDITF_ATTRIBUTESUBJECTALTNAME2 标志,这个标志的开启可以让攻击者为任意域用户注册证书,与ESC1中的CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 标志有相同的效果

要在 CA 上启用 EDITF_ATTRIBUTESUBJECTALTNAME2 标志,需要在 AD CS 服务器上执行以下命令并重启CertSvc 服务,这将在注册表项\CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy 的 EditFlags 键中设置 EDITF_ATTRIBUTESUBJECTALTNAME2 值

重启之后,可以使用以下命令查看该标志是否开启

利用

ESC6在CVE-2022–26923中的补丁修复,就临时换了域环境(ICE.COM),当前用户是test2,test1为域管用户

  • Certify 的 find 命令也将尝试检查它枚举的每个 CA 证书颁发机构的这个标志值

请求者名称并不是"在请求者提供",低权限用户可注册

  • 伪造管理员请求证书

  • 后面操作与ESC1一样,直接放出dcsync截图

ESC7

这是基于对Enrollment Services 下CA的权限

使用powershell的PSPKI模块查看扩展权限

如果使用powerview只能看见ExtendedRight,不够详细

如果对其拥有"管理CA"和"颁发和管理证书"权限,则可以为其添加ESC6中的EDITF_ATTRIBUTESUBJECTALTNAME2 标志

利用

添加EDITF_ATTRIBUTESUBJECTALTNAME2 标志之后就是ESC6中的攻击了。当然根据ESC5来看,有这个权限还可以尝试颁发证书

ESC8

ESC8是NTLM Relay to ADCS HTTP Endpoints

可利用原因:

  • 默认情况下,web注册界面(在http://<caserver>/certsrv/访问旧版ASP应用程序)仅支持HTTP,无法防止NTLM中继攻击。它明确地只允许通过其 Authorization HTTP 标头进行NTLM 身份验证,因此更安全的协议(如 Kerberos)不可用

  • 证书注册服务(CES)、证书注册策略(CEP)Web 服务和网络设备注册服务(NDES)默认支持通过其授权 HTTP 标头协商身份验证,协商身份验证支持 Kerberos 和 NTLM。因此,攻击者可以在 Relay攻击期间协商到 NTLM 身份验证。这些 Web 服务至少默认启用 HTTPS,但不幸的是 HTTPS 本身并不能防止 NTLM 中继攻击。只有当 HTTPS 与通道绑定相结合时,才能保护 HTTPS 服务免受 NTLM 中继攻击。不幸的是,AD CS 没有为 IIS 上的身份验证启用扩展保护,这是启用通道绑定所必需的

利用条件:

  • ADCS 配置为允许 NTLM 身份验证ADCS 配置为允许 NTLM 身份验证

  • NTLM身份验证不受EPA或SMB签名保护 (域控是有SMB签名保护的,所以重新配置了ADCS在其他机器)

  • ADCS 正在运行以下任一服务:

    • 证书颁发机构 Web 注册

    • 证书注册 Web 服务

利用

  • 定位域内CA服务器

    因为域控默认开启smb签名保护,这里选择其他证书服务机器

    或者直接

  • 测试连通性

  • 设置ntlm relay的监听

  • 强制域控访问攻击机,这里使用spoolsample

    这边接收到了证书

  • 使用上面接收到的证书在rubeus中获取域控机器用户的TGT并注入

  • 尝试使用dcsync获取域用户hash

    成功,可以发现一开始是不能dcsync的(一开始没有注入TGT),后面重新打开mimikatz就可以了(注入了TGT)

工具

ADCSTemplatearrow-up-right (需要Active Directory模块)

server机器安装ActiveDirectory模块:

SpoolSamplearrow-up-right

Certifyarrow-up-right

AdMod (joeware.net)arrow-up-right

AdFind (joeware.net)arrow-up-right

mimikatzarrow-up-right

Rubeusarrow-up-right

PowerView.ps1arrow-up-right

ADExplorerarrow-up-right

参考文章

AD CS Domain Escalation - HackTricksarrow-up-right

ADCS 攻击面挖掘与利用-安全客 - 安全资讯平台 (anquanke.com)arrow-up-right

Skidaddle Skideldi - I just pwnd your PKI – LuemmelSec – Just an admin on someone else´s computerarrow-up-right

Attack Surface Mining For AD CS - 跳跳糖 (tttang.com)arrow-up-right

Certified_Pre-Owned.pdf (specterops.io)arrow-up-right

证书模板 (forsenergy.com)arrow-up-right

ADCS + PetitPotam NTLM Relay: Obtaining krbtgt Hash with Domain Controller Machine Certificate - Red Team Notes (ired.team)arrow-up-right

Last updated