今天奶爸接了一个客户的网站杀毒任务，和之前碰到的病毒不一样，这次的病毒是被同服务器其他网站跨站感染的，所以写篇文章记录一下。
中毒客户网站基本情况
本次找奶爸处理病毒的是2021年找奶爸建站的客户，网站已经过了售后期且客户自己借助EasyClaw对网站进行了改版、运营等操作，自己也让AI扫描和处理过比当年高度，但是并未根治。
服务器是使用的Hostinger的VPS，安装的宝塔面板。面板上一共两个网站。
进入网站列表，我看到网站列表另外一个站的日流量居然又800多MB，本次让我杀毒的网站日流量才50多MB，根据奶爸自己多年的经验，这个站大概率是不正常的，要么中毒，要么被攻击，不过不是本次杀毒目标，所以我只给客户提了一嘴，并没有去管这个站。
病毒排查和清除
进入排查病毒的网站文章目录，很明显的看到了一个不属于WordPress的文件，site.php
打开文件后里面的代码一看就是病毒代码，从bujang.online这个站下载恶意脚本。
然后继续查看，又找到了第二个病毒文件wp-hide.php
进一步排查插件目录，发现一个奇怪的文件夹
这个不知道是不是客户自己用AI处理，给文件夹加了名称，正确的应该是insert-headers-and-footers。
客户网站插件数量比较多，一共42个，人工来核对的话比较麻烦，所以奶爸直接让AI帮忙对所有插件进行了官方代码比较，最终找到了“伪装成 WordPress 安全模块的 wp-core 插件”和“被植入 POST 执行后门的插件和主题文件”
将这些恶意代码清理后，这个站的病毒就算彻底查杀了。
事后分析，发现根因
因为是国庆假期，白天处理完毕后，晚上奶爸准备分析下日志来排查下这个站是如何被挂马的，结果AI分析日志发现，上面这个站并不是最先被挂马的网站，而是一开始日流量高达800多MB的那个站。
| 时间 | 事件 | 证据 |
|---|---|---|
| 8 月 28 日 10:26 | 攻击者 IP 187.14.109.121 成功登录 ****.com 后台 | POST /wp-login.php 返回 302，随后后台首页返回 200 |
| 10:26:46 | 打开后台插件上传页 | /wp-admin/plugin-install.php?tab=upload 返回 200 |
| 10:26:54 | 上传恶意插件 | POST /wp-admin/update.php?action=upload-plugin |
| 10:27:03 | 直接执行恶意插件中的命令后门 | 请求 wp-cache-4ed103ec.php?...&c=echo+test 返回 200 |
| 10:43:22 | 使用后门执行 pwd | 命令执行成功并返回工作目录 |
| 11:37:14 | 攻击者再次成功登录后台 | 登录 POST 返回 302，后台返回 200 |
| 11:37:47 | 再次通过后台上传插件 | POST ...action=upload-plugin 返回 200 |
| 11:39:32 | 激活 WP File Manager | 日志明确记录激活 wp-file-manager/file_folder_manager.php |
| 11:39:40 起 | 打开文件管理器并从 / 根目录浏览服务器 | File Manager 的目标 l1_Lw 解码后是 / |
| 11:43 左右 | 通过 File Manager 向 x-** 写入后门 | 同一 IP 正在持续调用 mk_file_folder_manager，同时 x-teamrc 后门文件出现 |
| 11:43:43 | 测试 /site.php | 攻击 IP 请求该文件 |
| 11:43:53 | 测试 /aa.txt | 返回 200，内容长度 4 字节 |
| 11:45:15 | 测试 /wp-hide.php | 后门返回 401，要求认证 |
| 11:45:25 | 使用后门用户名成功进入 | HTTP 200；日志记录 Basic Auth 用户名 @FradaB321 |
| 11:47 | 在 Revolution Slider 目录建立辅助后门 | xmlc.php、includes/bs4.php 均返回 200 |
| 10 月 1 日 | 增加插件、主题内的 POST 执行后门 | custom-1790893767 和 category-template-1790893826 |
| 10 月 4 日 | 增加伪装的 wp-core 持久化插件 | 冒充 “WordPress Security Team”，加载隐藏远程 JS |
| 10 月 6 日 02:07 | 带毒旧副本被复制/恢复到正式目录 | 文件修改时间仍是 8 月，但 inode 创建时间为 10 月 6 日 |
简单来说，就是攻击者先获取了日流量比较大的那个站的管理员权限，然后通过后台插件上传了恶意插件。
然后恶意插件上传PHP文件感染另外一个站。
为什么一个站中毒另外一个也中招？
导致一个网站被攻破，然后同服务器其他服务器也感染病毒的根因是这两个站都是同一个Linux用户组运行。
他们都是www:www
攻击者通过在另外一个站上传WP File Manager后，把文件管理器根目录配置成了服务器的根目录，可以访问另外网站的文件。（提示，奶爸之前碰到过WP File Manager插件本身漏洞导致网站被感染的情况，现在基本上不信任这个插件了。）
总结
当网站被挂马后，常规的排查方向很简单：
- 查看网站根目录下的文件和文件夹，看看是否有不属于WordPress的内容。
- 查看不应该存在的文件，看看代码是不是乱码，是乱码基本上就是恶意文件。
- 查看有没有你没有安装的插件，如果有，大概率也是恶意插件。
绝大多数情况下，删除中毒的文件，重新覆盖安装WP核心和插件，可以解决这些病毒感染，但是碰到感染数据库的，还需要清理数据库的恶意内容。
这次网站病毒查杀整个过程中，真正导致目标网站被感染并不是网站本身的漏洞，而是同服务器另外一个网站被攻破，并且所有网站默认使用了相同的用户和用户组，导致跨站感染。
为此，建议担心此类问题的朋友可以进行以下操作：
- 每站独立 Linux 用户；
- 每站独立 PHP-FPM Pool；
wp-config.php仅本站用户可读；- 数据库独立用户；
- 禁止后台文件编辑；
- 上传目录禁止 PHP；
- 非维护期锁定插件、主题和核心；
- 管理员使用独立强密码；
- 定期检查管理员、应用程序密码和组件变化；
- 保留足够长的访问日志；
- 定期生成站外备份与文件基线。
当然，如果你使用的是WP Panel，那么不用担心这个问题，WP Panel默认就是每站独立 Linux 系统用户和用户组；每站独立 PHP-FPM Pool 与 socket；一个网站被攻破而感染同服务器其他网站的可能性相对较低。