阅读量 76400

分享到：

发布时间：2022-01-12 10:00:53

这两天Log4j余波还没过去，就看到了windows爆了一个提权漏洞，从域用户直接到域控(从此翻身做主人)，趁热学习。

域环境 AD：192.168.1.2 win7：192.168.1.3 

1.创建域用户

2.配置域用户远程登录权限

这里有一个小坑。如果不配置此设置，域内主机将无法通过远程桌面访问。有两个点需要配置。DC上配置testuser1到Remote Desktop Users组

第二步是向域内主机添加testuser1到允许登录的账户

最终效果如下

复制完成后，发现没有弹回来shell，去git上看到如下issue，脚本在ubuntuserver从目前的结果来看，上执行是成功的DC的ticket

1.Kerberos 基础概念

从这里可以看出，这个漏洞的核心实际上是普通域用户冒充的DC拿到DC的ticket，进而实现对DC完成提权操作。上述过程的核心是获取DC的ticket，这里简述一下ticket的概念

在域环境中，Kerberos该协议用作身份认证，如上图所示，是一个简单的身份认证过程，具体细节可参考相关资料，这里只介绍几个术语：

• KDC(Key Distribution Center)： 密钥分发中心包括两项服务：AS和TGS
• AS(Authentication Server)： 身份认证服务
• TGS(Ticket Granting Server)： 票据授予服务
• TGT(Ticket Granting Ticket): 身份认证服务授予的票据用于身份认证，存储在内存中，默认有效期为10小时

TGT票据包含 Client/TGS Session Key （AS 随机字符串)、 Client Info（PAC？） 和 Timestamp TGT票据由TGS 密钥(krbtgt 用户的 NTLM Hash)用户无法解密加密。

• ST(Server Ticket) 服务端票据，用户使用票据要求相应的服务，验证后获得服务访问权
• Pass The Ticket： 如果我们能得到用户TGT，并将其导入内存，冒充用户获得其访问权限

网上有很多版本kerberos的流程（上面记录的流程）是

1.用户向KDC发起AS_REQ,请求凭证是用户hash加密时间戳，KDC使用用户hash解密，如果结果正确返回krbtgt hash加密的TGT票据 2.用户凭借TGT票据向KDC为特定服务启动TGS_REQ请求，KDC使用krbtgt hash解密，如果结果正确，返回服务hash 加密的TGS票据 3.用户拿着TGS票据要求服务，服务使用自己的服务hash解密TGS票据。如果解密正确，用户可以访问。

上述过程似乎是正确的，但忽略了最重要的因素之一，即用户是否有权访问该服务。在上述过程中，只要用户hash如果是正确的，你可以得到它TGT，有了TGT，就可以拿到TGS，有了TGS，任何用户都可以访问任何服务。也就是说，上述流程已经解决Who am i?问题没有解决， “What can I do?”的问题。

为了解决上述问题，微软引进了它PAC，引进PAC之后的kerberos流程变成

用户向KDC发起AS_REQ,请求凭证是用户hash加密时间戳，KDC使用用户hash解密，如果结果正确返回krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含用户的sid，用户所在的组。

1.用户凭借TGT票据向KDC为特定服务启动TGS_REQ请求，KDC使用krbtgt hash解密，如果结果正确，返回服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据，这也是kerberoating任何用户都可以使用，只要hash正确的，可以要求域内任何服务TGS具体内容可参考票据Windows学习内网协议Kerberos篇之TGSREQ& TGSREP) 2.用户拿着TGS票据要求服务，服务使用自己的服务hash解密TGS票据。如果解密正确，拿着PAC去KDC询问用户是否有访问权限，域控解密PAC。获取用户的sid，以及所在组，然后判断用户是否有访问服务权限和访问权限(有些服务没有验证)PAC这一步也是白银票据成功的前提，因为即使有用户hash，可以制作TGS，也不能制作PAC，PAC当然，验证不成功，但有些服务没有验证PAC，允许用户访问白银票据成功的前提。

特别说明，PAC用户和服务的整个过程是看不见的。KDC能制作和查看PAC。

2.换句话说Kerberos流程

