Detection Logic Bugs, Developing Context to Bypass MiniPlasma Rules

Recently, because of Nightmare-eclipse’s Green Plasma and MiniPlasma variants, it’s been a busy week. There are tons of community detection rules out there now. But as someone who practices Adversarial Detection Engineering, that is, hunting for bugs in detection logic, you know a small tweaks can bypass detection.

Let me explain how.

For GreenPlasma to successfully escalate privileges to SYSTEM, the following sequence of Windows kernel and subsystem interactions must occur. If you are writing a robust detection rule, this is the only activity that matters.

TL:DR of the process: When a standard user triggers a UAC prompt, Windows switches to a secure desktop where processes like consent.exe run as SYSTEM. As part of that switch, a SYSTEM process creates a shared memory object at a predictable, hardcoded path. GreenPlasma exploits that predictability. The attacker pre-plants a symbolic link, at that exact path. The SYSTEM process follows it blindly, creating the memory object at the attacker’s chosen destination instead. The attacker’s unprivileged process grabs that handle the moment it appears, and that’s the foothold.

1. Text Services Framework (TSF) When a UAC prompt forces a switch to the Winlogon desktop, Windows activates a CTF server instance in SYSTEM context. Processes like consent.exe running on that desktop interact with TSF session objects as SYSTEM.

2. NtCreateSymbolicLinkObject Because the user's session isolates Object Manager namespaces, a standard user has write access to their own BaseNamedObjects directory. The exploit calls NtCreateSymbolicLinkObject to plant a malicious symlink at that location before the desktop switch completes.

3. Hardcoded Object Path The attacker cannot choose an arbitrary path. The Winlogon desktop context process is hardcoded to create its shared memory object at: \Sessions\<N>\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon<N> The symlink must be waiting at exactly this path.

4. Section Handle The SYSTEM context process follows the attacker’s symlink without verification, creating the Section Object at the attacker’s chosen destination. The attacker’s low-privileged process, polling in a loop via NtOpenSection,grabs a handle to that memory the moment it appears.

This is the exact moment SYSTEM is given.

With a handle to memory that a SYSTEM process is actively reading and executing, the attacker can manipulate its contents to redirect execution flow and spawn their payload.

So if your detection rule relies on detecting conhost.exe , you are in trouble.

In the GreenPlasma exploit, conhost.exe is nothing more than the bait. It is the catalyst used to force Windows to transition to the Secure Desktop.

Several community detection rules were published that incorrectly anchored their logic on the conhost.exe binary. These rules, integrated into platforms like Splunk Security Content and Palo Alto's Cortex XDR, typically look for anomalous invocations of the Windows Console Host as the primary indicator of compromise. Specifically, the detections trigger when conhost.exe is launched with unusual parameters (such as --headless), when it is executed via ShellExecute using runas to force a UAC prompt, or when it spawns suspicious child scripting processes. Because these rules rely on brittle string-matching of the process.name field, they are highly susceptible to the ADE3-01 Process Cloning bug, meaning an attacker can simply copy and rename the binary to bypass the logic entirely.

Wait.. what? How? Explain.

Standard users have implicit Read and Execute permissions for almost everything in the System32 directory.

• The operating system requires standard users to be able to read and run conhost.exe whenever they open a basic command prompt (cmd.exe).
• Because a file copy operation only requires the ability to read the source file data streams, any standard user can read the contents of conhost.exe and pipe it into a new file elsewhere.

So.. When you copy conhost.exe to a user-writable directory and rename it to something likeconthehost.exe, Windows treats it as a completely valid, functioning executable.

• No Internal Dependency on Name: The binary does not care what its filename is on disk. It will launch, initialize the console sub-system, and look for a parent or child process to host.
• Signature Remains Valid: The embedded Microsoft digital signature stays intact. If an EDR checks the file’s hash or signature block, it still verifies as legitimate Microsoft code.

Now you might think, but then the context isn’t system it’s user. Aha! you ate the bait, it’s got nothing to do with conhost.exe as system.

