授权内网测试中发现 WinRM 横向痕迹，如何确认权限边界并完成日志闭环？

背景

在一次已授权的 Windows 域内网测试中，测试人员使用普通域账号登录一台运维终端后，发现该账号可以通过 WinRM 连接部分业务服务器。问题是：这究竟属于预期的远程运维权限，还是由本地管理员组嵌套、域组配置错误或会话凭据暴露形成的越权链路？同时，蓝队需要确认连接是否已经发生、涉及哪些主机，以及日志能否支撑完整溯源。

以下排查应在明确授权范围内进行。建议优先执行只读查询，不要直接创建账户、修改组成员或关闭安全策略。

问题定位

这类问题不要只凭“5985 端口开放”或“Enter-PSSession 成功”下结论。至少需要分别确认网络可达性、WinRM 服务配置、远程登录授权、本地管理员组来源、实际令牌权限和日志留痕。

操作步骤

第一步从测试终端确认目标端口和当前身份。这里仅验证指定资产，不建议对整个网段进行无差别扫描。

$Target = "srv-app-01.contoso.local"
whoami /all
Test-NetConnection -ComputerName $Target -Port 5985
Test-NetConnection -ComputerName $Target -Port 5986

# 只测试当前凭据是否能够建立远程会话，不执行配置变更
Test-WSMan -ComputerName $Target -Authentication Negotiate

Test-WSMan 成功只能证明服务响应正常。随后可执行最小化的身份查询，确认远程会话中的账号、组和完整性级别。建议将测试时间、源地址、目标主机和工单编号同时记录下来，方便蓝队对表。

Invoke-Command -ComputerName $Target -ScriptBlock {
    hostname
    whoami
    whoami /groups
    whoami /priv
} -Authentication Negotiate

如果返回 Access is denied，应先核对账号是否属于 Remote Management Users、本地 Administrators，或者 WinRM 会话端点是否配置了自定义安全描述符。不要为了“验证”而直接把账号加入管理员组。

技术分析：权限从哪里来

能够远程连接后，需要在目标服务器上以管理员或审计账号检查本地组成员。重点不是只看直接成员，还要继续解析其中的域组。

# 目标主机执行：查看本地授权组
Get-LocalGroupMember -Group "Administrators"
Get-LocalGroupMember -Group "Remote Management Users"

# 域管理模块可用时，在管理终端解析域组嵌套
Get-ADPrincipalGroupMembership -Identity "test.user" |
    Select-Object Name, GroupScope, DistinguishedName

# 查看限制组或本地用户和组策略应用结果
gpresult /scope computer /h C:\Windows\Temp\gp-computer.html

常见根因有三类：其一，业务部门域组被错误加入服务器本地 Administrators；其二，GPO 的“受限制的组”或“本地用户和组”首选项覆盖范围过大；其三，WinRM 自定义端点给普通用户授予了超出预期的命令能力。第三类情况应检查会话配置。

Get-PSSessionConfiguration |
    Select-Object Name, Permission, RunAsUser, ConfigFilePath

winrm enumerate winrm/config/listener
winrm get winrm/config/service
winrm get winrm/config/service/auth

检查时尤其关注 Basic、AllowUnencrypted、CredSSP 和 TrustedHosts。域环境通常应优先使用 Kerberos；不应把 TrustedHosts 设置为通配符，也不应为解决连接问题长期启用未加密传输。

日志如何形成证据链

建议使用统一的 UTC 或明确时区，以源主机、目标主机和域控三端时间为主线。目标服务器至少检查 Security、Microsoft-Windows-WinRM/Operational 和 Microsoft-Windows-PowerShell/Operational。

• 4624：成功登录，关注 LogonType、源地址、AuthenticationPackageName。
• 4625：失败登录，可用于确认探测或错误凭据。
• 4672：向新登录分配特殊权限，不能单独证明已经执行高危操作。
• 4688：进程创建；需要启用“审核进程创建”并配置命令行记录才有足够信息。
• 4103、4104：PowerShell 模块与脚本块日志。
• WinRM Operational 相关事件：用于关联远程 Shell 的创建和活动。
• 域控 4768、4769：Kerberos TGT 与服务票据申请，可辅助确认账号访问目标服务的时间。

