FalconFriday — Detecting MMC abuse using “GrimResource” with MDE — 0xFF24
Last 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 files
The 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.
By default, Windows will open a .msc file using MMC when the user double-clicks on it from Explorer.
Abusing MMC
While 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 access
To 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 restrictions
Since 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 telemetry
Based 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 memory
MDE 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 file
This 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 executable
Based 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:
- CreateRemoteThreadApiCall
- MemoryRemoteProtect
- NtAllocateVirtualMemoryRemoteApiCall
- NtMapViewOfSectionRemoteApiCall
- ReadProcessMemoryApiCall
- SetThreadContextRemoteApiCall
- QueueUserApcRemoteApiCall
Wrapping up
The “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 info@falconforce.nl.
