Kerberos实验

• kdc：192.168.72.163

• 客户端（机器账户win10）：192.168.72.159

• 用户：administrator

• 抓包：开机登录win10，使用administrator域用户凭据登录。

生成 Kerberos 解密文件

1. 抓取 krbtgt 用户和 win10 机器账户的 hash 。

   • krbtgt 用户的 hash 是为了解密 as-rep 中 tgt 里的加密部分。

   • 机器账户的 hash 是为了解密 tgs-rep 中 st 里的加密部分（使用 administrator 登录机器需要向 kdc 申请 st）。

抓取 hash 内容如下：

打开mimikatz
​
lsadump::dcsync /user:hacker\krbtgt
lsadump::dcsync /user:hacker\win10$
​
krbtgt 和 win10$ 的 hash 分别如下：

1. 使用脚本生成解密文件

   https://github.com/dirkjanm/forest-trust-tools/blob/master/keytab.py 为生成解密文件的工具

下载脚本后替换脚本的 key 为krbtgt 和 win10$ 的 hash ，如下图所示

执行命令：python keytab.py 1.kt 后
​
生成的 1.kt 就是解密 流量的文件

登录时抓包

1. 当开启 win10 机器后，输入域用户 administrator 账号密码进行登录，并使用 wireshark 抓包。

2. 打开 wireshark ，并导入 1.kt 解密文件，如下图（点击 “编辑” ，再点击 “首选项”，找到 “KRB5协议” ，引入解密文件 1.kt）：

抓包分析

此时我们就能分析 kerberos 的报文了，这里我们只看关键部分。我们先分析前4个包。

as-req

关键部分：

• pA-ENC-TIMESTAMP：用户 hash 加密的时间戳

• cname：发起请求的用户：administrator

• sname：要访问的服务：krbtgt

as-rep

图中的 ticket 就是 tgt。

关键部分：

• tgt加密部分中的 key ：是 tgt 内部的 Logon Session Key。

• authorization-data ：存放的 PAC 信息，如下图。

tgs-req

关键部分：

• 发送的 tgt 。

• 发送的 Logon Session Key 加密的时间戳。

• 其他信息。

tgs-rep

关键部分：

• ticket ：就是返回的 st 。

• enc-part 中的 key ： Logon Session Key 加密的 Server Session Key。

多出来的 tgs-req 和 tgs-rep

这里还多出来一个 tgs-req 和 tgs-rep，这是怎么回事呢？

其实 administrator 登录 win10 后，不光申请了访问 win10 机器账户的 st，也申请了访问域控机器账户的 st，这样用户在 win10 上访问域控的话，能直接使用这个访问域控的 st，不需要另行申请了。也就是说 administrator 仅使用了1个 tgt 就申请到了2个 st。

但是我们观察它申请出来的 st 没有被解密（如下图），这是因为这里的st是被域控机器账户的 hash 加密了，而我们生成解密文件 1.kt 时，没有引入域控机器账户的 hash 。