下面示例按测试时间窗口提取目标端关键事件。与其导出整份日志，更建议先缩小范围，再保存原始 EVTX 供复核。

$Start = (Get-Date).AddHours(-2)
$End   = Get-Date

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624,4625,4672,4688
    StartTime = $Start
    EndTime   = $End
} | Select-Object TimeCreated, Id, MachineName, Message |
    Export-Csv C:\Windows\Temp\security-window.csv -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-WinRM/Operational'
    StartTime = $Start
    EndTime   = $End
} | Select-Object TimeCreated, Id, Message |
    Export-Csv C:\Windows\Temp\winrm-window.csv -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-PowerShell/Operational'
    Id        = 4103,4104
    StartTime = $Start
    EndTime   = $End
} | Select-Object TimeCreated, Id, Message |
    Export-Csv C:\Windows\Temp\powershell-window.csv -NoTypeInformation -Encoding UTF8

分析 4624 时，不要机械地把 LogonType 3 全部判定为 WinRM，因为 SMB、计划任务管理及其他网络服务也可能产生该类型。应使用账号、源 IP、时间窗口、WinRM Operational 事件和 4688 中的 wsmprovhost.exe 进行交叉关联。若看到 wsmprovhost.exe 派生 powershell.exe、cmd.exe 或业务管理程序，再结合 4104 内容判断实际执行行为。

审计配置检查

如果 4688 没有命令行，或 4104 完全缺失，应先确认审计策略，而不是直接认定攻击者清除了日志。

auditpol /get /subcategory:"Process Creation"
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled

# 查看 PowerShell 日志策略是否下发
reg query "HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
reg query "HKLM\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging"

生产环境建议通过 GPO 统一启用高级审核策略、进程命令行记录和 PowerShell 脚本块日志，并将日志转发到集中平台。脚本块日志可能包含路径、参数和业务数据，应设置访问控制与合理保存周期。

风险判定

报告中应区分“服务暴露”“允许远程管理”和“获得管理员权限”三个结论。只有在证据表明低权限账号通过错误的组嵌套、端点 ACL 或策略配置获得超出职责范围的能力时，才应定性为权限边界缺陷。

• 低风险：5985 仅对管理网开放，账号无会话权限，日志完整。
• 中风险：普通账号可建立受限会话，但仅能执行明确授权的运维命令。
• 高风险：非运维账号可获得本地管理员令牌，且可在多台服务器复用该路径。
• 严重风险：高权限链路覆盖域控、证书服务或身份管理系统，同时缺少集中日志与告警。

修复建议

• 清理本地 Administrators 和 Remote Management Users 中不必要的域组，特别是多层嵌套组。
• 按服务器角色拆分运维组，避免一个通用组覆盖全部业务服务器。
• 通过防火墙将 5985、5986 限制到堡垒机、管理网段或指定运维终端。
• 域环境优先使用 Kerberos；关闭 Basic 和 AllowUnencrypted，谨慎启用 CredSSP。
• 不要使用 TrustedHosts 等于通配符作为长期方案。
• 对确需委派的场景使用 JEA 限制可执行命令、参数和运行身份，而不是直接授予本地管理员。
• 启用 4688 命令行、PowerShell 4103/4104、WinRM Operational 日志，并集中转发。
• 建立检测规则：非管理网地址建立 WinRM 会话、普通账号触发 4672、wsmprovhost.exe 派生异常进程、短时间访问多台服务器。

复测与总结

修复后应使用原测试账号重复 Test-WSMan 和最小化 Invoke-Command，并验证未授权连接被拒绝、授权运维账号仍可正常工作。同时复查 GPO 应用结果，避免手工删除组成员后又被策略自动加回。

