我最近处理了一个Linux Web服务器被侵略的案件，作业的原因是客户发现Web服务器上呈现了一个新的PHP文件，它与运转在服务器上的WordPress运用程序和特定的用户署理无关，全部的流量都被重定向到另一个站点。

 blob.png

本文并不是一个详细的取证攻略，也不是一个翔实的安全作业呼应手册。写作的意图是想为您供给一些思路，碰到需求处理这类Linux服务器被黑的Case时分，你应该作何考虑？施行那些行为？需求预备哪些常用的东西？

1．开端

当管理员第一次发现服务器被侵略后，当即整理了全部发现的歹意文件，修正了重定向的问题，以为全部都现已恢复了，直到不久之后服务器再次被侵略。管理员又做了修正作业，这次还更新了体系，在决议将运用程序转移到一台新服务器上之前，他们决议请其他人员查看以下，所以，我就上场了。

摆在我眼前的待取证对象是：

仍在出产环境中运转的体系

至少遭受了两次侵略

管理员进行对体系进行了实质性的修正

这些条件都不算抱负，乃至可以说是不适宜的，提早声明：我的意图不是去发明一个合法有用的监测链，而是要做混合取证，在尽可能的不终端运转中的服务的状况下，进行作业呼应和修正被损坏的东西。我的方针是：

断定体系是否仍然处于风险状况（假如是的话，删去或阻挠与此相关的全部内容）

检测是否存在被修正的文件，以防止将已被感染文件迁移到新的服务器上

抱负状况下，找出初始的侵略向量，并保证它已被阻挠。

在取得域名、IP和SSH凭据之后，我就开端作业了。

2．搜集依据

在衔接到服务器之前，我记载了自己的IP，保证今后可以在日志中辨认出它。

然后我经过SFTP指令衔接到了服务器上。由于服务器的磁盘现已被加载并且正在运转，因而我无法取得镜像，所以我下载了全部感兴趣的、能得到的日志文件。我仿制了整个/var/log目录和存储Apache日志文件的特定目录，仿制了受损的PHP运用程序，以及在作业发作后不久所采纳的一些备份。不幸的是，第一次被侵略和管理员做出更改之间没有进行体系备份，因而一些要害文件可能现已被修正了。

敞开了Kali，针对服务器发动Nmap端口扫描和wpscan扫描。由于服务器运转了一个老旧的WordPress实例，并且这个实例曾履行过歹意的重定向，所以WordPress很可能是侵略的初始点。但是，由于WordPress在被侵略后现已更新过了，wpscan没有在当时的版别中找到任何缝隙。Nmap端口扫描的成果是敞开了FTP，SSH，HTTP和HTTPS端口，这关于一个Web服务器来说有点剩余，进犯者也可能从其间一项服务进行打破。但是，管理员的陈述里说全部的shell都是在wp-content目录下被发现的，这在某种程度上暗示了进犯者可能侵略了WordPress运用程序。

我还运用VirusTotal查看了该站点是否有传达歹意软件的记载，但好像全部都很好。

我决议经过控制台登录体系。由于不断定服务器上的二进制文件是否被感染了，所以为了削减影响，我运用了自己的静态链接二进制文件。从BusyBox下载了coreutil二进制文件并上传到服务器上，一起还上传了chkrootkit东西和SLEUTH东西包中的一个名为mac-robber的东西。

用静态二进制文件查看体系，得到运转中的进程和cronjobs等的列表信息，你可以运用

netstat-tulpen

指令得到一个监听（TCP和UDP）进程的列表（我没有掩盖全部扫描到的端口，所以得到的输出可能是风趣的）。可以运用

netstat-taupn

指令显现从服务器中输出的活动的衔接（TCP和UDP）。但是，这两个清单都没有发现可疑的活动。

Rootkit检测东西chkrootkit也什么都没发现，运用rkhunter和ClamAV也没有什么收成（这不意味着什么，不幸的是，ClamAV错失了PHP shells和Windows木马）。

我开端手艺寻觅一些不同寻常的事物，但现在为止全部好像都很洁净：没有不寻常的敞开端口、没有不寻常的进程在运转。我用一个管理员账户验证了FTP和ssh帐户，它们看起来不错。在这个层面上好像没有侵略的痕迹。

mac-robber东西协助我搜集了服务器上创立和修正的文件的信息（稍后可被用于创立作业的时刻线）：

./mac-robber / >/root/forensics/timeline.txt

现在，我发现了：

服务器上被创立的文件及时刻的信息

各种日志文件，其间包括Apache日志

被侵略的网站一些元代吧，包括一些（被修正过的）shell文件

第一次和第2次被侵略之间的备份

总的来说，还算有所收成。当然，您可能以为这些日志数据不能被信赖，由于它们可能被进犯者修正过了。但我却没有理由等待进犯会这么杂乱。

