电脑中病毒是怎么产生的 计算机病毒主要侵害的系统

网络安全描述由于频繁购买服务器，有一天发现一台服务器上虽然安装了360，但仍然提示入侵提示。我特别纳闷，就开始调查原因。首先设想三种可能:1。存在系统漏洞；2.因为前期运维期

网络安全

描述由于频繁购买服务器，有一天发现一台服务器上虽然安装了360，但仍然提示入侵提示。我特别纳闷，就开始调查原因。

首先设想三种可能:1。存在系统漏洞；2.因为前期运维期间服务器上安装了一些工具软件，会不会有工具软件引入的病毒；3.应用层漏洞。

首先，系统级漏洞是通过更新库的漏扫描来检测的，没有发现异常。

因为会有开发者连接到这个服务器，到那里开发采集工具软件进行病毒检测，没有发现异常，所以排除了通过软件传入病毒的可能；是通过应用层漏洞吗？

因为系统上线前会经过web渗透测试，并且文件上传、SQL注入等常规漏洞已经修复。即便如此，漏洞也经过了再次验证，没有任何问题。D-Shield webshell检测工具已用于扫描表面，未发现任何webshell。

病毒是怎么产生的？

准备好追踪源头了吗

因为病毒无法清理，也不清楚黑客在机器上做了什么，所以我们重建一个干净的环境，给系统打最新补丁。

前期没有主机端的日志收集工具，缺乏主机端的攻击追踪手段，所以临时搭建了splunk日志分析系统，在新建的服务器上安装sysmon日志收集工具，在主机层面收集日志。

过了一周左右，小Z发现系统进程中居然有一个叫wcmoye的进程。它觉得这不是一个正常的过程，所以让我们从这个过程开始调查。

例行调查

日常故障排除仍然使用微软经典系统工具systeminternals suite，对启动项、系统进程、网络连接等进行简单的故障排除。

启动项发现了一个奇怪的StuvwxAbcdefg Jkl除了服务，没有什么特别值得注意的。

调查的过程被称为wcmoye.exe。

该过程依赖于服务StuvwxAbcdefgh Jkl。

通信:使用tcpview观察wcmoye.exe时不时会连接到一个公网ip的端口9999。

同时在注册表和文件系统上会有一些行为，确定wcmoye藏在C:windowssyswow64目录下。

初步结论是:wcmoye进程依赖于名为Stuvwx Abcdefg Jkl的系统服务，链接到syn的公共ip的9999端口，是一个木马程序。

在了解了wcmoye之后，小Z很好奇它是从哪里来的。这时，之前搭建的日志分析系统就派上了用场。

0×4日志疑难解答

这个问题要从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执行了一段比较长的脚本，不，进一步搜索NewRat揭示了更多信息:在wcmoye创建前一秒的20: 24: 10，tomcat7.exe调用cmd.exe执行一个相对较长的脚本。

随着计时追踪事件的发展，发现NewRat.exe是在20: 24: 12通过拨打cmd.exe的电话被删除的。

同时，还观察了services.exe的实施和系统服务的创建。

注意sysmon的EventCode 3，wcmoye的进程会有一个与下载了NewRat的公网ip的端口9999的通信日志，

其实在这里，基本就清楚了wcmoye是从哪里进来的。下一个问题是它为什么进来？Tomcat为什么要执行这些恶意命令？现在唯一的线索就是日志中ftp登录的ip和账号密码。去吧。

0×5

带着好奇心，继续探索过程，直接进入这个ftp服务器！

用FileZilla进入ftp服务器的目录，快速扫一遍，一目了然。首先映入小Z眼帘的是NewRat.exe。没错，和之前的调查结果一致，NewRat就静静地躺在这里。

还有一个独特的特别版st2-045 winlinux组版文件夹。潜意识告诉这个文件夹，很可能有谜底。我们先直接百度一下。

好家伙，双系统传播马，秒杀国内外主流杀毒软件。关键是st2-045。这是远程代码执行(RCE)漏洞(S2-045，CVE-2017-5638)。我不禁颤抖起来。之前没想到会测试这个高危漏洞。

开始。蝙蝠，让我们看看

有一个叫wincmd.txt的文件，是winows平台下的执行脚本，红框的内容和前面splunk日志中的那段日志一模一样，也就是帮引导到这里的那段关键日志。有一个文件叫wincmd.txt，是winows平台下的执行脚本。红框中的内容和之前splunk日志中的内容一模一样，也就是帮助我们引导到这里的密钥日志。

