0x00 概述

上周，Microsoft报告了一起罕见的网络安全事件，有攻击者对Microsoft Exchange服务器进行持续的大规模漏洞利用，其中使用到了各种0-Day漏洞。高度复杂的攻击者再加上此前未知的威胁，这样的攻击无疑是安全团队遇到的最有挑战性的情况之一。

但对于CrowdStrike Falcon Complete团队来说，这只是平常的一天。

在这篇文章中，我们描述了Falcon Complete团队是如何在客户侧快速检测和清除这类复杂的攻击。在本文发布时，类似的攻击仍在继续。在此过程中，我们将探讨安全团队内部协作的关键作用。与Falcon Complete团队共同协作的事CrowdStrike Falcon OverWatch团队，他们是积极的威胁探寻者，在此次攻击中与CrowdStrike Intelligence团队共同提供了威胁的特征。我们的威胁专家在几分钟的时间内实现了对威胁的检测，随即有能力理解并应对这种新型威胁，最终阻止了攻击行为。

0x01 攻击概述

在此次攻击活动中，攻击者扫描并自动化利用多个0-Day漏洞（包括CVE-2021-26855、CVE-2021-26857、CVE-2021-26858和CVE-2021-27065），将ASPX格式的Webshell放置在存在漏洞的Microsoft Exchange服务器上。一旦成功后，就将其用于后漏洞利用的活动中。我们可以看到，这些漏洞影响包括2013、2016、2019在内的多个Exchange版本。在几乎所有案例中，投递的Webshell都是类似于菜刀的Webshell。

在本文后续部分，我们将展现安全运营团队处理复杂威胁的流程和运营思路。我们团队通过快速了解新型威胁和疑似0-Day、识别并隔离受影响的系统、删除关联的Webshell、通知受影响的客户威胁的影响方式等关键步骤，实现了快速有效的响应。

0x02 初始检测

从2月28日开始，Falcon OverWatch团队开始监测到新型入侵的相关迹象。我们观察到未知攻击者未经授权访问了多个客户环境、多台主机上的本地Microsoft Exchange应用池，随即我们立刻开始通知受影响的组织。与此同时，Falcon Complete团队立即开始对威胁开展深入调查。

根据我们的初步检测，可疑命令行与常见的Webshell行为一致。进一步分析表明，该Webshell类似于菜刀 Webshell的变种，这种Webshell由于其轻量级大小和使用简单而被攻击者广泛使用。

检测w3wp进程：

上图展示了使用Process Explorer查看到的感染链。在进程树中有两个值得关注的节点。首先，我们观察到W3WP.EXE视图利用名为“MSExchangeOWAAppPool”的Exchange应用程序池，因此可以确定W3WP.EXE为恶意进程。接下来，将会执行一个命令，通常在命令中会包含侦查相关的内容。

我们可以在关联的检测中查看执行详细信息，以此来识别被利用的应用程序池。如下图所示，我们高亮标记了W3WP.EXE进程运行的恶意命令之中的应用程序池。更准确地来说，这个命令本身并不是恶意的，所以我们可以对其进行精准分类。

w3wp.exe包含的CMD：

由于在CMD进程的“执行详细信息”中分析了其他上下文，因此我们现在能确定该活动为恶意活动。恶意活动如下图所示。根据其命令中的字符串模式（特别是以下高亮标记的字符串模式），表示Webshell视图从“Exchange Organization administrators”组中删除管理员帐户。目前还不清楚攻击者为什么要执行这一命令，但其作用是防止合法管理员阻止其执行命令。

Webshell命令：

但到这里，最初的感染载体仍然是未知的。我们在掌握了当前的检测信息，并确认该活动属于恶意之后，接下来的一步就是确定恶意活动的全部范围。

0x03 使用EDR数据进行调查

一旦掌握终端检测与响应（EDR）的丰富源数据，就能够确定每个终端的详细行为。我们的终端活动监视器（EAM）应用程序可以实时搜索执行数据，快速调查并确定受影响的范围。

针对Falcon Complete客户，我们使用了EAM的功能来查找写入到磁盘的Webshell文件，从而缩短响应时间并节省了工作量。

用于搜索ASPX文件写入的EAM查询：

我们的突破口是文件扩展名为“.ASPX”的写入磁盘的最新文件，以此来调查有关Webshell入侵的相关线索。这些文件表示威胁参与者已经上传到受感染主机的Webshell。在这里，团队利用了一个简单的命令来搜索任意“NewScriptWritten”事件。通过广泛的查询，我们识别到了其中的几个文件，但进一步排查确定只有“\inetpub\wwwroot\aspnet_client\system_web”路径下的文件才是恶意Webshell。不同漏洞利用所选取的目标路径各不相同，我们发现的其他路径可以参考最下方的威胁指标一节。

我们可以通过终端窗口中的实时响应工具来分析这些文件，也可以下载这些文件进行进一步的离线分析。在确定目标后，我们就可以深入研究这些文件，以获取其他上下文呢信息，如下图所示。

在此处观察到的写入时间相似的其他文件实际上与Exchange更新相关，并且是合法文件。

其他EAM详细信息：

在初步调查完成后，我们将工作方向转变为遏制和补救。

0x04 消除威胁

当涉及到高度复杂、从未见过、由国家支持的攻击时，一些技术就显得不太足够，这也就是在击杀链中的每一个环节都需要引入分析专家的原因。在我们检测到后漏洞利用活动时，我们会立即按照高危应急预案进行操作，第一时间联系客户，通知受影响主机范围，并详细介绍该恶意活动。

我们最初建议采取的恢复措施之一，是使用最新的补丁对主机进行修补。但是，由于该威胁参与者使用了多个0-Day漏洞，因此没有可用的补丁程序来缓解所有问题，攻击者可以重复进行多次漏洞利用。面对这样的场景，我们仍然成功阻止了攻击者的第二次攻击尝试。

在进行安全事件响应时，应该预见到可能存在的影响因素。如果客户只有一个Exchange Server网络，其中的一台主机可以切断客户的电子邮件通信，那么此时客户可能无法接收到通过电子邮件方式发送的威胁相关信息。在这种情况下，如果能通过与客户事先商定的其他通信方式配合使用，就可以迅速将事件通知到客户，并持续、即使地向他们提供更多信息和建议。

从初始检测过程中已知目录C:\inetpub\wwwroot\aspnet_client\system_web\位置开始，再到NewScriptWritten EAM事件中的匹配目录，分析人员开始在这些目录中查找潜在的Webshell。

在所有主机上，我们发现了具有与正则表达式字符串匹配的命名模式的Webshell，如下图所示。

Webshell名称符合正则表达式字符串的完整文件路径：

这些文件似乎是属于Microsoft Exchange。Server离线地址簿（OAB）配置文件，在外部URL部分似乎包含菜刀 Shell，如下图所示。

在主机上发现的Webshell，红色标记部分为类似于菜刀的脚本：

此外，在漏洞利用活动进行的同时，W3WP.EXE进程树下还包含一个CSC.EXE（C#命令行编译器）进程在磁盘上写入和编译临时DLL。

新的可执行写入和临时DLL文件路径正则表达式示例：

我们尝试恢复这些DLL。分析表明，当ASP.NET将.aspx文件编译为程序集时，通常会看到这些DLL文件。在首次访问.aspx文件时，ASP.NET会将结果程序集时复制到此临时目录中，此时会发生编译过程。

__BuildControlTree()函数示例，这是由ASP.NET运行时生成的程序集：

PageLoad()函数示例，这是由ASP.NET运行时生成的程序集：

在一个不与菜刀相似的示例中，我们发现了一个Shell，其作用是充当文件上传工具，将特定的文件写入到磁盘中。这个行为恰好与“MultiUp.aspx”的命名相符合。

不与菜刀相似的Shell：

接下来，我们继续查找和修复Webshell以及相关的DLL文件。

0x05 理解核心原因

每当我们对这类活动进行响应时，我们团队都会着重于理解已经检测到的内容以及如何对恶意活动进行遏制和补救，以确保客户受到保护。除了了解这些关键数据之外，如果能够了解漏洞利用的核心原因是非常有价值的，因为它有助于更加清楚地识别漏洞利用的发生方式，可以让我们能够实施其他保护措施，来防止进一步漏洞利用。

