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

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

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

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

查找漏洞的根本原因

每当应对此类攻击活动时，我们团队都会强调了解已检测到的内容，以及如何对这些攻击活动进行遏制和补救，以确保我们的客户受到相应的保护。除了了解这些关键数据外，能够了解漏洞的根本原因也是非常有价值的，因为这有助于更清楚地识别漏洞是如何发生的，并实施额外的防护措施，以防止未来进一步的攻击活动。

一旦威胁被消除，我们的团队就能够将工作重心转向从主机本身提取数据，以确定更多信息并进行漏洞根本原因的分析。这种分析包括但不限于分析IIS日志文件、ECP日志文件和主机的事件日志。

在调查Web攻击时，网络日志是一个非常有价值的信息来源。于是，我们立即开始从受影响的主机中提取IIS日志，以搜索相关证据，试图确认攻击的切入点。正如2021年CrowdStrike全球威胁报告中所讨论的那样，影响微软Exchange服务器的CVE-2020-0688是CrowdStrike在2020年期间观察到的最常见的漏洞之一。

于是，我们首先搜索了通过CVE-2020-0688发动攻击的证据，并很快意识到没有证据表明这次利用了该漏洞。此外，我们还仔细检查了主机的补丁级别，并注意到一些被入侵的主机似乎已经打了最新版本的Exchange补丁。

随后，我们开始调查其他潜在的漏洞，包括最近曝光并已经修复的Microsoft Exchange Server服务器欺骗漏洞CVE-2021-24085（可利用该漏洞提升权限）。值得注意的是，该漏洞的PoC代码已于2月15日公开发布。

通过IIS日志搜索与CVE-2021-24085相关的证据，我们得到了一些有趣的结果，特别是发送到DDIService.svc的POST。

图13  发送到DDIService.svc的POST

然而，在日志中观察到的这些POST似乎并不是针对CVE-2021-24085的利用代码，特别是我们没有看到额外的证据指向CVE-2021-24085的CSRF令牌生成（以及随后的提权）部分。

我们现在掌握了两个事实：首先，从主机上找到的webshell似乎是Microsoft Exchange Server Offline Address Book (OAB)配置文件，外部URL部分有一个类似China Chopper的shell；其次，设置OABVirtualDirectory的DDIService.svc/SetObject的POST与CrowdStrike所知道的Microsoft Exchange的任何已知漏洞都不匹配。我们开始怀疑这次攻击利用了zero-day漏洞，并立即通知CrowdStrike情报团队并展开合作。

围绕着这些文件被写入的时间戳，我们在多个客户的IIS日志中发现了一种行为模式，从而表明这种日志模式很可能与漏洞利用活动有关。

在进行IIS日志分析时，通过POST向单字母JavaScript文件发送请求是一种非常不同寻常的行为。我们发现，该POST似乎是将webshell写入主机的利用链的核心部分。 值得注意的是，我们无法从这些活动中收集y.js的副本，以确认该文件的用途。

图14  对应于DLL和Webshell文件写入的时间戳的日志模式

此外，在IIS日志中，我们还找到了攻击者会向webshell发送POST请求的线索。这些POST对应于针对该攻击活动的初始检测中发现的命令执行。

图15  向webshell发送的请求

此时我们知道，针对这些漏洞的利用活动在某种程度上与更新OABVirtualDirectory ExternalURL字段有关，包括一个类似于China Chopper的webshell，事后我们知道这涉及到PowerShell commandlet即“Set-OabVirtualDirectory”。

我们继续收集W3WP(IIS)进程的内存转储，试图恢复y.js文件或其他线索，以帮助我们发现原始攻击的相关细节。通过与OverWatch团队的紧密合作，我们从收集到的内存转储中提取了以下工件。

图16  来自W3WP内存转储的数据

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

图17.从W3WP内存转储中解密的数据

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

在分析过程中，我们审查了应用程序事件日志，我们能够确定更多的日志来源，以帮助我们了解更广泛的漏洞利用情况。

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

事件ID 4007 MSComplianceAudit：该条目指向包含在以下文件路径的Exchange审计日志：

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

通过对该审计日志的分析，我们进一步了解了漏洞的利用过程，特别是使用Set-OabVirtualDirectory以管理员身份投放了许多webshell，并通过“Chopper ” Shell脚本修改外部URL字段。有趣的是，该日志还显示了入侵者清除自己踪迹的行为：首先使用Remove-OabVirtualDirectory命令，然后再使用Set-OabVirtualDirectory将配置返回到其原始状态，这可能是为了防止检查Exchange配置的人发现入侵踪迹。

类似的活动也可以在“MSExchange管理”事件日志中看到，如果你能访问这些日志的话。

接下来，我们转而分析ECP服务器日志。我们之所以对它感兴趣，是因为在IIS日志中观察到了包含类似“/ecp/y.js”字符串的URI的POST请求。这表明有人试图绕过认证并远程执行代码。

图18中的ECP服务器日志表明，在外部URL部分嵌入了一个类似Chopper的webshell，它利用Set-OabVirtualDirectory cmdlet来修改离线地址簿（OAB）虚拟目录。

图18  ECP服务器日志

在图19显示的ECP活动日志中，可以看到针对/ecp/y.js的OABVirtualDirectory的SetObject命令的请求。

图19  ECP活动日志

将ECP服务器的日志时间戳与IIS日志进行关联，我们注意到多个来源于虚拟专用服务器（VPS）地址的HTTP POST请求，我们现在知道，这些请求类似于远程代码执行，很可能是CVE-2021-26858和CVE-2021-27065漏洞被联合利用了。

图20  IIS日志

此时，恰好微软发布了在Exchange中发现了四个zero-day漏洞的安全报告，所以，我们将观察到的入侵活动与微软报告的zero-day漏洞关联了起来，并向客户提供关于如何打补丁的建议，以防止进一步的入侵活动。

缓解措施

为了防范这种持续的威胁，我们建议各组织实施以下措施：

•     限制访问权限。微软提到的初始漏洞利用方法涉及“能够对Exchange服务器443端口进行不受信任的连接”的要求。正因为如此，我们建议对Exchange服务器的网络访问至少要限制在无法及时应用补丁的受信任的内部IP上，或者将其放在只能由经过认证的客户端访问的VPN后面。

•     及时安装补丁。作为即时响应，我们建议在所有Exchange服务器上安装KB5000871中包含的补丁程序，该补丁程序修复了本次入侵活动中利用的漏洞。有关相关补丁的更多信息，请访问下面的链接：https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901。

•     阻止相关的恶意IP。到目前为止，这些入侵活动中，仅涉及到有限数量的IP地址。通过在您的防火墙上阻止这些地址，只要利用这些漏洞的入侵者还是来自同一IP，就能将之拒之门外。

•     主动猎取Webshell。在本文中，我们已经提供了一些指标，以帮助大家查找与本次入侵相关的webshell。

结论

本文中，我们详细介绍了针对Microsoft Exchange新型漏洞的安全响应过程，希望对大家有所帮助。

IOC

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

用户代理

• 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

本文作者：mssp299

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/154900.html