Hotdry.
归档
ai-security

Microsoft RC4淘汰工程指南：Kerberos迁移的检测工具与兼容性策略

深入分析Microsoft淘汰RC4加密算法的技术实施，提供检测工具使用、迁移步骤与遗留系统兼容性解决方案。

在网络安全领域，有些技术债务的偿还需要数十年时间。RC4（Rivest Cipher 4）加密算法就是这样一个典型案例。自 1987 年由 Ron Rivest 开发以来，这个流密码算法在 1994 年泄露后就被发现存在严重弱点，却仍在 Microsoft 的 Active Directory 中作为 Kerberos 认证的默认选项持续使用了 26 年。直到 2025 年 12 月，Microsoft 终于宣布将在 2026 年中彻底淘汰 RC4，这一决定背后是数十年的安全漏洞和重大数据泄露事件。

RC4 的历史包袱与 Kerberoasting 威胁

RC4 的弱点并非新闻。早在 1994 年算法泄露后不久，研究人员就展示了针对 RC4 的密码学攻击，显著削弱了其安全性保障。然而，由于历史兼容性考虑，RC4 在 SSL/TLS 协议中一直存续到大约十年前，而在 Microsoft 的生态系统中，它更是 Active Directory Kerberos 认证的默认选择。

Kerberoasting 攻击自 2014 年已知，它利用 RC4 的弱点进行离线密码哈希破解。攻击者通过请求 Kerberos 服务票据，获取使用 RC4 加密的哈希值，然后在离线环境中进行暴力破解。这种攻击方式特别危险，因为它不需要网络交互，可以在攻击者的本地环境中无限次尝试。

2024 年 Ascension 医疗系统的重大数据泄露事件就是 Kerberoasting 攻击的直接后果。这次攻击影响了 140 家医院，危及患者生命安全，并将 560 万患者的医疗记录暴露给攻击者。美国参议员 Ron Wyden 在 2025 年 9 月公开批评 Microsoft 的 "严重网络安全疏忽"，并呼吁联邦贸易委员会进行调查。

Microsoft 的淘汰时间表与迁移计划

根据 Microsoft 官方公告，到 2026 年中，Windows Server 2008 及更高版本的域控制器将更新 Kerberos 密钥分发中心（KDC）的默认设置，仅允许 AES-SHA1 加密。RC4 将被默认禁用，只有在域管理员明确配置账户或 KDC 使用它时才会启用。

这一变化意味着，如果现有的 RC4 使用在默认更改应用前没有得到解决，依赖这一遗留算法的认证将停止工作。Microsoft 提供了明确的迁移路径：

  1. 检测阶段（现在至 2026 年初）：使用新工具识别 RC4 使用情况
  2. 修复阶段（2026 年初至年中）：配置账户支持 AES-SHA1
  3. 验证阶段（2026 年中前）：全面测试确保业务连续性

技术实施：检测工具与迁移步骤详解

新的安全事件日志字段

Microsoft 在 Windows Server 2019、2022 和 2025 中增强了安全事件日志，为 Kerberos 事件 4768（Kerberos 认证票据请求）和 4769（Kerberos 服务票据请求）添加了三个关键字段：

  1. msds-SupportedEncryptionTypes：指定账户支持的加密算法
  2. Available Keys：提供账户在 Active Directory 中创建的加密密钥信息
  3. Session Encryption Type：包含特定 Kerberos 请求使用的加密算法

这些字段使管理员能够识别：

  • 仅支持 RC4 的认证客户端设备
  • 仅支持 RC4 的认证目标设备
  • 未配置 AES-SHA1 密钥的账户

PowerShell 检测脚本

Microsoft 在Kerberos-Crypto GitHub 仓库中提供了两个关键的 PowerShell 脚本：

List-AccountKeys.ps1：查询安全事件日志中的 Available Keys 字段，枚举账户可用的密钥信息。输出包括事件时间、账户名称、账户类型和可用密钥列表。

PS C:\tools> .\List-AccountKeys.ps1

Time                  Name         Type Keys
----                  ----         ---- ----
1/21/2025 2:00:10 PM  LD1$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}

Get-KerbEncryptionUsage.ps1：查询相同事件以查看环境中 Kerberos 使用的加密类型。可以使用-Encryption RC4参数专门查找使用 RC4 的请求。

迁移操作步骤

根据检测结果，Microsoft 提供了具体的修复指南：

场景 1：用户账户仅有 RC4 密钥 当 List-AccountKeys.ps1 脚本识别出仅包含 RC4 密钥的用户或机器账户时，解决方案是重置账户密码。重置密码将在 Active Directory 中自动为账户创建 AES128-SHA96 和 AES256-SHA96 密钥。

场景 2：用户账户不支持 AES-SHA1 如果 msds-SupportedEncryptionTypes 字段不包含 AES-SHA1 加密类型，需要检查账户配置：

  1. 使用Active Directory Users and Computers (ADUC)，启用高级功能（视图 > 高级功能）
  2. 右键点击账户，选择属性 > 属性编辑器标签
  3. 查找 msDS-SupportedEncryptionTypes 属性确认配置
  4. 如果需要，使用组策略配置账户以包含 AES128-SHA96 和 AES256-SHA96

或者使用 PowerShell：

PS C:\> Get-ADObject -Filter "Name -eq 'LM1' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')" -Properties "msds-SupportedEncryptionTypes"

