应急响应—特洛伊挖矿木马事件排查

上一次算是最简单的挖矿环境排查，可以根据：CPU资源占用、进程占用、计划任务等方式进行排查，且删除木马后不会重生。

---

环境介绍

环境：特洛伊挖矿木马事件排查

本文基于大型项目安全运营中的真实事件：复现某设备感染挖矿恶意程序的完整排查过程。
（1）安全设备先触发告警，提示某设备存在对外挖矿连接行为，排查随即展开。
（2）通过top命令确认存在高占用可疑进程，但尝试kill命令终止时失败；进一步用lsof定位到挖矿文件后，即便以 root 权限执行删除操作，仍提示无权限。
（3）后续排查更发现多重反常现象：crontab中存在明显的挖矿文件重生逻辑，rm -rf仅对与挖矿文件关联的文件提示无权限，stat命令查看挖矿文件及相关释放文件时返回空值。
（4）基于上述异常，排查人员怀疑系统文件已被感染，遂提取sudo与wget文件上传至沙箱检测，最终确认这两个文件已被恶意程序感染，印证了此前的猜测。
（5）后面我们使用busybox清除木马以及更新被感染的可执行命令程序

本次环境中增加了一些互动元素，不再通过漏洞进入，而是以人为本，其次通过环境名：特洛伊挖矿木马，我们可知是存在"感染"的情况，一般这种都是人为下载破解或三方的程序导致的，这种程序我们称为捆绑程序。

===============================================

版权所有：solar应急响应团队、州弟学安全

环境下载地址

• 百度网盘：https://pan.baidu.com/s/1Zjghkg55-USdDiWKgnJ7Dw?pwd=zhou
• 环境地址-夸克网盘：https://pan.quark.cn/s/a2c2454a196c(夸克可能会屏蔽文件，存在文件丢失的情况，一般需要更新链接，这出自于他们的风控原因)

==============================================

题目描述：

角色: 你是一名初级安全工程师。
事件: 运维团队报告，公司的一台核心开发服务器（Ubuntu 22.04 LTS）出现CPU使用率异常飙高告警及安全设备检出外联挖矿事件。现在，你需要登录该服务器，排查并处置这一安全事件，并最终找出问题的根源。
- 账号：root
- 密码：P@ssw0rd

==============================================

1. 提交挖矿文件的绝对路径，最终以flag{/xxx/xxx}格式提交
2. 提交挖矿文件的外联的IP与端口，最终以flag{ip:port}格式提交
3. 停止挖矿进程并尝试删除挖矿程序，根据异常判断，提交守护进程脚本的绝对路径，最终以flag{/xxx/xxx/xxx/xxx}提交
4. 根据出现的异常及守护进程脚本，继续排查，以人为本，使用环境内浏览器访问：http://chat.internal-dev.net:8081 获取可疑网址，最终以flag{http://www.example.com}格式提交
5. 分析病毒文件，提交其感染的所有程序，最终以flag{md5(/usr/bin/whoai,/usr/bin/ls,/usr/bin/top)}进行提交，顺序需以病毒文件中为准
6. 修复系统并恢复文件完整性：已知所有程序被感染，当前系统属于断网状态，所以作者贴心的在/deb_final目录下存放了对应程序的deb包，请尝试恢复所有程序，恢复完毕后在/var/flag/1文件获取flag
7. 最终清理：删除挖矿程序、删除计划任务及守护进程及清除相关进程，等待片刻在/var/flag/2获取flag

1. 提交挖矿文件的绝对路径，最终以flag{/xxx/xxx}格式提交

首先我们登录靶机后，显示文件（再次**免责声明**）

话不多说，我们根据题目“挖矿”字样，所以首先想到通过top，ps -ef等命令去排查可疑程序：
这里我们首先使用top 命令，发现返回结果为空：

正常情况下这是不应该的，常见于如下两种情况：

1. top命令被篡改
2. top命令被劫持

所以我们通过alias命令去查看，发现了异常：

被攻击者修改为输出 空 ，删除后再次通过top进行查看：

# 命令执行
unalias top
top # 再次查看

很明显我们发现kworkerds存在异常情况，那么我们如何得到它的路径呢？

方法一：

这里我是通过find命令去寻找：

find / -name kworkerds 2>/dev/null

最后得到结果为在 /tmp/kworkerds 目录下：

方法二：

根据top得到的结果，我们可以知道kworkerds的PID，然后通过ps，lsof等得到详细的信息：

top |head -n 5 # 显示前五条信息
ps -ef|grep 364 # 因为进程的PID为364

最后得到结果为在 /tmp/kworkerds 目录下；

