异常发现

11 月 8 日下午，有小伙伴告诉我某服务异常，表现为后端程序报错与 PostgreSQL 查询相关。由于使用了 CDN 且仅配置了 HTTP 服务监控告警，因此并未在第一时间收到异常告警。

通过 SSH 连接服务器，使用 htop 命令查看正在运行的所有进程，发现 /tmp/kdevtmpfsi 进程高占用，运行用户为 postgres。

尝试结束该可疑进程，发现该程序会在 1 分钟内再次启动，猜测配置了定时任务或存在守护程序。

在云计算平台查看资源监视，该病毒于 UTC 11-7 16:15（北京时间 11-8 0:15）左右开始运行。

由于该病毒占用资源过多造成服务器性能下降，且位于 /tmp 目录下，因此对服务器进行重启以临时缓解。

重启服务器后连接 PostgreSQL 数据库发现所有的数据已被删除，同时入侵者创建了一个名为 readme_to_recover 的数据库，内容如下：

很显然，服务器受到了勒索，入侵者针对 PostgreSQL 数据库实施入侵行为，同时利用服务器资源进行挖矿，造成服务器卡顿和服务崩溃。

入侵者的网站已在 archive.org 存档，链接 https://web.archive.org/web/20251108155042/https://2info.win/psg/，请谨慎访问

从服务器创建到被侵入仅 8 小时，好在还在部署阶段，没有重要数据（离谱

复盘与分析

先贴一下事故服务器的情况：

• Ubuntu 24.04 LTS，运行在 Oracle Cloud
• 仅允许 SSH 密钥登录
• 端口全开
• 安装了宝塔面板，PostgreSQL 使用宝塔安装
• PostgreSQL 允许所有地址使用密码连接，且未对 PG 的登录配置日志

不难看出这起事故的导火索（因为还在部署阶段就没太注意，我反思）

进程

病毒的二进制文件在重启后已被临时清除，为了弄清病毒的入侵和运作方式，我并没有对服务器进行任何操作和加固，而是维持原样运行，等待病毒再次出现。

不出意外，在 11 月 9 日的 0:14 左右，服务器 CPU 占用再次来到了 100%。

查看 /tmp 目录，存在两个二进制文件，如下：

两个程序的所有者均为 postgres，其中 kdevtmpfsi 权限 700，创建时间 UTC 16:14；kinsing 权限 777 ，创建时间 UTC 16:11，略早于 kdevtmpfsi。

同时，我下载了一份病毒样本备用：

使用 ps -ef 命令查找两个进程，如下：

从进程信息来看，kdevtmpfsi 的运行时间在增长（从 06:25:29 变为 06:26:17），而 kinsing 的运行时间在一段时间内几乎保持不变（为 00:00:04），二者的 PPID 均为 1。

稍微熟悉 Linux 的小伙伴不难看出，kdevtmpfsi 持续占用 CPU 时间，为挖矿主程序；kinsing 占用 CPU 时间较少，为 kdevtmpfsi 的守护程序。同时，父进程 ID 为 1 说明二者原始父进程已经终止，转为孤儿进程，由 systemd 进程接管。

但不管怎么说，systemctl 又不是摆设，直接通过 sudo systemctl status <pid> 来查看启动链：

怎么和 postgres 进程一起启动了，再看看。

使用 sudo crontab -u postgres -l 命令查看 postgres 用户的定时任务：

该定时任务设置为每分钟执行一次，使用 wget 工具在静默模式（-q）下载至标准输出（-O -），并通过管道（|）传递给 sh 直接运行，将脚本的运行输出和系统邮件丢弃（> /dev/null 2>&1），以此实现执行信息的隐藏。

在 syslog 中查找相关进程的调用记录，只能找到定时任务相关的记录。

但当我尝试访问该网址时出现 502 错误，只好暂时放弃。

入侵方式

使用 sudo last postgres 命令查看 postgres 用户的登录情况，发现输出为空，说明不是通过 postgres 系统用户的弱口令入侵的。同时，运行在 postgres 用户的服务只有 PostgreSQL。

只有一种可能了。

从 /www/server/pgsql/logs 目录找到了 PostgreSQL 的执行日志，在日志中发现了异常。

这份虽不完整的日志反映了服务器被侵入的全过程，可以将入侵者的操作分为 5 个步骤：

1. 服务探测

入侵者配置了自动工具，对某一特定 IP 段的服务器端口使用 nmap 工具进行扫描，查找符合 5432 端口开放的服务器，并尝试使用空凭证连接，确认 5432 端口上运行的是 PostgreSQL；

2. 成功入侵

入侵者通过爆破弱口令密码/无密码成功连接后，通过尝试访问不存在的数据库 bbbbbbb 和执行大量的 SELECT VERSION(); 来确保已经完成登录，并收集数据库信息以查找漏洞；

3. 破坏数据库

入侵者先列出所有数据库，再依次通过 information_schema.tables 获取表。对于每张表先从 information_schema.columns 获取列数，再使用 SELECT * FROM ... LIMIT 50 来读取表数据，读取后通过 DROP TABLE IF EXISTS ... CASCADE 彻底删除表信息，最终删除原有数据库并写入勒索信息；

4. 提权

入侵者创建了一个 pgg_superadmins 的超级管理员，随后尝试 ALTER USER postgres WITH NOSUPERUSER 命令来撤销 postgres 用户的超级管理员权限，但因为 postgres 为数据库的初始化用户而被阻止；

5. 植入病毒

PostgreSQL 的 COPY ... FROM PROGRAM 命令允许读取系统命令输出到表中，因此被入侵者用于执行脚本。

