文章总结： 本文分析微软2026年7月将Kerberoasting的RC4防护进入Enforcement阶段后，基于RC4票据的检测规则命中率归零的问题。文章指出攻击手法并未消失，而是迁移至成本更高的AES加密，弱口令风险依旧。作者提出三条新增监控点：4769失败码0xE、显式配置RC4账户清单及0x18双重含义，并给出本周可执行的三项操作建议，包括检查加密类型分布、排查显式RC4账户及改版检测规则。 综合评分： 88 文章分类： 安全运营,威胁情报,安全工具

RC4票据归零之后：重写你的Kerberoasting检测

cwbird cwbird

bird网络安全

2026年9月15日 09:37 贵州

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

7 月 14 日,微软在 Windows 消息中心公告:随 July 2026 安全更新,Kerberos RC4 防护进入 Enforcement 阶段,Audit 模式和临时注册表项 RC4DefaultDisablementPhase 被移除,域控上 Enforcement 成为唯一支持的配置。到今天两个月过去,多数团队的注意力还停在「老系统会不会认证失败」上,SOC 侧有四件事需要单独拉出来处理:检测规则命中率归零、攻击手法迁移、失败码告警形态变化、显式 RC4 账户成为残留通道。

先把时间线钉死

RC4 退出分三步走。

2022 年 11 月 8 日,响应 CVE-2022-37966 的补丁(KB5021131)把未显式配置加密类型账户的 Kerberos 默认值从 RC4 改为 AES-SHA1。这一步只动默认值,账户层面显式配置了 RC4 的照旧工作。

2026 年上半年,微软公布 CVE-2026-20833(Kerberos 信息泄露),同时宣布在 2026 年第二季度末之前,让域控停止把 RC4 作为默认假定的受支持加密类型。

2026 年 7 月 14 日公告确认最终形态:July 2026 安全更新移除 Audit 模式,Enforcement 全面生效。微软在 6 月 19 日的 30 天提醒里特意强调,Audit 回滚从该阶段起不再可用。

时间线来源是 Microsoft Learn 的《Detect and remediate RC4 usage in Kerberos》以及消息中心 2026-06-19、2026-07-14 两条公告,后文所有配置细节同出此处。

你的 Kerberoasting 规则正在静默报平安

Sigma 官方仓库里两条 Kerberoasting 主力规则,判定核心都锚定在 4769 事件的 TicketEncryptionType 0x17(RC4-HMAC)上。

一条是 Florian Roth 2017 年写的 win_security_susp_rc4_kerberos,规则 ID 496a0e47:EventID 4769 加 TicketOptions 0x40810000 加 TicketEncryptionType 0x17,剔除 $ 结尾的机器账户。另一条是 2022 年的 win_security_kerberoasting_activity,ID d04ae2b8:4769 加 Status 0x0 加 0x17,过滤 krbtgt 和机器账户,规则描述里明确写了还需要二次计算「单主机 5 秒内请求多个服务名」才能成警。

Enforcement 生效后,域控默认不再签发 RC4 服务票据,这两条规则的匹配集会持续萎缩直至趋近于零。麻烦的地方在于:规则不会报错,不会变灰,它只是在后台安静地匹配不到任何东西。如果 SOC 的规则健康度视图只看「有没有误报」而不看「该出现的流量是不是消失了」,仪表盘上就是一片祥和。建议给高危规则加一条元数据监控:近 30 天命中数为 0 且历史日均命中大于 N 的规则自动标记,人工复核是威胁真没了还是数据源断了。

规则安静下来本身是好事,说明攻击面真的被压缩了。但把「规则安静」读成「威胁消失」,这个推论站不住,原因在下一节。

Kerberoasting 没死,换了一把更贵的锁

RC4 票据的离线破解在 hashcat 里是 13100 模式(Kerberos 5, etype 23, TGS-REP),密钥派生走 HMAC-MD5,单次哈希成本低,消费级显卡就能跑出很高的枚举吞吐,这是过去十年 Kerberoasting 泛滥的技术底座。

