如果你在安全运营平台里看到一台主机短时间内朝内网几十台服务器发起 5985 端口连接第一反应大概率会把它当成 Windows 远程管理的正常运维流量。这正是 WinRM 横向移动在真实攻防中最让人头疼的地方它用的是微软官方的管理协议走的是正规服务端口只要手里有一组合法的管理凭据就能像运维一样在目标机器上执行命令而不像传统的 PsExec 那样需要创建服务、写文件、产生大量进程行为。这篇文章想聊的是 WinRM 横向移动这条技术路径的完整面貌它为什么容易被攻击者盯上、用的时候有哪些必须注意的前提条件、实操过程中最常见的几个认知误区以及蓝队要如何才能从日志和流量里把它识别出来。适合刚接触内网安全评估的渗透测试人员也适合正在做 EDR 规则、安全基线的防御工程师参考。1. WinRM 被“挑中”的原因它天生就是低调的合法通道1.1 官方管理协议的身份带来天然的低告警率横向移动的本质不是在目标机器上安装什么神秘后门而是用合法的方式拿到目标的执行权限。WinRM 全称 Windows Remote Management是微软基于 WS-Management 协议实现的远程管理组件从 Windows Vista 和 Server 2008 时代就内置在系统里。它的定位和 RDP、SSH 一样是给管理员远程管理服务器用的。这个“官方”身份直接影响告警处置的判断。很多企业的流量监控规则对 3389、445 这类端口非常敏感但 5985HTTP 明文和 5986HTTPS 加密很多时候并不在重点监控清单上因为运维团队自己也要用这些端口做日常服务器管理。攻击者利用 WinRM 横向移动时不需要上传任何可执行文件不需要创建服务不需要在目标磁盘上留下攻击工具的副本只要通过 PowerShell 或命令行工具建立一个远程会话就可以在目标机器上执行命令、查信息、做下一步动作。相比 SMB 场景下可能触发的文件写入和服务创建行为告警WinRM 这条路干净得不像攻击行为。这也是为什么在红队评估的成熟阶段越来越多的测试者倾向于把 WinRM 作为横向移动的首选通道而不是事后第一反应选 PsExec。因为它把“攻击流量”伪装成了“运维流量”完全吻合合法协议加合法凭据的组合逻辑。1.2 协议交互逻辑里那几个值得记住的关键点WinRM 的工作模式简单说就是客户端通过 SOAP 消息向目标 WinRM 服务发起请求服务端执行对应命令后把结果回传。默认情况下HTTP 监听 5985 端口HTTPS 监听 5986 端口。在域环境里通常直接使用 5985因为身份验证可以由 Kerberos 完成消息内容大多数评估场景下不做加密也能跑通所以很多实际利用案例都是走 5985 明文端口。底层身份验证支持 Kerberos 和 NTLM 两种主流方式。域内主机之间如果网络信任正常默认走 Kerberos如果跨域、工作组环境或者指定了 IP 而不是主机名则可能退化为 NTLM。理解这个验证差异对后续排查很有用因为某些检测规则会专门关注非 Kerberos 的 WinRM 登录行为。还有一点容易被忽略目标机器的 Windows Remote Management (WS-Management) 服务必须处于运行状态并且 HTTP 监听器已经配置好。很多人以为 Windows 默认开启 WinRM其实不然普通工作站默认该服务是手动启动状态域内的服务器是否开启也取决于运维基线。攻击者在横向移动之前通常会先探测目标是否响应 WinRM 请求最简单的方式就是用 Test-WSMan 命令看对方返回的协议版本号Test-WSMan -ComputerName 192.168.10.20如果目标返回了 ProductVersion、ProtocolVersion 等信息说明 WinRM 服务在线如果报错 0x8033810C 一类错误大概率说明目标没有开启服务。这个探测动作虽然不起眼却是整个横向移动路径里必不可少的“踩点”步骤。2. 横向移动前必须摸清的三件事服务、凭据与可达性2.1 不是有凭据就能连还要看目标配置在实际授权评估中拿到一枚有效凭据只是起步能否用 WinRM 横向移动过去取决于三个条件同时满足目标机器网络可达、WinRM 服务在线且监听器存在、当前凭据具备远程管理权限。网络可达和端口连通很好判断但有一点经常翻车目标可能启用了 WinRM但监听在自定义端口上而不是默认的 5985。我在某次内部评估中遇到过目标机器为了避开扫描器的默认探测把监听器端口改成了 47001 这类非标准端口常规端口扫描完全看不到后面通过配置文件信息才定位到。对于这类情况可以在客户端设置里指定端口后再做验证winrm set client {AllowUnencrypted true}提示AllowUnencrypted 只建议在明确授权的评估环境中临时启用不要在生产环境随意修改。另外一个容易被忽略的判断项是权限模型的差异。域管理员或目标机器的本地管理员账号通常能直接建立 WinRM 会话但如果是普通域用户即使加入了本地 Administrators 组也可能受 UAC 远程过滤影响无法连接这部分后面会详细展开。所以在横向移动之前先确认当前拿到的凭据能不能通过远程登录是必要步骤。2.2 WinRM 横向移动的三种主流姿势围绕 WinRM 的横向移动最常用的无非三种方式winrs、Enter-PSSession、Invoke-Command。它们各自适合不同的场景但对目标系统产生的作用基本相同。第一种 winrs 是 Windows 自带的远程 Shell 命令行工具类似一个瘦身后的远程 cmd。它的特点是用起来简单适合快速执行单条命令。命令格式如下winrs -r:http://192.168.10.20:5985 -u:corp\\administrator -p:password ipconfig需要注意的是winrs 默认可能走 HTTPS 或者要求输入明文密码实际操作时经常要额外加参数指定端口和验证方式踩坑概率不低。如果只是临时确认目标是否可控可以用它但如果要完成复杂的 PowerShell 操作体验称不上友好。第二种 Enter-PSSession 是建立交互式 PowerShell 远程会话。连接成功后本地提示符会变成目标主机名开头的提示符所有命令都直接在目标上下文里执行。这种方式的体验最接近拿到一台机器的 Shell适合需要持续操作多个命令的场景比如在目标上翻查本机信息、查看服务列表、判断当前用户权限。示例$cred Get-Credential Enter-PSSession -ComputerName 192.168.10.20 -Credential $cred第三种 Invoke-Command 是我个人最常用的横向移动姿势。它不需要进入交互式会话直接向一台或多台目标机器发起命令执行返回结果以对象形式呈现。这种方式的一大优势是可以在一条命令里完成批量操作并且能直接把执行结果回传到本地控制台减少在目标机器上长时间驻留的痕迹。示例$cred Get-Credential Invoke-Command -ComputerName 192.168.10.20,192.168.10.21 -Credential $cred -ScriptBlock { whoami hostname Get-ChildItem C:\Users\ }在实际横向移动里Invoke-Command 的 ScriptBlock 可以执行更复杂的内存操作并且配合多台目标机器列表可以实现“复制式”控制。整个过程目标侧只会产生 PowerShell 进程和 WinRM 网络连接不会看到传统攻击武器落地这也是它很难被普通防病毒软件拦截的原因。3. 实操容易翻车的三个坑TrustedHosts、双跳与 UAC 过滤3.1 TrustedHosts 到底影响了什么很多第一次用 WinRM 做横向移动的人都会卡在同一个报错上连接到目标时提示“拒绝访问”或者“未找到 WinRM 服务”。排除了网络连通和服务未启动的问题后最常见的原因是工作组环境或非 Kerberos 认证场景下客户端没有把目标主机加入 TrustedHosts 列表。打个比方Kerberos 认证就像公司统一发的刷脸权限系统层面认这个身份而 NTLM 认证类似于门卫需要你提前把来访者名单报上去不在名单里的人一律不让进。TrustedHosts 就是这份名单决定了一台机器在 NTLM 模式下可以接受哪些来源主机的 WinRM 请求。如果你是在域环境内用主机名访问Kerberos 通常不需要配置 TrustedHosts但如果你直接用 IP 地址访问或者目标和工作组环境大概率会踩到这个问题。配置方式Set-Item WSMan:\localhost\Client\TrustedHosts -Value 192.168.10.20 -Concatenate注意不要因为图方便把 TrustedHosts 直接设置成“*”这等于无条件信任所有来源主机的 NTLM 远程管理请求等于把管理入口的大门对全网敞开。即使是在评估环境里也应该尽量缩小名单范围。3.2 双跳Double-Hop问题卡住了多少初级操作者横向移动真正遇到过比较头疼的问题其实是双跳。假设你通过 WinRM 从攻击机连上了机器 A在 A 上拿到了本地管理员权限接下来你想从 A 继续通过 WinRM 连接到机器 B。这时你大概率会发现在 A 的会话里再次调用 Invoke-Command 到 B会提示身份验证失败或者直接拒绝访问。原因在于 WinRM 的会话默认不会把当前凭据“转交”给后续连接第二次连接在认证机制上非常尴尬。这就像你拿自己工牌进了 A 公司的门A 公司前台的临时访客卡不允许你再去刷 B 公司的门禁。Kerberos 环境下这种情况尤其明显因为默认未开启委派功能。解决这个问题有几种思路。启用 CredSSP 是一种经典方式通过在客户端和目标两边同时启用 CredSSP 来支持凭据委派也可以开启 Kerberos 委派但需要域环境支持还有更轻量的做法是在第一次连接时明确将凭据对象传进去或者用计划任务在目标机器上创建携带凭据的执行任务。但每一种方案都有代价CredSSP 会在目标上留下较深的配置痕迹Kerberos 委派则涉及域控配置不是所有评估环境都允许这么操作。从实际经验来看如果只想快速继续横向最简单的替代方案是绕开“从会话里再建立新会话”的方式把需要执行的命令和数据直接带到目标 A在 A 本地落地后再通过 A 的上下文发起新的连接。虽然听起来不够优雅但在多数真实评估场景里更稳定。3.3 UAC 远程过滤和你常用的账号类型有直接关系还有一个隐藏很深的坑是 UAC 的远程过滤机制。Windows 从 Vista 开始引入了 UAC 远程限制默认情况下非内置 Administrator 的本地管理员账号在远程登录时会收到降权处理导致明明账号在 Administrators 组里却无法通过 WinRM 获得高权限会话。换句话说你拿到一台机器的本地管理员账号比如叫“admin”的用户这个账号在本地组策略里属于管理员但你用这个账号通过 WinRM 连接结果报 Access Denied。这就是因为 UAC 把远程登录的令牌过滤成了标准用户权限。而内置 Administrator 账号或者域管理员账号默认不受这个限制。如果确实需要在评估中解决这个问题常见做法是在目标机器上修改注册表项 LocalAccountTokenFilterPolicy把值改为 1 来放行本地管理员账号的远程高权限令牌。但这个修改在目标机器上留下非常明显的痕迹而且本身也是需要管理员权限才能操作的。所以更实际的判断是横向移动之前优先确认手里账号的类型内置 Administrator 和域管账号的成功率远高于普通创建出来的本地管理员账号。4. 蓝队视角下怎么看见它日志与行为的双重研判4.1 单看端口不能说明问题关键要看组合特征既然 WinRM 是合法协议那蓝队要做的不是看见 5985 就告警而是从多个维度组合研判同一个源主机是否在进行横向移动。最基础的维度是连接模式正常运维通常是一个管理终端连到少量服务器而横向移动往往是一个失陷节点在短时间内朝多个目标发起连接。在日志里看到一个内网 IP 在几十秒内依次连接多台机器的 5985 端口即使没有其他恶意识别也足够引起关注。第二个维度是身份验证类型。域内正常 WinRM 运维绝大多数走 Kerberos如果日志显示大量来自同一源 IP 的 WinRM 连接使用了 NTLM 认证就需要多问一句为什么。NTLM 在横向移动里的高频出现往往是因为攻击者倾向使用 IP 地址而不是主机名连接或者手持的凭据无法通过 Kerberos 完成验证。第三个维度是连接后执行的命令。Windows 安全日志中的登录事件会记录网络登录行为通常对应登录类型 3配合 PowerShell 脚本块日志Event ID 4104和 Microsoft-Windows-WinRM/Operational 日志可以还原出远程会话里到底执行了什么命令。需要提醒的是不同 Windows 版本下 WinRM 操作日志的事件 ID 并不完全一致不要只盯着某一个固定 ID 做检测规则把日志源整体纳入监控范围更稳妥。下面这个表格可以作为日常告警运营的参考特征对比特征维度正常运维场景WinRM 横向移动常见表现连接源数量少量固定管理终端大量来自同一个失陷源目标数量单个或少数目标短时间内多个目标认证类型域内以 Kerberos 为主NTLM 频率明显偏高连接后行为执行常规运维命令大量 PowerShell 脚本块、枚举信息命令时间特征工作时间段为主可能集中在深夜或非工作时间4.2 从行为回溯和日志采样角度补全检测能力如果你的环境已经接入了 EDR 或 Sysmon可以更进一步做进程维度的关联分析。Sysmon 的事件 ID 3 记录网络连接事件 ID 1 记录进程创建通过同一时间窗口内 powershell.exe 的创建记录和 5985 端口的外连记录做关联能比较准确地还原一次 WinRM 横向移动的链路从源主机发起的 powershell 进程去连目标主机的 WinRM 服务目标主机随之响应并开启新的 powershell 进程执行脚本内容。需要特别关注的是 PowerShell 使用了大量内存操作和反射加载的场景。虽然 WinRM 横向移动本身不落地文件但如果 ScriptBlock 里包含下载或加载工具类的行为PowerShell 日志里会留下明确的线索。实际运营中我见过不少团队把所有异常都集中在“是否出现陌生进程”上却忽略了 PowerShell 日志本身就是最丰富的情报源。建议把 ScriptBlock 日志、模块日志、深度脚本日志全部打开并做集中采集这样无论攻击者用 Invoke-Command 还是 Enter-PSSession 从远处执行命令都会在目标机器的 PowerShell 日志里留下可追踪的记录。5. 落地加固的正确姿势让管理通道不再成为突破口5.1 不是所有环境都能直接关停 WinRM关键是收敛访问源讨论防御策略时最容易被提出来的方案是“把 WinRM 服务全部禁用”。这句建议本身没有错但现实里很多企业内部自动化运维工具、监控代理、资产采集程序都依赖 WinRM 工作直接禁止会让服务大面积瘫痪。更现实的做法不是关掉通道而是把通道限定在一个可控的范围内。组策略里可以配置 WinRM 服务的允许访问来源也可以限制信任主机列表更精细的做法是构造一个独立的运维子网只允许特定跳板机或运维终端连接 Windows 服务器的 5985/5986 端口其他网段一律禁止访问。我在不少评估项目里复现过一种场景所有服务器都开放了 WinRM来源没有任何限制攻击者一旦拿到一台边界机器凭据复用到内网其他机器的成功率极高。后来运维团队只在核心管理网段放行 WinRM横向移动的噪声立刻下降了一个量级。对于已有的日志建议周期性核查 WinRM 服务日志中是否出现来自非运维网段的连接记录。出现一次错误凭据或少量访问失败可以理解但如果某个源 IP 持续高频访问多台服务器就要当成潜在横向移动事件来调查而不是顺手关闭告警。5.2 最小权限与账号分离是降低杀伤半径的核心比起研究各种检测规则账号体系的治理才是 WinRM 横向移动最有效的防线。横向移动能不能成功取决于攻击者手里的凭据能访问多少机器。如果运维环境里大量服务器共用同一个本地管理员密码或域账号权限普遍过大那么哪怕检测手段做得再完善攻击者仍然可以在不被注意的时间内快速穿行。比较务实的做法是给不同管理场景分配不同权限的账号域管理员账号只用来做域控和关键基础设施管理日常业务服务器的运维用普通管理账号并且所有管理账号开启登录源限制。另一个容易被忽略的点是本地内置 Administrator 账号的重命名和禁用。如果一个机器内置管理员账号一直在低水平密码下运行WinRM 横向移动里这种账号的成功率非常高因为 UAC 远程过滤对它就相当于失效状态所以这不是可以忽略的小配置。5.3 从实操角度给出几条可以立即落地的检查项如果你正在负责某个内网环境的安全基线可以先从下面几条入手梳理一遍用 Test-WSMan 或端口扫描工具做一次网络层盘点确认全网到底有哪些主机开放了 5985/5986形成一份“WinRM 暴露资产清单”。对每一台开放 WinRM 的主机检查其 TrustedHosts 配置里是否包含 “*” 或过大网段发现后尽快收敛。在日志平台中建立一条检测规则同一个源 IP 在 10 分钟内连接超过 3 台不同主机的 5985 端口时触发告警这个阈值可以按实际情况调整。核对所有服务器是否启用了 PowerShell 脚本块日志如果没有至少对开放 WinRM 的服务器优先开启。检查域环境中是否有非运维人员账号具备多台服务器的本地管理员权限尤其是那种一次性创建后长期不使用的账号。这些检查项不需要多高深的技术能力但它能把 WinRM 横向移动从“看不见的管理流量”变成“可见的可疑行为”。即使后续发现误报也总好过让攻击者在树冠之间悄无声息地跳跃。最后再分享一个小技巧做检测规则的时候不要一上来就搞复杂的机器学习模型先看日志里有没有“同一个源 IP 在短时间内以 NTLM 方式向多台主机发起 WinRM 登录”这种简单模式通常这类元数据判断已经能抓到相当一部分真实横向移动行为。我在实际评估里反复验证过这个规律而它的投入成本不过是一条查询语句而已。