3. 深度查看

管理员现已断定了一些被进犯者上传的webshells文件。我开端查看这些文件，发现大部分文件的姓名都比较荫蔽，如Xjrop.php，Nwfqx.php或Rwchn7.php（首字母都是大写的），这些文件是完全相同的，涣散在正常的运用程序文件之间。但是有一个名为up.php的文件，与上述几个文件的源代码不同，功用也稍有不同。可以运用diff指令比较两个文件：

diff Xjrop.php Nwfqx.php

或许比较它们的MD5值：

md5sum Xjrop.php

md5sum Nwfqx.php

还有2个文件的姓名比较古怪，bjrnpf.php和jemkwl.php，全部是小写这两个文件是相同的，但有别于其他文件。一个可疑的可履行文件被命名为windoze.exe，我置疑一些歹意软件可能现已从该主机传达出去了。运用md5sum核算这个文件的哈希值，在VirusTotal进行查看，（留意上传到VirusTotal的文件可以被其他研究人员看到，是公共的，所以最好不要上传可能含有保密或灵敏信息的东西，可以首要运用哈希值进行剖析）。VirusTotal的剖析成果断定该文件为木马程序。因而我将它保存下来以备后续的剖析。

剖析这些PHP shell样本，发现某些文件中包括如下信息：

留意它们的标题“404-server!!”。用查找引擎查找胰腺癌，发现了其他一些可能受感染的服务器信息：

 还有一些可疑文件中，包括了一些看似无用的代码：

这一行代码的意义是正则匹配“saft”字符串中的小写字母“pageerror”，将其替换成$_POST 变量“mkf3wapa”。由于返回值被疏忽，所以我不知道这个代码片段详细的效果是什么。

但是，运用Google查找，发现一大堆的查询成果，标明这段代码与黑客上传的“404-Server!!”shell脚本有联络，它们一起呈现在被侵略的服务器上。因而，假如您在服务器上找到此代码，它可能存在被感染的要挟，您应该对服务器做进一步的查看。

查看包括“404-Server!!”的shell文件的源代码，发现它们供给了上传／查看／删去文件以及调整权限的功用。

查看文件的全部者和用户组，发现它们都是用PHP进程的全部者创立的，所以它们很可能是由被侵略的PHP运用程序创立的。

另一个被感染的文件名为way.php，它仅仅包括了来自另一个服务器的一个文件，源代码如下所示：

这段代码中指向的歹意服务器向咱们展现了一个风趣的音讯：

可能是由于我没有运用正确的referer头，或许是服务器不供给歹意负载了。

在一个HTML文件中，发现如下代码：

寻觅更多的Shells

管理员供给的可疑的Shell文件是由于它们有比较特别的、古怪的命名，接下来，我开端经过运用程序代码来寻觅更多的可疑文件，尤其是，您可能期望查找在服务器上履行指令的函数，如：

passthru

exec

shell_exec

eval

system

运用以下指令查找全部包括这些函数的文件：

egrep -rin "system|passthru|exec|shell_exec|eval" /var/www/vhosts/xyz/ > ~/forensics/results_shell_grep.txt

人们常常会运用 *.php的后缀来查找可疑的PHP文件，但PHP文件其实还有其他的扩展名，如*.php5、*.php4 或 *.phps，假如只查看可能*.php的话，可能会错失许多。所以，假如条件答应的话，可以查找一下上述全部扩展名的文件。也有一些歹意文件运用恣意扩展名，由更规矩的PHP文件加载，因而也应该测验检测一下这类文件。

留意，现在还没有检测那些既没有混杂也不存在上传Shells状况的文件，由于这些没有不直接履行代码。别的，您可能还会查找一些不太可疑的函数，这样做或许还会得到太多的成果，例如：

fputs

fwrite

fopen (特别是带着 URLs的)

chmod

socket_*

curl_*

base64_decode

gzinflate

假如你有一个大致的主意，当侵略作业发作时，你可能会想到查找一下在那个日期之后被创立或修正的文件，如：

find -mtime -2 /directory

您可以递归地辨认出／目录下在前2天内或更早时刻之前修正过的全部文件。依据服务器文件上文件修正的规矩，您可以很简单地经过这种方法检测到其他的Shells文件。

假如你现已断定了一些歹意文件，也应该依据一些发现的特征寻求更多的变种，如在本例中查看字符串“404-server!!”，可能会发现更多可疑的文件信息。

除了传统的防病毒软件之外，还有另一种办法，即运用OWASP出品的依据YARA规矩的WebMalwareScanner扫描仪，要做到这一点，你需求装置YARA、Python绑定并从Github上下载WebMalwareScanner。在处理这件作业时，我在另一台Linux机器上运转了WebMalwareScanner对被感染的PHP运用程序的源代码进行检测，花了一些时刻，不过得到了许多成果，正确辨认了一些webshells。

