Listen to this Post
Introduction
Researchers have confirmed that a publicly available local privilege escalation exploit, dubbed “MiniPlasma,” grants attackers full SYSTEM access on fully patched Windows 11 systems—including those updated with the latest May 2026 Patch Tuesday fixes. The vulnerability, a race condition in the Windows Cloud Files Filter driver (cldflt.sys), was first reported to Microsoft in September 2020 and assigned CVE‑2020‑17103, but according to multiple independent tests, the original proof‑of‑concept (PoC) works unchanged six years later, raising serious questions about the efficacy of long‑standing patch processes.
Learning Objectives
- Understand the technical root cause of the MiniPlasma exploit and how it abuses the cldflt.sys driver to bypass Windows privilege boundaries.
- Learn to detect and block MiniPlasma activity using Sigma rules, behavioral monitoring, and Microsoft Defender’s built‑in protections.
- Implement practical mitigation measures, including registry hardening, EDR/SIEM rules, and system configuration changes to prevent local privilege escalation.
You Should Know
1. How MiniPlasma Exploits the Cloud Filter Driver
MiniPlasma targets the Windows Cloud Files Minifilter Driver, cldflt.sys, specifically the routine HsmOsBlockPlaceholderAccess. The exploit leverages a race condition to write arbitrary registry keys into the `USER.DEFAULT` hive without proper access checks, using an undocumented API called CfAbortHydration. By hijacking the `windir` environment variable for the SYSTEM account, the attacker redirects the Windows Error Reporting (WER) `QueueReporting` scheduled task to execute a malicious binary of their choice with SYSTEM privileges.
Step‑by‑step explanation of the exploit chain:
- Initial foothold: The attacker must already have local code execution on the target—typically via phishing, drive‑by download, or another initial access vector. MiniPlasma is not a remote code execution flaw; it elevates an existing low‑privileged user to SYSTEM.
- Race condition trigger: The exploit creates a timing window where it can write a registry key in the `USER.DEFAULT\Volatile Environment` path. No legitimate software ever writes to this location, making it a reliable detection indicator.
- Environment variable hijack: By setting the `windir` variable to a path containing the attacker’s binary, the exploit forces the WER `QueueReporting` scheduled task—which runs as SYSTEM—to execute that binary instead of the legitimate
werfault.exe. - SYSTEM shell: The malicious binary (often a simple `cmd.exe` or reverse shell) spawns with full SYSTEM privileges. In tests, running the exploit from a standard user account opened a command prompt with `nt authority\system` identity within seconds.
Why it works on fully patched systems: Microsoft released a patch for CVE‑2020‑17103 in December 2020, but the underlying issue remains exploitable. The researcher who released MiniPlasma states: “I’m unsure if Microsoft just never patched the issue or the patch was silently rolled back at some point for unknown reasons”. The original Google Project Zero PoC works unchanged, and the vulnerability affects “all Windows versions”.
PowerShell detection script (run as Administrator to check for potential exploitation remnants):
Check for suspicious registry writes in USER.DEFAULT volatile environment
Get-ChildItem "Registry::HKEY_USERS.DEFAULT\Volatile Environment" | ForEach-Object {
if ($<em>.GetValue("windir") -ne $null) {
Write-Host "Potential MiniPlasma artifact detected!" -ForegroundColor Red
Write-Host "windir value: $($</em>.GetValue('windir'))"
}
}
2. Microsoft Defender’s Built‑in Block—and What It Misses
According to independent tests by security researcher Bartosz Wysocki, Microsoft Defender does block MiniPlasma out of the box on properly maintained systems with up‑to‑date signatures. This is a crucial layer of defense, but it is not a complete solution. Defender’s static signatures can be bypassed with minor modifications to the exploit binary, and the vulnerability itself remains present in the kernel driver regardless of AV status.
Step‑by‑step guide to verify and strengthen Microsoft Defender settings:
- Ensure real‑time protection is enabled (default on most systems):
Check Defender status Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled, AntivirusEnabled
-
Update signatures aggressively—especially given the public availability of the PoC:
"C:\Program Files\Windows Defender\MpCmdRun.exe" -SignatureUpdate
-
Enable cloud‑delivered protection and sample submission for faster zero‑day detection:
Set-MpPreference -CloudBlockLevel High -SubmitSamplesConsent Always
-
Configure Attack Surface Reduction (ASR) rules to block common privilege escalation patterns:
Block process creations originating from PSExec and WMI commands Add-MpPreference -AttackSurfaceReductionRules_Ids "d3e037e1-3eb8-44c8-a917-579279475963" -AttackSurfaceReductionRules_Actions Enabled
Critical limitation: Microsoft Defender’s block is signature‑based. If an attacker recompiles the exploit or obfuscates its payload, the detection may fail. Therefore, relying solely on Defender is insufficient—organisations must implement deeper monitoring.
3. Sigma Rule for Proactive Detection
Security teams can deploy a purpose‑built Sigma rule to detect the core exploit primitive: a registry write to USER.DEFAULT\Volatile Environment\windir. This rule works across all major SIEM platforms (Splunk, QRadar, Sentinel) and provides a high‑confidence indicator of MiniPlasma activity because legitimate software never accesses this registry path.
Sigma rule YAML (miniplasma_wer_windir_hijack.yml):
title: MiniPlasma WER Windir Hijack status: experimental description: Detects registry modification to USER.DEFAULT\Volatile Environment\windir references: - https://github.com/Nightmare-Eclipse/MiniPlasma logsource: product: windows service: security category: registry_event detection: selection: TargetObject|contains: 'USER.DEFAULT\Volatile Environment' TargetObject|endswith: '\windir' condition: selection falsepositives: None (legitimate software never writes here) level: critical
Step‑by‑step deployment instructions:
1. Save the rule as `miniplasma_wer_windir_hijack.yml`.
- Convert to your SIEM’s format using the Sigma CLI:
sigma convert -t splunk -p windows miniplasma_wer_windir_hijack.yml > miniplasma_splunk.conf
- Deploy to your SIEM following your organisation’s change management process.
- Create an alert that triggers immediately on any match—this is a red‑level indicator.
KQL query for Microsoft Sentinel:
DeviceRegistryEvents | where RegistryKey contains @"USER.DEFAULT\Volatile Environment" | where RegistryValueName == "windir" | project Timestamp, DeviceName, InitiatingProcessAccountName, RegistryKey, RegistryValueData
4. Advanced EDR/SIEM Hunting Queries
Because MiniPlasma spawns a SYSTEM‑level `cmd.exe` or reverse shell from a low‑privileged context, EDR solutions can detect this anomalous process lineage. The core hunting logic focuses on unexpected child processes of high‑privileged services.
Sysmon‑based detection (Windows Event ID 1):
<Sysmon> <EventFiltering> <RuleGroup name="MiniPlasma_hunt" groupRelation="and"> <ProcessCreate onmatch="include"> <!-- Suspicious parent processes: WerFault.exe, svchost.exe, QueueReporting task --> <ParentImage condition="contains">WerFault.exe</ParentImage> <ParentImage condition="contains">svchost.exe</ParentImage> <CommandLine condition="contains">cmd.exe</CommandLine> <CommandLine condition="contains">powershell.exe</CommandLine> <!-- Detect elevation from medium integrity to SYSTEM --> <User condition="contains">NT AUTHORITY\SYSTEM</User> </ProcessCreate> </RuleGroup> </EventFiltering> </Sysmon>
Splunk search:
index=windows sourcetype=WinEventLog:Security EventCode=4688 | where Process_CommandLine="cmd.exe" OR Process_CommandLine="powershell.exe" | where Parent_Process_Name="WerFault.exe" OR Parent_Process_Name="svchost.exe" | where Account_Name="NT AUTHORITY\SYSTEM" | table _time, ComputerName, Account_Name, Parent_Process_Name, Process_CommandLine
Linux‑based EDR correlation (if monitoring Windows via cross‑platform tools):
Monitor for SMB/RPC connections that might indicate lateral movement from compromised SYSTEM account sudo tcpdump -i eth0 'port 445' -e -n -c 100
5. Registry Hardening and Scheduled Task Monitoring
The exploit’s success depends on modifying the `USER.DEFAULT` hive. Administrators can pre‑emptively harden this location using Windows security policies, though a complete fix must come from Microsoft.
Step‑by‑step hardening guide:
- Block write access to the volatile environment path for non‑administrative users (use `Process Monitor` to test policies before deployment):
icacls "C:\Users\Default\NTUSER.DAT" /deny "Users:(W)"
2. Monitor the `QueueReporting` scheduled task for changes:
Export current task configuration as baseline schtasks /query /tn "\Microsoft\Windows\Windows Error Reporting\QueueReporting" /xml > QueueReporting_baseline.xml Periodic check for modifications schtasks /query /tn "\Microsoft\Windows\Windows Error Reporting\QueueReporting" /xml | Compare-Object (Get-Content QueueReporting_baseline.xml)
- Restrict who can modify scheduled tasks via Group Policy:
– Navigate to `Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment`
– Ensure “Create global objects” and “Create symbolic links” are limited to Administrators and SYSTEM only.
6. Mitigation Workflow for Incident Responders
If you suspect MiniPlasma activity, follow this structured response workflow:
- Isolate the affected host from the network to prevent lateral movement.
2. Extract registry artifacts for offline analysis:
reg.exe save HKU.DEFAULT C:\DFIR\DEFAULT_HIVE.reg
3. Search for the `windir` modification using forensic tools (e.g., RegRipper):
rip.exe -r C:\DFIR\DEFAULT_HIVE.reg -p windir > miniplasma_indicators.txt
4. Review scheduled tasks for unexpected binaries in the `QueueReporting` action:
Get-ScheduledTask -TaskPath "\Microsoft\Windows\Windows Error Reporting\" | Get-ScheduledTaskInfo
5. Check for unknown binaries in the `C:\Windows\Temp` or `%APPDATA%` paths that may have been executed as SYSTEM.
What Undercode Say
- MiniPlasma is a stark reminder that patch compliance alone does not guarantee security. A “patched” system can still harbour exploitable vulnerabilities if the original fix was incomplete or regressed later.
- Organisations must adopt a defence‑in‑depth strategy: endpoint detection and response (EDR), behavioural monitoring, and registry‑level hardening complement traditional antivirus. Microsoft Defender’s ability to block the known exploit is valuable, but it should never be the sole control.
- The disclosure pattern (public PoC releases without coordinated disclosure) places defenders in a difficult position: they must react quickly to protect assets while awaiting an official patch. This highlights the need for resilient detection rules and rapid incident response playbooks.
Prediction
The MiniPlasma disclosure is part of a larger trend of uncoordinated vulnerability releases that force vendors to respond reactively. Over the next six months, we expect to see:
– Weaponisation of MiniPlasma by ransomware gangs within 2–3 weeks, used as a privilege escalation tool after initial access via phishing or drive‑by downloads.
– Microsoft’s accelerated patch validation processes, possibly including third‑party code reviews for kernel‑mode drivers, to prevent similar regressions.
– Increased adoption of behavioural EDR rules over signature‑based detection, as defenders recognise that static indicators are insufficient against public PoC exploits that can be trivially recompiled.
– Regulatory scrutiny of patch verification if further evidence emerges that CVE‑2020‑17103 was never fully resolved, potentially leading to mandatory independent re‑testing of security fixes.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Bartosz Wysocki – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
