授权内网测试中 WinRM 连接被拒，如何区分网络、认证与权限问题？

背景

在授权内网渗透测试中，经常会遇到这类现象：目标主机的 5985 端口可以访问，域账号也确认有效，但使用 PowerShell Remoting 连接时仍返回 Access is denied、WinRM cannot process the request 或 Kerberos 相关错误。此时不应反复尝试口令，而应按网络、协议、认证、授权和主机策略五层逐项定位。

以下操作仅适用于已获得书面授权的测试环境。建议先确定测试账号、目标资产和允许的验证时段，避免触发锁定策略或干扰业务。

问题定位

先记录完整错误，而不是只看“连接失败”。常见报错与排查方向如下：

第一步：确认网络与监听状态

端口开放只说明 TCP 可达，不代表 WinRM 服务配置正确。客户端先测试 5985 或 5986，服务端再检查监听器、服务状态和防火墙规则。

# 客户端：仅验证目标端口和 WS-Man 响应
Test-NetConnection server01.corp.example -Port 5985
Test-WSMan server01.corp.example

# 服务端：检查服务与监听器
Get-Service WinRM
winrm enumerate winrm/config/listener
Get-NetTCPConnection -LocalPort 5985,5986 -State Listen -ErrorAction SilentlyContinue

# 查看与 WinRM 相关的防火墙规则
Get-NetFirewallRule -DisplayGroup 'Windows Remote Management' |
  Select-Object DisplayName, Enabled, Profile, Direction, Action

如果服务处于运行状态但没有监听器，可检查是否被组策略统一管理。不要直接执行会覆盖现有配置的初始化命令，应先导出配置并与运维基线核对：

winrm get winrm/config
winrm get winrm/config/service
winrm get winrm/config/client
gpresult /h C:\Windows\Temp\gp.html

第二步：区分 Kerberos 与 NTLM 问题

域环境中应优先使用目标主机的完整域名。使用 IP 地址连接通常无法正常匹配 HTTP 服务主体名称，可能退回 NTLM；如果目标策略禁用了 NTLM，连接会直接失败。先检查 DNS、当前票据和目标 SPN。

Resolve-DnsName server01.corp.example
klist
setspn -Q HTTP/server01
setspn -Q HTTP/server01.corp.example

# 使用主机名验证，而不是直接使用 IP
Test-WSMan server01.corp.example -Authentication Kerberos

如果 setspn 查询显示同一个 HTTP SPN 注册在多个对象上，应由域管理员确认服务归属后修复重复项。不要在未核实业务依赖时直接删除 SPN。还要检查客户端与域控时间差，Kerberos 默认无法容忍明显时钟漂移：

w32tm /query /status
w32tm /stripchart /computer:dc01.corp.example /samples:5 /dataonly

第三步：确认账号是否有进入远程会话的权限

认证成功不等于获得 PowerShell 会话权限。默认 Microsoft.PowerShell 端点通常只允许管理员组成员访问，环境中也可能部署了 JEA 端点，对可执行命令进行限制。

# 在目标主机以管理员身份检查端点
Get-PSSessionConfiguration |
  Select-Object Name, Permission, RunAsUser, PSVersion

# 查看本地相关组成员
Get-LocalGroupMember -Group 'Administrators'
Get-LocalGroupMember -Group 'Remote Management Users'

# 查看端点详细配置
Get-PSSessionConfiguration -Name Microsoft.PowerShell | Format-List *

如果测试账号只需要执行有限的巡检命令，建议将其授权到专用 JEA 端点，而不是直接加入本地 Administrators。若使用普通端点，应核对端点安全描述符和组成员关系是否由组策略覆盖。

第四步：检查本地账号与远程 UAC 限制

使用本地管理员账号远程连接时，可能受到远程 UAC 令牌过滤影响，表现为账号口令正确但远程管理操作被拒绝。不要为了测试方便直接关闭过滤。更合理的做法是使用受控域账号、LAPS 管理的本地管理员账号，或给指定端点配置最小权限。

# 只读检查，不建议直接修改
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy

# 检查内置管理员及本地管理员组状态
Get-LocalUser | Select-Object Name, Enabled, LastLogon
Get-LocalGroupMember Administrators

LocalAccountTokenFilterPolicy 设置为 1 会降低远程 UAC 的保护效果。若业务确实依赖该设置，应把它作为例外项记录，并配合来源地址限制、主机防火墙和高权限账号监控。

第五步：从日志确认失败发生在哪一层

服务端日志比客户端报错更可靠。建议围绕测试时间、源地址和账号建立时间线，重点查看以下日志：

• Microsoft-Windows-WinRM/Operational：WinRM 请求、插件和会话错误。
• Windows PowerShell/Operational：远程 PowerShell 执行及引擎事件。
• Security 4624、4625：登录成功或失败，关注 Logon Type、Status、SubStatus。
• Security 4648：使用显式凭据。
• Security 4672：分配高权限特权。
• Security 4688：进程创建，前提是已启用相应审计策略。

# 最近 30 分钟的 WinRM 错误
$start = (Get-Date).AddMinutes(-30)
Get-WinEvent -FilterHashtable @{
  LogName   = 'Microsoft-Windows-WinRM/Operational'
  StartTime = $start
} | Where-Object LevelDisplayName -in 'Error','Warning' |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

# 查询登录失败事件，避免直接导出整个安全日志
Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4625
  StartTime = $start
} | Select-Object TimeCreated, Id, Message

