AS-REP Roasting 攻击：工作原理与防御策略

什么是 AS-REP Roasting？

Kerberos 通常需要进行预身份验证（pre-authentication）：在 KDC 签发 Ticket Granting Ticket（TGT）之前，客户端必须向 Key Distribution Center（KDC）证明自己的身份。若某个账号被配置为跳过预身份验证（“Do not require Kerberos pre-authentication” 设置），攻击者可以针对该账号发送 AS-REQ，随后 KDC 会返回包含以该账号长期密钥加密的数据的 AS-REP（该密钥由密码派生）。攻击者提取该加密数据块，并对其执行离线密码破解——如果密码较弱，攻击者即可恢复密码，随后便能以该账号进行身份认证。这种技术称为 AS-REP Roasting。

AS-REP Roasting 如何工作？

下面是一次典型 AS-REP Roasting 攻击的逐步解析。

1. 侦察 — 查找未启用预身份验证的账号

攻击者会枚举目录账号，以查找禁用 Kerberos 预身份验证（"Do not require Kerberos pre-authentication"）的用户或服务主体（service principals）。这类账号往往是遗留的服务账号、计算机账号，或配置错误的用户账号。枚举通常通过 LDAP/AD 查询或侦察工具来完成。

2. 为目标账户请求 AS-REP

对发现的每个账户，攻击者都会针对该用户名向域 KDC 发送 AS-REQ。由于禁用了预身份验证（pre-authentication），KDC 将返回包含使用账户密码派生密钥加密的数据的 AS-REP。

3. 提取加密的 blob

攻击者会提取 AS-REP 响应中加密的部分（加密的时间戳，或票据的加密部分），并将其格式化以用于离线破解。

4. 离线破解密钥

攻击者使用离线密码破解工具（GPU 加速或分布式破解），尝试通过暴力破解、字典，或针对性的候选列表来恢复密码。弱口令或静态密码容易受到攻击。

5. 使用已恢复的凭据进行横向移动与持久化

一旦密码被恢复，攻击者就可以使用该账户进行身份验证，横向移动、访问服务或提升权限。服务账户和计算机账户往往拥有较广泛的访问权限，从而扩大影响范围。

✱ 变体：针对机器/服务主体（principal）和长期有效账户

AS-REP Roasting 经常会针对那些为兼容性而配置时未启用预身份验证（pre-authentication）的非交互式账户（服务主体、计算机账户）。这些账户通常拥有较长且固定的密码，并且访问权限范围较广，因此是高价值目标。

攻击流程图

示例：从组织视角

攻击者扫描 Contoso 的 AD，发现由于与旧设备兼容而被标记为“no pre-auth”的多个遗留备份服务账户。攻击者向这些账户请求 AS-REPs，提取加密响应，然后在离线环境中破解弱口令。利用恢复到的凭据，攻击者访问备份共享和域资源，随后通过利用配置错误的组成员资格进一步提权。

示例与真实世界模式

AS-REP Roasting 的后果

如果被入侵的账户具有特权访问权限或对敏感数据的访问权限，AS-REP Roasting 可能带来广泛的影响。

财务后果

服务账户遭到入侵可能导致 IP（知识产权）、客户数据或财务记录被盗，从而引发罚款、整改/补救成本或勒索要求。

运营中断

使用服务凭据的攻击者可以访问备份、篡改计划任务或中断关键服务，进而导致停机和恢复成本。

声誉损害

域名遭到入侵的情况一旦公开披露——尤其是当客户数据或可用性受到影响时——会损害信任，并可能阻碍合作伙伴关系。

法律与监管影响

受监管数据一旦暴露，可能会引发 GDPR、HIPAA、PCI 或其他合规调查和罚款。

常见目标：谁处于风险之中？

已禁用预身份验证的账户

传统服务账户，旧设备的兼容账户

非交互式服务主体

静态密码和长期有效的凭据

使用弱口令或未轮换密码的账户

高风险的破解

账号卫生较差的大型组织

大量遗留系统和错误配置

风险评估

如何防止 AS-REP Roasting

从概念上看，防范很直接，但需要持续的账户卫生（管理）以及配置控制。

