基于 Kerberos 日志的黄金票据攻击检测:使用 Anthropic-Cybersecurity-Skills 的 Splunk/KQL 威胁狩猎实战指南
发布时间:2026/9/12 12:51:30 锦皓数字建站

基于 Kerberos 日志的黄金票据攻击检测使用 Anthropic-Cybersecurity-Skills 的 Splunk/KQL 威胁狩猎实战指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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黄金票据Golden Ticket是攻击者在窃取 KRBTGT 账户哈希后伪造 Kerberos TGT票证授予票据的经典持久化与横向移动手法对应 MITRE ATTCK T1558.001 技术。本指南以 Anthropic-Cybersecurity-Skills 仓库中的detecting-golden-ticket-attacks-in-kerberos-logs技能文档为核心系统讲解如何在域控制器事件日志中利用 Windows 安全事件 ID 4768/4769/4771通过 Splunk SPL 与 KQL 查询发现 RC4 加密降级、不可能票证生命周期、无前序 TGT 的 TGS 请求等黄金票据特征并配套仓库自带的 agent.py 检测代理实现源码级剖析。读完本文你将掌握一套可直接落地到 SIEM 环境的黄金票据威胁狩猎流程、可直接复用的检测查询与自动化脚本。技能背景黄金票据攻击原理与检测价值黄金票据攻击的本质是攻击者通过 DCSync、NTDS.dit 提取等 凭据窃取手段T1003 获取域中 KRBTGT 账户的密码哈希后即可离线伪造任意用户的 TGT且不受域内 Kerberos 票证生命周期策略约束。由于伪造的 TGT 直接绕过了正常的 AS-REQ/AS-REP 认证交换域控制器无法通过常规口令校验识别其真伪攻击者可以凭借伪造票证在数月甚至数年内保持对域的持久访问。在本仓库的技能体系中该技能被映射到 MITRE ATTCK 技术映射表 的 T1558.001Kerberos 票证伪造黄金票据并在 ATTACK_COVERAGE.md 中与conducting-domain-persistence-with-dcsync、detecting-golden-ticket-forgery等技能共同构成 T1558.001 的攻防覆盖。检测侧的核心思路是虽然伪造的 TGT 在密码学上难以直接验证但其加密类型、票证生命周期、账户存在性、认证流程完整性等旁路特征会不可避免地暴露异常。适用场景When to Use根据 SKILL.md 的定义以下场景应当启动本技能进行威胁狩猎KRBTGT 哈希疑似泄露通过 DCSync 或 NTDS.dit 提取等途径KRBTGT 账户哈希可能已被攻击者获取持久化域访问取证狩猎可能被用于维持持久化域访问的伪造 Kerberos 票证域级凭据失窃应急响应之后事件响应已确认发生域级凭据窃取需要回溯确认黄金票据是否在流通不可能登录模式调查用户在同一时间从多个地理位置同时登录正常账户几乎不可能出现的行为模式入侵后评估判定黄金票据是否正在被攻击者使用。前置条件Prerequisites在开始检测前需要确保以下环境与配置就绪域控制器上启用了Windows 安全事件 ID 4768、4769、4771的日志记录掌握本域的Kerberos 策略配置最大票证生命周期、允许的加密类型等基线域控制器审计策略已启用Kerberos 服务票证操作Kerberos Service Ticket Operations具备可跨多台域控制器关联 Kerberos 事件的 SIEM如 Splunk、Microsoft Sentinel因为同一账户的 TGT 与 TGS 可能记录在不同的 DC 上。七步检测工作流WorkflowSKILL.md 给出了一套完整的七步检测流程每一步对应一类可观测的黄金票据异常特征监控 TGT 请求事件 4768跟踪 Kerberos 认证服务请求。黄金票据完全绕过了 AS-REQ/AS-REP 交换因此在 4769 之前没有对应的 4768 是可疑信号。检测加密类型异常黄金票据通常使用 RC40x17加密。如果域强制执行 AES0x12任何 RC4 的 TGT 都是危险信号。重点监控事件 4769 中的TicketEncryptionType字段。检查票证生命周期异常默认 Kerberos TGT 生命周期为 10 小时、可续期 7 天。黄金票据可以被伪造为长达 10 年的生命周期。检测任何超过域策略上限的票证持续时间。狩猎不存在的 SID黄金票据可以携带任意 SID包括不存在的账户或组。将 TGS 请求与已知的 AD SID 清单进行关联比对。检测无前序 TGT 的 TGS当服务票据4769出现而同一 IP/账户之前没有 TGT 请求4768时可能表明存在预先伪造的黄金票据。监控 KRBTGT 密码年龄跟踪 KRBTGT 最近一次重置时间。如果 KRBTGT 哈希在已知入侵后从未更改则该时期伪造的黄金票据仍然有效。验证 PAC 签名在 KB5008380 及之后的版本中配合 PAC 校验强制执行域控制器会拒绝伪造的 PAC。监控指示PAC 校验失败的 Kerberos 错误事件。检测查询Splunk SPL 与 KQLSKILL.md 提供了三类可直接部署到 SIEM 的检测查询以下完整继承并附带参数说明。SplunkKerberos TGS 中的 RC4 加密该查询统计各账户使用 RC4 加密请求服务票证排除 krbtgt 服务本身的频次当单账户聚合计数超过 5 次时视为可疑indexwineventlog EventCode4769 | where TicketEncryptionType0x17 | where ServiceName!krbtgt | stats count by TargetUserName ServiceName IpAddress TicketEncryptionType Computer | where count 5 | sort -countSplunk无前序 TGT 的 TGS利用eventstats按账户与 IP 聚合最早 TGT 时间筛选出先出现 TGS 而无 TGT 前置的记录indexwineventlog (EventCode4768 OR EventCode4769) | stats earliest(_time) as first_tgt by TargetUserName IpAddress EventCode | eventstats earliest(eval(if(EventCode4768, first_tgt, null()))) as tgt_time by TargetUserName IpAddress | where EventCode4769 AND (isnull(tgt_time) OR first_tgt tgt_time) | table TargetUserName IpAddress first_tgt tgt_timeKQLMicrosoft Sentinel黄金票据指标与第一条 Splunk 查询等价适合部署在 Microsoft Sentinel / Defender for Endpoint 环境SecurityEvent | where EventID 4769 | where TicketEncryptionType 0x17 | where ServiceName ! krbtgt | summarize Countcount() by TargetUserName, IpAddress, ServiceName | where Count 5扩展基于 JOIN 的 TGS 无 TGT 关联查询API 参考文档 还提供了一个基于 Splunkjoin的变体思路是直接以 TargetUserName 左关联 4768 记录筛选出完全缺失 TGT 请求的用户indexwineventlog EventCode4769 | join typeleft TargetUserName [ search indexwineventlog EventCode4768 | rename TargetUserName as tgt_user ] | where isnull(tgt_user) | table _time TargetUserName ServiceName IpAddress Computer扩展KQL 监控 4768 中的 RC4/EXP 加密另一个 Sentinel 查询侧重 TGT 请求阶段将 0x17RC4-HMAC与 0x18RC4-HMAC-EXP均视为可疑并排除计算机账户$结尾SecurityEvent | where EventID 4768 | where TicketEncryptionType in (0x17, 0x18) | where TargetUserName !endswith $ | project TimeGenerated, TargetUserName, IpAddress, TicketEncryptionType关键检测指标速查事件 ID 与加密类型为便于快速查阅API 参考文档将核心检测指标整理为两张表这里完整保留Windows 安全事件 ID事件 ID描述黄金票据信号4768TGT 已请求AS-REQRC4 加密、异常域4769TGS 已请求TGS-REQ无前序 4768、伪造 TGT4771Kerberos 预认证失败不存在的账户状态 0x6Kerberos 加密类型代码算法可疑程度0x11AES128-CTS正常现代0x12AES256-CTS正常首选0x17RC4-HMAC可疑Mimikatz 默认0x18RC4-HMAC-EXP可疑其中 0x17 被标注为 Mimikatz 默认这是因为 Mimikatz 的kerberos::golden模块默认使用 RC4 加密来伪造票证对应命令kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-... /krbtgt:hash /ptt这也是 RC4 成为首要检测信号的原因。源码级剖析agent.py 检测代理仓库为该技能提供了完整的 Python 实现 agent.py将上述七步工作流固化为可执行的检测逻辑是理解检测原理的绝佳参考。加密类型与检测指标定义脚本开头的ENCRYPTION_TYPES字典与GOLDEN_TICKET_INDICATORS字典直接对应上文的速查表并显式标注了每个指标的严重级别与 MITRE 技术 IDENCRYPTION_TYPES { 0x1: DES-CBC-CRC, 0x3: DES-CBC-MD5, 0x11: AES128-CTS, 0x12: AES256-CTS, 0x17: RC4-HMAC, 0x18: RC4-HMAC-EXP, } GOLDEN_TICKET_INDICATORS { rc4_encryption: {desc: RC4 encryption used (0x17) instead of AES, severity: HIGH, mitre: T1558.001}, impossible_lifetime: {desc: TGT lifetime exceeds policy maximum, severity: CRITICAL, mitre: T1558.001}, non_existent_account: {desc: TGS request for non-existent account, severity: CRITICAL, mitre: T1558.001}, no_tgt_request: {desc: TGS (4769) without prior TGT (4768), severity: HIGH, mitre: T1558.001}, domain_field_mismatch: {desc: Domain field differs from environment, severity: HIGH, mitre: T1558.001}, }脚本默认策略阈值MAX_TGT_LIFETIME_HOURS 10与 Windows 默认 TGT 生命周期一致可通过EXPECTED_DOMAIN配置预期域用于域字段异常检测。可以推断impossible_lifetime与domain_field_mismatch两个指标对应工作流中的第 3 步生命周期检查与跨域伪造场景。事件解析核心逻辑parse_kerberos_events函数基于python-evtx库解析 EVTX 文件通过正则提取 XML 中的关键字段实现三个事件的分类处理事件 4768提取TargetUserName、TargetDomainName、TicketEncryptionType、IpAddress将非计算机账户不以$结尾的 TGT 请求记录到tgt_requests字典键为小写用户名同时若加密类型为0x17/0x18则产生rc4_encryption发现项事件 4769提取TargetUserName、ServiceName等字段将用户名按拆分为基础名若该用户在tgt_requests中不存在且非计算机账户则产生no_tgt_request发现项——这正是工作流第 5 步的自动化实现事件 4771检查Status字段是否为0x6KDC_ERR_C_PRINCIPAL_UNKNOWN命中则产生non_existent_account发现项对应工作流第 4 步。Sigma 规则自动生成脚本还内置了generate_sigma_rule()可将检测逻辑一键转换为标准 Sigma 规则便于导入到其他 SIEM/EDR 平台def generate_sigma_rule(): return { title: Golden Ticket - TGS Without Prior TGT, status: stable, logsource: {product: windows, service: security}, detection: { tgs: {EventID: 4769}, tgt: {EventID: 4768}, condition: tgs and not tgt, }, level: high, tags: [attack.credential_access, attack.t1558.001], }CLI 用法# 依赖pip install python-evtx # 解析 Windows Security EVTX 日志文件并输出 JSON 发现结果 python agent.py --security-log Security.evtx --domain corp.local # 仅生成 Sigma 检测规则 python agent.py --generate-sigmaCLI 参数说明--security-log指定 Windows 安全日志 EVTX 文件路径--domain指定预期 AD 域名用于域字段一致性检测--generate-sigma输出标准 Sigma 规则。输出结果包含时间戳、tgt_requests计数、findings数组每个发现项携带事件 ID、时间戳、用户、加密类型/服务/状态及指标描述与严重级别与total_findings汇总。若未安装python-evtx脚本会返回明确的安装提示pip install python-evtx。python-evtx 离线解析模板当 SIEM 中无完整日志或在离线取证场景下可直接使用 EVTX 离线解析import Evtx.Evtx as evtx with evtx.Evtx(Security.evtx) as log: for record in log.records(): xml record.xml() # Parse Events 4768, 4769, 4771 # Check TicketEncryptionType, TargetUserName常见攻击场景Common ScenariosSKILL.md 总结了四类最常见的黄金票据实战场景理解它们有助于在检测命中时快速研判DCSync 后的黄金票据攻击者提取 KRBTGT 哈希后用 Domain Admin SID 伪造 TGT有效期可持续数月直到 KRBTGT 被轮换两次才会失效Kerberos 默认保留当前与上一个哈希各一次验证窗口。RC4 降级在仅允许 AES 的环境中用 RC4 加密伪造的黄金票据会因加密类型不匹配而被检测——这是本技能检测查询的核心命中场景。跨域黄金票据伪造的域间inter-realmTGT 被用于在 AD 域/林之间进行跳板移动。补救后的持久化由于 KRBTGT 只轮换了一次当前与之前的哈希均有效黄金票据在密码重置后依然存活攻击者借此绕过清理措施。输出格式与研判记录检测完成后建议按 SKILL.md 规定的固定格式产出狩猎报告便于追踪与跨团队协作Hunt ID: TH-GOLDEN-[DATE]-[SEQ] Suspected Account: [Account using forged ticket] Source IP: [Client IP] Target Service: [SPN accessed] Encryption Type: [RC4/AES128/AES256] Anomaly: [No prior TGT/RC4 in AES environment/Extended lifetime] KRBTGT Last Reset: [Date] Risk Level: [Critical]其中Hunt ID用于唯一定位本次狩猎Anomaly字段应明确标注命中的具体异常类型无前序 TGT、AES 环境中的 RC4、超长生命周期等KRBTGT Last Reset用于结合工作流第 6 步判断黄金票据的存活窗口。缓解与加固建议结合技能文档的检测逻辑黄金票据的根治路径围绕 KRBTGT 账户展开连续两次重置 KRBTGT 哈希这是让既有黄金票据失效的唯一可靠手段对应场景 4 的两次轮换要求在域中强制执行 AES 加密禁用 RC4AllowNtlm4/ 加密类型策略使 RC4 伪造票证立即暴露保持 PAC 校验启用确保域控制器运行 KB5008380 并启用 PAC 签名验证拒绝伪造 PAC为 KRBTGT 密码重置设置变更管理任何对 KRBTGT 的重置都应视为高敏感变更留存审计记录跨 DC 关联检测在 SIEM 中统一汇聚多台域控制器日志避免因 TGT/TGS 分散在不同 DC 而漏检。框架映射与定位本技能在仓库的技能体系中明确定位为防御侧威胁狩猎能力其 YAML frontmatter 声明了 MITRE ATTCK 子技术 T1558.001黄金票据以及 NIST CSF 2.0 的 DE.CM-01持续监控、DE.AE-02异常与事件分析、DE.AE-07攻击流程关联与 ID.RA-05威胁情报控制项。在 attack-navigator-layer.json 中T1558.001 被标记为该仓库的覆盖技术点读者可将该层文件导入 MITRE ATTCK Navigator 可视化查看技能覆盖热力图。本文所有检测查询、事件 ID 对照表与脚本逻辑均可直接对照仓库中 SKILL.md、API 参考 与 检测代理实现 进行验证与二次开发。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
锦
锦皓数字建站
深耕本土企业品牌数字化升级,专注原创端正雅致商务官网,从视觉设计到稳定运维全程保驾护航。