基于 Windows 安全事件日志检测 Kerberos Golden Ticket 伪造（Anthropic-Cybersecurity-Skills 实战指南）

基于 Windows 安全事件日志检测 Kerberos Golden Ticket 伪造（Anthropic-Cybersecurity-Skills 实战指南）

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

本指南基于 Anthropic-Cybersecurity-Skills 仓库中的detecting-golden-ticket-forgery技能（SKILL.md），系统讲解如何通过分析 Windows Event ID 4768/4769 检测 Golden Ticket（黄金票据）伪造：包括 RC4（0x17）加密降级、孤立 TGS 请求、超长票据生命周期与 krbtgt 账户异常四类核心指标，并给出可落地的 Splunk SPL、Elastic KQL 查询与离线 Python 分析工具（agent.py）。读完本文，你将掌握一条从日志采集、检测规则编写到 JSON 告警输出的完整检测流水线。

Golden Ticket 攻击原理与检测思路

Golden Ticket 攻击（MITRE ATT&CK T1558.001）的本质是：攻击者窃取域内krbtgt账户的 NTLM 哈希后，离线伪造一张 Ticket Granting Ticket（TGT）。由于 krbtgt 哈希是域内所有票据签发的根凭据，伪造的 TGT 可以让攻击者伪装成任意用户（甚至不存在的用户）、访问域内任何服务，且票据生命周期可长达数十年。

从检测视角看，Golden Ticket 并非"无法检测"，而是在行为与属性上存在多处可被日志捕捉的偏差。本技能围绕四条检测线索展开：

1. RC4 加密降级：在强制 AES 加密策略的现代域环境中，合法 TGS 请求几乎总是使用 AES256（0x12）或 AES128（0x11）。而 Mimikatz 等工具伪造的票据默认采用 RC4-HMAC（0x17），因为 RC4 不要求校验 krbtgt 哈希对应的 Kerberos 加密类型，因此0x17在 AES 环境中的出现是强指示。
2. 孤立 TGS 请求：正常 TGS 请求必然由一次成功的 AS-REQ（TGT 获取）前置。若某用户存在 4769 事件却无对应的 4768 事件，说明其持有的 TGT 并非由域控签发，而是被"凭空注入"——这正是伪造票据的特征。
3. 异常票据生命周期：域策略MaxTicketAge默认 10 小时，而伪造 TGT 的生命周期常被设置为数十年。
4. krbtgt 服务异常：合法场景下几乎不会出现直接向krbtgt服务发起 TGS 请求的事件，此类事件高度可疑。

该技能在仓库中被映射为 MITRE ATT&CK T1558.001，在 attack-navigator-layer.json 中记录了技能关联元数据，并关联 NIST CSF（DE.CM-01、DE.AE-02、DE.AE-06、ID.RA-05）与 D3FEND 响应技术，可用于安全覆盖验证。

前置条件与日志基础

检测 Golden Ticket 需要以下环境就绪：

• 启用 Kerberos 审计日志的 Windows 域控制器（DC）；
• Splunk 或 Elastic SIEM 已接入 Windows Security 事件日志；
• Python 3.8+ 环境用于离线事件日志分析（运行 agent.py）；
• 明确当前域的 Kerberos 加密策略（AES-only 还是兼容 RC4），这是判定"RC4 降级"是否成立的前提。

核心事件字段速查

检测依赖两类 Windows 安全事件：Event ID 4768（AS-REQ，请求 TGT）与 Event ID 4769（TGS-REQ，请求服务票据）。完整字段说明见 api-reference.md，关键字段整理如下：

Event ID 4768 — TGT Requested (AS-REQ)

Event ID 4769 — TGS Requested (TGS-REQ)

检测指标判定基准

Splunk SPL 检测查询

1. RC4 TGS 检测（Golden Ticket 核心规则）

在 AES 强制环境中，任何TicketEncryptionType=0x17的 TGS 请求都值得告警。对同一用户/来源聚合统计，可进一步压缩误报：

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4769 TicketEncryptionType=0x17 ServiceName!="krbtgt" | stats count by TargetUserName, IpAddress, ServiceName | where count > 3 | sort -count

2. 孤立 TGS（无前置 TGT）

通过 left join 将 4769 与 4768 按用户关联，找出没有对应 TGT 请求记录的 TGS 请求：

index=wineventlog EventCode=4769 | join type=left TargetUserName [search index=wineventlog EventCode=4768 | dedup TargetUserName | fields TargetUserName] | where isnull(TargetUserName) | stats count by TargetUserName, IpAddress

3. krbtgt 服务异常

直接列出所有指向 krbtgt 服务的 TGS 请求，供分析师快速核查：

