凌晨两点，提示我盯着终端里那行base64编码的提示字符串，手心全是提示汗。解码后是提示`eval($_POST['x']);`——典型的一句话木马。攻击者把这段代码塞进了我们服务器上一个三个月没更新的提示图片上传插件里。我删掉文件，提示改了FTP密码，提示但心里清楚：这只是提示一次试探，真正的提示攻击者可能早就拿到了更高权限。

Webshell本质就是提示一段恶意脚本，但它的提示可怕之处在于“隐蔽”。你以为服务器是提示自己的，其实它早就是提示别人的后花园。攻击者不需要登录后台，提示不需要修改核心文件，提示只需要一个能执行代码的入口——一个被忽略的上传点、一个老旧的编辑器漏洞、甚至是一张精心构造的图片。图片里藏代码？对，就是这么魔幻。把PHP代码拼进PNG文件的二进制尾部，文件头依然正常，图片能正常显示，但一旦被包含执行，服务器就成了傀儡。

我见过最骚的操作，是把webshell伪装成`.ico`文件，藏在网站根目录的favicon位置。浏览器请求网站时自动加载这个图标，但谁能想到图标文件里藏着`system($_GET['cmd'])`？安全扫描器扫不到，因为文件内容看起来就是一堆乱码图片数据。直到某天日志显示有人通过这个“图标”执行了`cat /etc/passwd`，我们才反应过来。

检测webshell难在哪？难在它没有固定特征。你可以用正则匹配`eval`、`assert`这些危险函数，但攻击者会用`create_function`、`preg_replace`的`/e`修饰符，甚至用`call_user_func_array`配合动态变量名来绕过。更绝的是，有些webshell把代码拆成多段，分别藏在不同的日志文件里，运行时再拼接起来——你扫单个文件永远看不出问题，就像拼图碎片散落一地，不拼起来根本不知道是什么画。

有一回我排查一台被入侵的测试机，翻遍所有PHP文件都没发现异常。最后是检查了Apache的访问日志，发现有个IP反复请求一个不存在的路径`/tmp/.cache/`。我顺着路径找过去，发现目录里躺着一个`.htaccess`文件，里面用`SetHandler`指令把该目录下所有文件都当CGI执行——攻击者根本不需要上传可执行文件，上传一个`.txt`文件就能当脚本跑。这种利用服务器配置缺陷的玩法，比直接传webshell高明十倍。

防御呢？别迷信WAF和扫描器。最有效的方法是盯日志，看异常请求——比如某个文件频繁被POST、参数里带长串base64、User-Agent是冷门工具。更狠的做法是文件完整性监控，把核心目录的哈希值定期比对，任何新增或修改的文件都触发告警。但说实话，这些都要靠人去看，机器只能筛出可疑项，最终判断还得靠经验。

那次事件后我养成了个习惯：每次部署完网站，先把所有上传目录的PHP执行权限关掉，用`php_admin_value engine off`直接禁掉解析。麻烦是麻烦点，但至少堵死了90%的上传型webshell路径。至于剩下的10%？那就只能靠日志和运气了。反正记住一点：webshell不是病毒，它是你服务器上的一把备用钥匙——攻击者什么时候用，取决于他什么时候想进来。你得做的，是让他即使有钥匙也打不开门。