|
首先，我在前一篇文章中已经拙陋的分析了下我方服务器中毒的大概经过和我的查处方式，这篇文章呢，继续送上处理病毒篇 为什么要获取busybox？这就是此次事件的特别之处，如果你使用top、ps等系统命令是看不到挖矿进程的，因为挖矿病毒修改了系统的动态链接库配置文件 /etc/ld.so.preload 内容并引用了 /usr/local/lib/libioset.so ，所以有些运维人员开始top、ps等未查找到异常进程是由于该病毒涉及到 Linux动态链接库预加载机制，是一种常用的进程隐藏方法，而系统的ls，ps等命令已被通过so库的preload机制被病毒劫持, ls会导致/etc/cron.d/root文件被刷写为病毒定时执行命令。 而busybox是静态编译的，不依赖于系统的动态链接库，从而不受 ld.so.preload 的劫持，能够正常操作文件。 根据这个我们可以很清楚的看到有两个用户kxadmin和root创建的两个进程 这两个进程一个是临时文件夹下的 总之经过一两分钟的观察我们可以确定的是 他们两个都不是啥 正常进程了 已经被感染了 然后，我就不信邪 天真的跑去 kill 进程 可是并没有卵用 一会儿他又会拉起来了，感觉病毒当时就是这个表情
那怎么办呢？幸好发现了前辈们已经有过讲解了，赶紧再去翻阅前辈们的文章，今天推荐的是这位的，分析很到位 大佬再文章中从专业角度出发，分析解剖了Watchdogs变种的kthrotlds病毒，总之呢就是有办法了，我就跟着大佬的脚步去试探，发现大佬说的那个病毒和我的中的不一样，但是可以得出结论他们的形式是一样的，下面我就着重分析一下 大佬文章里面有一段是描述这个病毒的特征把自己******进开机启动服务的，所以我们也去找找 这个脚本 我和大佬分析出来的kthrotlds病毒的脚本对比了一下 就是名字不一样，他叫kthrotlds，我这里叫 对于杀毒啊，我总结了一个小道理，一般病毒都更新的比较快，所以我们要参考去处理的时候，一定要选取时间最近的处理方式去着重参考，这样有利于我们快速解决问题 1、恶意进程我们已经通过刚刚的netdns找到了名字，他就叫做kpsmouseds 2、上面引用的大佬们在文章中已经指出，要去查看/usr/local/lib/libcset.so 所以我们也去这个目录找，发现，并没有这个文件，但是有且仅有一个libcmoused.so，我们一看这个文件的后半部分不就和我们1步找到变种文件的后半部分一样么，所以宁静而错杀也不放过，他就是嫌疑人了，
那么我联想到2月份有段时间 我服务器上的redis确实是有问题过，也是大概从那时候起 我们的服务器开始高负荷运转，所以只设置让其监听127.0.0.1就行。 先这样吧 如果有类似的问题 刚好你遇到，可以在底下评论 我可以给点小小的建议。 Watchdogs利用Redis实施大规模挖矿，常见数据库蠕虫如何破？ 背景 2月20日17时许，阿里云安全监测到一起大规模挖矿事件，判断为Watchdogs蠕虫导致，并在第一时间进行了... Watchdogs利用Redis实施大规模挖矿，常见数据库蠕虫如何破？ 背景 2月20日17时许，阿里云安全监测到一起大规模挖矿事件，判断为Watchdogs蠕虫导致，并在第一时间进行了... 周六告警一个接一个，感觉极不寻常 netstat -anpd执行结果如下 久违的中毒感觉，查看一下各用户下的cro... 背景 从昨日(20190221)中午起, 发现大量测试环境机器和一台线上机器疑似感染挖矿病毒(后来确认的确是门罗币... 技术支撑单位360企业安全集团安服团队发现：近日发生多起企业内网遭Linux WatchDogs 挖矿病毒感染事件... |
