道高一尺,魔高一丈:服务器挖矿木马追查

这件事说来有点不可思议,作为管理员我很惭愧。经过这么长时间与来路不明的黑客的斗法,着实让我深刻体会到了无缝不入的黑客手段能有多危险,如果黑客没有盯着你,只是因为你暂时没有被黑的价值,而不是因为他做不到。

因为此前发见过小规模的挖矿木马,当时在一些服务器上发现有名为./htral的进程,占用400%的CPU资源。当时我们重新整理了iptables的规则,对所有的外网访问都做了严格控制,只有指定的IP才能访问特定的端口。这之后就一直比较太平,没有多少问题反馈,加上自身任务繁忙,对机房的管理比较疏忽,直到最近发现了新的情况。

#东窗事发

前些天发现机房的温度过高,精窖空调发出了高温警报,查看空调的温度历史,发现晚上12点之后到早上7点之间,机房的温度都会异常得升高。按照常理,到了晚上没什么人做实验,机器的负载应该会低一些才对。由于之前出现过挖矿木马的情况,于是我第一时间就往这方面猜想了。

我回想起之前有人向我反馈,晚上运行的程序计算很慢,或者服务器上出现了一个[watchdog]进程。由于都是在晚上,而且也不是每次都在特定的服务器上出现,排查比较困难;当时认为[watchdog]进程是系统进程,在执行系统定期任务等(后来反应过来后才发现,这都是木马进程)。联想到此前的这些情况,加上上次遇到这[migration]进程的事件后,我猜意识到出问题了。(http://fatalfault.com/2015/12/09/bitcome-miner-process-record/)

#寻根溯源
由于白天都一切正常,晚上回到寝室在服务器上一个个查看。之前的经验告诉我,遍历每台服务器,输出top信息,应该会看到占用大量CPU资源的可疑root进程存在,使用循环脚本

1
for i in {1..10}; do echo server$i=======================; ssh server$i "top -bn1 | head -n 15"; echo; done

输出每台服务器的系统和进程信息,但是出乎意料的是,输出的信息显示系统就是限制的,没有任何占用CPU的进程,样例输出如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
top - 22:19:57 up 137 days,  6:49,  1 user,  load average: 13.63, 16.04, 12.41             
Tasks: 738 total, 1 running, 737 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.1%us, 4.9%sy, 0.0%ni, 93.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65949776k total, 17388120k used, 48561656k free, 289180k buffers
Swap: 8388600k total, 0k used, 8388600k free, 7292560k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3370 root 20 0 164m 3132 1104 S 5.6 0.0 8089:33 /opt/paratera/paramon/sbin/pcn
3734 root 20 0 130m 2476 972 S 3.3 0.0 5023:56 /opt/paratera/paramon/sbin/pcn
6252 root 20 0 15612 1788 960 R 1.0 0.0 0:00.16 top -c
3122 root 39 19 0 0 0 S 0.3 0.0 731:52.46 [kipmi0]
3437 root 20 0 78784 10m 1292 S 0.3 0.0 492:42.65 /opt/lampp/bin/python /opt/DCA
17187 hadoopcj 20 0 3461m 432m 17m S 0.3 0.7 0:34.85 /home/hadoopcj/java/jdk1.8.0_6
17478 hadoopcj 20 0 3663m 478m 17m S 0.3 0.7 3:53.25 /home/hadoopcj/java/jdk1.8.0_6
1 root 20 0 21488 1496 1188 S 0.0 0.0 0:02.30 /sbin/init

经验富足的人会发现上面输出信息中的端倪。所以经验不足的我一开始并没有看出什么问题。看到服务器都是空闲的,我想到经前的经历(http://fatalfault.com/2015/12/09/bitcome-miner-process-record/),挖矿进程会在识别到用户登录后的若干秒后自动退出进程,但那毕竟有一定的时延,用上面的命令应该可以捕捉到进程信息。我以为扑了个空。第二天去机房查看温度监控,发现前天晚上11点~次日早上7点之间温度依然升高了不少。

#初现端倪
由于没有健全的运维系统,一切都只能动手和动脑人肉检查,一时间我陷入了困境。好在下午的时候有了亮点重要的发现:

  • 几乎所有服务器上有存在crontab记录异常;
  • 购买的在线运维服务的技术人员建议我用他们的工具监控;

crontab异常

之前使用crontab -l检查服务器的crontab记录,看到的都是正常的。偶尔使用了crontab -e参数,看到了系统下/var/spool/cron/root的真正内容为如下:
crontab异常

上面的文件内容明显不是一个正常的crontab文件,前两行的内容中有非打印字符。而且因为语法不对,前两行没有被正常解析,导致使用crontab -l看到的结果是第三行的内容,才使得之前都没有发现端倪。在确定了这些内容不是我们自己人添加的后,认定这是攻击者添加的记录。并且之后我有了更多可以佐证这一点的证据:

  1. 执行/usr/bin/systemc文件后,系统上会启动一个进程名为[watchdog]的进程;
  2. 启动[watchdog]进程的时间和杀死该进程的时间与机房空调的温度抖动时间吻合;
  3. 新建一个到该服务的ssh登陆,[watchdog]进程立刻就会结束,行为与前面观察到的一样;
  4. 另外,反复执行/usr/bin/systemc程序或者将系统时间调整到21:58,等系统时间到达22:00后,服务器上出现[watchdog]进程;

虽然添加了内容,但是这两条记录并没有生效,只是留下了蛛丝马迹。推测攻击者当时是想,在crontab中添加定时任务,在晚上10点和早上7点之间执行木马程序。但是失误导致crontab文件中有非打印字符。之后攻击者采用了其他方案。

检查/var/spool/cron/root文件最后被修改的时间:
crontab修改时间

并且推测,上面三行记录,前两行的添加时间是要早于最后一行的。因为初始的时候才会显示,系统中没有任何crontab记录的时候,才会提示没有任何root用户的记录。

##实时监控
服务器上的系统时间比我们PC上的时间晚20分钟,大约在晚上21:40的时候,我开始在监控软件上看到服务器上陆续出现了很多[watchdog]进程,特征也与前面观察到的相同。借助监控工具,终于直接观察到了木马进程的真实面目和感染规模。