从NTAuthCertificates证书伪造到内网穿透实践与思路

上篇文章讲了NTAuthCertificates证书伪造，获取白银票据的实验，在研究过程中还有一些问题点，后面深入研究了证书发布者组与 Active Directory 域中的证书服务 (ADCS)

并且我们发现，Microsoft 不会通过 AdminSDHolder 保护该组：

证书发布者的目的是什么？

微软关于该组的官方文档：

“证书发布者组的成员有权发布 Active Directory 中用户对象的证书。“

意思是组的成员对用户和计算机的userCertificate属性具有写入权限，并且此权限由AdminSDholder配置控制：

userCertificate 属性是一个多值属性，包含颁发给用户的 DER 编码的 X509v3 证书。如果在证书模板中设置了“发布到 Active Directory”，则由 Microsoft 证书服务颁发给该用户的公钥证书将存储在此属性中：

并且大部分情况下这还是默认的设置，这样设置在使用电子邮件加密、电子邮件签名或加密文件系统 (EFS) 时非常有用。

但是如果我们想利用这一点，目前还没有合理的路径可以允许攻击者通过更改此属性中存储的证书来提升权限。

理论上，通过向属性添加大量证书以在 DC 之间创建复制问题，可能会出现拒绝服务攻击。

因此，如果确实需要此属性，至少请选中“不要自动重新注册..”，这将防止此属性不受控制的增长。

赋予配置分区中的证书发布者的权限

证书发布者 可以控制位于 AD 配置分区的“公钥服务”容器下的一些对象：

CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=…

查看文献我们会发现这样一段话

“This container stores the intermediate CA and cross-certificates. All certificates from this container are propagated to each client in the Intermediate Certification Authority certificates store via Group Policy.“

这说明证书发布者对其拥有完全控制权，因此他们可以通过certutil或adsiedit创建带有假证书的新条目，例如：

certutil -dspublish -f fakeca.crt subCA
certutil -dspublish -f fakeca.crt crossCA

但是由于缺少root CA，发布的假证书将不被信任，所以这里也只是猜想（利用方法还需要更多实践） 还有一点值得注意的是，证书发布者无法修改在安装 CA 期间创建的原始 AIA 对象:

CN=[CA_NAME],CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC= …

证书吊销列表分发点 (CDP) 提供有关在何处查找与证书关联的 CRL 的信息。

证书发布者的成员可以完全控制此容器和后续对象。但是 ADCS 中这个容器的用途是什么？

官方的解释是：

“This container is used to store certificate revocation lists (CRL). To differentiate CRLs a separate container is created for each CA. Typically CA host NetBIOS name is used. CRLs from CDP containers are NOT propagated to clients and is used only when a certificate refers to a particular CRLDistributionPoint entry in CDP container.”

成员可以使用伪造的属性覆盖现有对象的属性，尤其是certificateRevitationList和deltaRevitationList属性，或者直接将其删除。然而，由于这些配置不会复制到客户端，因此从攻击者的角度来看，这些权限并不是很有用。

值得注意的是，证书发布者无法修改与 CA 服务器的 AIA/CDP 配置相关的扩展：

CN=[CA_NAME],CN=Certification Authorities,CN=Public KeyServices,CN=Services,CN=Configuration,DC=..

该容器存储受信任的根证书。CA服务器的根证书会自动放置在内部，并且证书将在受信任的根证书颁发机构下发布（通过GP）。

虽然证书发布者可以完全控制 CA_NAME 对象，但他们无法添加其他证书颁发机构对象。此限制可能是为了降低作为该组成员的恶意用户发布虚假 CA 证书的风险。此类假证书可能会受到所有客户的信任。因此，需要考虑哪些潜在的滥用情况？

滥用证书颁发机构对象

我的目标是探索潜在的问题，让我的假证书颁发机构 (CA) 发布并被所有客户信赖，尽管存在既定的限制。

