webshell方法

凌晨三点，某金融公司服务器报警。日志里多了一条诡异的请求，后缀是.jsp，参数带着一串base64编码。安全工程师老周扫了一眼就骂了句脏话——那是冰蝎的流量特征。三分钟后，他切断了那台服务器的外网连接，但数据库里已经多了几十万条用户记录被导出的痕迹。

webshell就这么简单粗暴。一段脚本，扔进目标服务器的web目录，然后你就有了一个浏览器里的后门。它不碰系统内核，不注册服务，甚至不写注册表。它只做一件事：让你能继续执行命令。有的叫“菜刀”，有的叫“蚁剑”，还有一堆自研的变种，本质上都是同一件事——把HTTP请求变成系统命令的翻译器。

最常见的入口是文件上传漏洞。去年我做过一次渗透测试，目标是个老旧的OA系统。上传点只校验了Content-Type，没检查文件内容。我改了个扩展名，把PHP代码塞进图片的EXIF信息里，上传，访问路径，shell就落地了。整个过程不到十分钟。那个系统在外网挂了六年，补丁打不上，因为业务部门说“不能停机”。
另一种路子是SQL注入写文件。MySQL的INTO OUTFILE，如果权限够，可以直接把PHP代码写到web目录。但前提是你得知道绝对路径。这就要靠报错信息、phpinfo页面或者目录爆破去猜。有些站点把web根目录设在D盘，你写C盘路径，写不进去，白费功夫。

真正麻烦的是内存马。它不落盘，直接注入到Java的Tomcat或Spring容器里。你扫描文件系统找不到任何恶意文件，但请求里带个特殊header，就能触发命令执行。我见过一个案例，红队把内存马挂在Filter上，过了三天，安全设备连个告警都没出。直到运维重启应用，shell才消失——但那时数据早被拖完了。

检测webshell，别指望特征库。冰蝎3.0的流量是加密的，菜刀的老特征早被各种魔改覆盖了。最靠谱的办法是看行为：一个正常的图片上传接口，为什么会在凌晨两点频繁请求cmd.exe？文件写入时间为什么和访问日志对不上？还有，查一下web目录下最近修改的jsp文件，如果是个刚入职的运维名字，但那个员工三个月前就离职了——恭喜你，中奖了。

写webshell的人越来越懒，但防御方更懒。很多企业买了WAF就当完事了，日志从不分析，访问记录从不回溯。实际上，一个普通的webshell存活周期平均是204天——这是某安全厂商去年公布的数据。204天，足够把整个数据库复制十遍。

最后说个观察：真正难缠的shell，往往不是技术多高深，而是藏在最脏乱差的业务逻辑里。比如某个上传头像的功能，文件名是用户ID加随机数，但路径拼接时没过滤../，于是你可以把shell写到上级目录的某个静态资源文件夹里。那个文件夹没人扫，因为“静态资源不需要监控”。等发现问题时，shell已经待了快一年。

别指望有银弹。代码审计、RASP、文件完整性监控，每样都做一点，比什么都强。但前提是——你得先承认自己可能已经被种了shell，然后才谈得上防御。