Linux平台的脚本:关闭防火墙，下载一个名为tatada的ELF文件，重命名netstat等系统命令，清除空日志等等。

Result.txt文件，记录着一些扫描到的ip的端口开放情况Result.txt文件记录了一些扫描到的ip的端口开放情况。

Windows.txt和linux.txt里面貌似都是存在漏洞的网址。。。Windows.txt和linux.txt似乎都是易受攻击的URL。。。

其中一个关键发现是，该公司的网站界面实际上是在一个名为http.txt的列表中

在这里，我已经大致猜到了我的公司网站是如何被盯上的。再看几个可执行文件:

是S.exe扫描仪。

加载IDA str045

看得出Str045.exe就是struts2-045的利用脚本程序，他会去读取S.exe扫描出的ip及端口开放情况的文件，组合do，action等开启多线程去exploit，然后根据被攻击的系统版本，去执行相应的脚本，像这台web服务器是windows的，就会去执行wincmd.txt。可以看出，Str045.exe是struts2-045的脚本程序。他会读取S.exe扫描的ip和端口打开文件，结合do、action等。来打开多个线程进行利用，然后根据被攻击系统的版本执行相应的脚本。如果这个web服务器是windows，它将执行wincmd.txt

0×6网络架构

目前种种迹象让我们相信黑客是通过struts2-45漏洞进来的！于是我上网下载了最新的struts漏洞检查工具，直接测试了网站的80端口，结果出乎意料，没有漏洞报警。

黑客服务器上只有针对Struts 2-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底部出来了

纽拉特也是在那根奇怪的木头之后诞生的。这个时候脑子里闪过一个想法，我还是用struts exploit工具，但是这次我尝试了web的8090端口！一串清晰的红色字母，警告:Struts远程代码执行漏洞S2-045存在！

再次尝试端口443，您也可以检测到:

获取web系统内网的IP信息

而且通过搜索tomcat目录找到 struts的版本为2.5.10，的确是存在S2-045漏洞的版本。而且搜索tomcat目录找到的struts版本是2.5.10，确实是有S2-045漏洞的版本。

至此，这次入侵的来龙去脉，小Z已经调查清楚了。由于网站使用的是struts框架2.5.10版，因此存在struts2-045漏洞。黑客扫描公网找到网站，然后执行exploit将病毒程序传输到服务器执行。不断的病毒预警是因为不断有人利用公网中的漏洞入侵服务器。

0×8题外话

同时，小Z也注意到了另一个问题。为什么struts exploit工具不能直接访问80端口检测漏洞？

z于是想到了Wireshark。这个网络放大镜或许能给出一些线索。我们抢包对比一下。

抓取带有未检测漏洞的80端口数据包，

第一次get请求，F5返回了一个https的302重定向后，由于connection:close，F5直接做出了FIN ACK在第一个get请求后，F5返回了一个https的302重定向，F5由于connection:close直接做了FIN ACK。

第二次，软件请求的还是与80端口，而且get请求是带完整https url路径的,这种请求格式导致F5返回一个奇怪的重定向
https://WWW.XXX.COMhttps://WWW.XXX.COM/test/test.do.导致漏洞验证失败。第二次，软件请求端口80，get请求带有完整的https url路径。这种请求格式导致F5返回一个奇怪的重定向
https://www.xxx.com https://www.xxx.com/test/test.do.漏洞验证失败。

我们来对比一下浏览器页面访问80端口测试:tcp三次握手后，浏览器发送get请求后，F5返回302重定向，于是浏览器启动三次握手到443端口，接下来是https通信过程。

通过对比实验分析，发现在漏洞利用工具在测试80端口时，如果网站做了80转443端口的强制跳转，浏览器在得到302重定向后就开始向443端口开始3次握手，而测试软件的数据包处理过程就有问题，这时候直接测试80端口软件就会存在误报。通过对比实验分析发现，漏洞利用工具测试80端口时，如果网站从80端口强行跳转到443端口，浏览器在得到302重定向后开始与443端口握手三次，说明测试软件的包处理过程有问题。这时候直接测试80口软件就会出现误报。

因为粗心，Z之前只测试了网站的80端口，得出了错误的结论。原因也找到了。

0×9结尾

至此，所有谜团一一解开，小C结束了这段曲折的入侵取证之路。