授权内网测试中发现疑似 Kerberoasting，如何确认影响范围并给出修复建议

发布于昨天 23:051天前

背景

最近在一次授权内网渗透测试的答疑里，有同学问到：在域环境里用普通域用户执行枚举时，发现多个带 SPN 的服务账号，且能请求到 TGS 票据。这种情况是否就等于存在 Kerberoasting 风险？如何在不扩大影响的前提下确认范围、留痕情况和修复优先级？

这个问题比较适合放在问答中心讨论，因为重点不是“怎么打”，而是授权测试里如何判断问题、怎么留证、怎么给蓝队可执行的修复建议。

前提：以下操作仅限已授权测试环境。建议优先使用只读枚举和日志验证，不建议在生产域内进行离线爆破验证，除非授权范围明确允许。

问题定位

判断是否存在 Kerberoasting 风险，不能只看“能否请求 TGS”。在 AD 里，普通域用户默认就可以为可访问的 SPN 请求服务票据，这本身是 Kerberos 机制的一部分。真正需要关注的是：

服务账号是否为普通用户账号，而不是 gMSA 或机器账号。
账号是否设置了 SPN，例如 MSSQLSvc、HTTP、HOST、LDAP 等。
服务账号密码是否长期不变、复杂度不足或可被离线破解。
账号是否拥有高权限，例如 Domain Admin、服务器本地管理员、数据库 sysadmin。
域控日志中是否出现异常批量 TGS 请求。

因此，问答中建议先把问题拆成三部分：资产范围、权限影响、日志证据。

技术分析

Kerberoasting 的核心点是：域用户可以请求某个 SPN 对应服务账号的 TGS，票据中包含用服务账号密钥加密的部分。如果服务账号密码弱，攻击者可以离线尝试破解。蓝队侧主要关注 Windows 安全日志 4769 事件。

关键字段包括：

Event ID 4769：请求 Kerberos 服务票据。
Service Name：被请求的服务账号或 SPN。
Account Name：发起请求的用户。
Ticket Encryption Type：加密类型，常见 0x17 为 RC4-HMAC，风险更高。
Client Address：请求来源 IP。

实际测试中，如果短时间内某个普通用户对大量不同 SPN 发起 4769 请求，尤其包含 RC4 加密类型，就值得关注。注意不要简单把单个 4769 事件判为攻击，很多业务访问也会产生该日志。

操作步骤

可以按下面顺序排查，尽量减少对业务影响。

第一步：枚举域内带 SPN 的用户账号。
第二步：查看账号属性，包括密码最后设置时间、是否禁用预认证、是否高权限组成员。
第三步：检查域控 4769 日志，确认是否存在异常请求行为。
第四步：将服务账号与实际业务系统对应起来，确认是否仍在使用。
第五步：按权限和密码年龄给出修复优先级。

命令示例

在已加入域的管理终端或授权测试机上，可以使用 PowerShell 和 Windows 原生命令进行只读排查。

# 查询域内带 SPN 的用户账号，需要 RSAT ActiveDirectory 模块
Import-Module ActiveDirectory

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' \
  -Properties servicePrincipalName,PasswordLastSet,Enabled,MemberOf,AdminCount |
Select-Object SamAccountName,Enabled,PasswordLastSet,AdminCount,servicePrincipalName |
Format-List

# 重点关注 AdminCount=1 的服务账号
Get-ADUser -LDAPFilter '(servicePrincipalName=*)' \
  -Properties servicePrincipalName,PasswordLastSet,AdminCount |
Where-Object {$_.AdminCount -eq 1} |
Select-Object SamAccountName,PasswordLastSet,servicePrincipalName

# 使用 setspn 查看指定账号 SPN
setspn -L svc_sql

# 查询域控 4769 日志，筛选 RC4-HMAC 类型 0x17
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddDays(-7)} |
Where-Object { $_.Properties[5].Value -eq '0x17' } |
Select-Object TimeCreated,
@{n='User';e={$_.Properties[0].Value}},
@{n='Service';e={$_.Properties[2].Value}},
@{n='ClientIP';e={$_.Properties[6].Value}},
@{n='EncType';e={$_.Properties[5].Value}} |
Sort-Object TimeCreated

如果环境里没有 RSAT，也可以用 setspn 做初步确认：

