GrimResource - 用于初始访问和规避的 Microsoft 管理控制台

Overview

在微软默认禁用来自互联网的文档的办公宏后，其他感染媒介（如 JavaScript、MSI 文件、LNK 对象和 ISO）的流行度激增。 然而，这些其他技术会受到防御者的严格审查，并且很有可能被发现。 成熟的攻击者试图利用新的和未公开的感染媒介来获取访问权限，同时逃避防御。 最近的一个例子是朝鲜参与者在 MSC 文件中使用了一种新的命令执行技术。

Elastic 研究人员发现了一种利用 MSC 文件的新感染技术，我们将其称为 GrimResource。 当用户点击特制的 MSC 文件后，它允许攻击者在mmc.exe上下文中执行完整的代码。 利用 GrimResource 的样本于 6 月 6 日首次上传到 VirusTotal。

关键要点

• Elastic Security 研究人员发现了一种新颖的野外代码执行技术，该技术利用了特制的 MSC 文件（称为 GrimResource）
• GrimResource 允许攻击者在 Microsoft 管理控制台 ( mmc.exe ) 中执行任意代码，且仅发出少量安全警告，是获取初始访问权限和逃避防御的理想方法
• Elastic 正在提供技术分析和检测指导，以便社区能够保护自己

分析

GrimResource技术的关键是利用apds.dll库中存在的旧XSS 缺陷。 通过在精心设计的 MSC 文件的相应 StringTable 部分中添加对易受攻击的 APDS 资源的引用，攻击者可以在mmc.exe的上下文中执行任意 javascript。 攻击者可以将此技术与DotNetToJScript结合起来以获得任意代码执行。

在撰写本文时，在野外发现的样本在VirusTotal中有 0 静态检测。

该样本以 transformNode 混淆技术开始，该技术在最近但不相关的宏样本中也曾观察到。 这有助于逃避 ActiveX 安全警告。

这会导致嵌入的 VBScript 被混淆，重构如下：

VBScript 在一系列环境变量中设置目标负载，然后利用DotNetToJs技术执行嵌入式 .NET 加载器。 我们将此组件命名为 PASTALOADER，并可能在未来发布针对此特定工具的更多分析。

PASTALOADER从上一步中VBScript设置的环境变量中检索有效载荷：

最后，PASTALOADER 生成一个新的dllhost.exe实例并将有效负载注入其中。 这是通过使用DirtyCLR技术、函数解除挂钩和间接系统调用以一种刻意隐秘的方式完成的。 在此样本中，最终的有效载荷是 Cobalt Strike。

检测

在本节中，我们将检查此样本的当前行为检测，并针对技术原语提出新的、更精确的检测方法。

通过 Microsoft 通用控制台进行可疑执行

这一检测是在我们发现这种新的执行技术之前建立的。 它最初是为了识别一种不同的方法（需要用户在打开 MSC 文件后单击任务板），该方法利用相同的 MSC 文件类型通过控制台任务板命令行属性执行命令：

process where event.action == "start" and
 process.parent.executable : "?:\\Windows\\System32\\mmc.exe" and  process.parent.args : "*.msc" and
 not process.parent.args : ("?:\\Windows\\System32\\*.msc", "?:\\Windows\\SysWOW64\\*.msc", "?:\\Program files\\*.msc", "?:\\Program Files (x86)\\*.msc") and
 not process.executable :
              ("?:\\Windows\\System32\\mmc.exe",
               "?:\\Windows\\System32\\wermgr.exe",
               "?:\\Windows\\System32\\WerFault.exe",
               "?:\\Windows\\SysWOW64\\mmc.exe",
               "?:\\Program Files\\*.exe",
               "?:\\Program Files (x86)\\*.exe",
               "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.EXE",
               "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe")

它在这里触发是因为该示例选择生成并注入 dllhost.exe 的牺牲实例：

在非标准 Windows 脚本解释器中创建的 .NET COM 对象

