AD域应急-AS-REP Roasting攻击狩猎

在 Active Directory 环境中，AS-REP Roasting 是一种针对 禁用了 Kerberos 预身份验证（Pre-Authentication）账户 的攻击手法。攻击者并不需要获取用户的明文密码，只要目标账户关闭了预身份验证，就可以直接向域控制器请求 Kerberos 的 TGT（Ticket Granting Ticket），并将返回的数据用于离线密码破解。

AS-REP Roasting 攻击原理

在正常的 Kerberos 认证流程中，预身份验证用于防止暴力破解。客户端需要先用用户的密码哈希加密时间戳，域控在验证成功后才会返回 TGT。但如果某个用户被配置为 不需要预身份验证，这个保护机制就被完全绕过了。

结果就是：
任何人，只要知道用户名，就能请求到一个可被离线破解的加密票据。

从应急响应角度看，这类攻击的危险性在于：

• 不需要登录失败
• 不需要横向移动
• 行为高度接近正常 Kerberos 认证
• 攻击痕迹极容易淹没在海量 4768 事件中

AS-REP Roasting 攻击过程

从攻击链视角看，AS-REP Roasting 往往发生在内网初期侦察阶段，甚至在尚未完全控制任何主机之前。

枚举域内有效用户名

如果攻击者事先并不知道域内有哪些真实用户，通常会先进行用户名枚举。

https://github.com/ropnop/kerbrute/releases

(root?kali)-[/var/tmp]
# ./kerbrute_linux_amd64 -h                                                                                                                                                                      

    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        

版本: v1.0.3 (9dad6e1) - 12/15/25 - Ronnie Flathers @ropnop

此工具旨在通过 Kerberos 预身份验证快速暴力破解有效的 Active Directory 帐户。
它设计用于可访问域控制器的内部 Windows 域。
警告：失败的 Kerberos 预身份验证算作登录失败，将会锁定帐户

用法:
  kerbrute [command]

可用命令:
  bruteforce    从文件或标准输入暴力破解用户名:密码组合
  bruteuser     从密码字典中暴力破解单个用户的密码
  help          获取任何命令的帮助
  passwordspray  针对用户列表测试单个密码
  userenum      通过 Kerberos 枚举有效的域用户名
  version       显示版本信息并退出

标志:
      --dc string       要定位的域控制器 (KDC) 的位置。如果为空，将通过 DNS 查找
      --delay int       每次尝试之间的延迟，以毫秒为单位。如果设置，将始终使用单线程
  -d, --domain string   要使用的完整域名 (例如 contoso.com)
  -h, --help            获取 kerbrute 的帮助
  -o, --output string   写入日志的文件。 可选。
      --safe            安全模式。 如果任何用户返回为已锁定，将中止。 默认值：FALSE
  -t, --threads int     要使用的线程数 (默认 10)
  -v, --verbose         记录失败和错误

使用 "kerbrute [command] --help" 获取有关命令的更多信息。

例如使用 kerbrute 这类工具，对常见用户名字典进行探测：

./kerbrute_linux_amd64 userenum -d polaris.local --dc 192.168.3.233 users.txt   

这一步本身并不算 AS-REP Roasting，而是为后续攻击做准备。

在实战中，这一步常常已经足以暴露域内大量真实账户。

请求 AS-REP 并获取可破解的 TGT

在拿到一批有效用户名后，攻击者会使用 Impacket 工具包中的 GetNPUsers.py 脚本，对这些账户逐个发起 Kerberos 请求：

python3 GetNPUsers.py polaris.local/ \
  -dc-ip 192.168.3.233 \
  -user users.txt \
  -no-pass

这里有几个关键点需要注意：

• 不需要任何合法凭据
• 只依赖域控 IP 和用户名
• 如果账户关闭了预身份验证，域控会直接返回加密的 TGT

在返回结果中，只要看到某个用户输出了 hash，就意味着该账户存在被 AS-REP Roasting 利用的风险。

利用成功的关键在于，域内用户配置了不要求 Kerberos 预身份验证 ，这个是我在测试过程中手动勾选的，否则无法复现成功。

离线破解密码

攻击者通常会把获取到的 hash 转换成 John the Ripper 或 Hashcat 支持的格式，然后进行离线破解：

john --wordlist=pass.txt hash.txt

一旦密码强度不足，整个过程可能在几分钟内完成。

从防守方角度看，这一步已经完全脱离了域控，任何日志都无法反映破解过程。

为什么 AS-REP Roasting 很难被发现

在 Active Directory 中，只要用户请求 Kerberos TGT，域控制器就会记录 事件 ID 4768。
无论是：

• 用户登录工作站
• 访问文件服务器
• 正常的服务认证

都会触发该事件。也就是说 AS-REP Roasting 与合法认证使用的是同一类日志。如果只靠事件 ID，本质上是无法区分攻击与正常行为的。

从日志中识别 AS-REP Roasting 的关键特征

虽然 AS-REP Roasting 行为“看起来很正常”，但在细节字段上仍然存在可用于检测的差异。

正常 Kerberos 认证的典型特征

在正常的用户登录行为中，事件 4768 通常具有以下特点：

• Ticket Encryption Type：0x12（AES-256）
• Pre-Authentication Type：非 0（通常为 2）

这说明账户启用了预身份验证，流程完整。

AS-REP Roasting 的异常特征

在 AS-REP Roasting 场景下，域控记录的 4768 事件往往表现为：

• Ticket Encryption Type：0x17（RC4）
• Pre-Authentication Type：0

其中，Pre-Authentication Type = 0 是最关键的信号，意味着该账户根本没有进行预身份验证。

虽然 RC4 在某些旧系统或服务中仍可能存在，但当它与 Pre-Auth = 0 同时出现时，就具备了极高的调查价值。

实战排查思路

在真实环境中，不可能人工翻看成千上万条 Kerberos 日志。因此，排查 AS-REP Roasting 时，应当优先通过条件过滤降低噪声：

重点关注以下组合条件：

• 事件 ID：4768
• Ticket Encryption Type：0x17
• Pre-Authentication Type：0
• 日志来源：域控制器

满足以上条件的事件，应当被视为高风险可疑行为，需要进一步确认：

• 请求来源主机是否异常
• 是否存在批量请求行为
• 该账户是否为服务账户或遗留账户
• 是否曾出现密码泄露或异常登录

防御与加固建议

从防守角度来看，AS-REP Roasting 并不难防，但经常被忽视。

清查禁用预身份验证的账户

首先，应定期在域内排查所有禁用了 Kerberos 预身份验证的账户：

Get-ADUser -Filter * -Properties DoesNotRequirePreAuth |
  Where-Object {$_.DoesNotRequirePreAuth -eq $true}

除非有极其明确的历史原因，否则不应允许普通用户账户关闭预身份验证。

强制为用户开启 Kerberos 预身份验证

Get-ADUser -Filter {Enabled -eq $true} `
  -Properties DoesNotRequirePreAuth,ServicePrincipalName |
  Where-Object {
    $_.DoesNotRequirePreAuth -eq $true -and
    -not $_.ServicePrincipalName
  } |
  Set-ADAccountControl -DoesNotRequirePreAuth $false

• ServicePrincipalName 不为空 → 极大概率是服务账号
• 没有 SPN → 更像是人类用户

仅修复启用的普通用户（避免误伤服务账号），将所有 DoesNotRequirePreAuth = TRUE 的用户，统一改为 开启预身份验证，直接消除 AS-REP Roasting 条件。相当于把域内所有禁用预身份验证的用户一次性修复掉。

如果某个服务账号“必须”关闭 Kerberos 预身份验证才能跑，那它本身就是一个严重的历史安全风险。

提升密码复杂度与长度

即使存在配置疏漏，只要密码强度足够高，离线破解的成本也会显著提升。对于延缓攻击、争取检测和响应时间非常关键。所以域内用户的密码建议设置得足够复杂并定期修改。

注意：排查发现已被 AS-REP Roasting 的用户，必须重置密码！

总结

AS-REP Roasting 是一种设计层面允许、但安全层面极易被滥用的攻击方式。它不依赖漏洞、不制造明显异常，却能直接获取可被离线破解的凭据。

对于应急响应来说，真正的挑战不在于理解攻击原理，而在于：如何在海量“看起来都正常”的 Kerberos 日志中，精准定位那几条不正常的事件。

赞赏

微信赞赏支付宝赞赏