记一次手动查杀Linux服务器挖矿木马

发布时间:2024年01月17日

前言

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

系统版本: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 查看网络连接,主要关注StateESTABLISHED的连接。
在这里插入图片描述
图中172.16.开头的是内网地址,与外网的连接有两个,红框的那一行以及其上一行。
红框中的连接的PID和程序名被隐藏,十分可疑,查询该IP发现是德国某数据中心的。
在这里插入图片描述

深入排查

修复指令篡改

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

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

通过ldd指令查看topps使用的动态链接库,并对比其他机器上的相同内容,发现确实多了一个动态链接库/usr/local/lib/libextrasshd.so
在这里插入图片描述
环境变量LD_PRELOAD和默认配置文件/etc/ld.so.preload指定了预加载的动态链接库路径。一般情况下,Ubuntu系统中不存在该文件,但在该服务器中该文件存在且指定了/usr/local/lib/libextrasshd.so。该动态链接库在正常的系统里也是不应该存在的。
在这里插入图片描述

通过删除/etc/ld.so.preloadlibextrasshd.sotopps指令恢复正常,可以发现木马进程及其对资源的占用情况。

隐藏程序查找

除了手动清除指令篡改外,也有其他手段发现隐藏的程序,如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"

在这里插入图片描述

文章来源:https://blog.csdn.net/DLW__/article/details/135648683
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。