webshell探测

某天凌晨两点，探测监控告警弹出“可疑PHP文件写入”，探测我登录服务器一看，探测`/tmp/.cache.php` 静静躺着，探测代码只有三行：`@eval($_POST['x']);`。探测就这么个破文件，探测绕过了WAF、探测IDS，探测还有我同事上周刚部署的探测“AI威胁检测系统”。

webshell的探测本质不是恶意代码，是探测“通信通道”。攻击者要的探测是稳定回连，不是探测代码多花哨。所以探测得反过来想：别只盯着文件内容，探测要看它跟谁说话、探测怎么说话。

静态扫描是基础，但别指望它抓活的。正则匹配`eval`、`system`、`base64_decode`，能拦住百分之六十的脚本小子，剩下百分之四十用`create_function`加字符串拼接就能绕过去。我见过最离谱的一个样本，把恶意函数拆成七个变量，在注释里分三段藏好，运行时才拼起来。这种就别用正则硬刚了，得看语法树。

动态检测更靠谱，但成本高。给PHP装个扩展，拦截`eval`和`system`的调用栈，记录参数内容，异常行为直接拉黑IP。这个方法能抓到大部分变形马，但有个致命弱点——攻击者可能先探测你装没装这个扩展。怎么探测？写个`phpinfo()`页面试试就知道了。所以别声张，把扩展静默装上，日志走独立通道。

真正让我头疼的是内存马。Java应用里`Filter`型webshell，代码不落盘，直接塞进运行中的JVM。你扫描文件系统，干干净净；查网络连接，它走的是正常业务端口。有个客户就是这样被偷了三个月数据，期间所有安全设备零告警。最后怎么发现的？业务日志里出现了一个永远不该出现的`User-Agent`字符串。

所以探测得加一层——行为基线。正常业务不会在凌晨三点往`/tmp`写文件，正常管理员不会用`?cmd=whoami`这种参数。建立每个应用的“日常行为画像”，偏离就告警。这不需要多高深的算法，统计下参数长度、请求频率、文件操作路径的分布，偏差超过两个标准差就拉出来看看。

还有个土办法，但特别好使：把上传目录的脚本执行权限关掉。百分之八十的webshell都放在上传目录里，你让那个目录只能存文件不能跑代码，一半的探测需求直接消失。剩下的，用文件完整性监控盯着关键目录，任何新增或修改的脚本文件都触发人工复核。

别迷信什么“下一代”产品。我见过最有效的方案是台破旧服务器上跑个`inotifywait`，监控所有web目录的文件变更事件，配合一个简单的哈希比对脚本。成本为零，效果超过市面上大部分商业扫描器。工具贵不贵不重要，关键是你知不知道攻击者在你系统里留下了什么痕迹——而这个问题，只有你自己最清楚。

哦对了，那台凌晨告警的服务器，最后发现是内部员工干的。他嫌每次发布代码要手动上传太麻烦，写了个后门方便自己更新。你说这算不算webshell？