Windows服务器被植入恶意服务或启动项后，最典型的特征不是CPU飙高，而是“看起来一切正常但网络有异常外联”。排查的核心思路是从“持久化入口”反推攻击者行为，而不是盲目扫描病毒。系统服务、计划任务、注册表Run键、WMI事件订阅、驱动加载项，这五类位置是攻击者最常利用的驻留点。下面直接按操作顺序讲排查方法。

第一步：枚举所有非微软签名服务

打开services.msc只能看到显示名称，无法判断服务对应的二进制文件路径和签名状态。更有效的方法是用PowerShell导出全部服务，并筛选出非Microsoft签名的项。执行以下命令：

Get-WmiObject win32_service | Select-Object Name,DisplayName,State,PathName,StartName | Format-List

重点看PathName字段。正常系统服务的路径通常是C:\Windows\System32\svchost.exe -k xxx，或者C:\Windows\System32\xxx.exe。如果出现C:\Users\xxx\AppData\Local\Temp\xxx.exe、C:\ProgramData\xxx\xxx.exe、或者路径中包含随机字符串，基本可以判定为恶意服务。还要注意StartName为LocalSystem且PathName指向用户目录的服务，这类组合非常可疑。

进一步验证签名，可以用Get-AuthenticodeSignature命令：

Get-AuthenticodeSignature "C:\可疑文件路径\xxx.exe" | Format-List

如果Status为NotSigned或者SignerCertificate中的签名者不是Microsoft Corporation，就需要立即隔离该文件并停止对应服务。

第二步：检查服务DLL劫持与svchost寄生

很多恶意程序不会直接注册一个独立的exe服务，而是通过svchost.exe加载恶意DLL。这类服务在services.msc中看起来和正常服务没有区别，但注册表中的ServiceDll键值被篡改。检查以下注册表路径：

HKLM\SYSTEM\CurrentControlSet\Services\

逐个查看每个服务子键下的Parameters项，如果存在ServiceDll值，确认该DLL路径是否位于System32目录且为微软签名。攻击者常把恶意DLL放在C:\Windows\Temp或C:\ProgramData下，然后修改ServiceDll指向它。例如BITS服务、Winmgmt服务都曾被用来做DLL劫持。

还有一种情况是svchost.exe本身被替换。正常svchost.exe位于C:\Windows\System32\svchost.exe，大小约50KB左右。如果发现C:\Windows\svchost.exe或者System32下svchost.exe的数字签名无效，说明系统文件被替换。用sfc /scannow可以修复，但修复前必须先清除恶意服务，否则重启后会再次感染。

第三步：排查注册表Run键和启动文件夹

用户态启动项比服务更容易被忽视，因为很多管理员只检查服务不检查Run键。需要检查以下四个位置：

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

用reg query命令导出后逐一核对。正常的启动项如安全软件、硬件驱动管理工具都有明确厂商名称。如果看到一个无签名、无版本信息、路径在Temp或AppData下的可执行文件，直接删除对应键值。同时检查启动文件夹：

C:\Users\用户名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

这里放的快捷方式或脚本文件也要逐个查看目标路径。攻击者经常把vbs、bat、ps1脚本放在启动文件夹，脚本内容可能是下载器或者反向Shell。

第四步：检查计划任务中的隐藏持久化

计划任务比Run键更隐蔽，因为触发条件可以设置为系统启动、用户登录、特定事件ID触发等。用以下命令导出全部计划任务：

schtasks /query /fo LIST /v > C:\tasks.txt

重点看Task To Run字段。如果指向的exe或脚本位于C:\Users\xxx\AppData\Local\Temp、C:\ProgramData\随机目录、或者指向cmd.exe /c powershell -enc开头的命令，基本可以确认是恶意计划任务。还要注意计划任务的Author字段，正常系统任务的作者是Microsoft Corporation或SYSTEM，如果作者是空白或者随机用户名，需要进一步核实。

攻击者还喜欢创建隐藏的计划任务，在任务名称前加上空格或使用特殊字符。在Task Scheduler GUI中可能看不到，但用schtasks命令可以列出。另外检查C:\Windows\System32\Tasks目录下的XML文件，直接查看原始任务定义，有些恶意任务会在XML中设置Hidden属性为true。

