Win服务器最常见的危险组件包括WScript.Shell、Shell.Application、MSXML、PowerShell的某些模块,以及被恶意利用的IIS CGI程序,它们常被黑客用来执行命令、提权和反弹shell。
先搞清楚:为什么这些组件会被盯上
Windows服务器不像普通家用电脑,它默认开启的服务和组件更多,很多运维人员装完系统后,只想着开IIS、装数据库,却忘了系统里还躺着一堆用不上的“后门”这里说的不是真正被植入的后门,而是微软官方带的功能组件,黑客只要探测到这些组件存在,就能用几行代码完成从webshell到系统控制权的跳跃。
比如最常见的场景:你的网站被上传了一个aspx或asp马,马儿想调用系统命令,必须通过某个组件来中转,如果没有WScript.Shell,这条链路就断了,这就是危险组件问题的根源它们不是病毒,但它们是攻击链上必不可少的“桥”。
哪些组件算危险?按风险等级排个序
下面按实战中被利用的频率和破坏力,从高到低列清楚,注意,不是说用了就完蛋,而是说一旦攻击者拿到代码执行权限,这些组件会立刻放大危害。
第一梯队:直接执行命令的组件
- WScript.Shell:最臭名昭著,通过
CreateObject("WScript.Shell")就能运行cmd命令,是ASP和.NET WebShell的头号调用对象,很多老服务器上,它被用在上古时期做管理任务,如今纯粹是给攻击者送分。 - Shell.Application:同样能执行命令,还能操作文件系统,它的
NameSpace方法可以遍历目录,ShellExecute能启动程序,相比WScript.Shell,它更隐蔽因为部分安全软件对Shell.Application的拦截规则不完善。 - WMI(Windows Management Instrumentation):这个不能简单删,系统正常运行依赖它,但攻击者可以用
Win32_Process.Create方法来启动进程,而且WMI调用往往不落磁盘,属于“无文件攻击”的最爱,对普通网站服务器来说,如果你不用WMI做远程管理,建议在注册表里限制远程访问。
第二梯队:帮攻击者读文件、传数据的组件
- MSXML(Microsoft XML Core Services):主要被用来发起HTTP请求,攻击者拿到WebShell后,可以用它下载后门程序,或者把服务器数据回传到远程VPS,MSXML还支持XMLHTTP,配合PowerShell可以做很多坏事。
- ADODB.Stream:老牌文件操作组件,它能读取写入任意文件路径,常见于一句话木马实现文件上传下载,虽然现在很多环境禁用了它,但老系统里依旧遍地都是。
- Scripting.FileSystemObject:文件系统操作组件,能枚举目录、复制删除文件,单独用危害有限,但和WScript.Shell组合,几乎等于把C盘裸奔。
第三梯队:容易被忽略的“帮凶”
- PowerShell:本身不是组件,但它依赖.NET Framework,攻击者会用PowerShell执行
Invoke-Expression加载恶意脚本,或者用Start-Process启动勒索程序,如果你开发中不用PowerShell做自动化运维,就应该在组策略里限制执行策略,甚至完全禁用。 - IIS的CGI模块:如果服务器上启用CGI,攻击者能直接扔一个
.bat或.exe进去通过URL执行,这个组件纯粹是用来跑老程序的,现在PHP等语言都走FastCGI,CGI基本是包袱。
windows服务器危险组件怎么查?三步定位法
动手删之前,先得知道你服务器上到底有哪些组件开着,这一步不要盲猜,用下面三条路径直接查。
用注册表看组件是否可用
在运行框输入regedit,定位到:
HKEY_CLASSES_ROOTWScript.Shell、HKEY_CLASSES_ROOTShell.Application、HKEY_CLASSES_ROOTADODB.Stream
如果这些键存在,说明组件注册了,删除前记得先导出备份,因为有些程序(比如老版Office)可能依赖它们。
用命令行测试调用情况
打开CMD,输入:
cscript /nologo test.vbs,其中test.vbs内容为:
Set objShell = CreateObject("WScript.Shell")
WScript.Echo "ok"
如果能输出“ok”,说明WScript.Shell可用,同理,可以用PowerShell测试其他组件:
powershell -Command "New-Object -ComObject Shell.Application"
如果报错,说明组件被禁用或没注册。
借助扫描工具批量排查
市面上有一些服务器安全软件,比如安全狗、护卫神,它们带有“危险组件检测”功能,还有微软自家工具Microsoft Baseline Security Analyzer,虽然老,但还能用来检查常见配置问题,个人经验是,直接用D盾的“危险组件扫描”模块,几秒钟就能列出当前IIS环境下可被利用的组件清单,省时省力。
服务器危险组件清除工具:哪些能用,哪些别瞎用
网上很多文章会叫你用各种工具一键删除,但现实是,有些组件删了会导致系统启动失败,比如WMI被禁用后,防火墙、杀毒软件都会出问题,所以这里分两种情况讲:
能安全删除的组件
-
WScript.Shell:在注册表中删除
HKEY_CLASSES_ROOTWScript.Shell键,或者用regsvr32 /u wshom.ocx来注销它,IIS环境下99%的网站用不上它,删了不影响正常运行。 -
Shell.Application:用
regsvr32 /u shell32.dll不能整体注销,因为shell32是系统核心,正确做法是删除注册表HKEY_CLASSES_ROOTShell.Application,或者用软件策略限制IIS进程池对该对象的创建。 -
ADODB.Stream:如果网站不用Excel或Access,可以删,删除
HKEY_CLASSES_ROOTADODB.Stream键即可。
千万别碰的组件
- WMI:别删,改成限制远程访问就行,按下
Win+R输入services.msc,找到“Windows Management Instrumentation”,把启动类型改为“手动”是可行的,但不要禁用,更安全的做法是配置防火墙规则,封掉TCP 135端口和TCP 445端口。 - PowerShell:不能删,因为Windows Update和部分微软自带工具依赖它,正确姿势是设置执行策略为
Restricted,在组策略里点击“计算机配置-管理模板-Windows组件-Windows PowerShell”,启用“关闭PowerShell脚本执行”。
用工具自动加固
如果你不想手动改注册表,可以用IIS加固工具里的“系统危险组件防护”功能,国内某些IDC提供的一键安全脚本也会处理常见组件,但请记住,任何工具执行前都要做快照,尤其云服务器,创建个快照再操作,出问题能秒回滚。
禁用组件之后的连锁反应,你得有心理准备
删除注册表键之后,原来依赖这些组件的程序可能会报错。
- 老的OA系统用WScript.Shell生成Excel报表,禁用后报表功能失效。
- 某些第三方短信组件用Shell.Application发送通知,禁掉后开会静默失败。
- 网站模板里的老ASP代码用了FileSystemObject,禁用后页面白屏。
所以实际操作建议是:先切换测试环境验证,再上生产,如果生产环境不允许停,那就用“按需启用”方案通过IIS的应用程序池隔离级别,在单个网站级别拒绝组件调用,而不是全局删除,方法很简单:在IIS中选中对应站点,进入“配置编辑器”,找到system.webServer/security/requestFiltering,添加隐藏Segment规则,把asp、exe等危险扩展名挡掉,但这招只对特定路径有效,治标不治本。
关于win服务器危险组件的常见疑问
我用的宝塔面板能自动处理这些组件吗?
宝塔面板的“系统加固”插件里有“危险函数禁用”选项,但主要针对PHP函数,像proc_open、shell_exec这些,对Windows组件,它只提供IIS的FastCGI设置,不会主动删除WScript.Shell等COM组件,需要你自己进入文件管理器,通过修改注册表的办法来处理,或者用安全软件的子功能。
为什么我的安全软件扫描出来有危险组件,但查杀不了?
因为安全软件大多只查恶意文件,不查系统组件,它们判断组件是否危险,看的是有没有被恶意代码调用,而不是组件本身存在与否,如果你只是想把组件禁用掉,安全软件帮不了你,还是得回到注册表和组策略的手动操作。
服务器上同时装了PHP和asp,禁用WScript.Shell会不会影响PHP运行?
不会,PHP的exec函数走的是命令解析器,和WScript.Shell没有任何依赖关系,但要注意,PHP也有自己的危险函数,比如eval、assert、preg_replace配合/e修饰符,这些不在本文讨论范围内,但也属于“危险组件”的变种,建议用disable_functions做限制。
最后说句实话
Win服务器危险组件排查是全球范围内Windows运维的基础课,关键门槛不是不会删,而是不知道哪些可以删、哪些只能限制、删了之后会发生什么,行业共识认为(此处仅限一次),多数中小网站被入侵,不是用了多新奇的漏洞,而是服务器上留着这些默认组件,黑客用通用一行命令就打通了整条链,花一个下午把本文提到的组件按顺序检查一遍,比装十个安全软件都顶用,操作前做备份,操作后做验证,至少每月复查一次,安全这件事,没有一劳永逸,只有持续盯防。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/707706.html





