1 现象
显卡资源断断续续地被占用，nvidia-smi看不到历程号，指定gpu卡设备(nvidia-smi -i 0)能看到对应历程号：
曾经截图发现的历程：
历程中带有octopus、stratum关键字，以此作为历程线索。
2 排查过程
2.1 开启体系调用审计
因为只有历程的关键字，也不知道挖矿历程出现频率，而且挖矿时，/proc/目录下对应挖矿历程的可执行文件显示deleted，因此并不知道泉源是那里，所以先对体系调用开启审计，具体方式：
修改auditd的审计配置/etc/audit/auditd.conf，增长日志文件数量与日志巨细：- # 10M
- max_log_file = 10
- # 100个
- num_logs = 100
- auditctl -a always,exit -F arch=b64 -S execve -F key=virus
过一阵子，对审计日志进行观察，确实发现有木马相关历程的执行，并且也记录了所有执行的参数：
分析时间规律：- grep 'octopus' /var/log/audit/audit.log* | awk '{print $2}' | awk -F ':' '{print $1}' | awk -F '(' '{print $2}' |xargs -I{} date -d @{} +"%Y-%m-%d %H:%M:%S" | sort
时间大概是6-7分钟一次，但具体秒数具有随机性，大概是木马步伐故意为之，因此并没有直接去相关定时任务中查看异常。
不过此时没法定位泉源，只能确切地知道挖矿历程停止性出现，没有具体的现场，难以分析。
2.2 暂停历程
因为挖矿历程常常性断断续续出现，没法一直保留历程现场，因此方式是采用SIGSTOP信号，将历程设置为T状态，使得历程HUNG住而不退出，编写如下脚本catch-virus.sh：- #!/usr/bin/env bash
- while true;do
- ps aux|grep 'octopus' | grep -v grep | awk '{print $2}' | xargs kill -19 2>/dev/null
- if [ $? -eq 0 ]; then
- echo 'I catch the virus!!!!' && exit 0
- fi
- sleep 1
- done
2.3 历程隐藏处置惩罚
理论上来讲，上一步能在挖矿历程出现时，直接给抓取到历程，不让其退出。但是在实际后面过程中发现，服务器还是出现了挖矿现象，而上面暂停历程的方法并没有生效。
也就意味着，挖矿历程出现时，并没有在ps命令列表里出现，也就是出现了历程隐藏现象，隐藏历程一般会有两种方式：
1. ps命令被篡改
这种环境，如果体系命令本身不可信托，那么需要采用应急处置惩罚，安装busybox：apt install -y busybox，后续执行命令时，加busybox前缀，如busybox ps aux。
但实际上也没有抓到，因此并不是ps命令篡改。
2. 动态链接劫持
通过修改LD_PRELOAD环境变量或/etc/ld.so.preload文件，配置动态链接库，实现将其注入到目的历程中。
当前服务器上，查看/etc/ld.so.preload文件（已经重定名为.bak的新文件），确实有一条.so文件内容：
因此历程隐藏大概率是通过ld.so.preload文件中加载的动态链接库实现的，所以办理方式是将该文件移除或重定名：mv /etc/ld.so.preload /etc/ld.so.preload.bak。
2.4 再次暂停历程
此时再次执行catch-virus.sh，后面便成功抓到了，ps命令显示历程已经变成了T状态，现场得以保留，隐藏历程的本领被成功打破：
但实际上去查看历程相关信息的时间，也没得到很多有代价的东西，/proc对应历程目录下，只能看到当前目录是根目录/，当前可执行文件显示deleted。不过从/proc/历程号/ns目录下能看到，当前的namespace空间是宿主机的空间（由lsns -p 1查看得出），并非某个docker容器的namespace，这样至少能定位到是宿主机上的题目。
2.5 排查定时任务
既然历程隐藏的题目办理了，也定位到是宿主机的题目，而且之前也观察到挖矿历程有肯定的时间频率规律，那么接下来排查方向应该是关注宿主机的异常历程以及定时任务，这里先主要排查定时任务：
起首执行crontab -l，无有代价输出。
再去/etc/下的各种cron相关目录下查看相关任务：ls -ltr /etc/cron*
其中发现一个可疑的/etc/cron.d下，3月27号修改时间的defunct文件：
[img=100%,100%]https://www.cnblogs.com/../upload/image-CPKm.png[/img] 查看文件内容：
执行其中部分内容echo L3Jvb3QvLmNvbmZpZy9odG9wL2RlZnVuY3QK|base64 -d：
[img=100%,100%]https://www.cnblogs.com/../upload/image-AeMo.png[/img] 可以看到，实际上是去执行/root/.config/htop/defunct文件，也的确在该目录下发现该文件（已经重定名）：
该文件是个二进制文件，无法查看具体执行了什么，此时选择手动执行该文件，同时用strace追踪该文件启动时的体系调用过程：
strace -ff /root/.config/htop/defunct
查看文件内容，发现几处可疑：
1、访问/etc/ld.so.preload ：
2、新打开一个/tmp/下的临时文件，并将该文件描述符设置为1：
3、往该文件描述符1中写入一些看不懂的二进制数据：
4、将该文件权限设为755，并切换到根目录/，执行该文件，并显示为[kworker/00:0]，这是linux内核线程的表现形式：
5、删除该文件：
[img=100%,100%]https://www.cnblogs.com/../upload/image-tllF.png[/img] 很显然，该历程的作用其实就是启动一个名为[kworker/00:0]的历程，伪装成内核线程在宿主机上，并且使用ld.so.preload加载动态链接库，隐藏历程并加以进一步的伪装，以致于极其难以发现。从体系调用过程也能看出来，chdir与unlinkat就是步伐所在执行目录是根目录/，并且文件显示deleted的原因。
3 规复措施
已经定位到该历程名，刚好此时在宿主机上执ps auxfww发现如下历程关系：
可以看到[kworker/00:0]下有个python3的子历程，也即我们最初发现的挖矿历程。
因此，实际挖矿现象产生本质原因，就是[kworker/00:0]历程定期去fork一个python3的挖矿历程，只不过这个期限应该是在步伐内部随机在7分半钟左右。
因此只需要避免[kworker/00:0]这个伪装出来的历程再次产生就行了，从上面的泉源可以看到，实际上就是定时任务天天去执行/root/.config/htop/defunct文件，那么只需要先将已有的历程kill掉，并将/root/.config/htop/defunct重定名即可。
进一步清算，应该是删除/etc/ld.so.preload文件，以及其中的库文件/lib64/libnss.so，删除/etc/cron.d/defunct文件，删除/root/.config/htop/defunct文件，不过先可以观察几天再删。
此时也仍然需要在后台执行catch-virus.sh，并查看/var/log/audit/文件下的日志，看是否有挖矿历程的产生，以便验证是否生效，没有任何结果输出就说明木马步伐确实消散了。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
