背景
最近师兄找到我,说他的服务器似乎被挂了挖矿木马,cpu占用率居高不下,网站(个人博客)也看起来像是被挂马了,这篇博客打算详细记录一下这次和挖矿木马斗争的过程
现象
首先是某云服务器控制台给出了性能受限警告
分析:师兄的服务器看起来貌似就只挂了个网站,一个mysql数据库,不至于遇到性能受限的情况,因此CPU持续的被占用这么高的情况,十有八九中了挖矿木马
然后是网站(个人博客)无法访问
分析:这张图片看起来像阿里cdn禁止访问的图片,因此分析应该是套了一层cdn,禁止直接使用ip访问,后期经过验证,果然如此,使用域名是可以访问的,但是出现了css样式加载不出来的问题,我猜大概率是因为https证书过期了,一些内容无法经过cdn加载出来,希望师兄尽快去处理一下
进一步分析
经过上面的分析,网站挂马应该是不存在的,不过也不排除是网站漏洞导致反弹了shell,从而被挂上木马的(建议师兄仔细看一下后台有没有鉴权或者未授权访问漏洞以及远程代码执行漏洞,尤其是文件上传的接口部分,更要仔细排查),为什么我会得出这样的结论呢?因为我把他的网站源码down了下来,使用某web扫描引擎,扫描了一遍,结论是没有发现明显的木马,我自己也大概的扫了一下,确实是没有明显的跳转到其他链接和其他比较明显的木马文件之类的。所以,接下来就只剩这个疑似中了挖矿木马的情况了
破局
定位木马
首先使用top
命令,查看一下当前的CPU占用情况
可以看到aLZmFuXY
这个进程一直在占用着CPU的资源,很明显就是罪魁祸首
于是尝试,全局搜索一下看看,执行
1 | find / -iname aLZmFuXY |
好吧,看来不是这么明显的,什么都没有搜到
然后,尝试直接kill掉这个进程试试,先执行
1 | ps -ef | grep aLZmFuXY |
定位到进程,然后执行
1 | kill -9 6283 |
尝试杀掉进程,没想到,直接断开了ssh
连接,看来这个木马还有点顽固,猜想肯定有某种重启或者定时执行的机制
于是,重新蓝(连)上ssh
,再次查看CPU使用情况
果不其然,它(aLZmFuXY
)又回来(自动启动)了
现在我们尝试去搞懂木马
的启动机制,经过上面的分析和实验,我们可以知道,这个挖矿的木马程序
应该是有自启动和重启机制的,于是,我们可以从这里入手,使用
1 | crontab -l |
查看所有的定时任务,发现只有一个/root/.systemd-service.sh
,那铁定就是它在捣鬼,等等,好像有什么细节被我们忽略了???想不起来,先放一下(其实是在top
命令的执行结果那里,捣蛋鬼systemd
总是和我们的木马进程aLZmFuXY
一起出现的)
现在我们来看一下,这个捣蛋鬼脚本到底写了什么,执行
1 | cat /root/.systemd-service.sh |
发现是一堆base64
编码之后的脚本,我们尝试解码看看
1 | nP8byPUGOwKjVfPZZsp5octdXHTWGyPqgVeY82zV1de6AY0ydAtgEGmo+JaumEfV |
好了,有了源代码的佐证,现在我们终于可以确定,这个捣蛋鬼就是一个活生生的挖矿木马,别问我怎么确定的(tor2web都出来了,这还不够明显吗???)
附上源文件:
1 | #!/bin/bash |
现在我们来仔细分析一下/root/.systemd-service.sh
这个文件的内容(当然是解码之后的内容啦,没解码谁看得懂。。。),不过,要说声抱歉的是,shell
我也不懂,就看懂个大概吧(大佬勿喷),大概就是监测挖矿进程是否在线,在线就一直连接socket,一直挖,一直挖,不在线就利用守护进程去启动它,然后还是一直挖,一直挖,一直挖。。。着实有点过分,怪不得那么吃资源,这简直丧心病狂。不得不提的是,脚本中有一个目录很值得我们注意一下,就是/tmp/.X11-unix/
,这个就是挖矿进程和守护进程所在的地方,我们去看一下,执行
1 | ls -la /tmp/.X11-unix/ |
可以看到,有三个文件,查看这三个文件(01、11、22
)的内容可以看到是几个数字,功能如下:
01
文件存放木马守护进程pid
11
文件存放木马运行进程pid
22
为一个空文件,功能暂时不清楚
分析就到这里了,下面是解决木马篇
干掉木马
为了防止分析过程有所疏忽,有必要再次进行一下全局搜索,执行
1 | find / -iname systemd-service.sh |
果然,我们有所遗漏,/opt/systemd-service.sh
这就是我们之前没有发现的,现在我们来看一下它又是什么,执行
1 | cat /opt/systemd-service.sh |
好吧,又是一个base64
编码之后的东西,看起来,套路都一样呢?惊得我直呼一声好家伙
源文件:
1 | #!/bin/bash |
解码之后:
1 | nP8byPUGOwKjVfPZZsp5octdXHTWGyPqgVeY82zV1de6AY0ydAtgEGmo+JaumEfV |
好家伙,不看不知道,一看下一跳,跟之前那个文件一模一样,吓得我又不由自主的说了一句,好家伙
这里补充一点分析:之前我们只是用crontab -l
,查看了定时任务,并没有找到定时任务的配置文件,而经验告诉我们,crontab
的配置文件,通常在/etc/cron.d/
下,还有,如果是root
用户,在/var/spool/cron/crontabs/root
文件中,于是我们分别执行
1 | ls -la /etc/cron.d/ |
果然,看到了熟悉的0systemd-service
我们来看一下,它的内容,执行
1 | cat /etc/cron.d/0systemd-service |
可以清晰的看到,它在定时的启动挖矿程序
好了,分析真的就到这里为止了,下面是解决木马篇
彻底干掉木马
分析了一大堆,最关键的文件是:
1 | /etc/cron.d/0systemd-service |
删掉这几个文件,然后停掉挖矿进程即可
1 | cat /tmp/.X11-unix/01 |xargs kill -9 && cat /tmp/.X11-unix/11 |xargs kill -9 && rm -rf /etc/cron.d/0systemd-service && rm -rf /opt/systemd-service.sh && rm -rf /root/.systemd-service.sh && rm -rf /var/spool/cron/crontabs/root |
重启,验证
1 | reboot now |
后续
根据经验,我们可以知道,挖矿木马,通常还会修改我们的know_hosts
文件和hosts
文件,所以我们去验证一下,执行
1 | cat .ssh/known_hosts |
可以看到,果然写了一个公钥到know_hosts
文件
可以执行,echo > .ssh/known_hosts
,修复它
我们在看一下hosts
文件,执行
1 | cat /etc/hosts |
看起来并没有修改
当然,也可以利用木马的特征,故意的制造一些混淆文件,防止再次感染,当然,也不是绝对有效的,安全与反安全,从来就没有高低之分,有的只是技术人员的能力差别而已
附上防止再次感染的命令
1 | mkdir /etc/cron.d/0systemd-service && chmod 000 /etc/cron.d/0systemd-service && chattr -i /etc/cron.d/0systemd-service && |
总结:解决挖矿木马,并防止感染,只需要两步:
-
1
cat /tmp/.X11-unix/01 |xargs kill -9 && cat /tmp/.X11-unix/11 |xargs kill -9 && rm -rf /etc/cron.d/0systemd-service && rm -rf /opt/systemd-service.sh && rm -rf /root/.systemd-service.sh && rm -rf /var/spool/cron/crontabs/root
-
1
2
3
4mkdir /etc/cron.d/0systemd-service && chmod 000 /etc/cron.d/0systemd-service && chattr -i /etc/cron.d/0systemd-service &&
mkdir /opt/systemd-service.sh && chmod 000 /opt/systemd-service.sh && chattr -i /opt/systemd-service.sh &&
mkdir /root/.systemd-service.sh && chmod 000 /root/.systemd-service.sh && chattr -i /root/.systemd-service.sh &&
mkdir /var/spool/cron/crontabs/root && chmod 000 /var/spool/cron/crontabs/root && chattr -i /var/spool/cron/crontabs/root
本文完。。。看到这里,也说明你很有毅力和探索欲,如果觉得我写的还不错,请打赏支持我,毕竟创作不易,谢谢大家