Full Report
FalconFriday — Detecting MMC abuse using “GrimResource” with MDE — 0xFF24Last week, Elastic Security Labs released a blog post detailing the “GrimResource” technique used by both red teams and malicious actors. This technique is based on crafting malicious .MSC files that are opened in the Microsoft Management Console (MMC).In this short FalconFriday blog post we provide three detections to detect MMC abuse, based on behavioral patterns. These detections can be used directly in an out-of-the-box configuration of Microsoft Defender for Endpoint (MDE).As always, the detections are available free of charge from our FalconFriday Github repository [1] [2] [3].Introduction to MMC and .msc filesThe MMC allows managing various components of a Windows environment using so called ‘snap-ins’. These ‘snap-ins’ are COM objects that are referenced from files with the .msc file extension. A commonly used MMC snap-in is the “Group Policy Editor” that is referenced from the ‘gpedit.msc’ file. One .msc file can reference multiple COM objects that represent the ‘snap-ins’ to show inside MMC.Example of MMC running the “Local Group Policy Editor” snap-in.By default, Windows will open a .msc file using MMC when the user double-clicks on it from Explorer.Example of a warning shown when opening a .msc file that is downloaded from the internet.Abusing MMCWhile MMC snap-ins can execute code, they can only call previously registered COM objects. Therefore, they cannot directly be used to call arbitrary code and are not typically considered executable files.The fact that MMC can be abused for malicious activities is something we have also observed in the past. For example, the Kamikaze payload used in the UACME collection that we analyzed in a previous FalconFriday blog post contains a malicious MMC file dating back to 2017 that can run an arbitrary command when it is opened.The recently documented “GrimResource” technique also uses a malicious .msc file. It chains multiple vulnerabilities and techniques together to load a .NET assembly that subsequently loads or injects a shellcode payload. The Elastic Security Labs blog post contains a detailed overview of the various techniques that are used for this.There are multiple purposes for which a malicious .msc file could be abused.Abusing MMC for initial accessTo gain initial access to a machine, a user could be tricked into opening a malicious .msc file. Users might be familiar with .exe and other common executable file extensions, but are likely to be unfamiliar with .msc files. Additionally, the icon of the .msc file can be modified by the attacker, allowing to further disguise the malicious payload as a legitimate file. For example, mimicking an Office document.Abusing MMC to bypass AppLocker or other executable restrictionsSince MMC is a commonly used administrative tool it is likely that it’s execution is allowed even in environments that have a very strict AppLocker policy to block execution of untrusted code.Detecting MMC abuse using MDE telemetryBased on trying out various variations of the “GrimResource” technique in our lab environment we came up with three detections that can be implemented using out-of-the box MDE telemetry.Detection #1 — MMC loading a .NET assembly from memoryMDE provides telemetry when a .NET assembly is loaded from memory (as opposed to being loaded from a .DLL file on disk) via the “ClrUnbackedModuleLoaded” event in the “DeviceEvents” table.This first query looks for .NET assemblies being loaded from memory by the MMC process. Based on baselining performed in multiple environments it appears that there are some legitimate .msc files that perform such module loads. Therefore, the query attempts to extract the name of the .msc file that was used to start MMC by parsing the command-line. If a known .msc file was used to launch the MMC process, no alert will be triggered. The list of known .msc files can be extended to fit the environment where the detection is deployed.Detection #2 — MMC launched via suspicious MSC fileThis detection covers the initial access scenario where a user is tricked into downloading a malicious .msc file and opens it.This second query looks for a number of conditions to mark an MMC file as suspicious:.msc files downloaded by web browsers, based on the process that created the file or the file being renamed from the .crdownload extension..msc files located in the Downloads folder..msc files that were recently extracted from ZIP files..msc files with a Mark Of The Web (MOTW).If these .msc files are subsequently opened by the user this will trigger the detection.Detection #3 — Process injection from MMC executableBased on baselining performed in multiple environments, we saw that the MMC executable does not inject into other processes under normal circumstances. Therefore, any cases where MMC initiates process injection should be considered as suspicious.This third query looks for the MMC process initiating process injection actions by looking at a number of events in MDE that are related to process injection:CreateRemoteThreadApiCallMemoryRemoteProtectNtAllocateVirtualMemoryRemoteApiCallNtMapViewOfSectionRemoteApiCallReadProcessMemoryApiCallSetThreadContextRemoteApiCallQueueUserApcRemoteApiCallWrapping upThe “GrimResource” technique is an interesting new attack vector that could be abused for initial access and to bypass certain AppLocker policies. We hope the publicly available detection content in this blog will help in preventing this technique from being successfully abused by malicious actors.Want to have access to our repository with over 500 advanced detections? Please have a look at our commercial offering and reach out via [email protected] — Detecting MMC abuse using “GrimResource” with MDE — 0xFF24 was originally published in FalconForce on Medium, where people are continuing the conversation by highlighting and responding to this story.
Analysis Summary
# Tool/Technique: GrimResource (MMC Abuse)
## Overview
The "GrimResource" technique involves crafting malicious Microsoft Management Console (.MSC) files. When executed, these files chain multiple vulnerabilities and techniques to load a .NET assembly, which subsequently loads or injects a shellcode payload. This technique is used by both red teams and malicious actors for initial access and to bypass executable restrictions like AppLocker, leveraging the trusted nature of the `mmc.exe` process.
## Technical Details
- Type: Technique
- Platform: Windows
- Capabilities: Execution via execution of a configuration file format (.msc), loading arbitrary .NET assemblies from memory, process injection, and potential evasion of application whitelisting controls.
- First Seen: Related malicious MMC files (e.g., Kamikaze payload) date back to 2017, but "GrimResource" is the recently documented chaining of techniques leading to shellcode injection via .NET assembly loading.
## MITRE ATT&CK Mapping
- **TA0001 - Initial Access**
- T1204.002 - User Execution: Malicious File
- **TA0002 - Execution**
- T1059.005 - Command and Scripting Interpreter: Visual Basic
- **TA0005 - Defense Evasion**
- T1036.005 - Masquerading: Match Legitimate Name or Location
- **TA0008 - Lateral Movement** (Implied by subsequent shellcode execution)
- T1572 - Protocol Tunneling (If shellcode executes)
## Functionality
### Core Capabilities
1. **Initial Access via Social Engineering:** Tricking users into opening a malicious `.msc` file, often disguised with a familiar icon (like an Office document) due to users being less familiar with the `.msc` extension.
2. **Evasion of Application Whitelisting:** Utilizing `mmc.exe`, a commonly allowed administrative tool, to execute payloads, potentially bypassing strict AppLocker policies that block arbitrary executables.
3. **Command Execution via COM Objects:** Leveraging registered COM objects referenced within the `.msc` file structure to initiate execution chains.
### Advanced Features
1. **In-Memory .NET Loading:** The chained technique loads a malicious .NET assembly directly into memory (`ClrUnbackedModuleLoaded` event), bypassing detection methods focused on file-on-disk artifacts for that assembly.
2. **Process Injection:** The malicious chain culminates with the `mmc.exe` process initiating process injection into other processes, often preceding the final shellcode execution.
3. **Historical Precedent:** Related techniques existed previously, such as the Kamikaze payload in the UACME collection (dating back to 2017).
## Indicators of Compromise
- **File Hashes:** Not specified in the text.
- **File Names:** Malicious files with the `.msc` extension, potentially customized or renamed for social engineering.
- **Registry Keys:** Not specified in the text.
- **Network Indicators:** Not specified in the text directly for the loading process, though subsequent shellcode actions might involve C2 communication.
- **Behavioral Indicators:**
* Detection #1: `mmc.exe` loading a .NET assembly from memory (`DeviceEvents` table, `ClrUnbackedModuleLoaded` event), where the starting `.msc` file name is not whitelisted (i.e., not a known legitimate `.msc`).
* Detection #2: Suspicious `.msc` files being opened, specifically:
* `.msc` files downloaded by web browsers.
* `.msc` files located in the Downloads folder.
* `.msc` files recently extracted from ZIP archives.
* `.msc` files exhibiting a Mark Of The Web (MOTW).
* Detection #3: `mmc.exe` initiating process injection activities (e.g., `CreateRemoteThreadApiCall`, `NtAllocateVirtualMemory`, `NtMapViewOfSection`).
## Associated Threat Actors
- Used by **Red Teams** and **Malicious Actors** (general reference).
- The Kamikaze payload associated with the **UACME** collection demonstrated earlier use of malicious `.msc` files.
## Detection Methods
Detection relies on Microsoft Defender for Endpoint (MDE) telemetry:
1. **Memory Artifact Analysis:** Monitoring for `mmc.exe` loading .NET assemblies from memory (`ClrUnbackedModuleLoaded`).
2. **File Origin/Context Analysis:** Identifying `.msc` files originating from web downloads, the Downloads folder, or archive extraction, followed by execution.
3. **Process Behavior Monitoring:** Detecting anomalous behavior from `mmc.exe`, particularly if it initiates remote thread creation or other process injection calls.
## Mitigation Strategies
1. **User Education:** Training users to recognize and be suspicious of unfamiliar file extensions like `.msc`, especially when downloaded from the internet.
2. **Application Control:** Leveraging AppLocker or similar controls to restrict the execution of applications based on path or publisher, although this technique specifically attempts to bypass such restrictions via `mmc.exe`.
3. **Enhanced MDE Monitoring:** Deploying the three behavioral detection queries provided in the source article within MDE to catch the execution chain in progress.
## Related Tools/Techniques
- **Kamikaze Payload/UACME Collection:** Earlier examples of malicious MMC file usage (2017).
- **General COM Abuse:** Utilizing COM objects for execution flow.
- **Standard Process Injection Techniques:** The final stage of the attack relies on common process injection API calls.