可以通过strings kworkerds看一下挖矿文件大概包含哪些东西

分析 PID 文件 /tmp/kworkerds.pid：
作用：PID 文件（Process ID File）的作用是存储当前正在运行的进程的 ID。

• 对于正常服务： 守护进程启动时将自己的 PID 写入此文件。如果服务需要停止，它的停止脚本会读取这个文件，获取 PID，然后使用 kill 命令停止该进程。

• 对于挖矿程序：它可以用来防止重复启动（如果文件已存在，则不启动）。它更有可能被它的守护进程/脚本用来监控和重启。

所以本题的flag为：flag{/tmp/kworkerds}

–

2. 提交挖矿文件的外联的IP与端口，最终以flag{ip:port}格式提交

（官方WP解释）挖矿除了高占用服务器资源外，还会对矿池进行外联行为，这里提出两个思路：

1. 使用Wireshark抓取网卡流量，但是缺点可能在纷繁的流量中很难定位到恶意IP
2. 使用ss命令定位指定文件对外连接的情况，但是前提应该知道这个文件名

方法一：流量抓取

这里我用Wireshark抓取靶机的流量，通过“筛选”按钮，也是得到了可疑IP地址：

（别说我没告诉你方法，饭都喂嘴里了）

然后筛选，查看详情：

# 目标IP为：
ip.dst==104.21.6.99

–

方法二：使用ZUI工具

在这篇文章中，我就使用过工具：

count() by id.orig_h,id.orig_p|sort -r count # 查看源IP和端口
count() by id.resp_h,id.resp_p|sort -r count # 查看目标IP和端口

count() by 表示计数，id.orig_h表示源地址，status_code表示状态码，|表示条件分隔

也是同样能够得到结果；

–

方法三：使用ss命令

使用命令ss -tupan|grep "kworkerds"进行查询：

得到结果都是一样的；

所以本题的flag为：flag{104.21.6.99:10235}

–

3. 停止挖矿进程并尝试删除挖矿程序，根据异常判断，提交守护进程脚本的绝对路径，最终以flag{/xxx/xxx/xxx/xxx}提交

正常情况下定位到挖矿文件路径和进程后执行kill -9 pid和rm -rf file：

kill -9 364
rm -rf kworkerds
top

但是没过一会，好像又重启了：

这说明本机可能存在命令被感染的情况，这里推荐使用busybox工具清除挖矿程序和进程

busybox kill -9 17414
busybox rm -rf /tmp/kworkerds

但是经过等待一分钟后再次验证发现，进程和文件又存活了，于是猜测是否有权限维持的情况，比如计划任务cron
可疑使用命令去查看定时任务：

cat /etc/crontab
crontab -l

虽然没有发现什么东西，但是还有/etc/cron.xxx目录，还可以进一步查看：

还可以使用命令ls -l /etc/cron.*去查看详细的内容，对照了一下，发现了可疑目录：

依次查看文件，在/etc/cron.d/0guardian文件发现可疑

进一步去查看详细内容：cat /usr/bin/.0guardian

此脚本意为每次执行都会触发一次stat命令，这里就比较疑惑了，看似这个脚本很正常，但是从命名和之前遇到的rm命令异常现象和kill后重生，说明stat是否会如同他们一样，被感染了？这也符合特洛伊木马的感染特征。

官方WP思路：

不妨大胆假设：恶意程序或攻击者->感染程序->埋藏脚本(看似正常)->植入计划任务->释放挖矿，即使使用busybox删除且不再操作本机命令以后，计划任务也可以通过看似正常的脚本去触发被感染的系统命令造成挖矿的"重生"。

最终flag：flag{/usr/bin/.0guardian}

