快捷搜索:  网络  后门  扫描  渗透  CVE  木马  黑客  as

记一次服务器被入侵的调查取证

*

0×1 事故描摹

小Z地点公司的信息安全建设还处于初期阶段,而且只有小Z新来的一个信息安全工程师,所以常常会碰着一些疑难问题。一天,小Z接到运维同事的反映,一台tomcat 的web服务器虽然装置了杀软,然则照样三天两头会出现杀软病毒报警,希翼他能查下缘故起因。

小Z起首假想了三种可能性:

1.存在体系漏洞

2.由于前期运维在服务器上装了一些工具软件,会不会工具软件引入的病毒

3.应用层漏洞

因而,他从这三方面最先了调查。

起首,小Z用更新库的漏扫对体系层面的漏洞检测,未发现任何异常;由于会有开发连接进这台服务器,他去开发那边网络工具软件进行查毒处理,也没发现异常,排除通过软件带入病毒的可能;那岂非是通过应用层漏洞进来的?因为体系上线前都会经过web渗透排泄测试,文件上传,SQL注入等常规漏洞已经修复,虽然如许,小Z照样重新验证了一遍漏洞,没有问题,又用D盾webshell检测工具进行了扫面,未发现任何webshell。

那病毒是怎么产生的?

0×2 溯源预备 

由于病毒没法清清洁,也不清楚黑客是已经在机器上做了哪些四肢行为,营业方请求小Z重新搭建一个清洁的环境,给体系打好最新的补丁,交给开发重新放入生产。由于前期没有在主机端做日记网络类工具,缺乏主机端的攻击溯源手段,小Z暂且搭建了splunk日记阐发体系,并在新搭建的服务器上装置了sysmon日记网络工具,对主机层面进行了日记网络。过了一礼拜左右,小Z发现体系进程内里居然多了个鸣wcmoye的进程,凭感觉这不是个正常程序,那就先从这个程序最先入手调查吧。

0×3 常规排查 

常规排查照样采用了微软经典体系工具systeminternals套件,分别对启动项,体系进程,收集连接等简单做了排查。

启动项除了services这一项发现了一个希罕的StuvwxAbcdefg Jkl,其他没有特别值得注意之处。

记一次服务器被入侵的调查取证

进程排查就是谁人鸣wcmoye.exe的进程

记一次服务器被入侵的调查取证

进程依靠于StuvwxAbcdefgh Jkl这个服务

记一次服务器被入侵的调查取证

收集通讯:用tcpview观察wcmoye.exe会不准时连接一公网ip的9999端口

记一次服务器被入侵的调查取证

同时会有一些注册表及文件体系上的举动,确定wcmoye藏在C:\windows\syswow64目录下

记一次服务器被入侵的调查取证

初步排查得出的结论是:wcmoye进程依靠于名鸣Stuvwx Abcdefg Jkl体系服务,去syn链接公网ip的9999端口,是个木马程序。

在对wcmoye有了一定认识以后,小Z想它是从那里来的,这时辰,小Z之前搭建的日记阐发体系派上了用处。

0×4 日记排查

这个问题得从wcmoye.exe在体系中产生的第一时间着手调查。因而关上splunk最先搜索:通过 wcmoye症结字的搜索,发现6月6日20:24发生以下可疑事故:

20:24:11 Tomcat目录下有一个鸣NewRat的可执行文件生成wcmoye.exe,原来wcmoye是有一个鸣NewRat的可执行文件生成的,然则归到Tomcat目录下查看,并没有发现NewRat.exe这个文件.

记一次服务器被入侵的调查取证

不急,进一步搜索NewRat,小Z发现了更大的信息量:在wcmoye被创建的前一秒 20:24:10,tomcat7.exe去调用cmd.exe执行了一段比较长的脚本,

记一次服务器被入侵的调查取证

随着时序跟踪事故的发铺,发现在20:24:12 调用cmd.exe删除了NewRat.exe

记一次服务器被入侵的调查取证

同时还观察到services.exe的执行,体系服务创建

记一次服务器被入侵的调查取证

关注sysmon的EventCode 3 ,wcmoye的进程会与下载NewRat的谁人公网ip的9999端口有通讯日记,

记一次服务器被入侵的调查取证

实在到这里,wcmoye是从那里进来的已经基本弄清楚了,接下来的问题就是为什么会进来?Tomcat为什么去执行这些恶意命令?现在唯一的线索就是日记中的谁人ftp上岸的ip和账号暗码了,继续吧。

0×5 顺藤摸瓜

