不弹窗、不加密、不断业务——它只做一件事：按分钟把你的服务器底账打包送走。

引言：一场"安静"的入侵

2026 年 10 月 20 日至 22 日，我们一组共 10 台服务器遭遇了一轮规模化入侵。攻击者的手法高度一致：先拿到 root 权限，再投放一类"信息收集型后门"。

这类后门最阴险的地方在于它几乎不打扰你——它不弹警告窗口，不加密你的文件，也不让业务中断。它只做一件事：按分钟把主机的面板数据库、站点配置、数据库转储和各类凭据悄悄打包，再通过外传接口发送出去。

目前我们已在 6 台机器上确认了两族后门：

• i9 系：出现在 5 台安装宝塔面板的 Linux 服务器上，变体包括 i9634probe、i9634_agent、i9634boot、i9634a2、i9734agent、i9733probe。
• i8 系：出现在 1 台 CentOS 8 服务器上，变体包括 i8967、i9068。

好消息是：两族后门已全部清除并逐台复验，业务服务运行正常。

但有一句话必须说在前面：

已清除的是"后门程序"，不是"攻击者掌握的信息"。

这 6 台机器的 root 口令、面板数据库、站点配置、数据库导出和 SSH 信任链都已经外传。在换密之前，攻击者手里的那些凭据依然有效。

这篇文章写给所有使用这组服务器的人。读完你会知道：到底发生了什么、怎么自查、发现后怎么处置、以及日常用机要守住哪些底线。

一、两族后门是怎么工作的

i9 系：藏在宝塔计划任务里的"内鬼"

i9 系没有新建独立服务，而是直接把自己塞进宝塔面板的计划任务目录 /www/server/cron/，文件名伪装成面板任务脚本，再由 root 的 crontab 以"每分钟一次"的频率拉起。宝塔本身就大量使用这个目录存放哈希命名的任务，混进其中的少数字节很难被一眼发现。

• 载体目录：/www/server/cron/
• 触发方式：root crontab 每分钟执行
• 投放时间：2026-10-20 17:19 至 18:00 之间集中投放，之后持续运行
• 常驻进程：部分机器上即使删了 cron，后台仍有 agent 进程继续跑

它把主机信息采集到 /tmp/i9733 等目录（部分机器为 /root/i9734_dump 等），采集内容几乎等于把服务器"底账"整体带走：

其中最严重的节点上还出现了面板库明文导出和业务库导出，说明攻击者在那台机器上走得最远。

i8 系：更"朴素"，但目的相同

i8 系出现在那台 CentOS 8 机器上。它比 i9 系更直接：确认权限，然后整库拖走。

• 通过 /etc/cron.d/i8967 与 root crontab 各一条每分钟任务，执行 id 确认身份与计划任务权限；
• 采集目录 /root/i9068/ 中的 dumpall.sh 直接用明文 MySQL root 口令登录数据库；
• 遍历除系统库外的全部业务库，逐库导出为 .sql.gz——这台机器一次性拖走了 371 个数据库 的转储，并打包了 30 余个站点的配置文件。

一句话总结：i8 系和 i9 系是同一套思路的不同实现——拿 root、按分钟轮询、把主机与数据库信息批量打包、等待外传。

二、这些 IOC 特征请记牢

发现以下任一特征，就要高度警惕：

• 文件名：匹配 i9634、i9733、i9734、i8967、i9068 等"i + 数字"前缀。
• 目录：/tmp/i9733、/tmp/i9634、/tmp/i9734、/root/i9734_*、/root/i9734_dump、/root/i9068。
• 计划任务：crontab 中出现指向 /www/server/cron/i9* 的每分钟任务。
• 异常端口：18080、18081、18082。
• 攻击者公钥：/root/.ssh/authorized_keys 中出现注释为 root@6acc0cc4b9e4 的 ssh-ed25519 公钥。

⚠️ 重要提醒：i 加数字命名的目录不全是攻击者产物。 同一台机器上的 /tmp/i10437 经核实只是本机自建的测试探测服务，并非恶意。判断一套文件是否恶意，要看内容和行为，不要只看文件名——否则可能误删正常业务组件。

三、怎么自查：6 类检查 + 一键脚本

以下命令可直接在服务器执行。核心思路是查六类地方：定时任务、可疑进程、采集残留、异常端口、授权密钥、提权账户。

# 1) 定时任务：重点看 /www/server/cron 下 i+数字 命名的文件
crontab -l | grep -E 'i[0-9]{4}'
ls -la /www/server/cron/ | grep -E 'i[0-9]{4}'
ls -la /etc/cron.d/ /etc/crontab /var/spool/cron/crontabs/

