盖茨木马入侵处理经历

 

今天早上在进行服务器巡检时,发现ps命令出现了比较诡异的进程.

开始怀疑命令被替换,于是执行stat命令,与正常服务器上的命令进行核对

Notice:这是处理后的截图,将原来的文件重命名了ps_bak

正常服务器
# stat /bin/ps File: `/bin/ps' Size: 87088 Blocks: 176 IO Block: 4096 regular file Device: fc01h/64513d Inode: 1183167 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-06-22 09:28:48.215933041 +0800 Modify: 2012-11-15 21:54:14.000000000 +0800 Change: 2017-02-28 16:11:53.275306524 +0800
异常服务器
# stat /bin/ps_bak 
  File: `/bin/ps_bak'
  Size: 1135000       Blocks: 2224       IO Block: 4096   regular file
Device: fc01h/64513d    Inode: 1183167     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-06-22 09:28:48.221003413 +0800
Modify: 2017-06-06 09:49:50.530887844 +0800
Change: 2017-06-23 09:14:44.717559139 +0800

根据ps命令中的路径,发现了3个被正常的文件,也根据文件显示的时间,初步判断被入侵时间为6月2号(竟然这么久了,监控系统还有很多的工作要做啊)

# cd /usr/bin/dpkgd/
# ls -lh
total 360K
-rwxr-xr-x 1 root root 143K Jun  2 02:58 lsof
-rwxr-xr-x 1 root root 126K Jun  2 02:58 netstat
-rwxr-xr-x 1 root root  86K Jun  2 02:58 ps

将剩余2个文件依次进行了stat检查,发现与ps命令如出一辙.

于是将3个文件分别mv,并将正常文件拷贝到了正常目录后执行,恢复正常.


再次执行ps命令,发现了一些看起来很奇怪的进程(只显示部分进程)

# ps axuf 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

root     12591  0.0  0.0 249496  3176 ?        Sl   Jun06   0:03 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
root     13130  0.0  0.0  74112   800 ?        Ssl  Jun06   6:51 /usr/bin/bsd-port/knerl
root     13135  0.0  0.0  11648   636 ?        Ssl  Jun06   0:15 /usr/bin/pythno
root     23074  0.0  0.2 145296  8208 ?        Sl   Jun19   0:30 ./agent

如图所示,knerl和pythno是什么东西?我只知道kernel和python.

Notice:agent是我用golang写的监控客户端

于是开始google,查询这到底是个什么东西.google甚至还好心的帮我查询/usr/bin/python,可惜我这次查的真不是python.

盖茨木马整体情况

此类Linux木马主要恶意特点是具备了后门程序,DDoS攻击的能力,并且会替换常用的系统文件进行伪装。
木马得名于其在变量函数的命名中,大量使用Gates这个单词。
从网上公开资料可以看出,盖茨木马主要针对中国地区的服务器进行DDoS攻击,有95
%的攻击目标都在中国,排名第二的是美国。
本段摘自http:
//www.freebuf.com/articles/system/117823.html

看样子基本可以确诊了,这就是文中提到的盖茨木马.

# file /usr/bin/pythno 
/usr/bin/pythno: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
# file /usr/bin/bsd-port/knerl
/usr/bin/bsd-port/knerl: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
# strings /usr/bin/pythno | less
...
11CAttackBase
13CPacketAttack
10CAttackUdp
10CAttackSyn
11CAttackIcmp
10CAttackDns
10CAttackAmp
10CAttackPrx
15CAttackCompress
...
nameserver
8.8.8.8
8.8.4.4
8CSubTask
9CCpuLimit
5CTask
7CConfig
13CInitResponse
11CBillStatus
15CCommonResponse
11CUpdateBill
12CUpdateGates
8CLoopCmd
9CShellCmd
...
211.91.88.129
211.138.180.2
218.104.78.2
202.102.199.68
202.175.3.3
202.175.3.8
202.112.144.30
61.233.9.9
...

先删除文件

# cd /usr/bin/bsd-port/
# ll
total 1116
-rwxr-xr-x 1 root root 1135000 Jun  6 09:49 knerl
-rwxr-xr-x 1 root root       5 Jun  6 09:49 knerl.conf
# mv * /tmp
# mv /usr/bin/pythno /tmp

但是很明显,这样处理绝对是扬扬止沸,于是在Google继续搜索如何清理该木马.

搜索到两位大神对该木马的分析,并对木马行为进行了整理:

1.关闭防火墙

2.伪装系统服务

3.伪装系统命令

4.定时自动启动

摘自http://blog.csdn.net/liukeforever/article/details/38560363

/usr/bin/.sshd                                      守护进程木马文件,首先应该被干掉
/usr/bin/bsd-port/getty                             主功能木马文件,直接删除
/bin/、/usr/bin/、/usr/sbin/ 下netstat、lsof、ps或ss    过滤功能木马文件,通过文件大小可判断
/tmp/lang                                              安装功能木马文件,直接删除
/etc/rc.local                                         自启动配置文件,清理掉里面的含有木马路径的
/etc/init.d/DbSecuritySpt                              自启动配置文件,直接删除
/etc/rc[1-5].d/S97DbSecuritySpt                        自启动配置文件,直接删除
/etc/rc[1-5].d/S99selinux                              自启动配置文件,直接删除
/etc/conf.n                                            木马残留文件直接删                                                  
/etc/cmd.n                                             木马残留脚本,直接删除
/usr/lib/libamplify.so                                 木马残留可执行文件直接删除
/usr/bin/bsd-port/conf.n                               木马残留文件直接删除
/tmp/*.lock
/tmp/moni.lod
/tmp/gates.lod

摘自http://www.youngroe.com/2016/08/25/Learning/Linux-malware-billgates-XORDDOS-analyze-first-time/

我现在遇到的木马行为与上面两位大神所描述的并未完全一致,但是两位大神给我提供了查杀思路.

检查系统服务,我的做法是用ls将信息输入到文件,再从一台正常的服务器上,将ls信息输入到文件,然后进行diff比对

# cd /etc/init.d/
# ls -lh > /tmp/err.log
# diff ok.log err.log 
1c1
< total 248K
---
> total 256K
39a40
> -rwxr-xr-x  1 root root   36 Jun  6 09:49 selinux
45a47
> -rwxr-xr-x  1 root root   53 Jun  6 09:49 VsystemsshMdt

可以看出,selinux和VsystemsshMdt是不同的两个文件.

Notice:selinux是内核启动的,不应该出现在这里,所以这个文件是在糊弄鬼.

# cat selinux 
#!/bin/bash
/usr/bin/bsd-port/knerl
# cat VsystemsshMdt 
#!/bin/bash
/usr/local/apache-activemq-5.9.0/bin/twd

what? 藏在activemq下?

这让我记起一件事,在大约半个月前,发现该服务器被入侵,经过检查之后,发现是activemq存在web弱口令并导致执行命令,但是上次只发现了挖矿机,难道这是上次事件的后续?(该事件只进行了简单记录,没有写博客,我会在稍后补上改事件的大致过程)

# cd /usr/local/apache-activemq-5.9.0/bin/
# ll -lh total 3.5M -rwxr-xr-x 1 501 games 22K Oct 15 2013 activemq -rwxr-xr-x 1 501 games 5.7K Oct 15 2013 activemq-admin -rw-r--r-- 1 501 games 16K Oct 15 2013 activemq.jar -rw-r--r-- 1 root root 69 Jun 6 09:49 conf.n -rwxr-xr-x 1 501 games 6.1K Oct 15 2013 diag -rwxr-xr-x 1 root root 5 Jun 6 09:49 idus.log drwxr-xr-x 2 root root 4.0K Mar 18 11:31 linux-x86-32 drwxr-xr-x 2 root root 4.0K Mar 18 11:31 linux-x86-64 drwxr-xr-x 2 root root 4.0K Mar 18 11:31 macosx -rw-r--r-- 1 root root 1.1M Jun 23 10:43 twd -rwxrwxrwx 1 root root 1.1M Jun 6 09:19 twd.bak -rwxr-xr-x 1 root root 1.1M Jun 6 09:49 twd.bak2 -rwxr-xr-x 1 root root 5 Jun 6 09:49 vga.conf -rwxr-xr-x 1 501 games 82K Oct 15 2013 wrapper.jar

很明显,多出来几个奇怪的文件conf.n  idus.log   twd  twd.bak  twd.bak2  vga.conf

Notice:twd这3个文件是上次处理时遗留下来的,并且twd是我touch的空文件,没有执行权限,但是现在看来已经不是空文件了

# rm -rf conf.n  idus.log   twd  twd.bak  twd.bak2  vga.conf
# rm -rf /etc/init.d/selinux /etc/init.d/VsystemsshMdt

删除掉这几个文件

Notice:关于定时任务,在crontab确实发现了异常的计划任务,但是被我顺手删除了,没有截图.

再次把正常服务器和异常服务器做diff比对

# cd /etc/rc.d/
# find . > /tmp/err.log
# diff ok.log err.log 
12a13
> ./rc4.d/S99selinux
13a15
> ./rc4.d/S97VsystemsshMdt
52a55
> ./rc5.d/S99selinux
53a57
> ./rc5.d/S97VsystemsshMdt
175a180
> ./rc1.d/S99selinux
176a182
> ./rc1.d/S97VsystemsshMdt
212a219
> ./rc3.d/S99selinux
213a221
> ./rc3.d/S97VsystemsshMdt
296a305
> ./rc2.d/S99selinux
297a307
> ./rc2.d/S97VsystemsshMdt

删除这几个文件

# ls rc[1-5].d/{S97VsystemsshMdt,S99selinux}
rc1.d/S97VsystemsshMdt  rc1.d/S99selinux  rc2.d/S97VsystemsshMdt  rc2.d/S99selinux  rc3.d/S97VsystemsshMdt  rc3.d/S99selinux  rc4.d/S97VsystemsshMdt  rc4.d/S99selinux  rc5.d/S97VsystemsshMdt  rc5.d/S99selinux
# rm -rf rc[1-5].d/{S97VsystemsshMdt,S99selinux}
# ls rc[1-5].d/{S97VsystemsshMdt,S99selinux}
ls: cannot access rc[1-5].d/S97VsystemsshMdt: No such file or directory
ls: cannot access rc[1-5].d/S99selinux: No such file or directory

好了,现在系统已经正常了...至少看起来正常了,如果还有问题,我将会写后续.

 

posted @ 2017-06-23 12:13  Redheat  阅读(1282)  评论(0编辑  收藏  举报