这类问题的关键不是证明 WinRM“能不能连”，而是明确谁通过什么策略获得了哪些能力，并用源端、目标端和域控日志还原完整链路。只有权限来源、实际令牌、行为日志和修复复测四部分都闭环，结论才足够可靠。

先把“授权边界”和“实际获得的权限”分开确认。WinRM 能连通不等于已经取得目标机管理员权限，建议保留原会话，用同一测试账号在目标端记录以下结果：

$env:COMPUTERNAME
whoami /all
whoami /groups
whoami /priv
([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

Get-PSSessionConfiguration |
  Select-Object Name, Permission, RunAsUser, SessionType

Get-LocalGroupMember -Group Administrators -ErrorAction SilentlyContinue

重点看令牌是否包含本地 Administrators、是否启用了高权限特权，以及连接落到默认端点还是 JEA/自定义端点。域账号、本地账号及受限管理员模式的结果可能不同；不要只凭 whoami 或“命令执行成功”判定边界。可以选一个只读但需要管理员权限的动作验证，例如查询服务配置或受保护日志，不要用创建管理员、关闭防护之类的破坏性动作。

日志闭环建议按“发起端—网络—目标端”三段关联，并统一记录 UTC 时间、源/目标地址、测试账号、工单号和实际执行命令。目标端优先导出原始 EVTX，不要清日志：

$start = (Get-Date).AddHours(-2)
$logs = @(
  'Security',
  'Microsoft-Windows-WinRM/Operational',
  'Microsoft-Windows-PowerShell/Operational'
)

foreach ($log in $logs) {
    $safe = $log -replace '[/\\]','_'
    wevtutil epl $log "C:\Evidence\$safe.evtx" "/ow:true"
}

Get-FileHash C:\Evidence\*.evtx -Algorithm SHA256 |
  Format-Table Path,Hash -AutoSize

事件关联时可按以下顺序排查：

• Security 4624：通常关注 Logon Type 3，核对账号、源地址、Logon ID。
• 4648：是否使用显式凭据；4672：该 Logon ID 是否获得敏感特权。
• 4688：检查 wsmprovhost.exe 及其相关进程；前提是已启用进程创建审核和命令行记录。
• PowerShell/Operational 4103、4104：模块调用与脚本块内容；没有事件不代表没有执行，先确认审计策略当时是否开启。
• WinRM/Operational：结合事件时间、客户端地址、用户名及 Activity ID 还原会话建立和插件调用，不建议只依赖单个事件 ID。
• 如部署 Sysmon，再关联事件 1（进程）和 3（网络），检查到 5985/5986 的连接及 wsmprovhost.exe 行为。

$from = (Get-Date).AddHours(-2)
$to   = Get-Date

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624,4648,4672,4688
    StartTime = $from
    EndTime   = $to
} | Select-Object TimeCreated,Id,RecordId,MachineName,Message |
    Export-Csv C:\Evidence\Security-Timeline.csv -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-PowerShell/Operational'
    Id        = 4103,4104
    StartTime = $from
    EndTime   = $to
} | Select-Object TimeCreated,Id,RecordId,Message |
    Export-Csv C:\Evidence\PowerShell-Timeline.csv -NoTypeInformation -Encoding UTF8

发起端还应保存 PowerShell 历史、终端转录、测试平台任务记录和出站网络日志。如果使用了 Invoke-Command、Enter-PSSession 或自动化框架，应记录参数，但报告中对密码、票据和密钥做脱敏；不要为了“补日志”重新执行超出授权范围的命令。

最终闭环里至少写清：授权的源主机和目标资产、允许使用的账号、允许达到的最高权限、实际令牌权限、执行时间线、目标端对应 Record ID、证据文件 SHA-256，以及是否触发告警。如果实际获得的权限高于授权上限，应立即停止继续横向，把现有会话和证据保留下来，按越界发现上报，而不是继续验证可达范围。