root@DESKTOP-XXX:~# cat webmalwarescan_results.txt |grep"webshell" [2017-08-0109:24:56] Scan result for file /path/to/up.php : webshelliMHaPFtp 2 [...]

别的，有些WordPress插件也是被侵略的方针，需求被检测，不过我不想在现已被损坏的体系上装置额定的插件，所以这一次没有测验这种方法，下次可能就会这么做了。

依据我的经历，最好可以结合不同的技能去寻觅webshells。它们有时很难辨认，乍看之下一些看似合法的文件也可能具有歹意功用。你越了解被侵略的体系，就越简单检测到不应该存在的文件。

制止被感染的文件

搜集完全部这些信息后，不要忘掉把歹意文件整理掉。我现已移除了这些可疑文件的全部用户的读取和履行权限，体系运转一段时刻后，没有显着的问题，将它们删去。别把可疑的文件残留在体系中，以防有人不小心激活了它们。

创立一个时刻线

前边说到运用mac-robber东西检索到了创立和修正文件的信息，现在我用mactime创立了一个时刻线：

mactime -b timeline.txt 2017-06-01> timeline_output.txt

得到了一个长长的条目列表，如下所示：

Fri Jun 30201715:43:02308 .a.. -rw-r--r-- 1000010040 /var/www/vhosts/xyz/httpdocs/way.php

Fri Jun 30201715:51:55308 m.c. -rw-r--r-- 1000010040 /var/www/vhosts/xyz/httpdocs/way.php

Fri Jun 30201716:07:4731 m.c. -rw-r--r-- 1000010040 /var/www/vhosts/xyz/httpdocs/newmessage.html

这是一个与服务器上的全部文件有关的十分有用的列表，包括了文件的owner id、group id，以及文件被修正、拜访和更改的时刻戳。

留意，在UNIX体系上，一般状况下可疑取得文件的拜访时刻、更改时刻和修正时刻（atime，ctime，mtime），以常见的mactime输出为例：

a  代表一个文件被拜访的时刻（atime）

c  代表一个文件的内容或权限被更改的时刻（ctime）

m  代表文件内容被更改的时刻，而不是全部者或权限被更改

b  代表文件被创立的时刻，不过你一般不会看到这个

所以，mtime显现了文件最终被写入的时刻。但是，咱们不能断定这是否与文件的创立日期相吻合，惋惜的是这儿无法重建，所以不能必定这就是文件被上传的时刻，但可以必定的是，上星期五，即7月07，该文件就现已存在于体系上了。在Linux体系上，您可以运用 stat 指令显现单个文件的详细信息。

关于这文件体系和文件的拜访／创立时刻的问题，请答应我再多说一点。首要，你的文件体系在加载时假如启用了noatime选项，那么就意味着不会记载对磁盘的拜访时刻，这样做可以进步拜访速度，但明显并不利于取证剖析。不过，某些文件体系仍然可以找出文件创立时刻，大多数Linux服务器上的ext4格局的文件体系就支撑这一功用，但没有简易的展现东西，mactime并不适用。

Linux下运用debugfs可以查询文件的创立日期。

查看时刻线，可以核算出第一个歹意shell呈现在体系上的时刻，成果显现是在作业被发现的几周之前，这不是一个好征兆。

查看日志文件

从日志中查看调用这些脚本东西的信息，发现几个首要来自于亚洲的IP地址，但由于apache日志里没有记载POST数据的嘻嘻，因而无法承认经过这些Shells上传了哪些文件。

寻觅初始进犯向量

为了定位初始的进犯向量，我运用了 apache-scalp东西，尽管它有点旧了，但仍然有用。但仍在作业。经过正则表达式它基本上能Apache日志中匹配出已知的进犯向量。

/opt/apache-scalp/scalp# python scalp.py -l /path/to/logs/access_log.processed.1_plain-f /path/to/default_filter.xml -a lfi,rfi,sqli,dt -p"25/Jun/2017;05/Jul/2017" --output /root/scalp --html

但是，没有发现可疑的SQL注入或LFI / RFI缝隙使用的状况，事发前一天也没有可以与可疑文件相关联的可疑作业发作。

查看WordPress插件标明，至少有一个SEO插件包括了一个严峻的文件上传缝隙，这个插件是一个月前装置的。由于运用程序装置了许多插件，因而我写了一个小脚正本查看WordPress插件目录，比对wpvulndb.com已发布的缝隙（不过该体系好几年没更新过了）。

事实证明，存在许多的严峻的安全缝隙，假如没有满足的日志信息，很难追寻初始向量。

留意，这个脚本不查看主题或WordPress中心的缝隙，它们也可能包括严峻的缝隙。

做完上述作业之后，我决议花满足的时刻为客户供给一份开始陈述，并打开进一步的举动。

4．成果

现在，咱们都知道哪些状况了呢？