第五步：检查WMI事件订阅持久化

WMI事件订阅是高级攻击者常用的无文件持久化手段，不会在磁盘上留下明显的启动项文件。攻击者通过注册WMI事件过滤器、事件消费者和绑定关系，在特定条件下执行恶意代码。检查方法如下：

Get-WMIObject -Namespace root\Subscription -Class __EventFilter | Format-List *
Get-WMIObject -Namespace root\Subscription -Class __EventConsumer | Format-List *
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding | Format-List *

正常系统中这些查询结果通常为空，或者只有少数几个与系统管理相关的条目。如果发现ActiveScriptEventConsumer或CommandLineEventConsumer中引用了powershell、cmd、或者可疑脚本路径，需要立即删除对应的Filter、Consumer和Binding。删除命令示例：

Get-WMIObject -Namespace root\Subscription -Class __EventFilter | Where-Object {$_.Name -eq "恶意Filter名称"} | Remove-WmiObject

WMI持久化的排查难度在于它不依赖文件系统，很多杀毒软件无法检测。管理员需要养成定期检查WMI订阅的习惯，尤其是在服务器被入侵后的应急响应中。

第六步：检查驱动级恶意加载

驱动级后门比用户态服务更底层，能够在内核层面隐藏进程、文件和网络连接。检查已加载驱动：

driverquery /v /fo csv > C:\drivers.csv

或者用PowerShell：

Get-WmiObject Win32_SystemDriver | Select-Object Name,DisplayName,State,PathName | Format-List

重点关注PathName不在C:\Windows\System32\drivers\目录下的驱动，以及签名无效的驱动。恶意驱动通常加载后立即隐藏自身，在driverquery中可能看不到，这时需要检查注册表中的服务键值：

HKLM\SYSTEM\CurrentControlSet\Services\

Type字段为0x1或0x2的表示内核驱动。如果Start字段为0（引导启动）或1（系统启动），且ImagePath指向可疑路径，说明存在驱动级持久化。清除驱动级后门比清除用户态恶意程序复杂得多，需要进入安全模式或使用专门的ARK工具，因为恶意驱动可能挂钩了文件系统和注册表操作。

第七步：网络连接与进程关联分析

完成上述静态排查后，还需要从网络行为验证是否存在异常外联。使用以下命令查看所有TCP/UDP连接及其对应进程：

netstat -ano | findstr ESTABLISHED

拿到PID后，用tasklist /svc /fi "PID eq xxx"查看该进程对应的服务。如果发现一个名为svchost.exe的进程有外联，但对应的服务是BITS或Winmgmt等系统服务，且目标IP是境外地址，说明该服务已经被DLL劫持。进一步用以下命令查看进程加载的模块：

tasklist /m /fi "PID eq xxx"

如果svchost.exe加载了非System32目录下的DLL，或者加载了名称随机的DLL，就可以确认恶意模块的位置。此时不要直接结束进程，因为恶意服务可能设置了重启机制。正确做法是先停止并禁用对应服务，删除恶意DLL文件，再清理注册表中的服务配置。

第八步：日志分析与时间线还原

排查的最后一步是还原攻击时间线，确认恶意服务或启动项的创建时间。重点查看以下日志：

安全日志中的服务安装事件（Event ID 7045）
系统日志中的服务启动失败事件（Event ID 7000、7009）
应用程序日志中的WMI活动记录

用wevtutil命令导出日志：

wevtutil qe Security /q:"*[System[(EventID=7045)]]" /f:text > C:\service_install.txt

通过服务安装时间可以判断入侵发生的时间窗口，结合其他安全事件还原攻击路径。如果日志被清除，可以检查文件系统的MFT记录，或者查看C:\Windows\System32\winevt\Logs目录下日志文件的最后写入时间是否异常。

整个排查流程的核心逻辑是：先看服务二进制路径是否异常，再看DLL是否被替换，然后检查Run键和计划任务，最后排查WMI和驱动。每一层都要交叉验证文件签名、路径合理性和网络行为。单独依赖杀毒软件无法发现所有持久化手段，必须结合系统原生命令和注册表分析才能彻底清除恶意启动项。