4. 根据出现的异常及守护进程脚本，继续排查，获取可疑网址，最终以flag{http://www.example.com}格式提交

这里我们访问靶机地址的8081端口，得到如下对话：

经过排查/home/op/restart_app.sh没有问题，内容如下：

root@solar-abc:/root# cat /home/op/restart_app.sh
#!/bin/bash# ==============================================================================
# Standard Application Restart Script
#
# @Description: This script handles the graceful stop and start of the main
#               application service.
# @Author:      Standard Operations Team
# @Version:     1.2
# ==============================================================================APP_NAME="core-business-app"
PID_FILE="/var/run/${APP_NAME}.pid"echo "Attempting to restart the ${APP_NAME} service..."# --- Stop Service ---
if [ -f "$PID_FILE" ]; thenPID=$(cat "$PID_FILE")if kill -0 "$PID" > /dev/null 2>&1; thenecho "Stopping ${APP_NAME} (PID: ${PID})..."kill -15 "$PID"sleep 2if kill -0 "$PID" > /dev/null 2>&1; thenecho "Service did not stop gracefully. Sending SIGKILL..."kill -9 "$PID"firm -f "$PID_FILE"echo "Service stopped."elseecho "PID file found, but no running process with PID ${PID}. Cleaning up stale PID file."rm -f "$PID_FILE"fi
elseecho "Service not running (PID file not found)."
fi# --- Start Service ---
echo "Starting ${APP_NAME} service..."
# In a real scenario, the following line would execute the application binary.
# For this simulation, we just echo a success message.
# /usr/local/bin/core_app --config /etc/app/config.json &
echo "Service ${APP_NAME} started successfully."exit 0

既然如此，我们就访问www.superlog-pro.com网址看看：

看着没有问题，将程序逆向一下，果然发现了异常：

这不是之前出现过的目录文件吗？所以很明显，这就是我们要的结果：

flag{http://www.superlog-pro.com}

–

5. 分析病毒文件，提交其感染的所有程序，最终以flag{md5(/usr/bin/whoai,/usr/bin/ls,/usr/bin/top)}进行提交，顺序需以病毒文件中为准

（以下均为官方WP，因为逆向我还暂时没学）
这里需要使用IDA进行逆向分析，来了解此程序的运行逻辑；

使用xshell或者命令行等方法将此程序下载到本机PC后，进行逆向分析：

（1）使用die查看到程序没有加壳，而且是C语言编写的

（2）使用IDA打开，找到main，这是C语言的入口点，双击main后，会跳转到对应视图并高亮

（3）第八行先获取自身的文件名

如上图所示，14行的sub_1670为感染程序的函数，unk_4040为挖矿程序(kworkerds)

sub_1670视角：

其中的24行取出了off_3CA8(指定文件列表)，给到V4，然后V5取出第一个，比如ls程序，然后递归循环进行感染双击off_3CA8，下图证明所有指定的感染文件：

再往下看：

1. write(v11, &unk_7900, v3): 写入内嵌的 wrapper_elf。
2. write(v12, v10, v15): 写入刚才从原始文件中读到内存里的内容。
3. write(v12, a1, n): 写入内嵌的矿工程序。
4. write(v12, v17, 0x18uLL): 写入最后包含元数据的 ChimeraMeta 结构体 (24字节)。

总体来说，此逻辑不是寄生，而是将需要感染的文件先提取出来，然后连带恶意挖矿程序及判断逻辑一并写入到新文件。

sub_18F0视角：

双击进去第二个函数，看运行逻辑


很明显，这是创建的守护进程和计划任务，因为前面逻辑看到了，stat也被感染了

看最后41行的remove会根据前面获取到的文件名进行自删除

分析完毕，所以最终本题的flag为：flag{md5(/bin/ls,/bin/ps,/bin/cat,/bin/rm,/bin/ss,/usr/bin/stat,/usr/bin/top,/usr/bin/wget,/usr/bin/curl,/usr/bin/vi,/usr/bin/sudo)}

flag{dac48e98a53b81b0218e2156e364f7ba}

–

6.修复系统并恢复文件完整性

修复系统并恢复文件完整性：已知所有程序被感染，当前系统属于断网状态，所以作者贴心的在/deb_final目录下存放了对应程序的deb包，请尝试恢复所有程序，恢复完毕后在/var/flag/1文件获取flag

更新命令为：dpkg -i --force-overwrite *.deb

在重新安装对应的包后，此时所有的被感染命令将恢复成功：

获取到flag：flag{e510c5fca680b1b4bd5c9d8d6b3f4bdc}

–

7.最终清理

删除挖矿程序、删除计划任务及守护进程及清除相关进程，等待片刻在/var/flag/2获取flag

这时候可以测试之前遇到的rm -rf /tmp/kworkerds出现的权限不足的问题和是否会存在重生的问题
（1）删除挖矿文件rm -rf /tmp/k*
（2）停止挖矿进程：kill -9 PID
（3）删除守护进程脚本和计划任务：rm -rf /usr/bin/.0guardian 和 rm -rf /etc/cron.d/0guardian

思路复盘

1. 小王在9.22日访问super-log非官方网站下载setup安装包
2. 执行setup安装包后，感染指定的常用可执行命令并释放挖矿，且释放计划任务和守护进程计划任务和守护进程的目的是为了防止用户使用busybox工具删除程序后，不在执行其它命令，而每分钟执行一次计划任务，调用stat可以造成"不死进程"
3. setup执行完毕后自删除，防止溯源逆向，且由于多重机制，沙箱无法给出结果以及告警