index=wineventlog EventCode=4769 ServiceName="krbtgt*" | table _time, TargetUserName, IpAddress, TicketEncryptionType

Elastic KQL 检测查询

在 Elastic 平台（Elastic SIEM）上使用 KQL 语法实现 RC4 降级检测：

event.code: "4769" AND winlog.event_data.TicketEncryptionType: "0x17" AND NOT winlog.event_data.ServiceName: "krbtgt"

离线事件日志分析（agent.py）

对于未接入 SIEM 或需要批量取证分析的场景，agent.py 提供了纯 Python 的离线检测能力，无需依赖外部库即可解析域控导出的安全事件 XML。

使用方法

python agent.py --evtx-xml security_events.xml --output golden_ticket_report.json python agent.py --show-splunk python agent.py --evtx-xml events.xml --max-ticket-hours 8

参数说明：

--show-splunk模式可直接输出与上文 SPL 对应的三类查询，方便将离线分析结论转换为线上 SIEM 规则。

源码实现与四类检测逻辑

agent.py 的检测流程与 SKILL 步骤一一对应，从源码结构看，各检测函数职责如下：

• 事件解析：parse_security_events 使用xml.etree.ElementTree解析标准 Windows 事件 XML 命名空间，仅保留 4768/4769 事件，并将EventData中的具名字段平铺为字典，供后续检测直接读取。
• RC4 降级检测：detect_rc4_in_aes_environment 匹配 4769 事件中TicketEncryptionType为0x17或十进制23的请求，输出 severity=critical 的告警，标注 MITRE 技术编号 T1558.001。
• 孤立 TGS 检测：detect_orphaned_tgs 先收集所有 4768 事件中的用户@域集合，再找出不在集合内的 4769 请求，并按用户聚合其目标服务、来源 IP 与首见时间。
• 异常生命周期检测：detect_abnormal_ticket_lifetime 计算同一用户的两次 TGT 请求时间差，若超过max_lifetime_hours的两倍（默认 20 小时）则判定异常——合法票据到期续期不可能出现如此长的间隔。
• krbtgt 服务异常检测：detect_krbtgt_service_anomaly 捕获所有ServiceName以krbtgt开头的 4769 事件。

输出报告

main 会将四类检测结果汇总为 JSON 报告并写入--output指定文件，结构包含：

• analysis_time/total_events：分析时间与解析到的 Kerberos 事件总数；
• detections：按rc4_encryption_downgrade、orphaned_tgs_requests、abnormal_ticket_lifetime、krbtgt_service_anomaly四类组织的告警列表；
• total_alerts：告警总数；
• mitre_techniques：关联的 MITRE ATT&CK 技术（T1558.001）；
• splunk_queries：内嵌的 SPL 查询，便于将结果同步到线上 SIEM。

每条告警均包含detection、mitre_technique、severity、description及对应的用户、来源 IP、服务等上下文字段，可直接用于 SOC 告警工单。

检测流程实施步骤

1. 审计域 Kerberos 加密策略，确认是否强制 AES（建立 AES-only 基线）；
2. 将 Event ID 4768 与 4769 转发至 SIEM 平台；
3. 部署 RC4（0x17）TGS 检测规则（在 AES 强制环境中生效）；
4. 识别无对应 TGT 请求的 TGS 请求（伪造票据指示）；
5. 对超过域 MaxTicketAge 策略的票据生命周期进行告警；
6. 监控 krbtgt 账户密码年龄与最近重置日期（账户异常的重要信号）；
7. 结合主机与用户上下文对发现进行关联，形成风险评分。

结果解读与风险处置

检测的最终产出是包含 Golden Ticket 指标的 JSON 报告：RC4 降级、孤立 TGS 请求、异常票据生命周期以及风险评分后的告警（均标注 MITRE ATT&CK 技术映射）。告警出现后，建议按以下优先级处置：

• 确认域内是否真的强制 AES：若域仍兼容 RC4，需结合其他指标（如孤立 TGS、异常生命周期）避免误报；
• 对命中用户立即重置凭据并强制重新认证；
• 立即执行 krbtgt 密码重置流程（连续两次重置并同步到所有 DC），因为 Golden Ticket 的根本缓解手段是更换 krbtgt 密钥，使所有已签发的伪造票据失效；
• 结合 coverage-summary.md 等映射文件检查现有检测覆盖，将本技能规则纳入持续监控基线。

需要注意的是，本技能的检测规则以"域强制 AES 加密"为适用前提；在仍允许 RC4 的兼容环境中，RC4 指标需要与孤立 TGS、生命周期异常等指标联合判定，才具备足够的告警价值。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills