这年头，木马也会用连环计

1.来文

收到上级通知，单位内网存外连恶意地址的行为，要求排查是否被植入木马。此时正值傍晚下班时间，无疑晚饭是吃不了了，马上进入应急状态。

到机房后，看到网络集成商、软件开发商、网站运维人员已然就位......顿感亚历山大。了解了一圈网络拓扑，机房无任何安全设备，服务器裸奔。又问了一下开放的服务和端口，得知服务器上是部署了一套运行在apache上的Java Web程序，直接使用IP和PORT方式访问。情况就是这么个情况。

2.上机

登录服务器，第一感觉是很卡，系统运维人员输入账号密码，连带输错的几次算下来，15min才进入主界面。进去后我执行的第一条命令是hostnamectl，等一分钟，上图：系统版本是CentOS 7，内核版本是3.10.0。由于通报中说是有恶意外连地址，因此先看看网络连接情况：

起了如此多的进程都指向外部的同一个端口，属实异常。然后又看了一眼计划任务，空荡荡。还有用户：

用户目录虽然乱，但是挨个排查并对比/etc/passwd也可以判断出没有异常，可登录账户总共root,admin两个，也未发现隐藏账户，再加上创建时间都是2019年，基本可以排除恶意账户的可能性。之后看了下日志：

secure日志被删除，登录日志也被删除，留下的三条日志是刚刚登录产生的，作案者挺谨慎，有经验。再查看内存、硬盘、CPU运行情况时就发现了卡顿的原因：

CPU被占满，其中三个进程同名，如果在挖矿的话那就是保活用。额外发现一个细节，服务器持续运行时间一千二百多天，着实够稳定。

3.马一

根据刚才网络连接中的进程名，直接搜索恶意程序文件，找到了一个：

上传的时间是在14号，修改的时间是在18号，所以这个家伙已经作案了一个星期。先干掉。在杀进程的时候（这里忘了拍照o(╥﹏╥)o）遇到了一个小插曲。开始的时候使用kill -9，杀掉后很快又发现死灰复燃，应当是被其他进程再次调起。前面没有看仔细，是存在一些同类进程。然后使用pkill命令，才将同类进程尽数杀掉。此时再查看CPU状态，刚才前几个100%的进程已然消失，CPU恢复正常。可以判断出那几个进程属于同类进程。又观察了一段时间，恶意进程没有重新启动，进入下一环节，分析马儿。

Tsunami家族木马，常见行为是DDoS攻击和挖矿。情报中还给出了一个准确的远控地址：

对比此木马和远控端常用样本的sha256特征值，相同：

然后，该木马运行后会创建sshd木马，那一长串的字符是其进程号：

4.马二

既然名称中包含sshd，那么直接筛选名称中包含sshd的网络连接：

启动了很多进程，指向外部22端口，大概可以确定是在暴力破解，且由于账密不对，tcp状态已变成CLOSE_WAIT。然后根据ossl木马所创建的位置或者根据进程名搜索，很容易定位到此木马的位置（这里又忘了拍照o(╥﹏╥)o）。再使用情报看一下：

SSHDoor木马，一个万能密码后门。它不仅可以获得用户或组的ID，还会对其他目标进行SSH暴力破解，使用的字典：

然后杀进程比较简单，kill -9 完事儿。既然已经有木马了，那么必然要排查一下是否存在其他后门。上rkhunter，运行完毕来一段summary：

很明显rkhunter没有发现其他后门，那么最后的可能性就是内存马。先前跟开发沟通的时候不是很愉快，毕竟web漏洞跑不了（这属于溯源了，本文不复现），唧唧歪歪不大愿意配合，java-memshell-scanner也就传不上去。好在最后给建议的时候他们会采取服务器迁移的方式，这样一来内存马不排查也就罢了。最后将残存的一些日志如messages、中间件日志等备份，木马删除并取样（这里要注意不要被自己电脑上的杀毒软件干掉，我第一次没注意，又去取了第二次），下机。之后写报告、汇报工作，都很顺利，顿感轻松。然后在准备打道回府时，领导提出了一个新的需求：能不能把木马恢复回去，我想看看来文中的那些IP能否对的上。