小Z带着好奇心,继续探索过程,直接进入了这个ftp服务器!

记一次服务器被入侵的调查取证

使用FileZilla进入ftp服务器的目录,以目下十行地速率快速扫了一遍,起首蹦入小Z眼帘的就是NewRat.exe,不错,以及前面的调查效果相切合,NewRat就安静地躺在这里。

记一次服务器被入侵的调查取证

还有个独特专版st2-045 winlinux小组版文件夹,潜意识告诉小Z这个文件夹内里极可能有答案的谜底,先直接百度一下

记一次服务器被入侵的调查取证

好家伙,双体系传马还Kill国内外支流杀毒软件,症结是st2-045这个就是遥程代码执行(RCE)漏洞(S2-045,CVE-2017-5638),小Z不禁一颤,之前居然没想到测试这个高危的提权漏洞。

记一次服务器被入侵的调查取证

start.bat最先看吧

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

有一个鸣wincmd.txt的文件,是winows平台下的执行脚本,红框的内容以及前面splunk日记中的那段日记一模同样,也就是帮小Z引导到这里的那段症结日记。

记一次服务器被入侵的调查取证

Linux平台的脚本:关闭防火墙,下载一个鸣tatada的ELF文件,把netstat等体系命令改名,清空日记等等

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

Result.txt文件,记录着一些扫描到的ip的端口开放情形

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

Windows.txt以及linux.txt内里貌似都是存在漏洞的网址。。。

而且其中有一个症结的发现,就是小Z地点公司的网站接口居然在一个鸣http.txt的list内里

记一次服务器被入侵的调查取证

到这里,小Z已经大致猜得出本人的公司网站是怎么被盯上的了。再看下几个可执行文件:

S.exe就是扫描器

记一次服务器被入侵的调查取证

IDA载入str045

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

看得出Str045.exe就是struts2-045的行使脚本程序,他会去读取S.exe扫描出的ip及端口开放情形的文件,组合do,action等开启多线程去exploit,然后根据被攻击的体系版本,去执行相应的脚本,像小Z公司的这台web服务器是windows的,就会去执行wincmd.txt。

0×6 收集架构

目前调查到的各种迹象让小Z坚信黑客是通过struts2-45漏洞进来的!因而小Z去网上下载了一个最新的struts漏洞检查工具,直接对网站的80端口进行检测,但效果出乎意料,居然没有漏洞报警。

记一次服务器被入侵的调查取证

黑客服务器上只有针对strusts2-045的攻击脚本,然则检测又没有发现漏洞。这个矛盾的问题不禁让小Z思考更多的可能性。

在陷入迷茫的沉思同时, 小Z不经意的翻看着tomcat的localhost_access_log日记,突然一批ABAB型日记出现在他面前,一个公网地址,工控黑客 ,一个内网地址,时间就在NewRat出现的前几分钟20:20:36:

记一次服务器被入侵的调查取证

这串高度相干的日记 事实隐躲着什么意义?会不会是解开谜团的入口?带着强烈的好奇心,小Z咨询了收集组的同事,什么情形下才会出现如许的情形,收集组给出了网站以下的收集架构,并说明晰由于营业的暂且需求,新对收集架构做了新的调整。

记一次服务器被入侵的调查取证

服务器的内网端口是7070,公网防火墙上开放了80,443以及8090端口。公网端口8090作了NAT对应内网的7070端口,据说是因为营业新需求开放的;同时为了安全考虑,公网用户要是只走访了80后,F5会做强制443端口跳转走访F5的一个vip地址。

这类收集架构,当有人在公网扫描到80以及8090端口时,就会出现ABAB型日记,即A就是通过NAT进来的,B是从vip地址过来的。所以才会出现上述希罕日记的缘故起因,谁人时刻,是黑客服务器在扫描 80以及8090端口。

0×7 水落石出

NewRat也是在谁人希罕的日记后产生的,这时辰一个动机显现在小Z脑海里,照样用struts漏洞行使工具,无非这次是去尝试web的的8090端口!一串清晰的红字,正告:存在Struts遥程代码执行漏洞S2-045 !

记一次服务器被入侵的调查取证

再试试443端口,也能检测出:

记一次服务器被入侵的调查取证

获取web体系内网IP信息

记一次服务器被入侵的调查取证

记一次服务器被入侵的调查取证

而且通过搜索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 结尾

到此为止,所有的谜团一一解开,小Z结束了这次蜿蜒的入侵取证之路。

参考链接:

https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

http://www.freebuf.com/sectool/125846.html

*

您可能还会对下面的文章感兴趣: