biden1挖矿病毒处理经过

介绍

之前公司一台服务器出现CPU爆满，有个进程占满了CPU，杀了之后没过几分钟就又重启了，后来查出是中了biden1挖矿病毒。搜索引擎上的相关文章都看过了，但是依然没有成功处理，现在有时间了回头试着处理病毒竟然不到半天就摸索出来处理办法了，在此记录一下。

处理过程

1. 首先想，解决问题肯定是要从问题处入手，先找到病毒进程，再对这个进程进行作文章。

top

2. 从网上找到该命令用于查询关于进程的状态。虽然我英语不好，但依然可以从图中得知一些信息：

• Active:距今已经运行了1月18日了（要不是前段时间太忙，早来治你了(>_<）
• Process:进程是从/etc/rc.d/init.d/vm-agent处开始的
• CGroup:进程树，父进程为vm-agent，还有子进程wqiaps，以及他们的位置/usr/bin/（这个属性究竟叫不叫进程树我并不太确定，只是认为这个是树状图，并且是有上父下子节点相连的，所以才这么称呼，希望大佬批评指正）

systemctl status pid

3. 之后我在vm-agent上花了点儿时间，尚且无果后把重心放到了病毒文件本身。因为初次处理改病毒时已经得出了一些结论：

• 病毒被杀掉后会在几分钟内重新运行
• 把病毒杀掉后连同文件一起删掉后，会在几分钟后文件回复，并且病毒重新运行
• 将病毒反复拉起很可能是定时任务，但是经过漫长时间考证并没有找到定时任务相关的异常（很可能还是找的不够细，但是上次已经花很长时间了，暂时难以为突破口，所以暂且不从定时任务处解决此问题）

4. 尝试杀掉病毒进程后修改病毒文件权限。后续观察到病毒进程被拉起，文件权限被改回，文件创建日期并不是今天。

kill -9 pid
chmod 400 /usr/bin/biden1

5. 尝试杀掉病毒进程后将病毒文件内容置空。后续观察到病毒进程被拉起，文件被恢复，文件创建日期变成了今天。

kill -9 pid
>/usr/bin/biden1

6. 根据上面两步基本可以确认的是，当病毒文件无法执行时，某处会执行命令将病毒文件复制到此处并运行。
7. 得出这个结论后，我们只要把biden1置空，并且让它无法被删除，那么复制命令可能会无法执行。
8. 尝试杀掉病毒进程后，将病毒文件置空，并设置文件为不可被删除或修改。后续观察到病毒进程被拉起，但biden1文件并未恢复。

kill -9 pid
>/usr/bin/biden1
chattr +i /usr/bin/biden1

9. 文件并未像往常一样被恢复，说明已经快要成功了，再查病毒进程状态，发现病毒位置到了/tmp/下了，这时我想到到了它还有个子进程：wqiaps。

systemctl status pid

10. 尝试杀掉病毒进程以及其子进程wqiaps，将/tmp/下的病毒文件和/usr/bin/下的子进程文件置空，并设置为不可被修改。后续观察病毒文件不再被拉起，但是vm-agent经常会活跃一下，可能是在尝试唤起病毒文件吧，但至少是解决了这个烦人的病毒了。

kill -9 pid
kill -9 wqiaps-pid
>/tmp/biden1
chattr +i /tmp/biden1
>usr/bin/wqiaps
chattr +i usr/bin/wqiaps

步骤总结

1. 查询biden1的pid

top

2. 查询biden1的路径及其相关进程路径

systemctl status pid

3. 杀进程，将biden1文件置空，然后将该文件设置为不可更改

kill -9 pid
>/usr/bin/biden1
chattr +i usr/bin/biden1

4. 如果biden1再次被拉起，再次查询biden1的路径及其相关进程路径

systemctl status pid

5. 杀进程及其子进程，将新路径的biden1文件和其子进程文件置空，并将这两个文件设置为不可修改

kill -9 pid
//此处wqiaps为biden1的子进程
kill -9 wqiaps-pid
//此处/tmp/目录为biden1的新路径
>/tmp/biden1
chattr +i /tmp/biden1
>usr/bin/wqiaps
chattr +i usr/bin/wqiaps

6. 观察cpu运行情况，应该biden1已经不会再次拉起了

总结

虽然解决了问题，但是并不能从根源上灭除，拉起程序该执行还会执行，每次大概会耗费0.3%的CPU，所以处理办法也有改进的空间，不过目前来看优先阻止病毒占用CPU更为迫切一点，因为说不定哪天病毒发飙可能会无法登录服务器导致需要麻烦服务器工程师进行重启服务器。