当前位置：首页 > news >正文

Trust Tickets（跨域信任票据）：内网渗透中的Kerberos信任票据滥用技术

news 来源：原创 2025/6/1 12:12:00

在内网渗透中，Trust Tickets 是一个常被提及但定义较为模糊的术语。尽管它并非标准术语，但通常被用来描述在Active Directory（AD）环境中，攻击者利用Kerberos协议的信任关系，通过伪造或滥用Kerberos票据（如TGT或TGS）实现跨域横向移动或权限提升的行为。

一、Trust Tickets的定义与背景

1.1 Trust Tickets的定义

在网络安全语境中，Trust Tickets 通常指攻击者在Active Directory环境中，利用域间或林间信任关系，通过伪造、转发或滥用Kerberos认证票据（如TGT或TGS），在信任域之间进行横向移动或提升权限的票据或相关技术。尽管“Trust Tickets”不是Kerberos协议的官方术语，但在渗透测试社区中，它常被用作对黄金票据（Golden Ticket）、银票（Silver Ticket）或S4U委派票据等攻击场景的通俗称呼，尤其是在涉及跨域信任的攻击中。

具体来说，Trust Tickets的核心是利用Kerberos协议的信任机制，特别是域间信任关系，伪造或操控票据以冒充合法用户或服务，从而访问受信任域的资源。其典型应用包括：

伪造TGT（黄金票据）：攻击者使用域的krbtgt账户密钥伪造TGT，冒充任意用户访问域内或跨域资源。
伪造TGS（银票）：针对特定服务的票据伪造，绕过KDC验证直接访问服务。
S4U委派攻击：利用Kerberos的S4U2Self或S4U2Proxy扩展，获取跨域服务的委派票据。

1.2 Kerberos协议与信任关系背景

Kerberos是Active Directory环境中广泛使用的身份认证协议，旨在通过票据机制实现安全的身份验证。Kerberos协议的核心组件包括：

TGT（Ticket Granting Ticket）：由KDC（密钥分发中心）的认证服务（AS）颁发，证明用户身份，允许用户请求服务票据（TGS）。
TGS（Ticket Granting Service）：由KDC的服务授予服务（TGS）颁发，允许用户访问特定服务。
PAC（Privilege Attribute Certificate）：包含用户权限信息（如SID、组成员关系）的票据部分，通常嵌入在TGT或TGS中。

在多域环境中，Active Directory通过信任关系（Trust Relationships）实现跨域身份验证，常见的信任关系包括：

父子域信任（Parent-Child Trust）：子域与父域之间自动建立的双向信任。
林间信任（Forest Trust）：不同AD林之间的信任关系，可能为单向或双向。
外部信任（External Trust）：与非AD环境的信任关系。

这些信任关系使得用户或服务可以在受信任的域中进行身份验证，而Kerberos协议通过跨域TGT和TGS的转发机制支持这一过程。

1.3 Trust Tickets的攻击场景

Trust Tickets的攻击场景通常围绕以下几个关键点：

伪造票据：攻击者通过窃取krbtgt账户的密钥（NTLM hash或AES密钥）伪造TGT（黄金票据）或TGS（银票），以冒充任意用户或服务。
信任关系滥用：利用域间信任关系，将伪造的票据用于跨域访问，特别是在父子域或林间信任环境中。
权限提升：通过在票据的PAC中注入高权限SID（如父域的Enterprise Admins SID），实现跨域权限提升。

这些攻击的核心在于，Kerberos协议的信任机制允许受信任域接受来自其他域的票据，而攻击者通过伪造或操控这些票据，绕过身份验证限制。

二、Trust Tickets的攻击原理

2.1 Kerberos认证流程回顾

要理解Trust Tickets的攻击原理，需先回顾Kerberos认证的基本流程：

AS-REQ/AS-REP（获取TGT）：
- 用户向KDC的认证服务（AS）发送AS-REQ请求，包含用户身份和时间戳。
- KDC验证用户身份后，返回TGT（包含PAC，记录用户权限信息）。
TGS-REQ/TGS-REP（获取TGS）：
- 用户使用TGT向KDC的TGS服务请求特定服务的票据（TGS-REQ）。
- KDC验证TGT后，返回TGS，允许用户访问目标服务。
AP-REQ/AP-REP（服务访问）：
- 用户将TGS提交给目标服务，服务验证TGS和PAC后提供访问。