经过各种测试，我尝试用假证书替换 CA 对象的caCertificate属性中存储的现有证书，或向当前caCertificate添加 假证书（但没有成功，因为假 CA 未发布），我最终发现一种绕过现有安全边界的解决方案。

创建一个与官方 CA 具有完全相同通用名称的假 CA，如果它按预期工作，它将被附加到现有 CA 的配置中

使用openssl工具创建假的自签名CA，这正是我在上一篇内容中提到的方法。

提供的通用名称与我们官方 CA 的名称相匹配。

获得证书后，我们将使用作为Cert Publishers 成员的用户的凭据登录到 AD 域，并继续将证书添加到证书颁发机构容器中

我们可以安全地忽略该错误，并使用adsiedit我们可以确认证书已添加：

成功了，我们现在将假证书颁发机构 (CA) 建立为受信任的实体。为了确认其功能，我们将使用我们的 CA 颁发的 SSL 证书配置 Web 服务器。

获得 csr 文件 (evil.csr) 后，我们需要为 CRL 端点和证书签名设置 CA 配置。

[ca]
default_ca = EVILCA
[crl_ext]
authorityKeyIdentifier=keyid:always
[EVILCA]
dir = ./
new_certs_dir = $dir
unique_subject = no
certificate = ./evilca.crt
database = ./certindex
private_key = ./evilca.key
serial = ./certserial
default_days = 729
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions
crlnumber = ./crlnumber
default_crl_days = 729
default_md = sha256
copy_extensions = copy
[myca_policy]
commonName = supplied
stateOrProvinceName = optional
countryName = optional
emailAddress = optional
organizationName = supplied
[myca_extensions]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth
crlDistributionPoints = URI:http://10.10.10.10/root.crl

我们现在准备好处理证书请求：

并将evil.crt导入到我们的网络服务器上。从加入域的计算机，我们尝试导航到https://myevilserver.mylab.local：

正如预期的那样，该网站受到我们的假 CA 的信任。

伪造的受信任证书可能使恶意行为者能够执行各种攻击，通过注册随后受信任的任何类型的证书，可能会导致整个域受到损害，也可以做中间人攻击，这里不做过多演示了

更进一步

为了能够通过 PKINIT 或 Schannel 使用伪造的客户端证书进行身份验证，CA 还必须出现在NTAuth 证书存储中。

让我们考虑这样的场景：Cert Publishers组被授予对NTAuthcertificates对象的写访问权限。虽然不是默认设置，但我遇到过一些实现此（错误）配置的现实场景。这改变了我上一篇文章中描述的默认情况，这样就导致对NTAuthcertificate具有写权限，从单纯的持久性技术转变为真正的权限升级。这种转变值得注意，特别是考虑到我们已经拥有一个值得信赖的证书颁发机构，可以伪造客户端证书。

此时我们需要的就是将假 CA 证书添加到NTAuthcertificates对象中（假设证书发布者已被授予此权限）

让我们等待域控制器上的 GP 刷新：

certipy forge -ca-pfx evilca.pfx -upn [email protected] -subject 'CN=Administrator,CN=Users,DC=mylab,DC=local' -crl 'http://10.10.10.10/root.crl'
certipy auth -pfx administrator_forged.pfx -dc-ip 10.10.10.2

并得到预期的结果！

结论

实验结束后，我们可以得出以下结论：

• 证书发布者的成员可以在 ADCS 环境的控制下添加恶意证书颁发机构，并随后受到所有客户端的信任。虽然在此 CA 下颁发的证书不会自动被信任用于通过 PKINIT 或 SChannel 进行客户端身份验证，但它们仍然可能被滥用于其他恶意任务。
• 在这些场景中，证书发布者成员资格加上对NTAuthcertificates 的写入权限是最危险的组合。可以伪造并请求证书Silver，用于针对域中的任何用户进行客户端身份验证。
• 证书发布者应被视为高价值目标，并且应主动监控该组中的成员资格，以及源自非特权用户导致该组的可能攻击路径。