场景 3：设备不支持 AES128-SHA96 或 AES256-SHA96 最后一个不支持这些加密类型的 Windows 设备版本是 Windows Server 2003。Microsoft 强烈建议尽快迁移到受支持的 Windows 版本。

对于不支持 AES-SHA1 的第三方设备，Microsoft 提供了联系邮箱stillneedrc4@microsoft.com，要求提供设备信息、工作流程和升级时间表。

工程挑战：遗留系统处理与风险缓解策略

兼容性风险评估

RC4 淘汰面临的主要工程挑战包括：

  1. 遗留系统识别：许多组织可能不知道环境中存在依赖 RC4 的遗留系统，直到它们停止工作
  2. 第三方设备集成：非 Windows 设备可能硬编码依赖 RC4 进行 Kerberos 认证
  3. 测试覆盖不足：生产环境中的边缘案例可能在测试中被遗漏
  4. 回滚复杂性：一旦禁用 RC4，重新启用需要明确的配置更改

分阶段迁移策略

建议采用分阶段迁移方法降低风险：

阶段 1：全面审计（1-2 个月）

  • 在所有域控制器上启用增强的事件日志记录
  • 运行检测脚本建立基线
  • 创建 RC4 依赖项清单

阶段 2：优先级修复（2-3 个月）

  • 首先处理关键业务系统和服务账户
  • 为高优先级账户重置密码
  • 更新组策略设置

阶段 3：广泛测试（1 个月）

  • 在测试环境中模拟 RC4 禁用
  • 验证所有业务应用功能
  • 进行负载测试和故障转移测试

阶段 4：生产部署（1 个月）

  • 分批次应用更改
  • 密切监控事件日志
  • 准备快速回滚计划

Windows Admin Center 配置

Microsoft 提供了通过 Windows Admin Center（WAC）配置允许的加密类型的方法。在安全基线合规报告中，可以筛选策略 "网络安全：配置 Kerberos 允许的加密类型"。符合基线且不允许 RC4 的合规值为：

  • 2147483624：AES128-SHA96 + 未来加密类型
  • 2147483632：AES256-SHA96 + 未来加密类型
  • 2147483640：AES128-SHA96 + AES256-SHA96 + 未来加密

监控与警报配置

在迁移过程中，建议配置以下监控：

  1. 事件 4768 和 4769 的 RC4 使用警报：任何使用 RC4 的 Kerberos 请求都应触发警报
  2. 账户密钥状态监控：定期检查账户是否仅配置了 RC4 密钥
  3. 加密类型支持监控：跟踪不支持 AES-SHA1 的设备数量趋势

技术决策点与参数选择

AES-SHA1 vs AES-SHA256

虽然 Microsoft 默认迁移到 AES-SHA1，但组织应考虑更长期的加密策略。AES-SHA1 虽然比 RC4 安全得多，但 SHA-1 本身已被 NIST 计划在 2030 年淘汰。技术决策时应考虑：

  1. 兼容性要求：AES-SHA1 在所有 Windows Server 2008 及更高版本中受支持
  2. 安全态势：如果环境支持，可以考虑直接迁移到 AES-SHA256
  3. 未来证明：评估是否需要同时支持 AES-SHA1 和 AES-SHA256 的过渡期

组策略配置参数

在组策略中配置加密类型时，需要理解数值含义：

  • 1：DES-CBC-CRC
  • 2：DES-CBC-MD5
  • 4：RC4-HMAC-MD5
  • 8：AES128-CTS-HMAC-SHA1-96
  • 16：AES256-CTS-HMAC-SHA1-96
  • 32：未来加密类型

推荐配置为 24（8+16）表示仅允许 AES128 和 AES256，或 28（4+8+16）如果仍需 RC4 支持。

应急回滚方案

尽管淘汰 RC4 是安全强化的必要步骤，但必须准备应急回滚方案：

  1. 组策略回滚：保留允许 RC4 的组策略备份
  2. 账户级别覆盖：了解如何为特定账户重新启用 RC4
  3. 监控阈值：定义触发回滚的故障指标（如超过 X% 的认证失败）
  4. 沟通计划：确保所有利益相关者了解回滚流程

长期安全影响

RC4 的淘汰不仅仅是技术债务的偿还，它代表了企业安全态势的根本转变：

  1. 减少攻击面：消除 Kerberoasting 攻击的主要载体
  2. 合规性提升：满足日益严格的安全标准和法规要求
  3. 现代化推动：迫使组织淘汰遗留系统和流程
  4. 安全意识：提高对加密算法生命周期管理的认识

Microsoft 的这一决定虽然迟到了数十年，但为整个行业树立了重要先例：当安全与兼容性冲突时，安全必须优先。对于 IT 专业人员来说，2026 年中的截止日期既是挑战也是机遇 —— 一个彻底清理技术债务、强化安全基础的机会。

迁移到 AES-SHA1 不仅是为了避免服务中断，更是为了构建更安全、更弹性的身份认证基础设施。通过系统化的检测、修复和验证过程，组织可以确保平稳过渡，同时显著提升整体安全态势。

资料来源：Microsoft 官方博客《Beyond RC4 for Windows authentication》和 Ars Technica《Microsoft will finally kill obsolete cipher that has wreaked decades of havoc》

查看归档