一、背景
某天客户运维工程师接运营商通知，指出属于公司的IP地址182.XXX.X5.XXX存在僵尸木马情况，要求进行及时处理，建议进行杀毒，整改加固消除安全风险，如果持续出现恶意Gong Ji 行为，运营商有权进行关停处理，且在指定日期前反馈处理结果。
收到通知后，鉴于事件结果可能导致的结果的严重性，立即开始根据预定的应急响应流程处置。这里记录一下我们的分析排查流程。
二、信息收集与处置思路
经过与运营商沟通，其提供的信息也是其上级单位提供，未提供该事件的具体时间、具体特征，该事件是否当前还在持续等信息。经过对该IP地址的分析，该IP对应的内网主机为公司私有云上虚拟机的弹性IP，我们在前期梳理无用资产的时候已经发现此主机由之前开通用于测试，并且在7月1日已经做了关闭处理。因此经过讨论，我们决定从该IP出发进行分析定位，分析相关联的设备的日志，同时也对内网所有的办公电脑进行杀毒。
三、排查过程
1、该IP分配情况检查。经分析该虚拟机在7月1日关停后，该公网IP未再次分配给其他的虚拟机使用，也就是说该事件的产生应该是在7月1日关停之前。
2、安全设备日志分析。确认了大致的时间范围后，我们对该流量路径上的安全设备进行关联分析，该路径上依次有IPS、防火墙，防火墙部署在出口处。首先分析防火墙中的安全日志，在防火墙上距离7月1日前半个月的安全日志未发现异常行为。再分析IPS发现在6月下旬开始至7月1日上午均存在安全告警，并且动作是阻断，其中一个截图如下：
可以看到该IP持续不断的向多个位于香港的公网IP的80端口发起大量的请求。并且可以看到在该虚拟机关机后再无相关的事件产生。
3、失陷主机分析。经过前面的分析可以确认是由于该测试虚拟机被攻陷，并且被植入了挖矿病毒，该主机在向公网上的矿池服务进行通信连接。我们将该虚拟机的公网及内网网络连接全部断开，开机后通过控制台登陆，通过手工进行排查。
（1）、查看主机CPU、内存等的使用情况。经过查看未发现明显异常，无CPU、内存使用明显较高的进程。命令如下：
通过进程查看：
# ps -aux | sort -nr -k 3 | less | awk '{print $1,$2,$3,$NF}' | head -20
查看实时情况：top
（2）、环境变更查看。经过查看未发现有异常的环境变更被添加。命令如下：
echo $PATH
（3）、检查异常端口。虚拟机已经断开网络连接，无法对外发起网络连接请求，可以查看是否有主动监听的端口，经过查看未发现异常的监听端口，如下：
netstat -antlp
（4）、查看/etc/passwd、/etc/shadow文件账户情况，关注是否存在除了root以外的超级用户、可以登陆的用户（/bin/bash结尾），注意是否有名字异常、空口令且可登录用户及不常见的用户名。经过查看未发现有异常的信息，相关命令如下：
cat /etc/passwd
cat /etc/shadow
cat /etc/passwd | egrep -v '^root' | awk -F: '{if($3==0) print $1}'
cat /etc/passwd | grep -E '/bin/bash$'
（5）、检查定时任务。经过查看未发现异常的定时任务，命令如下：
cat /etc/crontab
crontab –l
（6）、检查已知SSH登录主机。经过查看仍然没有发现异常的信息，命令如下：
cat ~/.ssh/known_hosts
（7）、查看操作历史。通过前面查看用户可以知道有哪些用户可以在本系统中登陆，依次查看这些用户的家目录中的.bash_history中的命令执行情况，关注异常不明确的操作，如wget、curl、git、cp等。本步骤未发现异常信息。
（8）、启动文件检查。检查相关启动文件中是否有异常的脚本命令等。
/etc/rc.d/*
/etc/profile
~/ .bash_profile
~/ .bashrc
~/ . cshrc
（9）、查看日志信息。
日志的主要保存目录为/var/log，如果有中间件httpd、nginx的时候，也要注意这些中间件的日志信息。本次排查过程中只发现大量的SSH爆破登录日志，但是均失败了。系统的日志信息包括以下几类：
/var/log/secure，通常会记录用户登录成功、登录失败、添加删除用户的情况，日志特征如下：
|
序号 |
场景 |
特征 |
|
1 |
登录成功 |
Accepted password |
|
2 |
登录失败 |
Failed password |
|
3 |
添加新用户 |
new user |
|
4 |
删除用户 |
delete user、removed group、removed shadow |
|
5 |
添加用户组 |
new group |
/var/log/message，普通日志信息，如文件传输信息等，日志特征ZMODEM
/var/log/cron，定时任务日志，可以查看是否有文件上传下载的操作
/var/log/btmp，登录失败日志记录，使用lastb命令查看
/var/log/lastlog，最后一次登陆操作，使用lastlog从查看
/var/log/wtmp，登录成功日志记录，使用last查看
/var/run/utmp，当前登录用户的信息，使用w/who/users进行查看
（10）、目录异常文件检查。查看目录中是否会有异常的文件存在，主要分析的目录包括：/、/opt、/tmp、/boot、/proc、/usr，在本步骤分析中我们发现了在/boot目录中有一个可疑的文件wkwfnxjpaa，查看为乱码，生成时间为虚拟机开机的时间，且连续执行查看命令，可以看到同目录下会随机生成另外一个文件，且大约1秒钟后即消失。
到这一步为止才查询到可疑文件，其他的排查手段均未发现有效的信息，当然也可能是能力不足及排查过程中不太仔细导致有漏掉的信息。后来在百度上找到命令egrep 'curl|wget' -R /，通过使用该命令也可以关联到这两个文件，提示如下：
Binary file /boot/ezfvmlunqc matches
Binary file /boot/wkwfnxjpaa matches
至此由于该虚拟机无法接入网络，也不能复现当时的情况，没有好的办法再进一步排查下去，排查至此结束。
四、结论
本次排查过程到了最后才发现可疑文件，且由于各种原因未再深入研究，未深入溯源到入Qin路径，结合各种信息可以推测该虚拟机中了挖矿病毒，并且在向外部矿池连接的过程中，被公司的IPS拦截阻断，大概率是由于IPS基于特征（如IP等）有漏报，导致运营商也有检测到，因此将其拦截的信息给到了客户。
五、总结
据事后分析，该问题在之前已经有所察觉，只是没有深入研究，当时查看日志只注意到有Gong Ji被阻断，却没有仔细分析其内在的原因。当从内部到外部的Gong Ji被阻断时，应当深度怀疑网络已经被攻陷，所以在安全运营中应该特别注意思考告警所代表的背后的问题。在安全运营中也要不断的引入新的日志分析告警方法，有了好的工具，工作可以轻松一大半。
最近两年经历多次挖矿病毒均是因为测试服务器未被有效地管理导致被黑，如之前的redis未授权访问，由于研发部署测试后，没有配置访问密码导致被植入挖矿病毒，所以开发测试服务器也要统一进行管理。另外，在数据中心或者在服务器侧，理论上讲不应该有这么多的服务器可以主动访问互联网，因为其主要对外提供服务，访问应当是从外向内的，所以应当断开不必要的服务器上网，避免服务器被攻陷后主动建立反向连接。
最后，本次采用手工逐步排查获取的信息有限，目前git上也有一些比较成熟的工具可以进行自动排查，以及检查系统是否被rootkit的工具，本次排查就不使用这些工具分析了。
补充：
本次排查过程中，在网上也搜索了大量的信息，注意到几个容易被挖矿混淆的进程，后续在排查中也要引起注意，如下：
|
序号 |
正确进程名称 |
异常进程名称 |
|
1 |
kthreadd |
kthreaddi |
|
2 |
kdevtmpfs |
kdevtmpfsi |
|
3 |
khugepaged |
khugepageds |
