应急响应案例：aliyun.one 挖矿木马

【背景】 服务器中了aliyun.one 挖矿木马

特点如下： 1、 crontab 中显示类似上面的任务，并且清理后又会出现。 2、 服务器负载高，CPU使用100%。存在fb972c73a8等数字的进程并且使得CPU100%

【原理分析】 为什么会删除不了crontab，原因是 /etc/ld.so.preload 被加载了木马so文件。

-rwxrwxrwx. 1 root root 26536 Apr 15 20:58 libevent_extrad.so

可以用如下命令进行核实并清理：

/etc/ld.so.preload #如果有只读保护，需要加 chattr –ia /etc/ld.so.preload 所以执行任何命令或者程序，都会加载libevent_extrad.so木马文件。

【木马源文件】

见附件

可以通过上面脚本分析执行的过程，从而找到清理该木马的方法 。

【清理】 注：以下操作如果删除不了或者修改不了 请执行 chattr –ia xx.xx 去掉只读属性。

一、 前置工作 上传busybox至主机 二、 清理免密登录 将机器authorized_keys、known_hosts文件命名为其他名字，重启sshd服务，与其他机器隔离，防止清理过程中被感染 三、 查看/etc/ld.so.preload中的内容，并利用busybox删除/usr/local/lib/下的动态链接库文件（文件名会变动）和/etc/ld.so.preload，删除恶意动态加载项

#./busybox cat /etc/ld.so.preload #./busybox rm /etc/ld.so.preload -f #./busybox touch /etc/ld.so.preload #./busybox rm /usr/local/lib/xxx-x.x.so -f

四、停止sshservice服务

systemctl kill sshservice

systemctl disable sshservice

五、busybox查看进程，杀掉挖矿进程和{00a022b712}进程（名称与此类似，字母加数字），并清理可能释放在下列路径中的恶意程序/usr/local/sbin（一般在此目录） 、/usr/bin/、/usr/libexec、/usr/local/bin/、/tmp/

./busybox rm /usr/local/sbin/fb972c73a8

./busybox killall -9 fb972c73a8

./busybox rm /usr/local/sbin/acpidets -f

./busybox killall -9 acpidets

六、清理/etc/bashrc文件末尾的恶意命令 七、清理/etc/cron和/var/spool/cron中的异常定时任务

grep -RE "(wget|curl)" /etc/cron*|grep "aliyun.one"|cut -f 1 -d :|xargs rm -rf

grep -RE "(wget|curl)" /var/spool/cron*|grep "aliyun.one"|cut -f 1 -d :|xargs rm –rf

八、清理/etc/rc.d/下的sshservice启动项

rm -f /etc/rc.d/init.d/sshservice

find /etc/rc.d -name "K01sshservice" -exec rm -f {} \;

find /etc/rc.d -name "S99sshservice" -exec rm -f {} \;

rm -f /etc/init.d/sshservice

rm -f /usr/lib/systemd/system/sshservice.service

rm -f /lib/systemd/system/sshservice.service

rm -f /etc/systemd/system/sshservice.service

九、清理/etc/hosts文件中被添加的信息 ------ 经过以上清理，可以把木马进行临时清理。由于没有清理干净或者漏洞，导致可能还会出现该木马，以及变异木马。 如果再次出现没有清理干净，原因: 某个进程已经加载了木马so，导致还会修改crontab任务 1、 开启audit审计功能，并加上标签方便后续进行分析。 # 安装 service start auditd yum install -y audit* # 启动 service enable auditd #监控 auditctl -w /var/spool/cron/root -pw -k marryhe #添加对cron文件的监控 auditctl –l # 核实配置是否生效。 cd /var/log/audit ; grep marryhe audit.log

ppid=1650 pid=5871 # 执行crontab的父进程，以及运行进程 comm=“crontab” exe="/usr/bin/crontab" #执行的命令 # 这样就可以监控是哪个进程对crontab进行修改。 2、如果是漏洞导致，下面溯源会进行分析。

二、mysql 数据库 数据库存在root启动，权限太高。

弱口令。

存在本地弱密码，但远程进行测试，发现此密码并不可以密码。

但用户root帐号是有远程登录的权限的。只是密码为另一个。具体需要用户自行核实该帐号的安全性。 三、redis 服务

1、Redis 使用root启动 2、空密码，直接对外 由于在8点49分已经把redis进行了删除，所以无法判断是否为此处进行入侵。该漏洞可以直接远程控制服务器，具体可以参考以下文章： https://blog.csdn.net/chenglanqi6606/article/details/100909518 四、nginx服务

Nginx日志非常少，并且没有发现可疑的请求。

并且未发现webshell相关的请求。

二、mysql 数据库 数据库存在root启动，权限太高。

弱口令。

存在本地弱密码，但远程进行测试，发现此密码并不可以密码。

但用户root帐号是有远程登录的权限的。只是密码为另一个。具体需要用户自行核实该帐号的安全性。 三、redis 服务

1、Redis 使用root启动 2、空密码，直接对外 由于在8点49分已经把redis进行了删除，所以无法判断是否为此处进行入侵。该漏洞可以直接远程控制服务器，具体可以参考以下文章： https://blog.csdn.net/chenglanqi6606/article/details/100909518 四、nginx服务

Nginx日志非常少，并且没有发现可疑的请求。

并且未发现webshell相关的请求。

【安全建议】 一、平台建议 1、安全组加固

目前的配置就像家里并没有上锁，所有人都可以进行出入。这样存在很大的安全隐患。 建议只开放需要的几个端口，如：

ssh 登录 tcp 22端口

nginx WEB服务器 tcp 80 或者 自定的端口

mysql 服务器 限制IP访问 3306

redis 服务 限制IP访问 6379

2、开启定期自动快照 二、数据库建议 1、定时进行数据备份 2、禁止数据库对外，如果一定需要，建议限制IP。 3、改为非root启动数据库 三、redis 建议 1、配置bind选项，限定可以连接Redis服务器的IP，修改 Redis 的默认端口6379 2、配置认证，也就是AUTH，设置密码，密码会以明文方式保存在Redis配置文件中 3、配置rename-command 配置项 “RENAME_CONFIG”，这样即使存在未授权访问，也能够给攻击者使用config 指令加大难度 四、web服务

禁止root启动。使用普通的帐号运行nginx。