该样本使用DotNetToJScript技术，该技术会触发另一项检测，代表 Windows Script Host (WSH) 脚本引擎（Jscript 或 Vbscript）从 .NET 寻找 RWX 内存分配：

以下 EQL 规则将通过 .NET 加载器检测执行：

api where
  not process.name : ("cscript.exe", "wscript.exe") and
  process.code_signature.trusted == true and
  process.code_signature.subject_name : "Microsoft*" and
  process.Ext.api.name == "VirtualAlloc" and
  process.Ext.api.parameters.allocation_type == "RESERVE" and 
  process.Ext.api.parameters.protection == "RWX" and
  process.thread.Ext.call_stack_summary : (
    /* .NET is allocating executable memory on behalf of a WSH script engine
     * Note - this covers both .NET 2 and .NET 4 framework variants */
    "*|mscoree.dll|combase.dll|jscript.dll|*",
    "*|mscoree.dll|combase.dll|vbscript.dll|*",
    "*|mscoree.dll|combase.dll|jscript9.dll|*",
    "*|mscoree.dll|combase.dll|chakra.dll|*"
)

以下警报显示mmc.exe分配 RWX 内存，并且process.thread.Ext.call_stack_summary 捕获从vbscript.dll到clr.dll的分配来源：

通过 MMC 控制台文件执行脚本

之前的两次检测都是由特定的实施选择触发的，目的是将 GrimResource 方法（DotNetToJS 和生成子进程）武器化。 可以通过使用更多 OPSEC 安全替代方案来绕过这些检测。

其他最初看似可疑的行为（例如mmc.exe加载jscript.dll 、 vbscript.dll和msxml3.dll ）可以通过与良性数据进行比较来澄清。 我们可以看到，除了vbscript.dll之外，这些 WSH 引擎通常由mmc.exe加载：

该方法的核心部分涉及使用apds.dll通过 XSS 执行 Jscript。 此行为在 mmc.exe Procmon 输出中明显表现为CreateFile操作（ apds.dll未作为库加载）：

我们使用 Elastic Defend 文件打开事件添加了以下检测，其中目标文件为apds.dll且process.name为mmc.exe ：

以下 EQL 规则将从 MMC 控制台检测脚本的执行：

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action == "open" and file.path : "?:\\Windows\\System32\\apds.dll"]

通过 MMC 控制台文件执行 Windows 脚本

另一个检测和取证成果是，由于 APDS XSS重定向，在 INetCache 文件夹中创建了一个名为redirect[*] 临时 HTML 文件：

以下 EQL 关联可用于检测此行为，同时捕获 msc 文件路径：

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action in ("creation", "overwrite") and
  process.executable :  "?:\\Windows\\System32\\mmc.exe" and file.name : "redirect[?]" and 
  file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*\\redirect[?]"]

除了提供的行为规则外，还可以使用以下 YARA 规则来检测类似的文件：

rule Windows_GrimResource_MMC {
    meta:
        author = "Elastic Security"
        reference = "https://www.elastic.co/security-labs/GrimResource"
        reference_sample = "14bcb7196143fd2b800385e9b32cfacd837007b0face71a73b546b53310258bb"
        arch_context = "x86"
        scan_context = "file, memory"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $xml = "<?xml"
        $a = "MMC_ConsoleFile" 
        $b1 = "apds.dll" 
        $b2 = "res://"
        $b3 = "javascript:eval("
        $b4 = ".loadXML("
    condition:
       $xml at 0 and $a and 2 of ($b*)
}

结论

攻击者已经开发出一种新技术，可以使用精心设计的 MSC 文件在 Microsoft 管理控制台中执行任意代码。 Elastic 现有的开箱即用覆盖范围表明，我们的纵深防御方法即使针对此类新威胁也是有效的。 防御者应该利用我们的检测指导来保护自己和他们的客户免受这种技术的侵害，以免其扩散到商品威胁团。

Observables

所有可观察数据均可采用 ECS 和 STIX 格式下载。

本研究讨论了以下可观察的结果。