AES 票据对应 hashcat 19600(etype 17,AES128)和 19700(etype 18,AES256),密钥派生换成 AES-CTS-HMAC-SHA1-96,单次计算成本明显上升,离线枚举吞吐按 hashcat 社区基准的普遍结论要低一个量级以上。

但 Kerberoasting 的本质是拿服务账户口令的派生密钥去撞字典。AES 提高的是每次尝试的价格,不改变弱口令会被撞开这个事实。一个口令只有 8 位小写字母的服务账户,无论票据是 etype 23 还是 etype 18,在定向字典面前都是同一个下场。加密算法升级解决不了服务账户口令十年不改的存量问题,这部分风险原样留在原地。

检测策略跟着迁移:0x17 票据的告警等级应该上调(理由见下节),同时补一条单账户短窗口内大量 TGS 请求的聚合检测,不区分加密类型。规则 d04ae2b8 的二次计算思路可以沿用,把 TicketEncryptionType 条件删掉,阈值按自己环境的请求基线定。

三条要新增的监控点

第一个,4769 的 Failure Code 0xE(KDC_ERR_ETYPE_NOTSUPP)。7 月更新后,仍在用 RC4 的老设备会集中爆出这个错误码,NetApp 存储配老版本 ONTAP 是典型场景,Florian Roth 规则的 falsepositives 字段里写的就包括 NetApp。这批事件要分两半看:大面积 0xE 是兼容性事故,走运维流程;单主机低频 0xE 更像加密类型探测,走安全流程。给 0xE 建独立规则并按源主机聚合,比混进通用认证失败规则有效。

第二个,显式配置 RC4 的账户清单。Enforcement 关掉的是「默认假定支持」,msDS-SupportedEncryptionTypes 里显式带着 RC4 位(掩码 0x4)的账户在更新后仍可正常拿到 RC4 票据,7 月 14 日公告原文的措辞是依赖项需要 remediated or explicitly configured(修复或显式配置)。这个口子给兼容留着,也给攻击者留着:有权限改服务账户属性的对手,把某个账户显式配回 RC4,就能在 Enforcement 时代继续走 13100 的低成本破解路线,还顺手获得一条避开默认检测逻辑的通道。把下面这段做成每周计划任务,结果集新增即告警:

$parameters = @{   Filter = 「(ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')」   Properties = 「msDS-SupportedEncryptionTypes」 } Get-ADObject @parameters |   Where-Object { $_.「msDS-SupportedEncryptionTypes」 -band 0x4 } |   FL DistinguishedName, msDS-SupportedEncryptionTypes

第三个,0x18 的双重含义。事件字段里 0x18 是 RC4-HMAC-EXP,属于 RC4 家族;注册表项 DefaultDomainSupportedEncTypes 里的 0x18 是位掩码,即 0x8|0x10,代表 AES128 加 AES256。微软文档里两处 0x18 先后出现,含义完全不同。写检测查询时按注册表语义理解事件字段,RC4-EXP 票据会从眼皮底下漏过去。机器解析不受影响(字段语义固定),人工写 SPL 或 KQL 的时候这个坑踩过的人不少。

这周能做完的三件事

拉一份 7 月更新前后的 4769 加密类型分布对比,确认 0x17 占比是归零还是残留,残留部分对应哪几台源主机。跑一遍上面的 Get-ADObject,拿到显式 RC4 账户全量清单,逐个定迁移期限,期限到了没迁的按风险敞口处理。把 Kerberoasting 类规则按新现实改版:0x17 命中从 medium 提到 high,加上去加密类型化的请求聚合检测。

RC4 退役把一条存在二十多年的低成本攻击路径堵掉了大半,剩下的口子集中在弱口令和显式配置两处。这两件事都不需要采购新产品,需要的是有人拿着清单把它清完。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：bird网络安全 cwbird cwbird《RC4票据归零之后：重写你的Kerberoasting检测》