# 2) 可疑进程（含常驻 agent）
ps -eo pid,user,etime,cmd | grep -E 'i[0-9]{4}|listener|srv\.py' | grep -v grep

# 3) 采集包与残留文件
ls -la /tmp | grep -E 'i[0-9]{4}|ak2scan|cons\.html|cap\.png|o[0-9]?\.bin|network_script'
ls -la /root | grep -E 'i[0-9]{4}'

# 4) 异常监听端口
ss -tlnp | grep -E '1808[0-2]'

# 5) 授权密钥：确认每一位都认识
cat /root/.ssh/authorized_keys

# 6) 提权账户与 sudo 权限
awk -F: '$3==0 {print $1}' /etc/passwd
ls -la /etc/sudoers.d/

网站目录与日志也要过一遍：查找近期新增或改名的 PHP 文件、检索 eval(、base64_decode(、system( 等 WebShell 特征串，并核查可疑的 POST 目标和静态资源之外的 200 响应。

如果嫌手动麻烦，可以用一键自查脚本，把 cron、进程、残留文件、端口、授权密钥、ld preload 六项一次跑完——只要出现任何非 "clean" 项，立即上报。

四、发现后门怎么办：处置五步

顺序不能错——先隔离、后留证、再清除、换凭据、做复验。

1. 先隔离：立即封堵管理端口与出站方向，阻断继续外传，再动手清理。
2. 后留证：处理前把 crontab、可疑脚本、采集目录、相关日志打包留档，避免破坏证据。
3. 再清除：停常驻进程、删 cron 任务、删脚本与采集目录，检查 systemd、rc.local、profile.d 等自启位置是否还有残留；核对 authorized_keys，删除攻击者公钥行。
4. 换凭据：清除后门不等于安全，必须逐项轮换下面这些凭据。
5. 做复验：重新执行全部自查项，确认无残留、无新增投放，才算处置完成。

这些凭据必须轮换或确认

本文不写入任何口令与密钥明文。轮换后的新口令通过安全渠道单独分发，切勿抄写到本机文件、记事本或聊天记录中。

已实施与待推进的加固

已实施：管理端口白名单、业务端口仅放行中国大陆 IP、PHP 侧 RCE 缓解、SSH 与面板口令轮换、部分节点部署 fail2ban。

建议继续推进：宝塔面板开启二次验证与登录告警；限制面板 API 来源；宝塔编译版 PHP 升级到官方修复版；SSH 改为密钥登录并关闭口令认证（前提是先确认密钥链可信）；定期审计计划任务变更。

五、给每一位使用者的用机底线

这次事件最大的教训，不是"后门多厉害"，而是"我们太容易把凭据摊在机器上了"。请守住这几条：

• 别把这几台机器当可信环境。 后门虽清除，但外传出去的凭据无法收回，攻击者凭旧凭据仍可再次进入。
• 别在服务器上存放明文凭据。 脚本、.env、记事本、/tmp 里的临时文件都算——攻击者的采集脚本正是靠这些清单一次性捞走。
• 别在命令行里直接携带明文口令。 它会被记进 shell history，也会出现在进程列表里。
• 每人独立账号，禁止共用 root 口令。 登录后可用 last、who 与 /var/log/auth.log 复核是否存在非本人登录。
• 不要把私人/生产/支付/短信密钥放在这些机器上。 已在的，逐项轮换，后续改用环境变量或专门的密钥管理方式保存。
• 不执行来源不明的 base64 脚本，也不直接运行 /tmp 下的临时脚本。
• 判定要谨慎。 "i + 数字"目录不全是恶意的，判定看内容和行为，避免误删业务组件。
• 两台无法登录取证的节点（Windows / Debian），在补齐核验前不要依赖其业务数据与配置的可信性。
• 需要登录受白名单保护的管理端口时，先向管理员申请加白，不要尝试绕过防护。

结语

安全事件里最容易被忽略的真相是：清理干净后门，只是拿回了服务器的控制权；真正泄出去的凭据，要靠"轮换"才能收回。 如果你也在用宝塔面板、把数据库和密钥摊在服务器上，不妨现在就跑一遍上面的自查脚本——趁攻击者还没回来的时候。

（本文由服务器安全处置小组整理，最后更新 2026-10-22。如有新发现，请第一时间同步管理员，切勿自行删除证据后再上报。）

文章来自网络收集