强制启用 Kerberos 预身份验证

除非出于对旧版功能的绝对需求，否则为所有账户启用 Kerberos 预身份验证。将任何配置为跳过预身份验证的账户数量降到最低，并给出充分理由。

强化账户密码与生命周期

为服务账户和计算机账户使用长且随机生成的密码，定期轮换密码（在可能的情况下使用 gMSA），并避免将机密以明文形式存储。

替换传统模式

将传统应用迁移以支持现代身份验证，或使用专用且隔离的服务账户，限制访问权限并进行频繁轮换。在适用的情况下，优先选择 Kerberos constrained delegation（受限委派）。

应用最小特权与分段隔离

限制服务账户的权限，并通过网络分段隔离来隔离传统系统。

使用 MFA 和条件访问

对交互式管理员工作流要求 MFA 和条件访问。请注意，AS-REP 以非交互式账户为目标，因此 MFA 属于纵深防御的一部分，而不是所有情况下都能直接缓解的措施。

Netwrix 如何帮助防御 AS-REP Roasting

Netwrix Identity Threat Detection & Response (ITDR) 通过持续监控 Active Directory 和 Microsoft Entra ID 中的高风险账户配置（包括那些可能易受 AS-REP Roasting 攻击的配置）来增强您的防御能力。凭借对可疑 Kerberos 活动、LDAP 侦察或异常身份验证尝试的实时告警，ITDR 使安全团队能够在攻击者破解服务账户凭据之前采取行动。Netwrix 将主动检测与自动化响应工作流相结合，帮助组织减少横向移动机会，并弥合对手所利用的身份漏洞。

检测、缓解与响应策略

检测

• 监控 AD 查询和 LDAP 枚举，留意列出账户标志或查询 pre-auth（预身份验证）被禁用属性的扫描活动。
• 对那些通常不应从异常来源被请求的账户，记录并告警过多的 AS-REQ/AS-REP 交换。
• 盘点 pre-auth（预身份验证）被禁用的账户，并标记任何意外变更；保持基线。
• 诱饵（Honeypots/ honey accounts）：创建诱导用的 no-preauth 账户，并监控是否存在对 AS-REP 的请求。
• 留意破解后凭据被使用的迹象：异常登录、资源访问，或横向身份验证（lateral auth）的模式。

响应

1. 如果检测到可疑的 AS-REP 活动，请立即轮换或禁用已暴露的账户。
2. 启用预身份验证（pre-authentication），轮换密码，并在可能的情况下用托管身份替换。
3. 开展凭据猎杀，以发现已恢复凭据的使用迹象，并进行范围/影响评估。
4. 如果已识别且可行，请在网络层面阻断攻击者基础设施。

缓解

• 如可行，消除不需要预身份验证（pre-auth）的账户；否则将其隔离并加固。
• 针对 LDAP 枚举、AS-REQ 突增以及对诱饵账户的 AS-REP 命中，引入自动检测（SIEM 规则）。
• 在 CI/CD 中集成密钥（secret）扫描，以防止意外泄露凭据。

行业特定影响

攻击演进与未来趋势

• GPU 加速和云端破解使离线密码恢复更快、更便宜。
• 自动化侦察将 AD 枚举与 AS-REP 请求整合到多阶段攻击活动中。
• 转向托管身份可在已实施的范围内降低暴露面，从而促使攻击者转向传统/高价值目标。
• 使用 AI 来对破解进行优先级排序——攻击者可能会应用机器学习来挑选最有可能的候选密码。

关键统计与信息图（建议的遥测数据）

• 您环境中已禁用预身份验证（pre-authentication）的账户比例。
• 服务账户的平均密码年龄（使用时长）。
• 在可用的破解硬件上破解常见密码类别所需的时间（用于风险建模）。

最终思考

AS-REP Roasting 效果显著且噪音较低，主要利用配置漏洞和较差的凭据卫生。最有效的防御措施包括：清除已禁用预身份验证（pre-auth）的账号、强制使用托管密钥（managed secrets），以及监控 Kerberos/AD 枚举行为。

常见问题（FAQs）