横向渗透防护：WMI不是渗透你想的那样无害

攻击者拿下第一台内网机器后，下一步动作几乎总是防护扫描网段里的其他主机。他们用ping、渗透用ARP、防护用SMB空会话，渗透但真正高效的防护手法往往藏在Windows自带的WMI里。你不需要安装任何额外工具，渗透一条命令就能远程执行进程——wmic /node:192.168.1.10 process call create "cmd.exe /c whoami > c:\result.txt"。防护就这么简单，渗透防火墙可能放行，防护杀软不报警，渗透因为它用的防护是系统自己的管理通道。

我见过太多安全团队把精力全放在SMB的渗透445端口上，盯着永恒之蓝补丁，防护却忽略了WMI这类"合法"横向移动手段。渗透去年某次应急响应，攻击者就是用WMI在域内四十多台机器上来回跳，日志里全是正常的WMI事件，运维根本没察觉。直到域控被拿下，才追查到最初的入口——一台没打补丁的财务电脑。

WMI横向移动的可怕之处在于它不产生传统意义上的"攻击流量"。它走的是RPC动态端口（默认135），加密协商后数据看起来就像普通管理操作。而且WMI支持异步执行，攻击者可以远程启动一个进程然后立刻断开，痕迹藏在大量正常的管理任务里。很多小型企业的安全设备根本解析不了WMI内容，只能看到"远程过程调用"这种模糊记录。

防护思路得反过来想：不是阻止WMI使用，而是让它的使用变得可审计、可控制。第一道闸门是账号安全——WMI远程执行要求目标机上有管理员权限的本地账号或域账号。攻击者拿到的是普通用户权限，WMI基本废掉。所以重点盯防那些被提权的账号，尤其是本地管理员组的成员变动。用事件ID 4720、4732去监控新账号加入管理员组，别等攻击者用你的合法账号来敲门。

第二道闸门是网络层过滤。在核心交换机上做ACL，限制哪些IP段可以访问其他段的135端口和动态RPC端口。内网通常不需要每台机器都能互相管理。把运维网段单独隔离，业务网段之间禁止WMI连接。这招土但有效——攻击者就算拿到一台机器，横向扫描时发现目标端口不通，就得换更慢更吵的工具，暴露风险大增。

第三道闸门是日志与行为基线。WMI活动在Windows事件日志里有迹可循——Microsoft-Windows-WMI-Activity/Operational日志记录所有WMI查询和操作，事件ID 5857、5858能告诉你谁在什么时候调用了什么类。但日志量巨大，纯人工看是扯淡。得设置基线：比如某台文件服务器平时没人用WMI连它，突然半夜出现来自非运维IP的WMI连接，直接告警。用Sysmon配合EventLog Analyzer这类工具能省不少力。

还有个小细节常被忽略：WMI的持久化能力。攻击者可以用__EventFilter和__EventConsumer组合，注册一个当特定事件发生（比如系统启动）时自动执行的脚本。这玩意儿藏得深，普通杀软扫不到，重启后依然有效。检查方法：用PowerShell执行Get-WmiObject -Namespace root\subscription -Class __EventConsumer，看看有没有可疑的消费器。别等出事再查，定期跑一遍这个命令，花不了两分钟。

说到底，WMI防护不是买套高端设备就能解决的。它考验的是你对内网资产和正常行为的熟悉程度——你得知道哪些机器之间本来就有管理关系，哪些连接是异常的。攻击者用WMI是因为它隐蔽、高效、符合系统设计。防守方要做的，就是让这种"合法"滥用变得寸步难行。哪怕只是把本地管理员密码改成25位随机串，都能让一大半WMI横向攻击直接哑火——因为攻击者拿到的账号密码在目标机上根本不存在。