奇安信攻防社区-刚跑的程序又被kill？服务器挖矿病毒解析与修复

刚跑的程序又被kill？服务器挖矿病毒解析与修复

疑惑不解，为什么刚提交的程序没跑几分钟就又又又又又被kill掉了？近期服务器中招了挖矿病毒。本文就对该病毒进行了分析，并附上一些解决方案，帮助遇到类似问题的读者进行修复。

0x00问题描述
========

疑惑不解，为什么刚提交的程序没跑几分钟就又又又又又被kill掉了？

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-2ea735fdb5070b4112c62f1a3b8e42f186ab4a6b.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-2ea735fdb5070b4112c62f1a3b8e42f186ab4a6b.png)

查看系统资源情况，发现CPU的内存被吃的很满，GPU中也有莫名奇妙名字的CUDA程序在运行。

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-083265a74605413dba59c12edc203563bb6a57a0.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-083265a74605413dba59c12edc203563bb6a57a0.png)

询问了一圈后发现该程序并不是我们自己人跑的，并且谁会使用htop作为CUDA程序的名字呢？于是我尝试kill掉这个进程，没过3分钟这个程序又自动恢复了。下意识，我发现这肯定是中了挖矿的病毒了。

最近有非常多的机器中招，然而这个病毒并不会吃太多的GPU显存资源（应该也是怕被发现），并且做的非常隐藏，所以许多同学没有注意到这个问题。

但是作为研究机构，这个程序跑在机器上就会导致测试性能出现波动，许多实验数据变得不可用，危害极大。遇到这种情况，我们绝不姑息，一定要把问题解决了，最好能揪出来始作俑者。

0x01问题查找
========

遇到这种情况，我们首先要排查问题所在。盯着htop命令并不能进行溯源，所以我打开了系统日志，如下所示：

`sudo vim /var/log/syslog`

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-83c6ac89a85c74baa9a2e896307c86a32664f3f0.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-83c6ac89a85c74baa9a2e896307c86a32664f3f0.png)

发现最近有非常多的root命令，通过pytorch的目录下跑有一个nano.backup的文件。这个现象说明，pytorch的用户被攻陷了，并且被植入了恶意代码在/.cache的隐藏目录下（还挺鸡贼，放到了隐藏文件夹）。

首先我们能看出来，root用户是自动运行的脚本，那就意味着他是写成了定时任务在服务器中，以我们的经验，那首先需要查看一下crontab。

`crontab -u root -e`

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-be982656a8ca5b57dd3a5a0362fbe7b856eae503.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-be982656a8ca5b57dd3a5a0362fbe7b856eae503.png)

**下面便解释一下crontab：**

简单来说，就是crontab用于执行定期的命令，这也就是为什么我们kill不掉挖矿程序的原因了。

之后我们根据crontab里面的命令进行追踪，发现该目录下确实被新建了htop目录：  
[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-8ba30032d553d33728a25ffcc1ec79bed872ab93.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-8ba30032d553d33728a25ffcc1ec79bed872ab93.png)

里面有非常多的新文件。后面我们就针对这些文件进行逐个解析。

0x02恶意攻击脚本解读
============

首先我们根据crontab的内容溯源nano.backup文件：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-9f49bef4df34a4d5b15dd85513a5d1f06ff60d82.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-9f49bef4df34a4d5b15dd85513a5d1f06ff60d82.png)

发现是一个bash文件，第二行为检查doos.pid文件是否存在，如果存在，则把该文件中的数据读出来赋值给pid变量，之后尝试关闭掉这个pid下面的已存在的进程（4行），之后进入htop目录并在后台运行run文件（9,10行）。

之后我们根据backup中的顺序，接着追溯doos.pid的内容：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-9b20aaad6a044760fbb2cc67fe0396c21d132c18.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-9b20aaad6a044760fbb2cc67fe0396c21d132c18.png)

发现只有一个int的数字，应该是进程号（发现和GPU中htop任务进程号一致）；  
之后我们进入/home/pytorch/.cache/htop目录查看run文件：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-3572839f644294332b9f79b8623889d37daaacdf.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-3572839f644294332b9f79b8623889d37daaacdf.png)

发现程序在后台运行了Xorg.log文件，并传入了htop参数（5行），并把当前进程的id写入doos.pid；

我们发现Xorg.log文件与htop文件是只读二进制文件，无法追溯到源码，但是我们也能根据系统的反馈猜测到其内容，后面我们进行展开。

此时我们还没有发现crontab是怎么被写入的，这些文件又是怎么被写入的？  
我们ll一下htop下的目录发现：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-93eeb5b28b9459e4ca2760269701640b54e946d3.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-93eeb5b28b9459e4ca2760269701640b54e946d3.png)

目录下的文件不只是pytorch这个用户所有，这些可执行文件来自另一个用户。我们打开Xorg.cfg：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-b1f31e6d8125a4a452530fdf0c52faa1cff77944.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-b1f31e6d8125a4a452530fdf0c52faa1cff77944.png)

发现4行是是写crontab的命令，8~17行是把具体内容写到nano.backup的。也就是说，黑客只需要把这个文件夹以及run文件、Xorg.log上传到受害者机器，然后执行一下这个Xorg.cfg即可以做到循环攻击。

此外，我们发现目录下存在logs文件夹，打开发现：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-cb32089a9c906e4c50a31c7a063f95d302ec2cec.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-cb32089a9c906e4c50a31c7a063f95d302ec2cec.png)

打开其中的一个log：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-328a7edc80045306acde4e4f24e2021edff08863.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-328a7edc80045306acde4e4f24e2021edff08863.png)

果然，乌鸦币映入眼帘，log里放出了黑客的钱包地址，放出来矿池的ip以及设备的一些信息等。

回过头看到配置文件里有一个config.ini：

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-2f9e62e9a034ce0988ef30fec023b7c6cb5e4dc7.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-2f9e62e9a034ce0988ef30fec023b7c6cb5e4dc7.png)

里面放入了攻击者的一些钱包等内容，那看来，前面的二进制文件：Xorg.log文件与htop文件具体内容就是读取这些配置文件（Xorg.log）然后传入挖矿cuda函数（htop）。

非常可恶了。

我使用`sudo tail -f /var/log/syslog`命令时刻监听系统日志，发现root每隔定期时间就会跑crobtab的任务。这也是为什么我们把进程kill掉后仍然会重启的原因。

0x03修复方案
========

为了解决这个病毒，我们要做几件事：

```php
1 修改用户的密码
2 删掉/.cache/htop里的代码
3 修改crontab定时命令，把定时任务清除
```

2中的删除我们不用多说，用root权限rm -rf就可以

3中需要调用crontab -u root -e 删除命令或者注释

[![](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-d527bfb98fba9832ef3dfe290a74fbb2a54c0d39.png)](https://shs3.b.qianxin.com/attack_forum/2022/02/attach-d527bfb98fba9832ef3dfe290a74fbb2a54c0d39.png)

大家如果遇到类似的问题，可以查阅我写的方法解决，希望大家的服务器都安全。这些挖矿程序是比较可恶的，会影响我们正常程序的运算时间，严重的话会吃很多内存显存，导致程序崩溃。

发表于 2022-03-02 09:49:48
阅读 ( 6115 )
分类：应急响应

刚跑的程序又被kill？服务器挖矿病毒解析与修复

0 条评论