AD域应急-Kerberoasting攻击狩猎

在 Active Directory 环境中，Kerberoasting 是一种非常经典、也非常“务实”的攻击方式。攻击者并不需要管理员权限，只要拥有一个普通的域用户账号，就可以对配置不当的服务账号发起攻击。

Kerberoasting 攻击原理

Kerberoasting 的核心逻辑很简单：
攻击者向域控制器请求某个服务的 Kerberos Service Ticket（TGS），然后将返回的票据离线破解，从而尝试还原该服务账号的明文密码。

只要一个账号设置了 SPN（Service Principal Name），并且密码复杂度不足、生命周期过长，理论上就具备被 Kerberoast 的可能性。在应急响应中之所以经常能看到这类攻击。在大量企业环境里，服务账号的权限配置和密码管理往往是最薄弱的一环。

服务账号配置不当，是最常用的突破口。在真实的 AD 环境中，服务账号常常被赋予了远超其实际需要的权限。为了“省事”或“避免服务出问题”，不少管理员会直接给服务账号分配高权限，甚至是 Domain Admin。

从攻击者的角度来看，这是极具性价比的目标：
一旦 Kerberoasting 成功并拿到一个高权限服务账号的密码，横向移动、权限提升几乎就是顺水推舟。

在多起应急事件中，我们看到攻击者并不会急于利用漏洞，而是优先在域内做枚举，专门寻找这些有价值的服务账号。

如何定位可被 Kerberoast 的账号

假设攻击者已经通过钓鱼邮件或弱口令拿到了一个普通域用户的访问权限。下一步，最常见的动作就是进行域内枚举。

GitHub – PowerShellMafia/PowerSploit: PowerSploit – A PowerShell Post-Exploitation Framework

在实战中，PowerSploit 套件里的 PowerView 是被滥用频率非常高的工具之一。不过该工具目前已经停止更新了。

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Import-Module .\PowerView.ps1

攻击者通常会先加载 PowerView 模块，然后枚举所有配置了 SPN 的账户。

通过带有 SPN 参数的用户枚举，攻击者可以快速筛选出疑似服务账号的目标。在大多数环境中，SPN 几乎只会配置在服务账号上。这里我们看到一个名为krbtgt的服务账户，这是Active Directory中的默认服务账户。

应急响应时需要注意的一点是：
有些管理员甚至会把密码直接写在账号的 Description 字段里。这种情况在真实企业环境中遇到过好多次。

Kerberoasting 的实际利用过程

当攻击者确认了目标服务账号后，接下来就可以直接请求对应的服务票据。

https://github.com/GhostPack/Rubeus
Rubeus 是最常见的 Kerberoasting 工具之一。

https://github.com/r3motecontrol/Ghostpack-CompiledBinaries

但是官方github上没有提供编译好的版本，需要自己编译。这里可以用别人编译好的版本。

.\Rubeus.exe kerberoast /outfile:hashes.txt

注意：Rubeus 默认把 $krb5tgs$... hash 按控制台宽度自动换行，复制出来就“断了”，John/Hashcat 解析不了。解决思路就是：让它输出到文件。

通过执行 Kerberoast 模式，攻击者可以一次性获取所有可被 Kerberoast 的服务账号票据，并将其导出为可离线破解的格式。

这一阶段的关键点在于：
整个过程不需要与目标服务发生真实交互，也不需要触发明显异常行为。请求 Kerberos 服务票据在域环境中本身就是高频、正常的操作。

票据一旦被导出，后续的破解工作完全发生在攻击者本地，对目标环境不会再产生任何噪音。

为什么 Kerberoasting 在日志里并不“显眼”

从防守方视角看，Kerberoasting 的最大难点在于——它隐藏在大量合法 Kerberos 行为之中。

即使执行多次Rubeus.exe kerberoast，域控上的日志也不会出现多条重复的476和4769日志。因为Kerberoasting 的关键是获取某 SPN 的 TGS。只要这张 TGS 在缓存里没过期，再跑一次就可能不再请求。

klist
klist purge

这样通常会看到 DC 上重新出现一波 4768/4769（至少 4769）。这也是Kerberoasting的攻击记录会淹没在大量日志中的主要原因。

例如，一个普通用户访问文件共享、数据库服务时，本身就会触发服务票据请求。在大型域环境中，每天都会产生成千上万条相关日志。这也是为什么很多组织在事后溯源时，才意识到服务账号早已被拖库破解。

日志层面如何识别 Kerberoasting 行为

尽管困难，但 Kerberoasting 并非完全不可检测。在应急分析中，最关键的还是域控制器上的安全日志，尤其是以下几个事件。

首先需要关注的是 Event ID 4768。该事件表示 Kerberos TGT 请求，如果其中出现加密类型为 0x17，就值得进一步关注。紧接着通常会看到 Event ID 4769，即服务票据请求事件。

在正常业务场景中，这个事件的加密类型多为 0x11 或 0x12。如果在 4769 事件中看到 0x17 的加密类型，这往往是一个非常重要的异常信号。

但实测在多次清除缓存后，重新执行触发的4768加密类型则一直为12，无法进行区分。所以重点关注4679的 0x17 加密类型即可。

Kerberoasting 的检测特征

单独一个异常事件并不足以定性攻击。在 SOC 或应急响应中，必须结合多个条件进行交叉验证。

常见的判断思路包括：
请求服务票据的账号是普通域用户，而不是服务账号或计算机账号（通常计算机账号和服务账号以 $ 结尾）。在短时间内，同一个用户请求了多个不同服务的票据，4769 事件中明确显示为 Audit Success（意味着票据请求成功，攻击者拿到了可用的哈希）。

将这些条件组合起来后，Kerberoasting 行为在日志中会清晰很多。

在实战中，可以将 Kerberoasting 的典型特征概括为以下几点：

• 出现 Event ID 4768，且加密类型为 0x17
• 紧接着出现 Event ID 4769，同样使用 0x17 加密
• 请求方为普通域用户，而非计算机或服务账号
• 在短时间内出现多次服务票据请求
• 事件结果为成功获取票据

当这些特征同时出现时，基本可以高度怀疑 Kerberoasting 行为正在发生。

Kerberoasting 的缓解措施

从根本上看，Kerberoasting 是一个“配置问题大于技术问题”的攻击。

在应急响应和日常防守中，至少应落实以下几点：

• 服务账号必须使用高复杂度、足够长度的密码
• 服务账号权限最小化，避免不必要的高权限
• 定期轮换服务账号密码，避免长期不变
• 在 SIEM 中建立针对 4769 + 0x17 的行为关联规则

这些措施并不能让 Kerberoasting 消失，但可以显著提高攻击成本，并降低成功率。在真实对抗中，拖慢攻击者、暴露攻击路径，本身就是一种成功的防御。

赞赏

微信赞赏支付宝赞赏