# 枚举所有注册 SPN 的对象
setspn -Q */*

# 查询指定服务类型，例如 MSSQL
setspn -Q MSSQLSvc/*

日志平台如果接入了 Windows 安全日志，可以用类似思路做聚合。下面是一个偏通用的检索逻辑，字段名需要按实际 SIEM 调整：

event_id:4769 AND ticket_encryption_type:"0x17"
| stats count, dc(service_name) as service_count by account_name, client_ip
| where service_count > 10
| sort -count

风险判断

建议按以下规则分级，而不是简单写“存在 Kerberoasting 漏洞”。

风险点	判断依据	优先级
高权限服务账号带 SPN	账号属于 Domain Admin、Enterprise Admin、服务器本地管理员、数据库高权限角色	高
长期未改密	PasswordLastSet 超过 180 天或更久	中高
使用 RC4	4769 中 Ticket Encryption Type 出现 0x17	中高
普通用户批量请求 TGS	短时间访问大量不同 Service Name	中
历史遗留 SPN	业务已下线但 SPN 仍存在	中

日志留痕与蓝队排查

蓝队可以重点看域控安全日志中的 4769，并结合 4624、4672、4688、7045 等事件还原链路：

4769：是否存在批量服务票据请求。
4624：请求账号是否随后登录到关键服务器。
4672：是否出现特权登录。
4688：终端是否执行异常工具或脚本，需要开启进程命令行审计。
7045：是否创建异常服务，常见于后续横向阶段。

一个比较实用的检测思路是：按用户和源 IP 统计 10 分钟窗口内访问的不同 SPN 数量。如果普通办公用户突然请求几十个服务票据，需要结合终端行为继续查。

# 本地快速统计近 24 小时某用户请求的不同服务数
$user = 'test.user'
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddHours(-24)} |
Where-Object { $_.Properties[0].Value -eq $user } |
ForEach-Object {
  [PSCustomObject]@{
    TimeCreated = $_.TimeCreated
    User        = $_.Properties[0].Value
    Service     = $_.Properties[2].Value
    ClientIP    = $_.Properties[6].Value
    EncType     = $_.Properties[5].Value
  }
} | Group-Object Service | Sort-Object Count -Descending

修复建议

修复不要只停留在“改复杂密码”。比较稳妥的处理方式如下：

将普通用户型服务账号迁移为 gMSA，由域自动管理密码。
清理无用 SPN，避免历史服务账号继续暴露。
服务账号最小权限化，不要加入 Domain Admin 等高权限组。
禁用或限制 RC4，优先使用 AES 加密；修改前需要确认旧系统兼容性。
为服务账号设置独立、长随机密码，并建立轮换流程。
开启域控 Kerberos 审计，确保 4769 能被集中采集。
对关键服务账号配置登录限制，例如只允许登录指定服务器。

清理 SPN 前必须确认业务依赖，否则可能导致服务认证失败。可先在变更窗口内操作，并保留回滚记录。

# 查看账号支持的 Kerberos 加密类型
Get-ADUser svc_sql -Properties msDS-SupportedEncryptionTypes |
Select-Object SamAccountName,msDS-SupportedEncryptionTypes

# 示例：删除废弃 SPN，执行前务必确认业务已下线
setspn -D MSSQLSvc/old-sql01.domain.local:1433 svc_sql

# 示例：查询服务账号所属组，排查不必要高权限
Get-ADPrincipalGroupMembership svc_sql |
Select-Object Name,GroupCategory,GroupScope

答疑补充

常见误区有两个。第一，能请求 TGS 不等于一定被攻破，它只是暴露了一个可被验证的攻击面。第二，不建议在生产环境直接对票据做爆破证明风险，报告里可以用账号属性、加密类型、权限关系和日志证据来证明可利用性。

如果甲方要求验证密码强度，建议使用专门授权的测试账号或在隔离环境复现，不要对真实业务服务账号进行大规模离线破解。

总结

在问答中心讨论这类问题，重点是把“现象”转成“可验证证据”和“可落地修复”。Kerberoasting 的风险判断应结合 SPN、账号权限、密码年龄、加密类型和 4769 日志，而不是只看单点输出。对蓝队来说，持续监控批量 TGS 请求、减少高权限服务账号、迁移 gMSA，是比较实际的防护路径。

登录