一个认证服务器（Authentication Server，简称 AS）：验证Client端身份(确定你是身份证上的本人)，验证通过后会给票证发票（Ticket Granting Ticket，简称 TGT）给 Client。 一个票据授权服务器（Ticket Granting Server，简称 TGS）：通过 TGT（AS 发送给 Client 访问票) Server 端的票（Server Ticket，简称 ST）。ST（Service Ticket）也有资料叫 TGS Ticket。

3.漏洞原理

• CVE-一般来说，机器账户的名称应该是2021-4278$结尾，但AD域内机器账户名未验证。

导致漏洞AS签发机器的名字不会结束 结 尾 的 T G T （ 伪 装 域 控 主 机 名 的 T G T ） 正 常 域 控 T G T 内 C l i e n t i n f o 里 的 机 器 名 信 息 比 如 说 时 M a c h i n e N a m e 结尾的TGT(伪装域控主机名TGT） 正常域控TGT内Client info例如，机器名中的信息 MachineName 结尾/span>的TGT（伪装域控主机名的TGT）正常域控TGT内Clientinfo里的机器名信息比如说时MachineName 该漏洞伪造的域控TGT内的Client info内的机器名信息就是 MachineName（并不合法） 因为TGT本身是被KDC用TGS 密钥进行加密的，因此当后续用户使用TGT向TGS请求服务票据时TGS是信任TGT内的信息的。

• CVE-2021-42287，与上述漏洞配合使用，该漏洞核心在于：当请求服务 ST 的账户没有被 KDC 找到时，KDC 会自动在尾部添加 **$** 重新搜索。创建与DC机器账户名字相同的机器账户（不以$结尾），账户请求一个TGT后，更名账户，然后通过S4U2self申请TGS Ticket，接着DC在TGS_REP阶段，这个账户不存在的时候，DC会使用自己的密钥加密TGS Ticket，提供一个属于该账户的PAC，然后我们就得到了一个高权限ST。

在请求到TGT之后，攻击者将机器名修改为其他机器名，然后用该TGT向TGS请求S4U2self服务，这里要先理解ST票据生成的流程才能明白攻击得以完成的原因。

TGS_request 、TGS_reply

TGS-REQ（请求）： 当TGS服务收到到client请求体KRB_TGS_REQ时，因为TGS端并没有session key，只能先利用TGS 密钥(krbtgt 的 NTLM Hash)去解TGT部分内容，得到session key，再去解Session key(client info+时间戳)部分，从而验证该用户是否是AS颁发给该client的。验证通过后，给client回复KRB_TGS_REP给client

TGS-REP（返回）： TGS 收到请求后，检查 KDC 数据库中是否存在所请求的服务(Service ID)。如果存在，TGS 使用 TGS 密钥(krbtgt 的 NTLM Hash)解密 TGT，得到 Client/TGS Session Key、timestamp、Client info；同时使用从 TGT 中解密得到的 Client/TGS Session Key去解密 Authenticator2，得到 Client info 和 timestamp。比对 Authenticator2 和TGT 的解密内容以验证通过。

• TGS 比对 Authenticator2 包含的 Client ID 和 TGT 中的 Client ID
• 比较时间戳（误差范围在2分钟）
• 通过生命周期字段检查 TGT 是否过期
• 检查 Authenticator2 是否在 TGS 的缓存中
• 若原始请求中的网络地址不为 NULL，比较 TGT 中的 IP 和请求的 IP

验证成功后，随机生成 Client 所请求服务的会话密钥 Client/Server Session Key； 使用 **Server 密钥（即服务器计算机的NTLM Hash）**对 Client/Server Session Key、Client Info（包含 Client ID）、TimeStamp 加密得到 Client-To-Server Ticket（也称为 ST）； 使用 Client/TGS Session Key 对 Client/Server Session Key 加密得到sessionkey_tgs 最终将 Client-To-Server Ticket、sessionkey_tgs 返回给 Client。

域控机器名：MachineName$ 伪造机器名：MachineName

介绍完ST票据，其实漏洞的核心点也已经触手可及了，当TGS使用TGS密钥对用户发送过来的TGT进行解密后，获取到了机器名：MachineName，同时由于用户请求的是S4U2self服务，因此需要用机器名对应的密钥（即主机自身的密钥）来对ST进行加密，然而我们已经将主机名修改为了其他名称，此时域内是不存在MachineName的机器名的，因此TGS自行在MachineName后添加了 $ 符号，再次在机器名列表中进行搜索，域控的机器名与之匹配，于是TGS就使用了MachineName$（也就是域控）的密钥加密了S4U2self的ST发给了用户，当用户使用该ST去访问域控时就获取了域控的控制权。 这里关于PAC的其实还有写不清楚的地方，看其他的分析里说法是TGS在利用域控的密钥对ST进行加密的时候就顺便提供了域控账户的PAC到ST中，从而使得域控在使用自身密钥解密ST后，通过了向TGS验证PAC有效性的过程。（没有深究了）

假如域内有一台域控名为 DC（域控对应的机器用户为 DC），此时攻击者利用漏洞 CVE-2021-42287 创建一个机器用户 saulGoodman，再把机器用户 saulGoodman$ 的 sAMAccountName 改成 DC（伪）。然后利用 DC（伪） 去申请一个TGT票据。再把 DC 的sAMAccountName 改为 saulGoodman。这个时候 KDC 就会判断域内没有 DC （伪）和这个用户，自动去搜索 DC（DC$是域内域控DC（真） 的 sAMAccountName），攻击者利用刚刚申请的 TGT 进行 S4U2self，模拟域内的域管去请求域控 DC（真） 的 ST 票据，最终获得域控制器DC的权限。 注意复现过程中使用了 powerspolit 和 Rubeus 两个工具

1.创建本地机器账户

$password = ConvertTo-SecureString 'ComputerPassword' -AsPlainText -Force
New-MachineAccount -MachineAccount "ControlledComputer" -Password $($password) -Domain "settest.com" -DomainController "administrator.sectest.com" -Verbose

最开始执行上述两条指令时出错，尝试使用ps脚本添加，发现当前用户不能执行ps脚本

尝试使用 set-executionpolicy remotesigned 解除限制时发现需要管理员账户，姑且用管理账户解开该限制

# 脚本创建
powershell
Set-ExecutionPolicy Bypass -Scope Process
Import-Module .\Powermad.ps1

# 运行完后需要输入一下密码：12345678（可任意密码）
New-MachineAccount -MachineAccount saulgoodman -Domain sectest.com -DomainController administrator.sectest.com -Verbose

# 验证是否添加成功
net group "domain computers" /domain

但是在执行添加账户指令时发现如下报错，查看报错脚本对应位置

由于是LDAP服务相关的错误，且在DC上查看 389 端口正常，因此猜测问题出在参数上，向上回溯发现可能是DomainController参数出现的问题，根据代码逻辑发现如果不指定该参数的话，脚本会自行补全。

删除 DomainController 参数后执行

成功添加本地机器账户

2.清除SPN信息

# 导入一下 PowerView.ps1
Import-Module .\PowerView.ps1
Set-DomainObject "CN=saulgoodman,CN=Computers,DC=redteam,DC=red" -Clear 'serviceprincipalname' -Verbose

这里才发现，上面用到的脚本其实是git上一个专门用于域渗透的项目（PowerSploit）里提供的功能，用到对应的功能的时候就将对应的ps脚本上传到主机上，最终执行结果如下

3.重设机器名称

这里开始利用CVE-2021-42278漏洞仿冒DC机器名

# 修改当前机器名称为DC机器名
Set-MachineAccountAttribute -MachineAccount saulgoodman -Value "WIN-E13FAE6DQB9" -Attribute samaccountname -Verbose

4.请求TGT

https://blog.csdn.net/weixin_43760829/article/details/89437363 https://myzxcg.com/2021/08/域用户与域成员机器关系及利用/ https://juejin.cn/post/6844903955416219661 https://mp.weixin.qq.com/s/Z3mI5eEc8-iudqdU7EZ3EQ https://www.anquanke.com/post/id/190625 https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html​ https://github.com/WazeHell/sam-the-admin​ https://wooyun.js.org/drops/域渗透——Pass The Ticket.html​ https://www.anquanke.com/post/id/192810​ https://www.cnblogs.com/0x7e/p/13862453.html​