真实挖矿事件--CPU占用率无异常

前序

以往，当CPU占用到80%或者100%的时候，我们就很容易判定它是挖矿行为，但是挖矿也会与时俱进，伪装自己，当CPU占用很低，并且符合平常业务特征，这时候我们就得靠经验去分析了

挖矿事件告警

在客户现场发现设备告警有挖矿软件的外连行为

下载流量数据包进行分析，可以看到该请求具有明显的访问矿池的行为：

定位病毒所在位置

首先使用top查看CPU和Cpu(s)的占用率，发现时高时低，符合正常业务行为，并没有挖矿占用大量CPU的特征：

ps -ef 查看进程信息，可以看到有向恶意IP发送请求的进程，可以看到UID是git：

查看网络连接状态可以看到服务器连接多个恶意IP，进程都是同一个与git相关的，观察发现IP变动是动态的，同一个进程会向不同的恶意IP发送TCP连接：

根据挖矿程序的PID查看进程文件，可以看到名为gitlab-workhorse的可疑文件，该文件的名称被伪装成上级目录的名称：

通过溯源，发现gitlab-workhorse下的config.json配置文件中被写入了特殊的域名：pool.supportxmr.com:3333：

通过查询域名pool.supportxmr.com:3333，发现对应的是一个挖门罗币的矿池：

通过查看gitlab-workhorse文件的MD5值，发现该文件为恶意文件，属于CoinMiner木马家族。

使用kill -9 187659直接杀掉该进程，使用ls -al /proc/187659和netstat -antpl查看该进程是否会重启，观察半小时后发现不会自动重启进程：

查看是否开启定时任务

查看定时任务发现没有任何内容，这样杀掉恶意进程后，就不会自动重启进程：

溯源入口

有些挖矿程序无法定位到具体位置，但是找到入口也可以交差，毕竟现在很多环境都经过备份，将入口修复后攻击者也是无法再次利用的。

尝试查看Nginx日志发现只有今年2月到4月的保存日志[未做反向代理]，而error.log和access.log是0字节，而git日志只能保存一个月(11.18-至今)，排查后无结果，无法通过日志进行溯源分析。

经初步判断该挖矿程序可能是通过服务器上部署的gitlab的相关漏洞传入的，该gitlab在11月24日之前具有最新的漏洞CVE-2021-22205，而2021年10月28日gitlab远程命令执行漏洞(CVE-2021-22205)在野利用方法被公开。通过该漏洞可做到执行任意命令，反弹shell获取git的用户权限等危害操作。
基于本台服务器，可以做到反弹shell之后可以获得git的用户权限、对gitlab配置文件内容进行修改、对服务器植入挖矿病毒程序。

在态势感知平台发现2021-11-10 12:38:35有来自乌克兰的恶意IP 212.3.101.118对xxxx服务器进行漏洞利用，该恶意IP分别请求了GET /users/sign_in和POST /uploads/user，并且请求体中附带明显的伪造的恶意图片，符合CVE-2021-22205漏洞利用的特征，并且存在写入恶意文件的命令。

整改

(1). 更新Gitlab到最新版本
(2). 将Gitlab服务放入内网中，通过代理等方式访问

总结

大佬随手给个赞呗 0.0