在消除威胁后，我们的团队就可以集中力量从主机中提取数据，以便确定其他信息并进行根本原因分析。我们的分析包括但不限于对来自主机的IIS日志文件、ECP日志文件和事件日志进行分析。

在调查任何Web漏洞利用时，Web日志都是一个有价值的信息来源。我们最开始就是从受影响的主机中提取了IIS日志，从中搜索关键特征，以尝试确认初始入侵点。正如在《2021年CrowdStrike全球威胁报告》中所讨论的，影响Microsoft Exchange Server的CVE-2020-0688是我们在2020年最常观察到的漏洞利用之一。

自然，我们首先以CVE-2020-0688作为关键词来搜索漏洞利用的证据，随后发现没有证据表明该漏洞已经被利用。此外，我们检查了主机的补丁安装情况，发现某些受到入侵的主机似乎已经更新了最新的Exchange补丁。

随后，我们开始调查其他潜在漏洞，包括最近发现和修复的Microsoft Exchange Server服务器欺骗漏洞CVE-2021-24085（可以用于特权提升）。这个漏洞的PoC代码在2月15日公开。

在IIS日志中，如果搜索与CVE-2021-24085相关的关键词，可能会找到一些有趣的结果，特别是对DDIService.svc的POST。

但是，在日志中看到的这些POST似乎不是对CVE-2021-24085的利用，特别是，目前我们没有看到其他指向CVE-2021-24085 CSRF Token生成（和之后的特权提升）过程的相关证据。

现在，我们掌握了两个事实。首先，从主机上发现的Webshell似乎是Microsoft Exchange Server离线通信簿（OAB）配置文件，在其“外部URL”部分包含类似于菜刀的Shell。其次，设置OABVirtualDirectory的DDIService.svc/SetObject的POST与我们已知的任意漏洞都不匹配，我们开始怀疑可能存在0-Day漏洞利用。

通过查看这些文件的写入时间戳，我们在多个客户的IIS日志中发现了一个共同之处，表明该日志可能与漏洞利用活动相关。

在对IIS日志进行分析的过程中，我们发现了对单个字母JavaScript文件的POST，这显然是不常见的行为。POST似乎是漏洞利用链中将Webshell写入主机的核心部分。不过我们没有从任何一台主机上收集到y.js的样本来确定这个文件的用途。

与DLL和Webshell文件写入的时间戳相对应的日志模式：

此外，在IIS日志中还有一些线索，展示了攻击者对Webshell的POST请求。这些POST对应我们在攻击活动的初始检测中所看到的命令执行。

至此，我们知道在漏洞利用过程中，会更新OABVirtualDirectory ExternalURL字段，以放入类似于菜刀的Webshell。事后看来，这可能涉及到PowerShell命令行开关“Set-OabVirtualDirectory”。

我们接下来着手于收集W3WP（IIS）进程的内存转储，以尝试恢复y.js文件或任何其他工件，从而发现最初漏洞利用的细节。我们最终从收集到的内存转储中提取了以下工件。

来自W3WP内存转储的数据：

解码后，我们得到了将初始命令传递到已投放的Webshell的证据。

解码后的数据：

在继续积极进行响应和补救的同时，我们继续分析了来自Exchange服务器的其他日志，以进一步了解我们观察到的内容。

在此过程中，我们查看了应用程序事件日志，并找到了其他日志源，从而有助于我们对漏洞利用进行更全面的了解：

事件ID 47 MSExchange控制面板：使用管理员SID，表明发生了特权提升

事件ID 4007 MSComplianceAudit：这一条目指向以下文件路径的Exchange审核日志：

“%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\LocalQueue\Exchange\”

通过对该审核日志进行分类，我们可以进一步了解漏洞利用过程，特别是以管理员帐户身份使用Set-OabVirtualDirectory通过菜刀Shell脚本修改“External URL”的Webshell投递过程。值得关注的是，该日志还体现了攻击者清理痕迹的行为，他们先使用了Remove-OabVirtualDirectory命令，随后使用了另一个Set-OabVirtualDirectory命令，以将配置恢复为原始状态。这一操作的目的可能是为了避免被任何查看Exchange配置的人发现。

