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

2021-03-16 8,585

原文地址: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。

 

1.png 

图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的副本,以确认该文件的用途。

 

1.png

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

 

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

 

 1.png

图15  向webshell发送的请求

 

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

 

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

 

1.png

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

 

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

 

1.png

图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)虚拟目录。

 

1.png

图18  ECP服务器日志

 

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

 

1.png

图19  ECP活动日志

 

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

 

1.png 

图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

Tags:
评论  (0)
快来写下你的想法吧!

mssp299

文章数:51 积分: 662

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号