Kerberos实验

原创于 2024-12-18 19:15:29 发布 · 990 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#网络安全 #安全 #web安全 #sql #数据库

kdc：192.168.72.163
客户端（机器账户win10）：192.168.72.159
用户：administrator
抓包：开机登录win10，使用administrator域用户凭据登录。

生成 Kerberos 解密文件

抓取 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 分别如下：

使用脚本生成解密文件

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

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

执行命令：python keytab.py 1.kt 后

生成的 1.kt 就是解密 流量的文件

登录时抓包

当开启 win10 机器后，输入域用户 administrator 账号密码进行登录，并使用 wireshark 抓包。
打开 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 。