如果你有权访问，就可以在“MSExchange管理”事件日志中看到这些活动。

接下来，我们将重点分析ECP服务器日志。由于在IIS日志中观察到对类似于“/ecp/y.js”的URI的POST请求，因此我们转而重点分析该日志。这表明攻击者尝试绕过身份验证并远程执行代码。

在ECP服务器日志中，包含了一个嵌入外部URL之中、类似于菜刀的Webshell，它利用Set-OabVirtualDirectory cmdlet修改了离线通讯簿（OAB）虚拟目录。

ECP服务器日志：

ECP活动日志中显示了针对指向/ecp/y.js的OABVirtualDirectory的SetObject命令请求。

ECP活动日志：

将ECP服务器日志时间戳和IIS日志关联起来，我们注意到有多个HTTP POST请求源于一个VPS地址，我们现在知道漏洞利用过程类似于远程代码执行，很可能是将CVE-2021-26858和CVE-2021-27065组合利用。

IIS日志：

在我们调查的过程中，Microsoft报告了Exchange存在的4个0-Day，我们发现观察到的恶意活动与这些0-Day相关联。随后，我们向客户提供了有关如何修复以及防止再次被攻击的安全建议。

0x06 缓解措施

为了防范这类持续威胁，我们建议组织采取以下措施。

1、限制访问。Microsoft提出最初的漏洞利用涉及到“与Exchange服务器的443接口建立不受信任的连接”。因此，我们建议设置Exchange Server的Web访问限制，确保仅有受信任的内网IP可以访问，或者将其放置在通过验证才能访问的VPN之后。

2、安装Exchange补丁程序。作为及时响应，我们建议所有Exchange Server应该安装KB5000871补丁程序，该补丁程序可修复恶意活动中利用的漏洞。更多信息可以参考Microsoft Exchange团队发布的文章。

3、阻止相关的恶意IP。迄今为止，恶意活动仅利用了有限数量的IP地址。如果在防火墙上阻止这些地址，可以在一定程度上防范相同攻击者继续使用原有IP地址发动的攻击。

4、主动寻找Webshell。在这篇文章中包含了威胁指标，以帮助查找该恶意活动中攻击者可能投放的Webshell。检索Exchange或Web服务器目录中新创建或新修改的ASPX文件可能能有效识别Webshell。管理员和安全人员可以查看可用的日志，以确认是否存在可疑活动或可疑迹象。

0x07 总结

我们将持续与客户展开紧密合作，并迅速做出响应，以检测并阻止这一恶意活动，防范攻击者的入侵尝试。我们可以使用各种分析工具和技术来进一步了解威胁，并更好地保护客户，使其能够专注于业务而不会受到干扰。即使是在Microsoft Exchange四个0-Day漏洞的持续大规模利用的场景中，借助标准化的排查手段，找准突破口层层深入，我们最终也成功发现并消除了威胁。

0x08 威胁指标

IP地址：

104.248.49[.]97

161.35.1[.]207

161.35.1[.]225

157.230.221[.]198

165.232.154[.]116

167.99.239[.]29

User Agent：

Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/74.0.3729.169+Safari/537.36

python-requests/2.24.0

ExchangeServicesClient/0.0.0.0

Webshell路径：

\[IIS Install Path]\aspnet_client\

\[IIS Install Path]\aspnet_client\system_web\

\[Exchange Install Path]\FrontEnd\HttpProxy\owa\auth\

Webshell文件名：

[0-9a-zA-Z]{8}.aspx

error.aspx

Logout.aspx

OutlookJP.aspx

MultiUp.aspx

Shell.aspx

RedirSuiteServerProxy.aspx

OutlookRU.aspx

Online.aspx

Discover.aspx

OutlookEN.aspx

HttpProxy.aspx

临时DLL写入路径：

C:\Windows\Microsoft.NET\Framework64\*\Temporary ASP.NET Files\root\*\*\App_Web_[0-9a-z]{8}.dll

本文翻译自：https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/如若转载，请注明原文地址：