我们是如何快速阻击针对Exchange服务器Zero-Day漏洞的入侵活动的（上）

我们是如何快速阻击针对Exchange服务器Zero-Day漏洞的入侵活动的（上）
2021-03-16 12:11:58 Author: www.secpulse.com(查看原文) 阅读量:329 收藏

原文地址：https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/

近期，微软的Microsoft Exchange服务器曝出了几个严重的安全漏洞，并有攻击者利用这些漏洞发动了入侵活动。本文中，我们详细介绍了我们的安全团队是如何通过齐心协力，在几分钟内无缝检测、理解和应对这一新威胁，并最终阻止相关的入侵活动的。

攻击活动概述

在本次的攻击活动中，攻击者自动扫描并利用了多个zero-day漏洞（CVE-2021-26855、CVE-2021-26857、CVE-2021-26858和CVE-2021-27065），将基于ASPX的webshell投放到易受攻击的Microsoft Exchange服务器上。当webshell被成功投放后，将用于后续的攻击活动。据悉，这些漏洞影响多个Exchange版本，包括2013、2016和2019等版本。

我们的安全团队通过快速了解新型威胁和潜在（现已确认）zero-day漏洞，识别并隔离受影响的系统，删除相关的webshell，并随时向受影响的客户通报每一步的处理情况，对该攻击活动做出了快速有效的响应。

初步检测

从2月28日星期日开始，我们的安全团队就发现了新型入侵行为的第一个迹象。他们观察到，一个未知的攻击者在未经授权的情况下访问了多个客户环境中的多台主机上运行的Microsoft Exchange应用池的实例，并立即通知了受影响的相关组织。同时，我们的团队立即着手深入调查威胁的性质。

经初步检测表明，一个被阻止的可疑命令行与常见webshells的行为一致。进一步分析发现，该webshell与类似中国菜刀的webshell相关的变种一致，由于其轻量级的特性和低进入门槛，这种webshell具有广泛的流行性。

图1 检测到的w3wp进程

上面的图1演示了这个感染链是如何出现在Falcon平台的Process Explorer中的。这个进程树有两个值得关注的节点。首先，OverWatch将W3WP.EXE进程标记为恶意进程，因为观察到它试图利用名为MSExchangeOWAAppPool的Exchange应用程序池。其次，它还执行了另一条命令，该命令被Falcon代理自动阻止了，因为它包含了与进行侦察的攻击者相关的特征。

通过查看关联检测中的执行细节，我们可以识别被利用的应用程序池。如下图2所示，其中应用池高亮显示的部分是在之前识别的W3WP.EXE进程下运行的恶意命令。这个命令本身的恶意行为并不是非常明显，所以，我们进行了进一步的分类。

图2 CMD环境下的w3wp.exe

通过在CMD进程的Execution Details中分析额外的上下文，最终确认该活动是恶意的。该恶意活动如下图3所示。该命令中的字符串模式，尤其是下面高亮显示的字符串模式，表明一个webshell正在试图从“Exchange Organization administrators”组中删除管理员帐户。目前还不清楚他们为什么要执行这条命令，尽管这可能只是表明他们的意图是废掉合法管理员的能力，以免阻挠他们的行动。无论哪种情况，破坏性活动最终都被Falcon代理阻止了。

图3 Webshell命令

此时，最初的感染载体仍然未知。一旦我们审查了手头的信息，并确认所注意到的活动是恶意的，下一步就是确定这个攻击活动的范围。

利用端点检测和响应数据进行调查

Falcon代理提供了丰富的端点检测和响应(EDR)遥测资源，可以帮助我们深入了解每个端点的行为。我们的端点活动监控器（EAM）应用提供了实时搜索这些执行数据的能力，并能快速调查和确定危害范围。同时，我们还可以利用EAM的强大功能来查找写入磁盘的webshell文件，加快响应时间，为他们节省精力。

图4 利用EAM查询搜索ASPX文件写入行为

为了查找相关的webshell，首先可以搜索识别最近写入磁盘的以.ASPX为文件扩展名的文件。这些文件代表了入侵者上传到受损主机的webshell。在这里，我们团队利用了一个简单的命令，就可以搜索所有的NewScriptWritten事件。通过这种广泛的查询，我们找到了几个文件，然而，最终发现只有\inetpub\wwwroot\aspnet_client\system_web目录下的文件才是恶意的webshell。这是因为，这些exploit的目标目录是各不相同的。至于我们发现的其他路径，请参阅下面的IOC部分。

一方面，我们能够通过实时响应工具在终端窗口中分析这些文件，同时，也可以下载这些文件进行进一步的离线分析。一旦识别出这些文件，我们就可以深入考察这些文件，以获得更多的上下文信息，具体如下图5所示。

这里观察到的其他具有类似写入时间的文件实际上与Exchange更新有关，并且是无害的。

图5 其他EAM详细信息

初步调查完成后，我们就转入遏制攻击和进行补救的阶段。

消除威胁

当涉及到高度复杂的、前所未见的攻击时，有时光靠技术是不够的——这就是为什么我们的分析师在杀伤链的每一步都随时准备着的原因。当防御系统检测到漏洞利用的活动后，团队立即开始按照我们的Critical Escalation Playbook制度与客户取得了联系。由于受影响的主机处于网络“收容”状态，我们开始给客户打电话，并通过电子邮件详细说明攻击活动的相关情况。

我们团队最初提议的恢复行动的一部分，是用最新的可用更新来给主机打补丁。为此，在与客户协调之后，解除了主机的收容状态；然而，由于攻击者利用了多个零日漏洞，因此，没有任何补丁可以缓解所有问题，上例中的服务器随后会被再次利用。尽管漏洞仍然存在，在没有有效补丁缓解的情况下，我们也防止和遏制了攻击者的第二次尝试。

在这个行业中，响应安全事件时应该预见到意外的障碍。其中一个障碍是：由于我们团队能够快速通过网络远程“收容”主机，以保护它们免受进一步攻击的影响，并阻止攻击者进一步的入侵活动；但是，如果客户只有一个Exchange服务器，如果用它来收容相关主机的话，将切断客户的电子邮件通信。但是，得益于我们的关键升级标准作业程序和预先商定的客户带外沟通路径，我们能够迅速通知我们的客户有关事件，并不断向他们及时更新进一步的信息和建议。

利用Falcon代理的实时响应能力，我们可以连接到受影响的主机，并收集恶意代码，以及进行修复活动。

通过初步检测中的Change Directory命令获悉的C:\inetpub\wwwroot\aspnet_client\system_web\目录，以及NewScriptWritten EAM事件中的匹配目录，分析人员开始查看其中的文件，以寻找潜在的webshell。

在所有的主机中，我们都发现了命名模式与图6所示的regex字符串相匹配的webshell。