本文讲的是<b>一次服务器被攻击的应急行动</b>，
如果你的PHP服务器被黑客入侵时该怎么办?这是我最近处理linux web服务器发现的一个问题。PHP服务器被黑时，会出现新的PHP文件，这与运行在服务器上的wordpress应用程序和特定的用户代理没有任何关系，所有的流量都被重定向到另一个站点。
应急准备
在第一次被攻击之后，我已经禁用了所有他所检测到的恶意文件，并修复了重定向，直到服务器再次被黑客攻击。
为此，要将这些应用程序转移到新的设备进行分析，我必须在原系统上对下列3个线索进行取证：
不过要说明的是，我的目的不是要建立一个合法有效的保护机制，而是要确定:
在获得域名、IP和SSH证书后，我就开始收集被黑的证据了。
收集证据
在连接到服务器之前，我注意到我的IP，以确保以后能够在日志中把它区分开。
然后通过SFTP连接，由于服务器的磁盘安装和运行，我无法进行映像。所以我下载了所有我可以得到的日志文件以及其他感兴趣的文件。我复制了整个/ var/log/目录，并从虚拟主机根文档所在的目录中复制了Apache特定的日志文件。我复制了被黑的PHP应用程序，以及在事件发生后不久的一些备份。不幸的是，我没有对管理员所做的更改进行备份，因此一些关键的文件可能已经被修改了。
我启动了Kali并运行了一个具有portscan端口扫描器程序的Nmap扫描，另外我还安装WPScan。因为服务器运行的是一个旧的Wordpress实例，而且这个实例也执行了重定向，所以Wordpress看起来很可能是攻击的初始点。然而，自从Wordpress在黑客攻击后已经更新，WPScan没有发现任何当前的漏洞。portscan为FTP、SSH、HTTP和HTTPS提供了开放端口，而这在web服务器上是不可能的。然而，我在wp – content目录下发现了所有的shell，在某种程度上，这意味着Wordpress应用程序已经被破坏。
我还检查了VirusTotal，看看网站是否传播了恶意软件，但一切似乎都很正常。
于是我决定通过控制台登录系统，但前提是我不知道服务器上的二进制文件是否被感染了，因此为了减少取证的影响，我带来了我自己的静态链接二进制文件。我从busybox下载了二进制coreutil，并将它们上传到了服务器上。我还通过SLEUTH Kit上传了chkrootkit和一个叫做mac-robber 的工具。
我使用静态二进制文件来检查系统，得到一个运行流程列表，cronjob……
为了得到一个监控列表(tcp和udp)进程，我没有涵盖portscan中的所有端口，因此这里的输出可能很有趣。
从服务器显示活动的传出连接(tcp和udp)，然而，这两个清单都没有显示可疑的活动。
对 chkrootkit进行rootkit检测，也没有找到任何东西。rkhunter和clamav也没有产生任何异常。ClamAV（Linux杀毒软件）也没有检测到php shell和windows木马程序。
虽然我很努力，但到目前为止还没有发现异常打开的端口，异常的进程运行。于是，我和一个管理员核实了FTP和ssh 帐号，这些账号看起来也很正常。
但我并没有放弃，在使用了mac-robber工具后，我收集了在服务器上创建和修改的文件信息(稍后可以用来创建事件的时间轴):
截至目前，我收集的证据包括:
分析证据
由于已经发现了攻击者放置的一些webshell，在经过分析后。我认为，这些文件很像Xjrop.php, Nwfqx.php 或Rwchn7.php，并且很可能驻留在常规应用程序文件。然而，也有一个up.php文件被调用，它提供了一个相似的目的，但有其他的源代码。而Xjrop.php, Nwfqx.php和Rwchn7.php是一样的, up.php是另一种具有略微不同功能的shell。用diff 命令，比较文件：
或者通过比较他们的md5sum比较:
还有2个文件—— bjrnpf.php和jemkwl.php，这些都是相同的，但不同于其他文件。一个可疑的可执行文件被命名为windoze，我怀疑是一些恶意软件可能是从这个主机分发的。我构建了这个文件的md5sum，并检查了VirusTotal的哈希值，注意，在VirusTotal上上传的文件可以被其他研究人员看到，因此是公开的。VirusTotal认为这个文件是木马，为了以后的分析，我保存了它。
一些PHP shell看起来如下所示:
你可能注意到了“404-server! !”的标题，利用谷歌搜索的结果可能是其他受感染的服务器:
有更多可疑的文件包含了看似无用的代码:
这行替换了字符串“saft”中的一个小写字母“saft”中的每一个匹配，并使用$ _POST变量mkf3wapa的内容。返回值被忽略，因此我不确定该代码片段的用法应该是什么。
然而，谷歌搜索结果显示，这段代码与404-server有关联! !上传shell并出现在相同的受损服务器上。因此，如果你在服务器上发现了这个代码，它可能是一个被攻击的标识，你应该进一步检查。
检查“404-Server!!“源代码使我得出结论，黑客提供了一个文件浏览器，它具有上传、查看和删除文件以及调整权限的功能。
通过检查这些文件的背后组织和开发者，我发现它们都是由PHP进程的所有者创建的，因此它们非常像PHP应用程序所创建的。
另一个被攻击的文件叫做way.php，它只是包含了来自另一个服务器的文件:
因此，这基本上是一种将外国html/javascript代码包含在该域下的方法。然而，恶意服务器向我展示了一个有趣的信息:
这可能是因为我没有使用正确的引用头，或者服务器不再为其恶意负载服务。
在一个html文件中，我发现:
它只是用iframe方法插入了way.php的输出。
进一步寻找shell
以上这些文件因为它们异常的文件名被识别后，我开始通过应用程序代码来查找更多可疑的文件。特别是，你可能希望查找在服务器上执行命令的函数，例如:
并grep所有这些函数的文件:
你经常看到人们只grep*.php文件，但这可能会遗漏很多信息，php文件可以有其他扩展，当只检查 *.php扩展时，就可能会忽略*.php5*， *.php4 或*.phps 。因此，如果条件允许，你最好能在所有文件中进行grep，或者在任何其他文件结束时提前搜索。也可能存在带有任意扩展的恶意文件，这些文件由更常规的php文件加载，因此你也应该尝试检测这些文件。
但是，请注意，由于这些文件没有直接执行代码，因此不会检测到混淆的文件和上传的shell。你可能会扩展你的搜索范围，减少一些可疑的函数。
如果你有一个粗略的想法，当攻击发生的时候，你可能也想要寻找在那个日期之后被创建或修改的文件。
根据在服务器文件上发生的常规更改，你可以很容易地以这种方式检测到更多的shell。
如果你已经发现了一些恶意文件，那么还可以使用检测到的文件的某些特性来寻找进一步的变体，比如，检查所有文件的字符串“404-Server!!”。
除了传统的杀毒软件扫描仪外，还有一种方法是使用基于yara的扫描仪，比如OWASP中的WebMalwareScanner。这些基本上是扫描文件，并以检测恶意代码的yara规则检查它们。为此，你需要在git中安装yara、python binding和WebMalwareScanner。在我的例子中，运行webmalewarescanner，可以在被破坏的PHP应用程序的源代码上产生了很多结果，我花了一些时间，但也正确地识别了三种类型的webshell中的两种。
此外，还有一些wordpress插件试图检测出攻击方案，比如sucuri。我不想在已经损坏的系统上安装额外的插件，所以我没有尝试这个。
根据我的经验，在寻找webshell时，你应该始终结合不同的技术。有些有些文件很难识别，乍看上去合法的文件也可能有恶意的功能。你越了解被破坏的系统，就越容易检测到异常文件。
禁用攻击文件
收集完所有这些信息后，不要忘记将恶意文件渲染成无用的。我已经删除了所有用户的阅读和执行权限，但在系统运行了一段时间后，我将删除它们。系统中不应该留下任何损坏的文件，以防有人不小心将它们重新激活。
建立一个攻击时间表
在前面提到的mac-robber 工具之前，我已经检索了文件信息，我用mactime创建了这个信息的时间轴。
然后你会得到一长串看起来像以下的条目:
这是服务器上所有文件的非常有用的列表，包括所有者id、组id以及文件修改、访问和更改的时间戳。
请注意，在unix上，通常会获得文件访问时间、文件更改时间和文件修改时间(atime,ctime,mtime)。这些是在文件大小之后的mactime时间线文件中显示的，例如上面示例中的第二行中的m.c.。这意味着给定的日期会显示文件修改和更改时间。
因此，mtime在文件最后写入时向我显示。但是，我不能确定它是否与文件创建日期相匹配。不幸的是，这里无法重新构造，因此我不能确定这是上传的时间，但是我可以确定，在周五，Jul 07文件已经在系统上了。在linux上，你可以使用工具stat来显示单个文件的这些信息。
还有一些与文件系统，文件访问，创建时间有关的副标题。首先，如果你的文件系统安装了noatime选项(你可以通过运行mount命令来解决这个问题)，则不需要编写访问时间。虽然这能增加取证速度，但显然非常复杂。
检查我的时间线，我可以知道第一个恶意的shell何时出现在系统上。
检查日志
我可以在日志中找到一些对这些工具的调用，主要来自亚洲IP地址，但由于POST数据没有被记录，我无法找到从apache日志中上传这些shell的文件。
寻找初始攻击向量
然而，在事件发生当天或之前，没有可疑的sql注入或lfi/rfi活动，可能会与其中一个可疑文件发生关系。
注意，脚本没有检查主题或wordpress核心漏洞，这也可能包含严重的漏洞。
总结
1.该系统已经被破坏了几个星期。在apache日志的shell中，最早的可见访问是在7月初；
2.我识别了各种受损的php文件和一个windows恶意软件；
3.至少有三种类型的shell被发现是攻击的指标；
4.windows恶意软件可能还没有传播；
5.服务器没有显示出明显的更深的感染迹象，从用户帐户来看，没有找到rootkit；
6.攻击可能被限制在webserver用户上。对于其他用户，我还没有任何攻击的迹象；
7.最初的攻击可能是过时的wordpress系统中最不安全的漏洞之一。
8.没有迹象表明其他用户通过shell访问了数据库或数据库凭据。但是，我不能排除有可能访问数据库的可能性。
9.一些可能是来自亚洲IPs的恶意活动(shell访问)
除了清理系统中的恶意文件,我也应用一些优化手段，比如更改密码和证书，安装一个主机id，执行定期扫描，主动监测服务器……。不过，你永远不会得到100%的安全性。特别是当你的服务器已经被破坏时，你所能做的最好的事情就是检查每一个来自非官方的备份或脚本。
原文发布时间为：2017年9月18日
本文作者：luochicun
本文来自云栖社区合作伙伴嘶吼，了解相关信息可以关注嘶吼网站。.
<a href="http://www.4hou.com/technology/7653.html" target="_blank">原文链接</a>