CertiFried漏洞（CVE-2022-26923）的AD提权方法是什么？

本文通过 Google 翻译 Domain Privilege Escalation – CVE-2022-26923: CertiFried 这篇文章所产生，本人仅是对机器翻译中部分表达别扭的字词进行了校正及个别注释补充。 导航 0 前言 1 漏洞 CVE-2022-26923 简介 2 远程枚举必要条件 2.1 枚举证书颁发机构和 DNSHostname 2.1.1 nmap 2.1.2 ldapsearch 2.1.3 certipy 2.2 枚举 ms-DS-MachineAccountQuota 2.2.1 ldapsearch 2.2.2 bloodyAD.py 3 远程利用 CVE-2022-26923 3.1 新建特殊机器帐户 3.2 申请证书 3.3 申请 TGT 票据并检索 DC 机器帐户的哈希 3.4 利用哈希传递转储 DC 所有账户的哈希 4 本地枚举必要条件 4.1 枚举 DNSHostname：nslookup 4.2 枚举 DNSHostname：PowerShell 4.3 枚举证书颁发机构：certutil 4.4 枚举证书颁发机构：PowerView.ps1 4.5 枚举 ms-DS-MachineAccountQuota：PowerView.ps1 5 本地利用 CVE-2022-26923 5.1 新建机器帐户并篡改 DNSHostname 属性 5.2 申请证书 5.3 申请 TGT 票据 5.4 发起 DCSync 攻击 6 预防措施 0、前言 在这篇文章中，我们将深入探讨一个破坏性极强的 CVE，该漏洞于 2022 年 5 月 10 日星期二公布并修复：CVE-2022-26923 – CertiFried。为此，我们将学习各种远程和本地的攻击方法，以及一些用于利用此漏洞所需条件的枚举技巧。 注：本文会多次提到 计算机账户 和 机器账户，实际上这两个词语所指的都是同一个意思。 1、漏洞 CVE-2022-26923 简介 CVE-2022-26923 是一种 AD 域权限提升漏洞，允许普通用户在启用 Active Directory 证书服务（AD CS） 的域环境中将权限提升至域管理员。漏洞原因在于 AD CS 在为机器账户签发证书时（这是一种支持 Kerberos 证书认证的证书），不会验证证书请求中请求账户的 UPN （即机器账户属性 DNSHostname ）是否属于请求者，而是直接认为账户的 UPN 就是请求者。这使得，如果攻击者伪造 UPN 字段为 域控机器账户，那 ADCS 便会为其签发一个域控机器账户的证书（相当于域管理员身份）。攻击者进而便可以使用该证书进行 Kerberos 证书认证，从而直接获得一个类似管理员身份的 TGT 票据。 要利用此方法进行恶意攻击，攻击者只需找到域中任意一个标准用户的凭据即可。这样，他们就可以以标准用户的身份创建一个机器账户 A，然后篡改该机器账户 A 的属性 DNSHostname 为 DC 的机器账户 。一旦篡改完成，攻击者便可以以机器账户 A 的身份请求到 DC 的机器账户的证书，进而凭借证书获取到获得 DC 的 TGT 以及 DC 的 NTLM 哈希，最后便可以使用 DC 的哈希转储整个域中的所有哈希值。 注：（1）上面所说的 DC 的机器账户 是类似于 DC2012$.domain.local 这样的格式，它们的权限相当于本地管理员或 SYSTEM。 （2）每一个域用户都可以在域中新建一定数量的机器账户（默认一般是 10 个）。该功能似乎是历史遗留的特性，放在如今并没有什么实际用途，反而容易受到攻击利用。 （3）Kerberos 身份认证的方式：密码认证、证书认证、FAST、Keytab、TGT 缓存。 若想深入了解这次的攻击，还可参考这篇 文章。 2、远程枚举必要条件 在本示例中，假设我们已经拥有了一组有效的凭证（efrost 用户）。 此外，我们还需要从 DC 中确认另外三条信息，分别是：DNSHostname、证书颁发机构、ms-DS-MachineAccountQuota。而这些信息我们可以使用一些不同的工具和技术通过远程或本地的方式向 DC 查询。 2.1、枚举证书颁发机构和 DNSHostname 可以使用以下这些工具来远程枚举 DC 上的证书颁发者：nmap、ldapsearch、Certipy！ DNSHostname 一般就是 主机名 + 域名 的组合。