2006年夏天，木马我帮一个做外贸的木马客户查服务器。登录他的木马Windows 2003机器，打开D盘，木马一个叫“images”的木马文件夹里躺着三十多张产品图，旁边却混着一个asp文件，木马大小只有2KB，木马文件名是木马“conn.asp”。客户说这不是木马他放的。我用记事本打开，木马第一行就是木马`<%@ LANGUAGE = VBScript.Encode%>`，后面全是木马乱码。解码后，木马里面藏着一句`execute request("value")`。木马这就是木马一个典型的asp木马后门。

asp木马不是病毒，它是一段用VBScript或JScript写的网页脚本，上传到支持ASP的IIS服务器上，就能通过浏览器远程执行系统命令、浏览目录、上传下载文件、连接数据库。它依赖的是服务器本身赋予ASP脚本的权限。很多老站长图省事，给IIS的匿名账户开了Administrator权限，结果一个asp木马就能直接加系统用户、开3389端口。

最早的asp木马出现在2002年前后，比较出名的有“海洋顶端”和“老兵”。海洋顶端2006版只有几十KB，界面是一个带框架的网页，左边是目录树，右边是文件列表。点“cmd命令”，输入`net user test 123 /add`，再点执行，服务器就多了一个账户。整个过程不需要任何客户端软件，浏览器就是控制端。这种设计在当时很震撼，因为防火墙通常只拦端口，不拦HTTP请求里的恶意参数。

我见过一个案例。某政府网站被挂上asp木马，攻击者没有立刻搞破坏，而是把木马改名为“error.asp”，放在一个不起眼的子目录里。三个月后，他用这个木马把网站首页替换成一张图片，上面写着“你们的数据库在我手里”。后来查日志，发现攻击者最初是通过一个上传漏洞把木马传上去的。上传时文件后缀是“.asp;.jpg”，IIS6.0解析时把分号后面的内容当参数，实际执行的是asp文件。这个漏洞在当年非常普遍。

asp木马能存活，靠的是三个条件同时成立：服务器支持ASP、上传目录有脚本执行权限、木马文件没被查杀。很多安全软件早期只查exe和dll，对asp文件视而不见。2008年之后，一些主机商开始用“asp木马专杀”工具，原理是匹配特征码，比如`execute request`、`server.createobject("wscript.shell")`。但攻击者很快学会用`eval`、`execute`加字符串拼接来绕过。比如把`wscript.shell`拆成`wscr`+`ipt.she`+`ll`，运行时再拼起来。

防御asp木马，最直接的办法是改IIS配置。把上传目录的“纯脚本”权限改成“无”，只留静态文件读取。这样即使传了asp文件，IIS也不会执行它，只会当文本返回。另外，禁用`WScript.Shell`和`Shell.Application`这两个组件，在注册表里把它们的CLSID项删掉或改名。很多运维懒得做这一步，觉得麻烦。但一个asp木马带来的损失，远比花十分钟改配置大得多。

现在ASP技术本身已经边缘化了，但老旧的Windows Server 2003/2008机器还在一些内网、工控环境里跑。去年我遇到一个客户，他的ERP系统还在用ASP，服务器上就有一个叫“up.asp”的木马，是前任运维留下的。木马没做任何隐藏，就放在网站根目录。客户说“反正内网，没人攻击”。我当着他的面，用浏览器访问`http://内网IP/up.asp`，输入密码“123456”，直接进了文件管理界面。他当场愣住。内网不等于安全，一个能访问该网段的设备，就能控制这台服务器。

asp木马的技术含量不高，但它的存在提醒一件事：服务器上的每一个脚本文件，都是一扇门。门没锁，或者钥匙插在锁上，就别怪有人推门进来。