前言

我实验室的座位隔壁放着一台其他课题组管理的服务器，平时利用率不高。那天我发现服务器的风扇转速拉满持续了至少一天，遂问隔壁在跑什么东西，隔壁同学在课题组问了一圈发现没人在用。两天后我恰好有点时间，帮他们在服务器上进行调查。最终发现是中了挖矿木马，进行了杀毒并把多个存在的系统漏洞都补上了。第一次手动实战查杀，故记录方法和过程。

系统版本：Ubuntu 20.04 LST

排查开始

系统占用

使用nvidia-smi查看显卡占用，发现没有进程使用显卡，占用为0。
使用top指令，按P以CPU占用率排序，按c显示完整的启动命令。
发现CPU总占用100%，有多个服务和应用分别占用不同的CPU资源。
查找CPU占用较高的进程，使用sudo kill [进程号]关闭。

进程排查

对于关闭后自动重启的进程，使用pstree -sap [进程号]查看该进程被启用的原因。
大部分分为以下几种：

1. 通过ssh连接的bash启动的，大部分可以认为是手动启动的。
   

2. 来自gnome-shell的，一般是图形界面手动启动的
   

3. 通过containerd-shim启动的，一般是docker。
   
   

4. 直接是systemd启动的，通过systemctl查看和管理。
   
   

在该过程中，我关闭了所有服务器上占用大量资源的服务，然而CPU占用仍为100%。

网络统计

使用 netstat -anp 查看网络连接，主要关注State为ESTABLISHED的连接。

图中172.16.开头的是内网地址，与外网的连接有两个，红框的那一行以及其上一行。
红框中的连接的PID和程序名被隐藏，十分可疑，查询该IP发现是德国某数据中心的。

深入排查

修复指令篡改

这种情况我已经预感是中了木马病毒，top和ps命令可能被篡改，便从别的机器复制了个新的top和ps文件来使用（也可以检查命令文件的md5），发现结果是一样的，这说明至少top和ps的二进制文件没被篡改。

那么还有一种可能是动态链接库劫持，如果top和ps指令需要调用的动态链接库被篡改，也会影响其正常工作。一种劫持方法是让被篡改的动态链接库预加载，使其具有更高的优先级，从而代替正常的动态链接库被程序调用。

通过ldd指令查看top和ps使用的动态链接库，并对比其他机器上的相同内容，发现确实多了一个动态链接库/usr/local/lib/libextrasshd.so。

环境变量LD_PRELOAD和默认配置文件/etc/ld.so.preload指定了预加载的动态链接库路径。一般情况下，Ubuntu系统中不存在该文件，但在该服务器中该文件存在且指定了/usr/local/lib/libextrasshd.so。该动态链接库在正常的系统里也是不应该存在的。

通过删除/etc/ld.so.preload和libextrasshd.so，top和ps指令恢复正常，可以发现木马进程及其对资源的占用情况。

隐藏程序查找

除了手动清除指令篡改外，也有其他手段发现隐藏的程序，如busybox还有unhide等工具。
安装并运行sudo unhide proc，发现多个隐藏进程，其程序位于/root/.cfg/，是名为rcu_tasked的二进制文件。

进程信息查看

通过pstree -sap 1369 发现其进程直接由系统守护进程systemd启动。我们通过sudo systemctl status [主进程PID]查看其运行信息。

发现其配置文件位于/lib/systemd/system/myservice.service。删除该文件并输入sudo systemctl stop myservice.service关闭该程序，关闭后服务器瞬间安静了下来。

myservice.service文件内容如下，其目的为保持启动一个藏在/usr/bin/player下的程序，该程序会启动多个/root/.cfg/rcu_tasked进程，而这些rcu_tasked进程会占用大量CPU资源。

后续清理

斩草除根，检查下述位置是否存在可疑内容

删除相关文件

删除/usr/bin/player以及/root/.cfg/下的所有文件，可以看到文件名写着gminer，是挖矿木马无误了。

此外，被攻破的用户dev的用户目录下也有包含木马的.cfg文件夹，一并删除。
还有这些文件被篡改，也一并删除：

/usr/bin/mslog
/home/dev/.local/share/gvfs-metadata/
/home/dev/.config/pulse/
/root/.ssh/authorized_keys

systemd

时间倒序排序检查 systemd 中是否还有别的启动配置。

ll -rt /lib/systemd/system
ll -rt /lib/systemd/user/
ll -rt /etc/systemd/system
ll -rt /etc/systemd/user/

计划任务

sudo crontab -l查看root用户的计划任务，发现一条，使用crontab –e删除。同时检查其他用户的计划任务。

@monthly /root/.cfg/./dealer > /dev/null 2>&1 & disown

用户

cat /etc/passwd查看服务器的用户，发现一个无人认领的账号pischi。

pischi:x:0:0::/home/pischi:/bin/bash

sudo cat /etc/shadow查看其密码最后更改时间，发现与myservice.service文件的创建日期一致，基本可以确定是问题账号，将其/bin/bash改为/bin/false，禁用该账号。

pischi:$6$8rq.pSIq86wW9CaK...:19730:0:99999:7:::

原因追溯

使用last查询登录历史，基于myservice.service文件的创建时间查找对应的记录，发现一条完全对应的记录。使用的账号为dev，说明该账号或其启动的服务存在漏洞；来源ip为127.0.0.1，说明是通过内网穿透服务连接的。

使用sudo lastb查询当时登录失败的记录，发现并没有，这说明可能不是直接通过ssh弱口令攻击黑进来的，除非第一次攻击就成功或暴力破解的记录被删掉了。

另一种可能是该用户下载并执行了包含木马的程序，但根据调查当时服务器并没有人在使用，那么剩下更大的可能是该用户部署的服务存在漏洞，导致黑客可以调用该用户权限进行操作。

进一步查看/var/log/auth.log中对应时间的日志

日志中记录的信息包括：黑客通过dev用户登录服务器后过了70秒切换到了root用户（切换时其所在路径是/home/dev/.cfg），7秒后添加了用户pischi、修改了pischi和root的密码，6秒后退出。

全盘查找这段时间中修改过的文件，发现漏网之鱼，已补充到删除相关文件章节中。

find / -newermt "2024-01-08 22:02:34" ! -newermt "2024-01-08 22:03:59"