So IF:

• The attacker clones conhost.exe to %APPDATA%\conthehost.exe to bypass string-based rules looking for conhost.exe.
• The attacker executes conthehost.exe using the runas verb (ShellExecuteEx).
• This then forces Windows to switch desktops to show the UAC elevation prompt.
• The act of switching to the secure Winlogon desktop triggers a privileged text services thread running natively as NT AUTHORITY\SYSTEM.
• That SYSTEM thread looks for its text memory sections, hits the attacker’s poisoned symbolic links, and that is what grants the attacker the SYSTEM handle.. not the renamed binary itself.

So this means that this rule is bypassed (KQL).

And any other that relies on conhost.exestring in the query.

If you want to know more about detection rule bypasses, how to find and fix them, and other types of bypasses — then follow me on Medium or Linkedin.

I try to drop some good ones regularly!

A more robust rule

Blackfort Technology confirmed the strongest IOCs are the registry artifacts. The BlockedApps key created as a volatile REG_LINK and SymbolicLinkValue pointing to ...\Policies\System showed the best signal-to-noise ratio in testing, producing very few false positives.

Here’s a psuedo rule that fixes this bug.

WITHIN 10 minute sliding window, ON SAME device + user:

STAGE 1 (Required):
  Registry key CREATED
  WHERE key path contains "CloudFiles\BlockedApps"

STAGE 2 (Required):
  Registry value SET
  WHERE key path contains "CloudFiles\BlockedApps"
  AND value name == "SymbolicLinkValue"
  AND value data contains "Policies\System"

  STAGE 1 must precede STAGE 2

IF (STAGE 1 AND STAGE 2):
  → ALERT

NEVER filter on:
  - process.name (cloning resilient)
  - binary hash
  - parent process name

But it doesn’t stop there. There are TONs of examples out there where process cloning can bypass detection rules. TONs. And process cloning is only one of many categories of detection logic bugs.

ADE3 — Context Development

From the Adversarial Detection Engineering’s framework, this bug taxonomy covers activities where the attacker takes additional, specific steps to poison/change the data values in the record to bypass the conditions within the rule. The attacker is developing the context surrounding the in-scope activity.

ADE3–01 Context Development — Process Cloning

This exists when the detection logic relies on a string match for a specific process or binary, yet the detection rule activity assumes a certain level of privileges are held by the attacker which also includes the ability to clone binaries and rename them. This is a bug by the cloning of processes.

ADE3–02 Context Development — Aggregation Hijacking

This is a bug by Hijacking the Aggregation Outcomes in the detection logic, which occurs when the detection logic in question contains an aggregation, which the attacker can control the aggregated value of. For example, file name lengths and file sizes.
It also occurs when the rule aggregates the logs into a UEBA entity such as source.ip:user.name combination and flags the activity if not present over a certain time period. Depending on the logic of the rule, and the specific context in the environment at time of compromise/activity, an attacker may undertake activity to gather information to assess whether or not they will be aggregated into an existing baseline which won’t be flagged, prior to undertaking the in-scope activity.

ADE3–03 Context Development — Timing and Scheduling

This occurs when the detection logic relies on time difference or duration schedules to identify unusual behavior. The attacker may be able to conduct activity in a manner that manipulates the time metric during the search to not get included in the hits, across each rule execution run. This is a bug by the manipulation of timing characteristics in an attack.

Other ADE3–01 Context Development — Process Cloning bypass examples can be found at the ADE framework repo.

https://github.com/NikolasBielski/Adversarial-Detection-Engineering-Framework

Detection Logic Bugs, Developing Context to Bypass MiniPlasma Rules was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.

Article Link: https://detect.fyi/detection-logic-bugs-developing-context-to-bypass-miniplasma-rules-903f1d7c68e8?source=rss----d5fd8f494f6a---4

1 post - 1 participant

Read full topic

Malware Analysis, News and Indicators - Latest topics