事件描述由于经常购买服务器 ，某天，发现一台服务器上面虽然安装了 360 ，但是 ，仍然提示入侵提示 。让我特别纳闷， 于是开始调查下原因首先设想了三种可能性: 1.存在系统漏洞 2.由于前期运维在服务器上装了一些工具软件，会不会工具软件引入的病毒 3.应用层漏洞。 首先，用更新库的漏扫对系统层面的漏洞检测，未发现任何异常；由于会有开发连接进这台服务器，去开发那里收集工具软件进行查毒处理，也没发现异常，排除通过软件带入病毒的可能；那难道是通过应用层漏洞进来的？ 因为系统上线前都会经过web渗透测试，文件上传，SQL注入等常规漏洞已经修复，虽然这样，还是重新验证了一遍漏洞，没有问题，又用D盾webshell检测工具进行了扫面，未发现任何webshell。 那病毒是怎么产生的？ 溯源准备 由于病毒无法清干净，也不清楚黑客是已经在机器上做了哪些手脚，于是重新搭建一个干净的环境，给系统打好最新的补丁。 由于前期没有在主机端做日志收集类工具，缺乏主机端的攻击溯源手段，于是临时搭建了splunk日志分析系统，并在新搭建的服务器上安装了sysmon日志收集工具，对主机层面进行了日志收集。 过了一星期左右，小Z发现系统进程里面居然多了个叫wcmoye的进程，凭感觉这不是个正常程序，那就先从这个程序开始入手调查吧。 常规排查 常规排查还是采用了微软经典系统工具systeminternals套件，分别对启动项，系启动项除了services这一项发现了一个奇怪的StuvwxAbcdefg Jkl，其他没有特别值得注意的地方。
进程排查就是那个叫wcmoye.exe的进程
进程依赖于StuvwxAbcdefgh Jkl这个服务
网络通信：用tcpview观察wcmoye.exe会不定时连接一公网ip的9999端口
同时会有一些注册表及文件系统上的行为，确定wcmoye躲在C:windowssyswow64目录下+�]��
初步排查得出的结论是：wcmoye进程依赖于名叫Stuvwx Abcdefg Jkl系统服务，去syn链接公网ip的9999端口，是个木马程序。 在对wcmoye有了一定认识之后，小Z想它是从哪里来的，这时，之前搭建的日志分析系统派上了用场。 日志排查 这个问题得从wcmoye.exe在系统中产生的第一时间着手调查。于是打开splunk开始搜索：通过 wcmoye关键字的搜索，发现6月6日20：24发生如下可疑事件： 20：24：11 Tomcat目录下有一个叫NewRat的可执行文件生成wcmoye.exe，原来wcmoye是有一个叫NewRat的可执行文件生成的，但是回到Tomcat目录下查看，并没有发现NewRat.exe这个文件.
不急，进一步搜索NewRat，发现了更大的信息量:在wcmoye被创建的前一秒 20：24：10，tomcat7.exe去调用cmd.exe执行了一段比较长的脚本，随着时序跟踪事件的发展，发现在20：24：12 调用cmd.exe删除了NewRat.exe同时还观察到services.exe的执行， 系统服务创建关注sysmon的EventCode3 ，wcmoye的进程会与下载NewRat的那个公网ip的9999端口有通信日志，
使用FileZilla进入ftp服务器的目录，以一目十行地速度快速扫了一遍，首先蹦入小Z眼帘的就是NewRat.exe，不错，和前面的调查结果相吻合，NewRat就安静地躺在这里。
还有个独特专版st2-045 winlinux小组版文件夹，潜意识告诉这个文件夹里面很可能有谜底的答案，先直接百度一下
好家伙，双系统传马还Kill国内外主流杀毒软件，关键是st2-045这个就是远程代码执行（RCE）漏洞(S2-045,CVE-2017-5638)，不禁一颤，之前居然没想到测试这个高危的提权漏洞。
start.bat开始看吧
有一个叫wincmd.txt的文件，是winows平台下的执行脚本，红框的内容和前面splunk日志中的那段日志一模一样，也就是帮引导到这里的那段关键日志。
Linux平台的脚本：关闭防火墙，下载一个叫tatada的ELF文件，把netstat等系统命令改名，清空日志等等
Result.txt文件，记录着一些扫描到的ip的端口开放情况
Windows.txt和linux.txt里面貌似都是存在漏洞的网址。。。而且其中有一个关键的发现，就是所在公司的网站接口居然在一个叫http.txt的list里面
到这里，已经大致猜得出自己的公司网站是怎么被盯上的了。再看下几个可执行文件:S.exe就是扫描器
IDA载入str045
看得出Str045.exe就是struts2-045的利用脚本程序，他会去读取S.exe扫描出的ip及端口开放情况的文件，组合do，action等开启多线程去exploit，然后根据被攻击的系统版本，去执行相应的脚本，像这台web服务器是windows的，就会去执行wincmd.txt。0×6 网络架构目前调查到的种种迹象让坚信黑客是通过struts2-45漏洞进来的！ 于是去网上下载了一个最新的struts漏洞检查工具，直接对网站的80端口进行检测，但结果出乎意料，居然没有漏洞报警。
黑客服务器上只有针对strusts2-045的攻击脚本，但是检测又没有发现漏洞。这个矛盾的问题不禁思考更多的可能性。 在陷入迷茫的深思同时， 不经意的翻看着tomcat的localhost_access_log日志，突然一批ABAB型日志出现在他眼前，一个公网地址，一个内网地址，时间就在NewRat出现的前几分钟20:20:36：
这串高度相关的日志 究竟隐藏着什么意义？会不会是解开谜团的入口？带着强烈的好奇心，咨询了网络组的同事，什么情况下才会出现这样的情况， 网络组给出了网站如下的网络架构，并说明了由于业务的临时需求，新对网络架构做了新的调整。
服务器的内网端口是7070，公网防火墙上开放了80，443和8090端口。公网端口8090作了NAT对应内网的7070端口，据说是因为业务新需求开放的；同时为了安全考虑，公网用户如果只访问了80后，F5会做强制443端口跳转访问F5的一个vip地址。这种网络架构，当有人在公网扫描到80和8090端口时，就会出现ABAB型日志，即A就是通过NAT进来的，B是从vip地址过来的。所以才会出现上述奇怪日志的原因， 那个时刻，是黑客服务器在扫描 80和8090端口。0×7 水落石出NewRat也是在那个奇怪的日志后产生的， 这时一个念头闪现在脑海里，还是用struts漏洞利用工具，不过这次是去尝试web的的8090端口！一串清晰的红字,警告:存在Struts远程代码执行漏洞S2-045！
获取web系统内网IP信息b
而且通过搜索tomcat目录找到 struts的版本为2.5.10，的确是存在S2-045漏洞的版本。至此，这次入侵的来龙去脉，小Z已经调查清楚了。由于网站使用了struts框架 版本为2.5.10，存在struts2-045漏洞，黑客通过公网扫描找到网站，进而执行exploit把病毒程序传到服务器里面执行，不停的病毒警告是因为不断有人在公网利用漏洞入侵服务器。0×8 题外话但同时，小Z也注意到了另一个问题，为什么struts漏洞利用工具直接访问80端口无法检测出漏洞?小Z于是想到了Wireshark，这个网络放大镜或许能给出点蛛丝马迹。还是抓包对比一下吧。抓一下未检测出漏洞的80端口的包，
第一次get请求，F5返回了一个https的302重定向后，由于connection:close，F5直接做出了FIN ACK
第二次，软件请求的还是与80端口，而且get请求是带完整https url路径的,这种请求格式导致F5返回一个奇怪的重定向https://WWW.XXX.COMhttps://WWW.XXX.COM/test/test.do.导致漏洞验证失败。 再来对比一下浏览器页面访问80端口测试：经过tcp三次握手，浏览器发出get请求之后，F5返回一个302重定向， 浏览器于是向443端口开始了三次握手，接下来就是https的通信过程，
通过对比实验分析，发现在漏洞利用工具在测试80端口时，如果网站做了80转443端口的强制跳转，浏览器在得到302重定向后就开始向443端口开始3次握手，而测试软件的数据包处理过程就有问题，这时候直接测试80端口软件就会存在误报。 小Z之前由于粗心，只测试网站的80端口，得出错误的结论，原因也找到了。 0×9 结尾到此为止，所有的谜团一一解开，小c结束了这次曲折的入侵取证之路。 作者：诸葛蛋蛋 链接：https://www.zhihu.com/people/zhuan-zhi-pcdan-dan/posts 来源：知乎 著作权归作者所有。 商业转载请联系作者获得授权，非商业转载请注明出处。 F
