授权内网测试中发现异常 Kerberos 委派，如何验证权限边界并保留审计证据？

背景与问题在一次已取得书面授权的 Windows 域安全评估中，资产梳理发现某业务服务账号配置了 Kerberos 委派。常见疑问是：这是否已经构成可利用问题，如何在不导出凭据、不接管账号的前提下验证影响范围，以及应该保留哪些日志供管理员复核？以下步骤以只读枚举和受控测试账号为前提。不要在生产域执行票据伪造、凭据导出或横向登录；若需要验证实际访问，应先约定目标主机、时间窗口和回滚负责人。问题定位：先区分三类委派类型关键属性主要风险非约束委派userAccountControl 含 TRUSTED_FOR_DELEGATION服务主机可能接触用户可转发票据，风险通常最高约束委派msDS-AllowedToDelegateTo账号可代表用户访问属性列出的后端 SPN基于资源的约束委派 RBCD目标对象的 msDS-AllowedToActOnBehalfOfOtherIdentity由资源端决定哪些主体可代表用户访问本机服务判断时不能只看“是否有委派”。还要核对委派主体是否可被低权限人员修改、后端 SPN 指向何处、敏感账号是否禁止委派，以及服务账号是否使用 gMSA。只读排查步骤确认当前使用的是审计账号，并记录域控、查询时间和工单编号。分别查询用户、计算机对象的 userAccountControl、msDS-AllowedToDelegateTo 与 RBCD 属性。检查委派主体对象的 ACL，重点关注 GenericAll、GenericWrite、WriteDacl、WriteOwner，以及对相关属性的写权限。解析 SPN 对应的主机和服务，核对它是否属于授权测试资产。检查高权限账号是否带有“Account is sensitive and cannot be delegated”，并核对 Protected Users 组。# 在装有 RSAT ActiveDirectory 模块的审计终端执行；以下命令仅查询目录
Import-Module ActiveDirectory

# 1. 查询非约束委派对象
Get-ADObject -LDAPFilter '(|(userAccountControl:1.2.840.113556.1.4.803:=524288)(userAccountControl:1.2.840.113556.1.4.803:=16777216))' `
-Properties objectClass,userAccountControl,servicePrincipalName |
Select-Object Name,ObjectClass,DistinguishedName,servicePrincipalName

# 2. 查询约束委派
Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' `
-Properties msDS-AllowedToDelegateTo |
Select-Object Name,DistinguishedName,msDS-AllowedToDelegateTo

# 3. 查询配置了 RBCD 的资源对象；只显示是否存在，避免误改安全描述符
Get-ADObject -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
-Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
Select-Object Name,ObjectClass,DistinguishedName,
@{N='RBCDConfigured';E={$null -ne $_.'msDS-AllowedToActOnBehalfOfOtherIdentity'}}

