webshell后门

2023年夏天，后门某电商平台的后门安全团队在例行巡检时发现了一台服务器上多了一个叫cache.php的文件。文件不大，后门内容看起来像是后门正常的缓存逻辑，但其中一行被注释掉的后门代码里藏着一句eval($_POST['cmd']);。就这一行，后门攻击者可以在这台服务器上执行任意PHP代码——读数据库、后门传文件、后门甚至反弹一个shell出来。后门

这就是后门webshell后门。它不是后门病毒，不是后门蠕虫，本质上就是后门一段被偷偷放进你服务器里的代码，充当远程控制的后门入口。攻击者拿到这个入口后，后门通常做的第一件事是提权，第二件事是横向移动，第三件事是清理痕迹。整个过程可以快到几分钟。

它长什么样

最常见的webshell是PHP的，因为PHP在Web环境里部署最广。一句话木马是最经典的形态：

<?php @eval($_POST['pass']); ?>

就这么短。上传到服务器上任何一个能被PHP解析的目录，攻击者用POST请求发指令就能执行。后来WAF和杀软开始查eval这个关键字，攻击者就换成了assert、preg_replace的/e修饰符、create_function，甚至用$_POST['a']($_POST['b'])这种动态函数调用来绕过检测。

更隐蔽的做法是把webshell藏进正常文件里。比如一个图片上传功能，攻击者上传一张真实图片，但在EXIF信息里塞入PHP代码，再配合本地文件包含漏洞去解析它。或者把后门写进.htaccess，让特定User-Agent的请求才触发执行。我见过一个案例，后门被伪装成一个404错误页面，只有带特定Cookie的请求才会进入恶意分支，普通访问者看到的就是一个正常的“页面未找到”。

怎么进来的

绝大多数webshell是通过文件上传漏洞植入的。开发人员只在前端做了accept="image/*"限制，后端没校验MIME类型和文件内容，攻击者改个后缀就能传上去。还有一种常见情况是使用了含有已知漏洞的第三方组件——比如某个老版本的编辑器插件、某个CMS的文件管理模块。攻击者不需要自己写代码，直接用公开的EXP就能打进去。

另一个容易被忽略的入口是日志文件。如果应用把用户输入写进了日志，而日志目录又恰好可以被Web访问，攻击者就可以在User-Agent里写入PHP代码，然后直接请求那个日志文件。这种手法叫“日志投毒+文件包含”，在CTF比赛里很常见，真实环境中也有不少案例。

怎么发现

靠杀软扫特征码只能抓到最粗糙的那一批。真正有效的办法是监控文件变化。Linux下可以用inotify监听Web目录的写入事件，Windows下可以用文件系统审计策略。一旦有非发布流程产生的文件出现，立刻告警。

另一个思路是看进程行为。Web服务器的子进程不应该去连外网IP的4444端口，也不应该去读/etc/shadow。用auditd或者EDR把Web进程的系统调用盯住，异常行为一目了然。我自己的习惯是定期用find /var/www -name "*.php" -newer /var/www/index.php扫一遍，看看有没有比入口文件更新的PHP文件——这招很土，但管用。

清理的坑

发现webshell之后，很多人第一反应是删掉那个文件。但如果攻击者留了多个后门呢？或者后门不在文件系统里，而在数据库的某个字段中，被应用动态写入临时文件再包含？只删文件往往清不干净。

更稳妥的做法是：先隔离服务器，保留现场做取证，确认所有后门位置和攻击者留下的其他持久化机制（比如cron任务、SSH公钥、启动项），然后从干净的备份恢复，或者重装系统。听起来很重，但比起删了一个后门、三天后又被同一个攻击者用另一个后门进来，重装反而是最快的。

说到底，webshell后门拼的不是技术深度，是运维的细致程度。文件权限、上传校验、组件更新、日志监控——每一环都做到位，攻击者能钻的空子就少一大半。可现实是，很多团队连Web目录不允许执行PHP这条最基本的策略都没配。后门能活下来，往往不是因为藏得多好，而是因为没人去看。

(责任编辑：百科)