渗透webshell

一个webshell传上去，渗透服务器基本就姓别人的渗透了。这话听着糙，渗透但干过应急响应的渗透人都懂。去年帮朋友看一台被挂马的渗透机器，日志翻到凌晨三点，渗透最后定位到的渗透入口就是一个两KB不到的PHP文件——名字伪装成正常缩略图缓存，内容只有一行经过base64编码的渗透eval。攻击者甚至懒得混淆，渗透因为他知道，渗透绝大多数运维根本不会去翻那个目录。渗透

渗透webshell这件事，渗透说白了就三步：传上去、渗透藏起来、渗透连上来。渗透但每一步的细节，决定了你是十分钟被揪出来，还是能在里面住上几个月。

传：入口比技术重要

很多人一上来就研究免杀马怎么写，其实方向偏了。webshell能不能落地，八成取决于你有没有一个可写、可执行、且不在监控范围内的目录。上传点可能是后台的图片上传功能，可能是某个插件的缓存路径，甚至可能是日志文件本身——把PHP代码写进User-Agent，再通过文件包含去读日志，这套路老得掉牙，但至今有效。

我见过最离谱的入口是一个WordPress站点的备份插件。插件会把数据库导出到web目录下，文件名带时间戳，可预测。攻击者写个脚本轮询，拿到备份文件里的管理员哈希，进后台，传插件，拿shell。全程没有用任何0day，全是配置疏忽。

藏：别用冰蝎默认的AES密钥

冰蝎和哥斯拉确实好用，但默认配置就是自首。流量特征太明显，稍微像样的WAF都能拦。真要藏，流量层做TLS指纹伪装，文件层把shell拆成多个片段，用的时候再拼。更狠一点，干脆不落地文件，用内存马——Tomcat的Filter、Servlet、Listener都能动态注册，重启才消失。但内存马不是万能，JSP容器版本、中间件类型都得对得上，实战里翻车概率不低。

文件名的伪装也有讲究。别用“shell.php”“cmd.jsp”这种，太蠢。放在/wp-content/uploads/2024/06/下面，命名成class-wp-image-editor-gd.php，混在一堆WordPress核心文件里，肉眼扫目录根本看不出来。权限设成644，时间戳改成和旁边文件一致，ls -la都看不出异常。

连：交互方式决定生存周期

一句话马最危险，因为URL里带参数，访问日志里全是明文命令。反弹shell又太吵，出站连接一多，流量监控立刻告警。比较稳的做法是走正常业务端口，比如把命令藏在Cookie里，通过80端口回传，流量看起来就像普通用户请求。或者用DNS隧道，慢是慢，但隐蔽性拉满。

有个细节很多人忽略：命令执行完要清理。~/.bash_history、/var/log/auth.log、access.log里的异常请求，该删的删，该改的改。但别删太干净，删出日志断层反而更可疑。我的习惯是只删自己那几条，其他原样不动。

防：别只盯着上传目录

防守方最容易犯的错，是只监控上传目录。webshell可以出现在任何有写权限的地方：缓存目录、session目录、模板编译目录、甚至/tmp下被包含进来。真正有效的检测是文件完整性监控加行为分析——一个PHP文件突然开始发起外连，或者某个进程频繁读写/etc/passwd，这些行为比文件特征靠谱得多。

还有，别迷信查杀工具。我试过把冰蝎马改几个字节，某商业查杀引擎直接放行。webshell对抗到最后，拼的是对业务的理解——你知道哪些文件该在哪儿，哪些请求不该出现，才能从噪音里捞出信号。

说到底，webshell只是结果，不是原因。入口漏洞不补，杀再多马也是白搭。