# 4. 查询具备 SPN 的用户型服务账号
Get-ADUser -LDAPFilter '(servicePrincipalName=*)' `
-Properties servicePrincipalName,PasswordLastSet,Enabled,AccountNotDelegated |
Select-Object SamAccountName,Enabled,PasswordLastSet,AccountNotDelegated,servicePrincipalName
如何验证权限边界建议采用“两段式证据”，而不是直接进行横向利用。第一段证明配置事实：导出目录对象属性、对象 SID、SPN 和 ACL。第二段证明可达边界：由管理员创建无业务权限的临时测试用户，仅访问预先指定的测试服务，并确认它无法访问授权清单之外的主机或服务。查看对象 ACL 时，应把 SID 解析成主体名称，尤其关注委派对象自身、其所在 OU，以及目标计算机对象。下面的命令可用于审计单个对象；输出应保存到受控目录并计算哈希。$dn = 'CN=svc_web,OU=Service Accounts,DC=corp,DC=example'
(Get-Acl ('AD:\' + $dn)).Access |
Where-Object {
$_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty'
} |
Select-Object IdentityReference,ActiveDirectoryRights,AccessControlType,
ObjectType,IsInherited |
Export-Csv .\svc_web_acl.csv -NoTypeInformation -Encoding UTF8

Get-FileHash .\svc_web_acl.csv -Algorithm SHA256
如果发现普通运维组可以修改服务账号 SPN、委派属性，或者可以控制配置了 RBCD 的计算机对象，即使尚未执行身份模拟，也足以形成“可控主体—可写属性—目标服务”的权限链。报告中应分别描述配置缺陷和潜在影响，不要把“存在配置”直接写成“已经失陷”。日志留痕与关联分析域控应启用“Directory Service Changes”和 Kerberos 相关高级审核。重点关联以下事件：5136：目录对象属性被修改；关注 AttributeLDAPDisplayName、SubjectUserSid 和 ObjectDN。4769：请求 Kerberos 服务票据；关注 ServiceName、TicketEncryptionType、ClientAddress 和失败码。4624：目标主机登录成功；关注 LogonType、AuthenticationPackageName、IpAddress。4672：新登录被分配敏感特权，可用于确认测试账号是否意外获得高权限上下文。# 在域控上按授权时间窗导出关键事件，避免全量拉取
$start = Get-Date '2025-03-08 10:00:00'
$end = Get-Date '2025-03-08 11:00:00'
$ids = 4769,5136

Get-WinEvent -FilterHashtable @{
LogName='Security'; Id=$ids; StartTime=$start; EndTime=$end
} | Select-Object TimeCreated,Id,MachineName,RecordId,Message |
Export-Csv .\dc_delegation_audit.csv -NoTypeInformation -Encoding UTF8

Get-FileHash .\dc_delegation_audit.csv -Algorithm SHA256
事件 4769 数量大，不宜只凭单条告警下结论。应按测试账号、目标 SPN、来源地址和时间窗与 4624 关联。5136 若没有记录，先检查高级审核策略和对应对象的 SACL，而不是默认认为属性从未被修改。常见误判只看到 msDS-AllowedToDelegateTo 就判定域控可被接管，没有核对 SPN 实际指向。忽略 ACL：委派范围有限，但低权限组能改目标计算机或服务账号，实际边界可能扩大。把计算机账号的正常 SPN 当成异常。HOST、RestrictedKrbHost 等通常由系统维护，应结合对象创建时间和变更日志判断。用生产管理员账号做验证，导致测试本身把高价值票据带到不可信服务。风险处置与修复建议优先移除非约束委派；确有业务依赖时，迁移到最小范围的约束委派或经评审的 RBCD。收紧服务账号、计算机对象及其 OU 的 ACL，删除非必要的 GenericWrite、WriteDacl 和属性级写权限。服务账号迁移到 gMSA，禁止交互式登录，并限制“Log on as a service”的主机范围。对域管理员等敏感账号设置不可委派，并评估加入 Protected Users；变更前验证旧协议兼容性。清理重复或废弃 SPN，建立 5136 委派属性变更告警，并将工单号、操作者和变更前后值一并留存。修复后重复执行只读查询，确认属性和 ACL 已收敛；再由业务方验证服务功能，避免只修安全配置却造成认证中断。总结委派问题的核心不是单个属性，而是委派配置、对象控制权、SPN 指向和日志证据组成的完整权限链。授权评估中，优先用目录查询、ACL 审计和受控测试账号证明边界；只有在明确批准后才进行更深入验证。这样既能给出可复现结论，也能避免测试行为扩大生产风险。

先不要直接做票据伪造或横向访问。委派的权限边界主要由委派类型、主体、允许的后端 SPN、协议转换能力共同决定，建议按“只读确认 → 受控验证 → 日志闭环”三步处理。

1. 先确认是哪一种委派

Import-Module ActiveDirectory

# 传统非约束/约束委派
Get-ADComputer -LDAPFilter '(|(userAccountControl:1.2.840.113556.1.4.803:=524288)(msDS-AllowedToDelegateTo=*))' `
  -Properties userAccountControl,msDS-AllowedToDelegateTo,TrustedForDelegation,TrustedToAuthForDelegation |
  Select-Object Name,DistinguishedName,TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo

Get-ADUser -LDAPFilter '(|(userAccountControl:1.2.840.113556.1.4.803:=524288)(msDS-AllowedToDelegateTo=*))' `
  -Properties userAccountControl,msDS-AllowedToDelegateTo,TrustedForDelegation,TrustedToAuthForDelegation |
  Select-Object SamAccountName,DistinguishedName,TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo

# 资源基约束委派 RBCD
Get-ADObject -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
  -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Select-Object DistinguishedName,msDS-AllowedToActOnBehalfOfOtherIdentity

TrustedForDelegation=True 通常是非约束委派；msDS-AllowedToDelegateTo 是传统约束委派的目标 SPN；同时存在 TrustedToAuthForDelegation=True 时，要重点确认是否允许协议转换。RBCD 的属性是安全描述符，不能只保存原始字节，最好把 SID 解析出来：

$targets = Get-ADObject -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
  -Properties msDS-AllowedToActOnBehalfOfOtherIdentity

foreach ($t in $targets) {
  $sd = New-Object System.DirectoryServices.ActiveDirectorySecurity
  $sd.SetSecurityDescriptorBinaryForm($t.'msDS-AllowedToActOnBehalfOfOtherIdentity')
  $sd.Access | Select-Object `
    @{n='TargetDN';e={$t.DistinguishedName}},IdentityReference,AccessControlType,ActiveDirectoryRights
}

另外核对 SPN 是否重复或指向了意外主体，否则看似受限的后端范围可能被错误注册扩大：

setspn -X
setspn -Q HTTP/app01.contoso.local
setspn -Q CIFS/files01.contoso.local

2. 验证边界时做正、反两组测试

建议新建一次性低权限测试用户，使用专门的测试服务和测试数据，不选域管、服务账号或真实管理员。先用批准的 Kerberos 测试工具验证清单内 SPN，再访问一个不在 msDS-AllowedToDelegateTo 中的 SPN作为反例。成功标准应同时包含：

• 清单内目标可以完成 Kerberos 身份转发；
• 清单外 SPN、不同服务类型及不同主机均失败；
• 目标服务实际授权仍生效，例如测试用户只能读取测试目录，不能取得管理员权限；
• 全过程不修改 AD 委派属性、不新增 SPN、不触碰生产凭据。

测试前后清票，避免已有票据干扰结论：

klist purge
# 执行一次受控访问
klist tickets

如果发现非约束委派，不建议通过诱导高权限账户登录来“证明影响”；确认该主机可接收被委派 TGT、结合登录范围和资产角色，通常已经足以判定风险。确需动态验证时，应由域管理员提供隔离账户并明确禁止敏感组成员参与。

3. 审计证据要同时覆盖 AD、KDC 和目标服务

在域控收集安全日志 4768、4769、4770，重点记录客户端地址、账户、服务名、票据选项、加密类型和状态码；属性变更则关注 5136，必要时补充 4662。目标服务器根据服务类型保留 4624、4634、SMB/WinRM/IIS 对应日志。验证协议转换时，关联同一时间窗内的前端请求、KDC 服务票请求和后端登录事件，不要只凭单条 4769 下结论。

$start = (Get-Date).AddMinutes(-30)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769,4770,5136; StartTime=$start} |
  Export-Clixml .\kerberos-events.xml

wevtutil epl Security .\Security.evtx "/q:*[System[TimeCreated[timediff(@SystemTime) <= 1800000]]]"
Get-FileHash .\Security.evtx,.\kerberos-events.xml -Algorithm SHA256 |
  Format-List | Out-File .\SHA256.txt

证据包里建议再放：UTC 时间线、执行人和授权单号、源/目标 IP、测试账户 SID、查询脚本及输出、域控与目标主机名、时钟偏差、每一步预期与实际结果。原始 EVTX 和导出结果只读保存，分析使用副本，并记录 SHA-256。

最后还要查清谁能改变委派边界：检查相关计算机/服务账户对象的 Owner、DACL，以及谁拥有 WriteProperty、GenericWrite、GenericAll、WriteDacl。很多异常并不是当前委派值本身，而是普通运维组可以修改 msDS-AllowedToDelegateTo、RBCD 属性或 SPN。发现这类权限时应单独作为可扩展权限路径记录。