CVE-2021-42278域内权限提升

主机IP

域环境

由于hacker拿下AD_USER的shell比较简单，使用ms17_010即可，所有进行省略

可见存在域的同时定位域控IP：

192.168.30.10

获取明文密码：

这个脚本仅仅利用了域控的IP和当前域用户，就成功获取了域控的Shell。

接下来详细分析一下CVE-2021-42287的问题。

Github：

https://github.com/WazeHell/sam-the-admin

一、Kerberos认证简述:

二、PAC简述

在讲述S4U2self提权之前，必须了解微软对原先Kerberos的改进，即PAC的概念

由于我们在上文提过在之前的Kerberos中存在缺少对访问服务的权限管控问题，因此在原来的Kerberos基础中加入了PAC。

三、CVE-2021-42278(伪造AD机器用户)

如果要解释CVE-2021-42287的原理，那么一定离不开CVE-2021-42278

这里的SAMTHEADMIN机器用户不存在$，而这就是CVE-2021-42278

四、 CVE-2021-42287

五、 S4U2self协议：

图片来自微软官方

1.User通过非Kerberos登陆Service 1在请求Service 1中的某项功能时需要访问Service 2可以理解为USER通过WEB服务访问了Service 1现在需要调用Service 2的SQL中的资源。

2.这时Service 1会使用自己的TGT向KDC请求一种授权访问自己服务的TS。KDC解密来自Service 1的TGT后返回一个新的TS1(这个TS证书可转发，因为后面需要使用S4U2proxy协议)，由于这个TS中的PAC是生成的并非原来TGT中发PAC，所以KDC在匹配到服务账户后，会生成与服务账户同权的PAC放入TS1，这也是CVE-2022-42287在拿着与域控同名无$的TGT返回的TS1为什么包含域控的PAC。

3. Service 1 拿着TS1通过S4U2proxy将TS1发送给KDC，即作为User的身份向KDC请求指向Service 2的TS

4. KDC解密TS1后把指向Service 2的TS 2返回给Service 1。

5. Service 1 再拿着TS2去请求Service 2的服务

总的来说，S4U2self的作用是使服务器获取用户身份，然后代理用户向KDC请求。因此S4U2self协议发送的TGSREQ中的Cname，Sname都是指向自己的。