webshell下载

凌晨两点，下载某甲方运维打来电话，下载说服务器CPU跑满，下载top命令看到一堆奇怪的下载php-fpm进程。我登录上去，下载在/tmp目录翻到一个叫`cache.php`的下载文件，只有三行代码，下载却能把整个服务器当肉鸡使——这就是下载webshell，攻击者留下的下载后门。下载它不需要什么高深技巧，下载一个`wget`命令就够，下载但真正的下载问题在于：你下载的是别人精心准备的陷阱，还是下载自己主动放进来的定时炸弹？

最常见的情况是，攻击者先利用某个upload漏洞传了个小马（一句话木马），下载然后通过小马执行命令，下载把大马（功能完整的webshell）从远程服务器拉下来。这时候流量里会有明显的特征——一个POST请求，参数里带着`eval`或者`system`，紧接着就是一个GET请求去访问某个陌生域名下的zip或php文件。我见过最粗糙的，直接在公网GitHub仓库放webshell源码，用`curl -O`就下载了，连加密都懒得做。

但更隐蔽的是第二种：攻击者把webshell拆成碎片，分多次写入。比如先用`echo`追加几行代码到日志文件，再通过包含漏洞把它触发。这种下载不是一次性的，而是“组装”过程。之前处理过一个案例，攻击者利用thinkphp的缓存机制，把恶意代码藏在`runtime/`目录的缓存文件里，每次请求特定URL就会重新生成一次，杀毒软件扫完删掉，下次访问又“下载”出来了。你根本找不到一个完整的webshell文件，它像水一样流动。

第三种情况最讽刺——管理员自己下载的。有些安全工具会“主动”去下载webshell样本做分析，或者某些扫描器误把正常文件当恶意文件隔离，管理员为了恢复业务，从网上随便找了个“原版”文件传回去，结果那个文件本身就带着后门。我见过一个小型电商网站，被安全公司扫描报告吓到，技术负责人连夜从某论坛下载了个“修复补丁”，上传后网站确实能跑了，但数据库每天凌晨三点定时往外传数据，持续了两周才被发现。

说到防御，别指望靠封禁下载源解决问题。webshell的下载行为本身没有统一特征，攻击者可以用DNS隧道、ICMP隧道甚至直接通过邮件附件把代码带进来。真正有效的办法是盯住文件落地的位置——正常情况下，web目录下不应该有可写可执行的php文件。用`inotify`监控目录变更，有新文件生成就立刻比对哈希，配合WAF拦截常见的`eval`、`assert`函数调用，比任何下载拦截都实在。

最后说个反直觉的观察：很多webshell下载回来根本跑不起来。为什么？因为攻击者要适应目标环境，php版本、扩展库、禁用函数都不一样。所以你会发现，真正危险的往往不是那些功能全的大马，而是被精心裁剪过、只针对当前站点定制的微型后门。它们可能只有几行代码，藏在某个图片文件的EXIF信息里，通过`exif_read_data`函数读取执行。下载只是第一步，后续的适配和隐藏才是攻防的焦点。

别把目光全放在“下载”这个动作上。webshell的可怕之处从来不是它怎么来的，而是它来了之后你怎么还没发现。下次看到服务器异常，先别急着删文件，花十分钟看看它的行为日志——谁在什么时间，通过哪个接口，把它带进来的，那才是你真正需要下载的情报。