在跨域场景中，Kerberos通过推荐票据（Referral Ticket）支持跨域认证。当用户请求访问另一个域的服务时，KDC会返回一个推荐票据，引导用户向目标域的KDC请求TGS。

2.2 黄金票据（Golden Ticket）与Trust Tickets

黄金票据是Trust Tickets攻击中最核心的技术之一。黄金票据是指攻击者使用域的krbtgt账户密钥（NTLM hash或AES密钥）伪造的TGT。TGT是Kerberos认证的起点，持有有效TGT的用户可以请求任意服务的TGS，从而访问域内或跨域资源。

在跨域场景中，黄金票据的攻击原理如下：

获取krbtgt密钥：
- 攻击者通过DCSync（Mimikatz等工具）或从域控制器内存中提取krbtgt账户的NTLM hash或AES密钥。
- 例如，使用Mimikatz的命令：
```
lsadump::dcsync /domain:sub.example.com /user:krbtgt
```
伪造TGT：
- 使用工具（如Impacket的ticketer或Mimikatz）生成伪造的TGT，指定任意用户名、域SID和额外SID（如父域的Enterprise Admins SID）。
- 示例命令（Impacket）：
```
impacket-ticketer -aesKey <krbtgt_aeskey> -domain sub.example.com -domain-sid S-1-5-21-xxx -extra-sid S-1-5-21-yyy-519 Administrator
```
跨域权限提升：
- 伪造的TGT包含父域的Enterprise Admins SID（通常为S-1-5-21-<父域SID>-519），使得KDC认为用户具有父域的最高权限。
- 攻击者使用TGT请求父域服务的TGS，进而访问父域资源（如域控制器）。

2.3 银票（Silver Ticket）与Trust Tickets

银票是针对特定服务的伪造TGS票据。攻击者通过窃取服务账户的NTLM hash（无需krbtgt密钥）伪造TGS，直接访问目标服务。由于TGS由服务自身验证，KDC不参与验证，银票攻击可以绕过部分Kerberos限制。

在跨域场景中，银票可用于访问受信任域的服务。例如，攻击者伪造父域某服务的TGS，通过信任关系直接访问该服务。

2.4 S4U委派与Trust Tickets

Kerberos的**S4U（Service for User）**扩展（包括S4U2Self和S4U2Proxy）允许服务代表用户请求票据。在跨域场景中，攻击者可利用S4U机制获取委派票据，访问受信任域的服务。这些委派票据在攻击语境中也可能被称为Trust Tickets。

三、Trust Tickets的实战应用

3.1 攻击场景与工具链

以下是Trust Tickets在渗透测试中的典型应用场景及其工具链：

场景1：伪造黄金票据实现跨域权限提升

目标：控制子域后，利用父子域信任关系冒充父域管理员。

步骤：

获取子域krbtgt密钥：
- 使用Mimikatz执行DCSync：
```
lsadump::dcsync /domain:sub.example.com /user:krbtgt
```
- 输出包括NTLM hash和AES密钥（如AES256）。

伪造TGT：

使用Impacket的ticketer生成TGT，注入父域Enterprise Admins SID：

impacket-ticketer -aesKey <krbtgt_aeskey> -domain sub.example.com -domain-sid S-1-5-21-xxx -extra-sid S-1-5-21-yyy-519 Administrator

设置票据环境：
- 将生成的票据导入环境：
```
export KRB5CCNAME=./Administrator.ccache
```
访问父域资源：
- 使用Impacket工具（如psexec）访问父域域控制器：
```
impacket-psexec example.com/Administrator@<父域_DC_IP> -k -no-pass
```

场景2：伪造银票访问跨域服务

目标：伪造父域某服务的TGS，直接访问服务。

步骤：

获取服务账户NTLM hash：
- 使用Mimikatz从目标服务主机提取服务账户的NTLM hash。

伪造TGS：

使用Mimikatz生成银票：

kerberos::golden /sid:<域SID> /domain:<域> /target:<服务主机> /service:<服务> /rc4:<NTLM hash> /user:Administrator

访问服务：
- 使用伪造的TGS直接访问服务，如CIFS、HTTP等。

场景3：S4U跨域委派攻击

目标：利用S4U2Proxy获取跨域服务的委派票据。

步骤：

控制具有委派权限的账户：
- 确保攻击者控制的账户具有TrustedForDelegation或TrustedToAuthForDelegation权限。

