去年秋天，检测我帮一个客户处理服务器被入侵的检测事。攻击者留了一个webshell，检测藏在WordPress的检测wp-content/uploads目录下，文件名伪装成正常的检测图片缓存文件，叫cache_7f3a.php。检测客户的检测安全插件扫了三遍都没发现。我打开那个文件一看，检测代码就一行，检测用base64编码嵌套了三层，检测解码后是检测一个功能完整的文件管理器。这种事我遇到过太多次了。检测

webshell的检测本质很简单：一段能在服务器上执行命令的代码。PHP、检测JSP、检测ASP、Python，甚至Node.js，什么语言都能写。攻击者上传它的方式五花八门——利用文件上传漏洞、SQL注入写入、远程文件包含，或者干脆通过弱口令登进后台再传。一旦落地，它就成了攻击者在服务器上的据点。有人用它偷数据，有人用它当跳板攻击内网，还有人只是把它当后门留着，等需要的时候再回来。

检测webshell，最直接的办法是看文件内容。但难点在于，webshell会变形。早期的webshell长这样：<?php eval($_POST['cmd']); ?>，特征太明显，随便一个杀毒软件都能认出来。现在不这么玩了。攻击者会把关键函数拆开拼接，用变量函数调用，比如$a = 'ev'.'al'; $a($_POST['x']);。还有的用回调函数，array_map、usort、preg_replace的/e修饰符，甚至用反引号执行命令。更隐蔽的会利用PHP的流包装器，或者把代码藏在图片的EXIF信息里，用include加载。

静态检测靠正则匹配关键字，比如eval、assert、system、exec、passthru、shell_exec、popen、proc_open这些。但正则一多，误报就上来了。WordPress的插件里经常出现eval，有些模板引擎也用。我见过一个客户的正经业务代码里用了call_user_func_array，结果被安全软件反复告警，运维都快疯了。所以单纯靠关键字，不靠谱。

动态检测的思路不一样。它不看代码长什么样，看代码干什么。比如用strace跟踪系统调用，或者用PHP的扩展hook掉危险函数，记录调用栈和参数。这种方法能抓到变形后的webshell，但性能开销大，生产环境不一定愿意上。还有一种做法是流量检测，在HTTP请求里找可疑参数。webshell的流量特征其实挺明显——POST请求里带一长串base64，或者参数名是a、b、c、z这类单字母，响应内容里出现大量文件路径或命令输出。WAF通常就靠这个拦。

我自己的经验是，没有哪一种方法能单独搞定。静态扫描做第一层，把明显的恶意文件筛出来；动态监控做第二层，抓运行时行为；流量分析做第三层，看有没有异常通信。三层叠在一起，漏报率能降不少。但即便如此，还是会有漏网的。我见过一个webshell，它不执行任何危险函数，只做一件事：把接收到的代码写进一个临时文件，然后用include加载。静态扫描看不出问题，动态监控如果没覆盖到文件写入后的加载行为，也抓不到。

另外说一个容易被忽略的点：webshell不一定在Web目录里。攻击者可能把它传到/tmp，然后用本地文件包含漏洞去加载。或者干脆写进session文件，利用session反序列化触发。检测的时候如果只扫网站根目录，等于白扫。我一般会建议客户把整个服务器上最近修改过的PHP文件都过一遍，尤其是那些权限不对、时间戳异常的。攻击者上传webshell后通常会改时间戳，但改得再像，也跟正常业务文件的修改规律对不上。

最后提一句，检测出来之后别急着删。先备份，再分析。看看它是怎么进来的，有没有其他后门，有没有横向移动的痕迹。我见过太多人一发现webshell就rm掉，结果第二天又被传了一个，因为入口根本没堵上。webshell只是症状，不是病因。