网站被黑反复发作？揪出隐藏在 PbootCMS 系统深处的持久化后门

很多站长都有过这种经历：
网站刚修复完漏洞，过两天又被挂马、跳转博彩、甚至首页被篡改。

更让人头疼的是——
明明已经清理过代码、重装过系统，问题还是反复出现。

这种情况，基本可以判断：不是“普通入侵”，而是持久化后门已经建立，而在不少案例中，目标正是基于 PbootCMS 搭建的网站。

下面我们从攻击逻辑出发，带你一步步拆解：黑客是如何“赖着不走”的。

一、什么是“持久化后门”？

很多人理解的“网站被黑”，是：

文件被改了 → 删除 → 问题结束

但现实是，攻击者往往做了三件更隐蔽的事：

• 留下隐藏执行入口（WebShell / 免杀脚本）

• 写入系统级自动恢复机制（定时任务 / 自启动）

• 修改CMS核心调用链（模板 / 解析 / 缓存）

结果就是：

你删一次，它自动再生一次

这就是“反复发作”的根本原因。

二、PbootCMS常见后门藏匿点

在 PbootCMS 体系中，攻击者通常不会直接改首页，而是“埋雷”。

1. Runtime目录（高危缓存区）

很多人忽视：

/runtime/
/cache/
/data/runtime/

这里常见问题：

• PHP缓存可执行

• 模板编译结果未过滤

• 写权限过大

常见后门形式：

<?php @eval($_POST@['x']); ?>

甚至被混淆成一行字符串插入缓存文件。

2. 模板解析漏洞利用

PbootCMS的模板机制如果配置不当：

• {if}标签解析

• 动态include

• 模板变量拼接

都可能被利用注入执行代码。

攻击者常见做法：

• 在可编辑模板中插入“看似正常”的JS

• 利用条件标签执行PHP函数

• 远程加载恶意模板片段

3. 上传目录“伪装图片木马”

最常见也最隐蔽：

/uploads/
/images/
/static/upload/

典型手法：

• 双扩展名：shell.jpg.php

• 图片马：正常图片 + PHP代码尾随

• MIME伪造绕过检测

只要服务器允许解析，就能执行。

4. 定时任务（真正的“复活点”）

如果你清理后又被黑，很可能：

• Linux crontab 被写入

• PHP自执行脚本存在

• Web入口触发“回写机制”

检查：

crontab -l
/etc/cron*

很多站点就是在这里“无限复活”。

三、为什么删干净还是会被黑？

因为你只清理了“结果”，没清理“控制器”。

常见误区：

❌ 只删网站文件

✔ 后门在数据库 / 缓存 / 定时任务

❌ 只重装CMS

✔ 服务器层面已被植入脚本

❌ 只改密码

✔ WebShell仍可直接执行

四、完整排查思路（实战级）

下面是建议你按顺序执行的排查路径：

Step 1：全站文件时间筛查

找“异常修改时间文件”

find /www/wwwroot/ -type f -mtime -7

重点关注：

• PHP文件突然新增

• 时间异常集中修改

Step 2：关键词查后门

grep -r "eval" .
grep -r "base64_decode" .
grep -r "assert" .

危险组合：

• eval + POST

• base64_decode + gzinflate

Step 3：检查上传目录执行权限

确认：

• upload目录是否可执行PHP

• 是否允许解析.php.jpg

Step 4：数据库隐患

重点查：

• 文章内容表

• 配置表

• 模板存储字段

攻击者可能：

• 在文章内容插JS跳转

• 在配置中写远程加载代码

Step 5：服务器层后门

一定检查：

• ssh登录记录

• nginx/apache异常rewrite

• 新增用户

五、彻底解决“反复被黑”的关键

如果你只做“清理”，一定会复发。

正确做法是三层封堵：

1. 文件层

• 重建干净源码

• 删除所有缓存目录

• 限制PHP执行范围

2. 权限层

• uploads禁止执行PHP

• runtime只读或不可执行

• 最小权限原则

3. 系统层

• 定期检查crontab

• 禁止未知用户写入

• 关闭危险函数（eval/assert）

六、最关键的一句话

如果网站“反复被黑”，说明：

你面对的不是漏洞，而是“已经建立控制链的入侵”

经验分享

在 PbootCMS 这类轻量CMS中，很多站长容易忽略“运行机制本身的风险”，导致后门一旦植入，就会长期潜伏。

真正的修复不是“删文件”，而是：

找到控制点 + 断掉自动恢复机制 + 重建信任环境