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

免责声明

由于传播、利用本公众号听风安全所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号听风安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！

公众号现在只对常读和星标的公众号才展示大图推送，

建议大家把听风安全设为星标，否则可能就看不到啦！

----------------------------------------------------------------------

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能否对的上。