去年帮一个客户做应急响应，检测攻击者用的检测是一个经过三次编码的PHP一句话木马，藏在WordPress主题的检测functions.php里。静态扫描工具跑了三遍，检测全部报"clean"。检测我手动翻文件的检测时候发现那行代码长得像正常的钩子注册——add_action('init', 'wp_normalize');，但wp_normalize函数的检测定义在文件最底部，中间隔了四百多行无关代码。检测这就是检测webshell检测的真实困境：特征库永远追不上变形速度。

说检测方法之前，检测得先搞清楚webshell到底长什么样。检测最朴素的检测一句话木马<?php @eval($_POST['cmd']);?>现在基本绝迹了，因为连最基本的检测WAF都能拦。活下来的检测webshell普遍具备几个特征：代码碎片化、函数名伪装、检测利用合法API做跳板、以及——最头疼的——无文件落地。内存马在Java环境里尤其猖獗，Tomcat的Filter链里塞一个恶意Filter，重启前根本找不到文件。

静态检测仍然是最基础的一层。思路无非是匹配危险函数：eval、assert、system、preg_replace带/e修饰符、create_function这些。但光靠关键词匹配误报率高得离谱。一个正常的CMS里eval可能出现在模板引擎中，system可能被运维脚本调用。我见过最离谱的误报是把某框架的call_user_func_array全部标红，结果整个项目三千多个告警。所以静态检测必须结合上下文——变量是否来自用户输入、是否在可控的调用链中、参数是否经过过滤。单纯的关键词匹配只能做第一轮粗筛。

动态检测的思路不一样。把PHP的disable_functions配好，监控eval的实际执行、文件读写操作、网络连接行为。RASP（运行时应用自我保护）就是干这个的，在eval的底层hook住，不管你怎么编码变形，最终执行的时候都会暴露。但RASP对性能有影响，高并发场景下延迟增加百分之十几是常事。另一个问题是内存马——RASP本身如果被绕过，攻击者可以直接把恶意逻辑注入到RASP的检测逻辑之前。

日志分析是事后检测的主要手段。Web访问日志里找异常POST请求，参数值长度异常、包含base64特征、或者响应体大小与请求不匹配。我习惯用grep先筛一遍POST请求里参数超过500字节的，再看响应码。攻击者用webshell执行命令，返回内容通常不会太小。但这个方法对加密通信无效，如果webshell走的是HTTPS且证书是攻击者自签的，中间设备看不到明文。

流量层面的检测需要DPI（深度包检测）。看HTTP请求里的参数是否符合webshell通信特征：固定长度的心跳包、特定编码格式的指令、响应体里的命令执行结果。有些C2框架的webshell通信有明显的时序特征——每隔固定秒数发一个请求。但攻击者也不傻，加个随机延迟、把指令拆成多个请求、用正常图片做隐写载体，流量检测就瞎了。

实际工作中没有哪种方法能单独扛住。我通常的做法是：静态扫描做第一轮，把可疑文件按危险等级排序；对高风险文件做人工审计，重点看变量传递路径；同时在测试环境部署RASP跑一段时间，观察有没有漏网的动态行为；最后拿访问日志做交叉验证。三层下来，能抓到九成以上的常见webshell。剩下的那一成，要么是0day级别的绕过技巧，要么是攻击者已经拿到了合法凭证在正常操作——后者其实更可怕，因为从行为上看和正常用户没区别。

检测webshell本质上是一场成本博弈。攻击者变形一次的成本很低，改个编码、换个函数名就行。防守方要覆盖所有变形路径，成本高得多。所以别指望有一个工具能解决所有问题，得接受漏报的存在，把精力放在提高攻击者的操作成本上——让他每次上传webshell都要花额外时间绕过你的检测，时间本身就是最好的防御资源。

(责任编辑：休闲)