请求S4U票据：

使用Rubeus执行S4U2Self和S4U2Proxy：

Rubeus.exe s4u /user:<账户> /domain:<子域> /msdsspn:<服务SPN> /impersonateuser:<目标用户> /targetdomain:<父域> /ticket:<TGT>

访问目标服务：
- 使用委派票据访问父域服务。

3.2 常用工具

Mimikatz：提取密钥、伪造票据、执行DCSync等。
Impacket：生成票据、执行跨域攻击（如ticketer、psexec）。
Rubeus：Kerberos票据操作工具，支持S4U、票据导出等。
BloodHound：分析域信任关系，识别攻击路径。

四、Trust Tickets攻击的成功条件与失败原因

4.1 成功条件

获取krbtgt密钥：
- 攻击者必须通过DCSync、内存提取或其他方式获取子域krbtgt的NTLM hash或AES密钥。
正确配置SID：
- 伪造的TGT必须包含正确的域SID和额外SID（如父域的Enterprise Admins SID）。
信任关系存在：
- 目标域之间必须存在有效的信任关系（如父子域信任）。
加密类型兼容：
- 伪造的票据加密类型（RC4或AES）必须与目标域控制器的策略兼容。

4.2 常见失败原因及排查

问题	表现	排查建议
RC4加密被禁用	`KDC_ERR_ETYPE_NOSUPP`	使用AES密钥重试（如`-aesKey`）。
PAC校验失败	`KRB_AP_ERR_MODIFIED`	确保`domain-sid`和`extra-sid`正确。
缺少高权限SID	权限不足	注入父域Enterprise Admins SID（如`S-1-5-21-xxx-519`）。
密钥过期	认证失败	使用最新同步的`krbtgt`密钥。
GPO限制	访问被拒绝	检查组策略是否限制跨域访问。

五、防御Trust Tickets攻击的措施

5.1 监控与检测

监控krbtgt账户：
- 定期更改krbtgt账户密码，降低黄金票据的有效期。
- 监控krbtgt账户的异常访问（如DCSync请求）。
Kerberos日志分析：
- 检查事件日志（如事件ID 4624、4768、4769）中的异常TGT/TGS请求。
网络流量监控：
- 检测异常的Kerberos流量（如非预期域的票据请求）。

5.2 强化配置

禁用RC4加密：
- 配置域控制器仅支持AES加密，降低RC4-based黄金票据的威胁。
限制信任关系：
- 最小化域间信任，启用SID过滤（SID Filtering）以防止跨域SID注入。
启用PAC校验：
- 确保服务验证PAC，防止伪造票据的使用。

5.3 高级防御

Protected Users组：
- 将高权限用户加入Protected Users组，限制其票据被委派或伪造。
Kerberos Armoring：
- 启用Kerberos Armoring（FAST），增强AS-REQ的加密保护。
MFA与条件访问：
- 结合多因素认证（MFA）和条件访问策略，限制异常认证行为。

六、Trust Tickets的未来趋势与进阶技术

6.1 隐蔽票据攻击

随着防御技术的进步，攻击者可能转向更隐蔽的票据攻击方式，如：

PAC-less TGT：通过移除PAC或构造无PAC的TGT，绕过PAC校验。
Kerberos Bronze Bit攻击：利用CVE-2020-17049漏洞，绕过Kerberos委派限制。
Shadow Credentials：通过修改账户的msDS-KeyCredentialLink属性，间接控制票据生成。

6.2 云环境中的Trust Tickets

在混合云环境中，Azure AD与本地AD的信任关系为Trust Tickets攻击提供了新场景。攻击者可能利用Azure AD Connect同步机制，伪造跨云票据或滥用云服务账户的信任关系。

七、总结

Trust Tickets作为内网渗透中的一种攻击技术，核心在于利用Kerberos协议的信任机制，通过伪造或操控票据实现跨域横向移动和权限提升。其典型形式包括黄金票据、银票和S4U委派票据，广泛应用于父子域、林间信任等场景。攻击的成功依赖于获取krbtgt密钥、正确配置SID以及信任关系的存在，而防御则需从监控、配置强化和高级防护多方面入手。

通过深入理解Trust Tickets的原理与实战应用，安全从业者可以更好地识别和应对此类攻击，同时优化企业网络的安全策略。未来，随着云环境和新型防御技术的普及，Trust Tickets攻击可能进一步演化，值得持续关注。