入侵者使用新建的 pgg_superadmins 创建了一个临时表 bwyeLzCF ，表中仅有 cmd_output 一个类型为 text 的字段，用于承载脚本的输出。echo ... | base64 -d | bash 将 Base64 编码的脚本解码后立即运行，运行成功后删除表 bwyeLzCF 销毁痕迹。

对于核心脚本，Base64 解密后得到如下内容：

这段脚本在运行时会先通过 pkill 命令终止竞争程序，随后下载并运行脚本。入侵者为了能在缺失 curl 和 wget 的环境中运行，甚至在 __curl 函数中直接通过 TCP 协议发送 HTTP 请求。

脚本分析

由于该脚本过长且具有风险性，在这里仅对部分片段进行分析。

1. 入侵准备

脚本先关闭防火墙，随后卸载云监控软件以防止被发现，移除竞争程序避免与 kdevtmpfsi 抢占资源，最终禁用 SELinux 和 AppArmor 安全机制。

2. 加载挖矿程序

在下载前根据架构选择了对应的二进制下载地址，同时根据如下优先级确定了下载位置（该部分代码已省略）：

• • /etc，该目录需要 root 权限
  • /tmp
  • /var/tmp
  • 创建临时目录 mktemp -d
  • /dev/shm

3. 运行和持久化

先给目标二进制文件（$BIN_FULL_PATH）赋予最高权限，确保可以被运行，随后向定时任务中加入一条每分钟执行一次的命令，以此完成持久化，这也是上文看到的加载在 postgres 用户的那条定时任务。

二进制分析

程序特征

使用 Radare2 查看二进制文件原始信息，结果如下：

使用 WinHex 查看 kdevtmpfsi 文件，不难找出 UPX 的特征

使用 UPX 脱壳后再次查看，结果如下：

与脱壳前不同，出现了如下内容：

kdevtmpfsi

通过查找关键字符串 http 快速定位到门罗币相关内容：

随后查找 monero\|xmr：

该程序连接地址为 xmr-eu1.nanopool.org 的矿池，收益地址为 4...b。

kinsing

接下来，我们来看看 kinsing 这个 Go 语言程序是如何实现进程守护的。

在 IDA 中先查找与 kdevtmpfsi 相关的字符串，但无法找到相关引用。

再查找与命令执行相关的函数：

其中 exec.Cmd 是 Go 执行命令调用的函数，而 github.com/shirou/gopsutil 是 Python 中 psutil 的 Go 语言实现，用于获取系统信息，由此判断 kinsing 可能存在执行系统命令的行为。

emm...似乎弄复杂了，我们来看看有没有简单一些的方法。

我先将 kinsing 放在 ~/ 目录下，在 ubuntu 用户下使用 strace 对 kinsing 及其子进程进行跟踪：

在一个新的终端中结束 kdevtmpfsi，等待 kinsing 将其再次启动：

kdevtmpfsi 再次启动时结束 strace 跟踪，并在日志中查找 kinsing 执行的相关命令：

那么这个 /tmp/kdevtmpfsi3355009150 是怎么出现的呢，在日志中查找 http 连接相关信息：

此时，kinsing 的逻辑已经水落石出，它的监控逻辑由四部分组成：

1. 监控进程：通过 read 读取进程信息，检测 kdevtmpfsi 是否存在；
2. 结束已存在的进程：通过 sh -c "pkill -f kdevtmpfsi" 命令，尝试结束已存在的 kdevtmpfsi 进程；
3. 下载挖矿程序：若 kdevtmpfsi 不存在，则执行前文出现的初始化脚本下载挖矿程序到 /tmp 目录下，这里 kdevtmpfsi 带随机数后缀是因为目录下已存在不可读写的同名文件；
4. 启动挖矿程序：通过 sh -c "/tmp/kdevtmpfsiXXXX &" 命令静默式启动挖矿程序。

回到 IDA 中，再次进行相关查找，发现先前被忽略掉的 /var/tmp/kdevtmpfsi 字符串在 main.minerRunningCheck 被引用：

main.minerRunningCheck 函数存在自身循环，那么基本上可以确定该函数就是进程守护的主要逻辑。

对该函数展开分析，发现该函数除自身循环外，还调用了 main.getMinerPid、main.isMinerRunning、main.minRun 等函数：

在 main.minRun 中找到了 strace 日志中出现的内容：

也发现 kinsing 内置了一个下载运行工具：

一切都理清了。

解决方案

基于对侵入流程的复盘，我总结出如下解决方案：

1. 删除可疑定时任务

临时禁用定时任务以防止二次感染：

编辑 postgres 用户的定时任务：

随后再次查看定时任务，确保可疑项已被清除：

2. 取消病毒文件的读写和执行权限

3. 终止相应进程

4. 删除病毒文件

全盘查找文件名包含 kinsing 和 kdevtmpfsi 的文件并删除

5. 删除可疑 PostgreSQL 用户

使用管理员用户登录数据库：

随后执行以下 SQL 语句：

6. 重启服务器

7. 恢复属性保护

8. 加固 PostgreSQL

查找 postgresql.conf 是否存在如下项：

查找 pg_hba.conf 是否存在如下项：

如有，应立即修改或删除。例如仅允许 Docker 容器连接：

9. 加固服务器

对 /tmp 目录进行加固：

建立防火墙规则（根据实际需求修改）：

恢复 SELinux 或 AppArmor

10. 重启，再次观察验证

需注意，该解决方法只适用于临时处理和加固，建议尽快对数据和服务进行迁移重建。同时做好服务器日常维护和监控，避免敏感服务端口直接暴露于公网，不要在 SSH 和数据库使用弱口令密码。在保证服务正常运行的情况下，将账号权限收缩到最小。