Zeltoc/ad-kerberoasting-detection

# Active Directory Kerberoasting 检测 **MITRE ATT&CK 映射：** - T1558.003 -- 窃取或伪造 Kerberos 票据：Kerberoasting - T1078 -- 有效账户（破解后） - T1562.001 -- 削弱防御：禁用或修改工具（Defender 排除项） **使用工具：** Rubeus 2.2.0, Hashcat 7.1.2, Wazuh 4.x, Sysmon 15.20 (Olaf Hartong 模块化配置), Microsoft Defender, Windows Event Log ## 目标 构建针对 Kerberoasting 的检测链（基于经过身份验证的内部用户上下文）。证明即使端点 AV 通过 Defender 排除项被绕过，该技术仍然可以通过域控制器上的 Kerberos 票据请求审计被检测到。 该实验环境模拟了一个真实的权限提升场景：一个对其工作站具有本地管理员权限的低权限域用户（在现实环境中这种情况极为普遍）试图通过对使用弱密码的服务账户进行 Kerberoasting 来提升权限。 ## 环境 | VM | OS | 角色 | IP | |---|---|---|---| | LAB-DC01 | Windows Server 2025 | 域控制器, DNS, DHCP | 10.10.20.10 | | W11-CLIENT01 | Windows 11 Pro 25H2 | 加入域的工作站（攻击者） | 10.10.20.100 | | Wazuh Manager | Ubuntu 22.04 | SIEM + 仪表板 | 192.168.1.161 | | OPNsense | FreeBSD | VLAN 20 与主 LAN 之间的网关 / 防火墙 | 10.10.20.1 | 实验环境 VLAN (10.10.20.0/24) 通过 OPNsense 与主 LAN 隔离。特定的防火墙规则允许：VLAN 20 → Wazuh Manager 的 TCP 1514–1515 端口（代理通信），VLAN 20 → 位于 192.168.1.150 的 Pi-hole（来自 DC 的 DNS 转发），以及 VLAN 20 → 互联网，同时阻止发往主 LAN 的所有其他流量。 域：`lab.internal`。两个端点均运行带有 Olaf Hartong `sysmonconfig.xml` 配置的 Sysmon，并将 Sysmon, Defender, Application, Security 和 System 通道转发给 Wazuh。 ## 背景知识 -- Kerberoasting 的工作原理 Active Directory 使用 Kerberos 进行身份验证。当用户想要访问某项服务时，他们会向域控制器请求目标服务主体名称 (SPN) 的服务票据 (TGS)。DC 在返回该票据之前，会使用服务账户的密码哈希对其一部分进行加密。 **攻击原理：** 任何经过身份验证的域用户都可以为任何带有 SPN 的账户请求 TGS，而不管他们是否拥有实际使用该服务的权限。如果服务账户的密码较弱，并且票据是使用 RC4-HMAC 加密（Kerberos etype 23，十六进制 `0x17`）颁发的，攻击者就可以离线破解嵌入的哈希值以恢复明文密码。 **为何危险：** - 可在任何经过身份验证的用户上下文中操作 -- 无需管理员权限 - DC 无法知晓该请求是恶意的 -- 这是一个合法的 Kerberos 操作 - 破解在离线状态下进行，不会产生任何进一步的网络流量 - 服务账户通常具有较高权限（数据库访问，SQL sysadmin，计划任务所有权），使其成为高价值目标 **现代 AD 倾向于使用 AES (etypes 17/18) 而不是 RC4 (etype 23)**，因为 AES 票据在消费级硬件上在计算上是不可破解的。Kerberoasting 只对那些明确支持 RC4 或者在强制使用 AES 之前就已设置密码的账户才能成功。寻找针对用户绑定 SPN 的 RC4 票据请求正是本实验室所针对的检测特征。 ## 诱饵设置 创建了一个“易受攻击的”服务账户来模拟现实世界中的配置错误： ``` # 创建了具有弱密码的 sservice (Sarah Service) Set-ADAccountPassword -Identity sservice -Reset ` -NewPassword (ConvertTo-SecureString "Summer2024!" -AsPlainText -Force) # 注册了伪造的 SQL Server SPN setspn -S MSSQLSvc/labsql.lab.internal:1433 sservice # 强制仅使用 RC4 加密（常见的遗留配置错误） Set-ADUser sservice -Replace @{'msDS-SupportedEncryptionTypes'=4} ``` `msDS-SupportedEncryptionTypes=4` 设置代表那些所有者为了保持与传统应用程序的兼容性而明确启用 RC4，并且从未将其移除的账户。在真实环境中，这些账户在度过了其最初的合理性阶段后会持续存在多年，成为 Kerberoasting 活生生的靶子。 已验证的 DC 审计策略： ``` Kerberos Service Ticket Operations Success and Failure ``` ## 攻击链 ### 阶段 1 -- 工具获取 (Defender Event 1116) 从 GitHub 发布页下载了 `Rubeus.exe`（编译好的二进制文件镜像）。Defender 在下载后约 30 秒内隔离了该文件。 **检测：** Microsoft Defender Antivirus 基于签名的检测将该二进制文件识别为 `VirTool:Win32/Kekeo.A!MTB`（Microsoft 将 GhostPack 的 Rubeus 归类在早期的 Kekeo 家族下）。`!MTB` 后缀表示 Monitor Threat Behavior -- 这是一个行为分类器，而不是纯粹的哈希匹配。 ``` Event ID: 1116 Provider: Microsoft-Windows-Windows Defender Path: C:\Users\user\Downloads\Rubeus.exe Threat: VirTool:Win32/Kekeo.A!MTB Severity: Severe Action: Quarantined ``` **Wazuh 转发缺口：** 默认的 Wazuh Windows 代理配置转发 Application, Security 和 System 通道，但不包括 `Microsoft-Windows-Windows Defender/Operational`。在两个端点上手动将该通道添加到了 `ossec.conf` 以捕获 Defender 遥测数据。这是一个常见的部署缺陷，在生产环境中值得检查。 ### 阶段 2 -- Defender 规避 (Event 5007) 添加了一个路径排除项，以绕过对暂存位置的实时扫描： ``` New-Item -ItemType Directory -Path "C:\Tools" -Force Add-MpPreference -ExclusionPath "C:\Tools" ``` **检测：** 每当 Defender 配置发生更改时，就会触发 Event 5007。事件负载包含正在修改的注册表路径，使得排除目标可见。 ``` Event ID: 5007 New value: HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\C:\Tools = 0x0 ``` **检测意义：** 在正常操作中，路径排除项的添加极为罕见。大多数企业通过 Group Policy 或 Intune 管理 Defender 配置；交互式 PowerShell 添加排除项几乎总是表明存在手动操作的攻击者，或者是由于管理员在排查 AV 拦截问题时感到沮丧。这值得直接以高严重性发出警报。 ### 阶段 3 -- 工具暂存 (Wazuh rule 92213, level 15) 将 Rubeus.exe 重新下载到 `C:\Tools\Rubeus.exe`。由于该路径已被排除，Defender 未对该文件采取行动。 SHA256: `1BFBEFA4FF4D0DF3EE0090B5079CF84ED2E8D5377BA5B7A30AFD88367D57B9FF` **检测：** 即使端点上的 Defender 已被绕过，Wazuh 的内置规则集仍会对暂存活动触发 level 15 警报（其最高严重级别）： ``` Rule ID: 92213 Description: Executable file dropped in folder commonly used by malware Level: 15 ``` 该规则逻辑匹配 Sysmon Event 11 (FileCreate)，其中目标路径符合与攻击者暂存相关的模式（根级 `C:\` 目录，如 `C:\Tools`, `C:\Temp`, `C:\PerfLogs`，以及用户配置文件的临时路径）。这正是 SIEM 提供的那种端点 AV 单独无法实现的关联检测类型——该文件本身通过签名已不再被视为恶意（仍然是同一个二进制文件，但 Defender 跳过了它），然而将其存放在可疑位置的*行为*仍然触发了警报。 **Sysmon 部署注意：** Sysmon 的默认安装运行时没有任何配置，几乎记录不到任何有用的信息。部署了 Olaf Hartong 的 `sysmon-modular` 配置以启用 FileCreate, RegistryEvent, ImageLoad 和 DNS 查询日志记录。在运行攻击之前通过测试文件创建验证了覆盖范围。这会在小型实验室中产生大量事件；在生产环境中，这需要配合下游过滤。 ### 阶段 4 -- 进程执行 (Sysmon Event 1, Wazuh rule 92154) 以普通域用户身份从 `C:\Tools` 执行了 Rubeus。无需提权 -- Kerberoasting 可在任何经过身份验证的用户上下文中运行。 ``` PS C:\Tools> .\Rubeus.exe kerberoast /user:sservice /outfile:hash_final.txt ``` **检测：** Sysmon 记录了进程创建 (Event ID 1)，包含二进制文件路径、哈希值、命令行参数和父进程。Wazuh 进一步关联了后续的 DLL 加载——包括 `taskschd.dll`——并触发了规则 92154（`Process loaded taskschd.dll module. May be used to create delayed malware execution`）。 ### 阶段 5 -- Kerberos 票据请求 (Event 4769) -- 主要检测 这是整条链中保真度最高的检测，因为它捕获的是技术本身，而不是工具。任何执行 Kerberoasting 的工具——Rubeus、Impacket 的 GetUserSPNs、PowerView、自定义脚本——都会产生相同的线上特征。 ``` Event ID: 4769 Provider: Microsoft-Windows-Security-Auditing TargetUserName: user@LAB.INTERNAL ServiceName: sservice ServiceSid: S-1-5-21-3890910729-4105664814-3090594008-1107 TicketEncryptionType: 0x17 (RC4-HMAC) SessionKeyEncryptionType: 0x17 IpAddress: ::ffff:10.10.20.100 ServiceSupportedEncryptionTypes: 0x4 (RC4) ``` **检测特征分解：** | 指标 | 为何重要 | |---|---| | Event 4769 (TGS-REQ) | Kerberos 票据请求操作本身 | | `TicketEncryptionType: 0x17` | RC4 -- 现代 AD 偏好 AES (etypes 17/18)。针对用户账户颁发 RC4 票据在传统环境之外极为罕见 | | `ServiceSid` 以 RID `>1000` 结尾 | 用户账户 SID 范围，而不是计算机/机器账户（`$` 账户对于内置或不同范围的计算机账户以 RID `<1000` 结尾）。针对用户账户的服务票据请求远少于针对计算机账户的请求 | | `IpAddress` 解析为工作站 | 来源于工作站（而不是需要服务身份验证的应用服务器）的服务票据请求是异常的 | 检测规则概念：`4769 AND TicketEncryptionType=0x17 AND ServiceName!~"$" AND IpAddress NOT IN trusted_application_servers` 这些条件的组合使得 Kerberoasting 成为 AD 中保真度最高的检测机会之一——当这四个条件都满足时，误报并不常见。 ### 阶段 6 -- 离线破解 将 `hash_final.txt` 传输到单独的破解系统。Hashcat 输出： ``` hashcat -m 13100 -a 0 hash_final.txt custom.txt Status..........: Cracked Recovered.......: 1/1 (100.00%) Digests Time.Started....: Fri May 15 23:36:36 2026 (0 secs) Time.Estimated..: Fri May 15 23:36:36 2026 (0 secs) $krb5tgs$23$*sservice$lab.internal$MSSQLSvc/labsql.lab.internal:1433...:Summer2024! ``` 密码 `Summer2024!` 在针对包含 14 个条目且以常见季节性模式为目标的定制字典下，不到一秒钟即被破解。 **字典注意：** 最初使用 `rockyou.txt`（源自 2009 年数据泄露的标准字典）的尝试未能破解该密码——`Summer2024!` 距今太近，未出现在传统字典中。这反映了真实攻击者的手法：单独的字典攻击通常是不够的，但从交战背景中派生的定向字典则能可靠地取得成功。生产环境中的攻击者通常会将字典与变形规则（例如 `hashcat -r best64.rule`）结合使用，以处理现代密码模式。 **阶段 6 没有检测界面。** 一旦哈希值离开 DC，破解就完全在网络外进行。不会再触发任何警报。然后，攻击者可以以合法经过身份验证的用户身份登录服务账户有权访问的任何系统——并且随后的身份验证看起来将与正常用户登录完全一样。 这就是为什么检测必须在阶段 1 到 5 进行。 ## 检测总结 | 阶段 | 事件来源 | Event ID / Rule | 严重性 | 检测层 | |---|---|---|---|---| | 1. 工具下载 | Microsoft Defender | 1116 | 高 (Defender 严重性: Severe) | 端点 AV 签名 | | 2. AV 规避 | Microsoft Defender | 5007 | 信息 (但为高保真 IOC) | 配置审计 | | 3. 工具暂存 | Wazuh + Sysmon | Rule 92213 | Level 15 | SIEM 行为规则 | | 4. 进程执行 | Sysmon | Event 1 + Rule 92154 | Level 4 | EDR 式遥测 | | 5. Kerberos 票据请求 | Windows Security | 4769 (etype 0x17) | -- (原始事件；需要自定义规则) | DC 侧审计日志 | | 6. 离线破解 | 无 | 无 | 无 | 无法检测 | **检测覆盖观察：** Wazuh 的默认规则集揭示了暂存行为 (rule 92213) 和进程执行 (rule 92154)，但没有将 4769 事件关联为 Kerberoasting 特定的警报。原始事件存在于索引中并且可以查询，但没有规则自动触发。**这是本实验室中发现的最重要检测缺口。** 一个匹配 4769 + etype 0x17 + 服务账户 SPN 的自定义 Wazuh 规则将填补这一空白，也是自然的下一步。 ## 加固建议 检测是必要的，但还不够。以下控制措施可以完全阻止 Kerberoasting 或限制其损害： 1. **将服务账户迁移至仅 AES 加密。** 从所有服务账户中移除 `msDS-SupportedEncryptionTypes=4`，并改为设置为 `0x18` (AES128 + AES256)。RC4 票据将变得无法颁发。 2. **使用组托管服务账户 (gMSAs)。** gMSAs 使用每 30 天自动轮换的 240字符的加密随机密码。即使 gMSA 哈希被提取，在轮换窗口内对其进行破解在计算上也是不可行的。 3. **强制实施强服务账户密码。** 25 个以上字符的随机密码使得无论使用何种加密类型，离线破解都不切实际。 4. **审计现有 SPN 的不必要注册。** 没有 SPN 的服务账户无法被 Kerberoasting。许多账户的 SPN 是从不再使用的传统应用程序中注册来的。 5. **蜜罐服务账户。** 创建带有 SPN 的服务账户，且任何合法进程都不应请求这些账户的票据。对任何引用这些账户的 4769 事件以高严重性发出警报。 ## 经验教训与撰写记录 **关于 Defender 与 SIEM 覆盖率：** 路径排除项是一个被低估的可见性风险。具有本地管理员权限的攻击者可以在几秒钟内添加排除项，从那时起，端点 AV 对该路径中的任何内容都将处于盲区。SIEM 侧的关联（可疑的暂存位置、异常的进程行为、网络侧的票据请求）提供了持续的可见性。对于已经拥有端点保护的环境来说，这是投资 SIEM 最有力的单一理由。 **关于加密类型作为检测信号：** RC4 Kerberos 票据在现代 AD 部署中极为罕见。通过 `TicketEncryptionType=0x17` 过滤 4769 事件是可用的最简洁的检测特征之一——高信号，低噪声。查询 `4769 AND etype=0x17 AND service NOT ending in $` 可以在几乎无需调优的情况下捕获大多数生产环境中的 Kerberoasting 尝试。 **关于检测的局限性：** 阶段 6（离线破解）不产生任何可检测的信号。每一个有意义的检测机会都存在于阶段 1–5 中。一旦哈希值离开 DC，攻击者拥有的限制只剩下时间和耐心。这使得 4769 检测（阶段 5）成为整条链中最重要的警报——这是在攻击者掌握有效凭证之前抓住攻击的最后机会。 ## 指标 | IOC | 类型 | 值 | |---|---|---| | Rubeus.exe SHA256 | File hash | `1BFBEFA4FF4D0DF3EE0090B5079CF84ED2E8D5377BA5B7A30AFD88367D57B9FF` | | Defender 威胁分类 | Signature | `VirTool:Win32/Kekeo.A!MTB` | | 暂存路径 | File path | `C:\Tools\Rubeus.exe` | | Defender 排除项注册表路径 | Registry | `HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\C:\Tools` | | 目标服务账户 | AD account | `sservice` / `MSSQLSvc/labsql.lab.internal:1433` | | 被破解的凭证 | Password | `Summer2024!` | *实验室环境被有意设置为易受攻击状态。所有活动均限于隔离的 VLAN 内。请勿对您不拥有或未获得明确授权测试的系统执行这些技术。*

标签：Active Directory, AD安全, AI合规, Bitdefender, Hashcat, Kerberoasting, Microsoft Defender, OPNsense, PFX证书, Plaso, Rubeus, Sysmon, VLAN, Wazuh, Windows事件日志, 关联分析, 协议分析, 域控安全, 安全实验室, 安全运营中心, 弱口令, 攻击检测, 数字取证, 数据展示, 权限提升, 活动目录, 漏洞复现, 红队, 网络分段, 网络安全, 网络映射, 自动化脚本, 防火墙, 隐私保护