事件 4625 中，0xC000006A 通常表示口令错误，0xC0000064 表示账号不存在，0xC0000234 表示账号锁定，0xC000015B 表示未授予请求的登录类型。若服务端没有对应日志，问题更可能发生在网络、名称解析、代理或客户端认证阶段。

可复用的排查顺序

• 确认授权目标和测试账号，记录开始时间与源 IP。
• 测试 DNS、路由和 5985/5986，不进行口令喷洒式尝试。
• 使用 FQDN 发起 Test-WSMan，确认 Kerberos 是否可用。
• 检查 HTTP SPN、系统时间及是否发生 NTLM 回退。
• 检查 WinRM 监听器、服务、防火墙和组策略结果。
• 核对 Remote Management Users、Administrators 及会话端点 ACL。
• 结合 WinRM Operational 与 Security 4624/4625 判断失败层级。
• 验证结束后清理临时授权，并复核日志是否完整。

风险与修复建议

• 优先启用 WinRM over HTTPS 或在受控管理网络中限制 5985 的来源地址，不要向普通办公网全网开放。
• 域环境优先使用 Kerberos，谨慎配置 TrustedHosts；尤其不要设置为通配符。
• 为运维和测试建立独立账号，设置登录范围、有效期和最小权限。
• 使用 JEA 暴露必要命令，避免为了远程管理统一授予本地管理员权限。
• 启用 WinRM、PowerShell Script Block、进程创建和账号登录审计，并将日志集中到 SIEM。
• 对短时间内多个目标出现 4625、异常 4648、远程启动 powershell.exe 等行为设置关联告警。
• 测试后删除临时组成员关系、端点授权和防火墙例外，保留变更单与验证记录。

总结

WinRM 的“拒绝访问”并不等同于口令错误。有效排查应把 TCP 可达、WS-Man 响应、Kerberos/SPN、端点 ACL、远程 UAC 和安全日志拆开验证。按层定位既能减少无效认证尝试，也便于在报告中明确指出问题属于配置缺陷、权限边界不清还是日志审计不足。

建议按“网络可达性 → WinRM 服务端状态 → 认证 → 会话权限”分层排查，不要只看客户端统一返回的 Access is denied。

1. 先确认端口和监听器

Test-NetConnection 10.0.0.20 -Port 5985
Test-NetConnection 10.0.0.20 -Port 5986

# 目标机本地执行
Get-Service WinRM
winrm enumerate winrm/config/listener
Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -in 5985,5986
Get-NetFirewallRule -DisplayGroup "Windows Remote Management" |
  Select-Object DisplayName,Enabled,Profile,Direction,Action

TcpTestSucceeded=False 通常先查路由、ACL、防火墙及网络配置文件；如果 TCP 可达但客户端报 WSMan 连接错误，再查监听器、证书或 URL ACL。目标机可用 Test-WSMan localhost 验证服务自身是否正常。

2. 区分认证失败和权限不足

# 域环境优先使用主机名/FQDN，让 Kerberos 正常匹配 SPN
Test-WSMan server01.corp.example
Enter-PSSession -ComputerName server01.corp.example `
  -Authentication Kerberos `
  -Credential CORP\tester

# 查看 Kerberos 票据和目标 SPN
klist
setspn -Q WSMAN/server01
setspn -Q WSMAN/server01.corp.example

使用 IP、跨域或工作组环境时，Kerberos 往往不可用，会回退到 NTLM 或直接失败。此时应先确认双方信任和名称解析，不建议为了“先连上”就把 TrustedHosts 设为 *。确有测试需要时只加入明确目标，并在测试后恢复：

$old = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.0.0.20"

# 测试完成后恢复
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $old

认证是否失败，直接看目标机事件日志更可靠：安全日志中的 4625 会给出状态码和登录类型；同时检查：

Get-WinEvent -LogName "Microsoft-Windows-WinRM/Operational" -MaxEvents 50 |
  Select-Object TimeCreated,Id,LevelDisplayName,Message

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624,4625
  StartTime=(Get-Date).AddMinutes(-15)
} | Select-Object TimeCreated,Id,Message

3. 认证成功后仍拒绝，检查会话端点权限

# 目标机本地执行
Get-PSSessionConfiguration |
  Select-Object Name,Enabled,Permission

Get-LocalGroupMember "Remote Management Users"
Get-LocalGroupMember "Administrators"

# 查看默认端点的安全描述
(Get-PSSessionConfiguration -Name Microsoft.PowerShell).Permission

账号至少需要被允许访问对应 PowerShell 会话端点；通常加入本机 Remote Management Users，或按授权范围修改端点 ACL。不要直接把测试账号加到 Administrators，除非测试方案确实要求管理员令牌。

还要注意两个容易混淆的点：

• 本地管理员账号远程连接可能受 UAC 远程令牌过滤影响。不要先改 LocalAccountTokenFilterPolicy，应优先使用域账号或明确授权的端点；如果必须修改，需记录并在测试后回滚。
• WinRM 已连接但访问远端文件共享或其他服务器失败，通常是 Kerberos 双跳问题，不是 WinRM 权限问题。可按场景使用受限委派、资源受限委派或显式建立第二段凭据，避免随意开启 CredSSP。

最后可根据报错快速归类：超时或无法连接多为网络/监听器；401、0x8009030e 多为认证协商；Access is denied 且目标机已有成功登录记录，多为端点 ACL、组成员关系或令牌过滤。排查时同时记录客户端完整错误和目标机同一时间点的 WinRM、安全日志，基本可以避免把三类问题混在一起。