VPS 被植入俄语暴力破解工具跑了 20 天才发现，复盘整个入侵过程

背景

我在某 VPS 服务商有一台 LA 的 VPS ，主要跑 Shadowsocks 自用。今天突然发现 Reddit 未登录不让访问了，打开 ipinfo 一看，好家伙！ IP 被列入了 AbuseIPDB 滥用数据库，让 Claude Opus 一查才发现服务器已经被人当肉鸡用了 20 天，在全球范围内大规模暴力扫描 VNC 。

把排查和复盘过程写出来，给大家提个醒。

发现过程

发现 IP 被 AbuseIPDB 收录后，SSH 上去排查，ss -tnp 一看直接傻了：

一个叫 bruteV19_vnc_static 的进程正在疯狂对外连接，同时有几十个到全球各地 VNC 端口（ 5900-5938 ）的并发连接。CPU 占用 35%，已经跑了好几个小时。

进程是以 scanner 用户身份运行的。这个用户我从来没有创建过。

攻击者部署了什么

/home/scanner/ 目录下有一套完整的攻击工具包：

• bruteV19_vnc_static — VNC 暴力破解工具（静态编译 ELF ，7.2MB ）
• bruteSSH_static — SSH 暴力破解工具（ 5.3MB ，Go 编写）
• agent — C2 远程控制代理（ 8.1MB ，Go 编写）

还有配套的数据文件：

• targets.txt — 16MB ，包含数十万个全球 IP:5900 目标
• passwords.txt — 851 个常见弱密码
• found_vnc_passwords.txt — 已经成功破解了 9 个 VNC 密码

agent 进程与控制服务器 144.31.184.1:500 保持长连接，日志文件 agent_autostart.log 已经膨胀到 803MB 。日志中有俄语字符（如 “пароль” = 密码），工具作者应该是俄语使用者。工具名 “bruteV19” 说明已经迭代到第 19 版，是一套成熟的自动化攻击框架。

入侵方式还原

根据 auth.log 还原的时间线：

2026-02-19 17:17 — 系统重启完成（内核从 6.8.0-85 升到 6.8.0-100 ）

17:17:13 — scanner 用户通过 tty1 （ KVM 物理控制台） 登录，不是 SSH

17:17:57 — 执行 sudo nano /etc/ssh/sshd_config，篡改 SSH 配置

17:19:00 — sudo systemctl restart ssh，重启 SSH 服务

篡改内容：开放 22 端口 + 设置 PermitEmptyPasswords yes

17:19:09 — 6 秒后，同伙从 212.192.31.88 通过 SSH 密码登录

19:42-19:44 — 部署全套攻击工具并启动

之后持续运行了 20 天。

关键点：攻击者是通过 KVM 控制台（ tty1 ） 首次登录的，不是 SSH 。这意味着他们拿到了主机商面板权限。

根本原因

排查下来是多个安全问题叠加：

1. 主机商面板被入侵

攻击者通过 VPS 服务商控制面板的 KVM 功能直接操作了服务器。面板密码我一直存在 1Password 里用自动填充，不存在本地泄露的可能。

2. SSH 配置存在”覆盖陷阱”

我之前在 /etc/ssh/sshd_config.d/99-local.conf 里做了安全加固（禁用密码登录），但实际上从未生效过。

原因是 OpenSSH 对 Include 的配置采用 “先匹配先生效” 的规则，而主机商模板自动生成的 50-cloud-init.conf 里写了 PasswordAuthentication yes。50 在字母序上排在 99 前面，所以 50 的值先生效，我的安全设置被完全架空。

我以为密码登录已经关了，但其实一直开着。

3. 主配置文件中 PermitEmptyPasswords yes

不知道是主机商模板的问题还是被篡改的，主配置里竟然允许空密码登录。

4. 防火墙完全缺失

iptables 规则为空，INPUT/OUTPUT/FORWARD 全部 ACCEPT 。

善后处理

1. 杀掉所有恶意进程
2. 保留现场证据到 /root/incident_evidence/（进程快照、网络连接、恶意文件哈希、攻击日志等）
3. 彻底删除 scanner 用户及所有恶意文件
4. 配置 iptables：INPUT 默认 DROP ，仅放行 SSH （非标准端口）和 Shadowsocks ；封锁 C2 服务器出站
5. SSH 加固：创建 00-security-hardening.conf 排在最前面加载，锁死所有安全选项，防止被 cloud-init 覆盖；关闭 22 端口；强制 AuthenticationMethods publickey
6. 验证系统二进制未被篡改（ dpkg –verify ）、无 rootkit （检查内核模块、ld.so.preload 、SUID 文件、PAM 配置等）

教训总结

1. sshd_config.d/ 的加载顺序是个大坑。 如果你用了 Include ，一定要用 sshd -T 验证实际生效的配置值，不要想当然以为自己写的配置生效了。想确保安全配置优先，文件名要用 00- 开头而不是 99-。（这他妈的似乎也是之前 AI 给的建议，忘记是 GPT 还是 Gemini 了）

2. VPS 控制面板是一个经常被忽视的攻击面。 你的 SSH 加固得再好，攻击者拿到面板权限后可以通过 KVM 控制台绕过一切。选主机商一定要选支持 2FA 的。

3. 出站防火墙很重要。 如果一开始就配了 OUTPUT 规则限制出站流量，即使被入侵了也扫不出去。AWS 之类的大型云服务商默认禁止出站还是很有必要的

4. 不要只看 SSH 登录日志。 这次攻击者走的是 tty1 物理控制台，如果只查 SSH 日志根本发现不了。

5. 定期检查 ss -tnp。 几千个对外连接的暴力扫描进程跑了 20 天我才发现，说明完全没有监控。哪怕每周瞄一眼活跃连接都能早点发现。

附：恶意文件哈希（供参考）

8982b2ab8370d537e07b4febeac6bfd9f0343da289b073efe528afe78f1032fa bruteV19_vnc_static c9699c37b1a88cba5d37c5d40d64d720bd7f57cd0d69436790e873f32cbee076 bruteSSH_static 77e2d440bdec45e9bddb5ddfa5a71331b90b0bf4415edf2ce3fff5031b724875 agent

C2 服务器：144.31.184.1:500 首次 SSH 登录来源：212.192.31.88 如果有人在自己的 VPS 上看到类似的进程或连接，请立即处理。