翻译：https://www.elastic.co/security-labs/grimresource

概述

自从Microsoft默认禁用了来自互联网的文档中的Office宏之后，像JavaScript、MSI文件、LNK对象和ISO等其他感染手段变得流行起来。然而，这些手段容易被安全专家发现并受到密切关注。老练的网络攻击者总是在寻找新的、未被广泛知晓的感染途径来绕过安全防护。近期的一个例子是，有朝鲜背景的攻击者在MSC文件中使用了一种新的命令执行技术。

Elastic的安全研究人员发现了一种新的感染技术，这种技术也利用了MSC文件，我们称之为“GrimResource”。它允许攻击者在用户点击一个特别制作的MSC文件后，在mmc.exe的上下文中完全执行代码。利用“GrimResource”的一个样本最早于6月6日上传到了VirusTotal。

关键点

Elastic安全研究人员揭露了一种新的野外代码执行技术，该技术利用了特别制作的MSC文件，称为“GrimResource”。
“GrimResource”允许攻击者在Microsoft管理控制台（mmc.exe）中执行任意代码，并且安全警告很少，这对于获取初始访问权限和规避安全防护非常理想。
Elastic正在提供这种技术的分析和检测指导，以便社区能够进行自我保护。

分析

“GrimResource”技术的核心是利用了apds.dll库中存在的一个旧的跨站脚本（XSS）漏洞。通过在制作的MSC文件的StringTable部分适当地引用这个易受攻击的APDS资源，攻击者可以在mmc.exe的上下文中执行任意的JavaScript。攻击者还可以将这种技术与DotNetToJScript结合起来，以获得任意代码的执行能力。


图1：参考 apds.dll 在 StringTable 中的重定向

在撰写本文时，VirusTotal 中野外样本的静态检测数为 0。


图2：VirusTotal 结果

样本以 transformNode 混淆技术开始，这是最近观察到的但与宏样本无关的技术。这有助于规避 ActiveX 安全警告。


图3：转换节点规避和混淆技术

这导致了一个混淆的嵌入式VBScript，如下所示：


图4：混淆的 VBScript

VBScript 通过一系列的环境变量设定了攻击目标，接着使用 DotNetToJs 技术来执行内嵌的 .NET 加载程序。我们将这个组件命名为 PASTALOADER，未来可能会对这一特定工具进行更深入的分析。


图5：设置目标有效载荷环境变量


图6：DotNetToJs 加载技术

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


图7：PASTALOADER 加载器检索有效载荷

最终，PASTALOADER 启动了 dllhost.exe 的一个新进程，并将有效载荷注入其中。这一过程采用了故意隐蔽的手段，使用了 DirtyCLR 技术（一种加载和执行 .NET 环境中恶意代码的方法）、函数解除挂钩（移除软件钩子的技术）和间接系统调用（通过间接方法调用系统功能，以规避安全检测）。在这个样本中，最终的有效载荷是被称为 Cobalt Strike 的恶意软件。


图8：注入到 dllhost.exe 的有效负载

检测

在这一部分，我们将分析这个样本的现有行为检测方法，并提出一些更新、更精确的检测方法，这些方法专注于攻击技术的基本操作。

可疑的MMC(Microsoft Common Console)执行行为

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


图9：命令任务 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 进程的一个实例中：


图10：GrimResource 被检测到

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

该样本采用了 DotNetToJScript 技术，这种技术会触发另一种检测机制，该机制寻找由 Windows 脚本宿主（WSH）脚本引擎（如 Jscript 或 Vbscript）代表进行的可读、可写、可执行（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的分配来源：


图11：mmc.exe 分配 RWX 内存

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

之前的两次检测是因为特定的实现选择被触发，这些选择用于利用 GrimResource 方法（通过 DotNetToJS 和生成子进程）。可以通过采用更符合运营安全的操作来绕过这些检测。

一些最初可能看起来可疑的行为 —— 例如 mmc.exe 进程加载 jscript.dll、vbscript.dll 和 msxml3.dll —— 可以通过与正常数据进行比较来解释。我们可以看到，除了 vbscript.dll 之外，mmc.exe 通常还会加载这些 WSH 脚本引擎：


图12：mmc.exe 的正常库加载行为

该方法的核心在于使用 apds.dll 通过 XSS 执行 Jscript。这种行为在 mmc.exe Procmon 输出中表现为 CreateFile 操作（ apds.dll 不作为库加载）。


图13：apds.dll 在 MSC StringTable 中被调用


图14：GrimResource 成功执行的示例

我们使用 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"]


图15：执行脚本的时间线通过MMC控制台展示

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

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


图16：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[?]"]


图17：时间线检测重定向.html

除了提供的行为规则外，以下 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 文件在微软管理控制台执行任意代码的新技术。Elastic 现成的即装即用安全措施表明，即使面对这种新型威胁，我们的多层次安全策略依然有效。防御者应当利用我们提供的检测指南，保护自己和客户不受这种技术侵害，防止其成为普遍的威胁手段。

IoC

Observable	Type	Name	Reference
`14bcb7196143fd2b800385e9b32cfacd837007b0face71a73b546b53310258bb`	SHA-256	`sccm-updater.msc`	Abused MSC file
`4cb575bc114d39f8f1e66d6e7c453987639289a28cd83a7d802744cd99087fd7`	SHA-256	N/A	PASTALOADER
`c1bba723f79282dceed4b8c40123c72a5dfcf4e3ff7dd48db8cb6c8772b60b88`	SHA-256	N/A	Cobalt Strike payload