Throughout May, our team closely monitored a continued run of Windows zero-day disclosures linked to the researcher operating under the aliases Chaotic Eclipse and Nightmare-Eclipse, whose activity has developed into a sustained campaign targeting trusted Microsoft security and operating system components. The sequence began in April with BlueHammer, RedSun, and UnDefend, all of which focused on Microsoft Defender, before expanding in May to YellowKey, GreenPlasma, and MiniPlasma, demonstrating a broader effort to expose weaknesses in BitLocker, WinRE, CTFMON, and the Windows Cloud Filter driver. This pattern is significant because earlier disclosures were not merely theoretical. Huntress saw BlueHammer, RedSun, and UnDefend used in real intrusions within days of release, and BlueHammer was eventually assigned CVE-2026-33825 and added to CISA's KEV catalogue once active exploitation was confirmed. Unlike conventional exploit development focused on memory corruption or kernel drivers, these disclosures repeatedly show how legitimate, trusted Windows functionality can be manipulated to achieve privilege escalation, defence evasion, or data access.
Alongside this activity, May also saw continued evolution in the ransomware threat landscape, with analysis of the Kyber ransomware operation highlighting the growing maturity of cross-platform campaigns targeting both Windows and virtualised infrastructure. Rapid7’s recovery of Windows and ESXi payloads from the same victim environment demonstrates how attackers are increasingly able to move beyond traditional endpoints and directly impact virtualisation layers, enabling rapid, large-scale disruption once privileged access is obtained. This shift reinforces the need for organisations to treat ransomware as an infrastructure-wide risk, particularly where hybrid Windows and VMware environments are in use.
On 13 May 2026, Nightmare-Eclipse released GreenPlasma, a publicly available Windows local privilege escalation proof-of-concept disclosed immediately after Microsoft's May Patch Tuesday cycle, continuing a pattern of timed post-patch releases intended to maximise the defender remediation gap. GreenPlasma is described as a flaw affecting the Windows Collaborative Translation Framework, specifically involving CTFMON (ctfmon.exe), a trusted Windows process that runs with SYSTEM privileges in interactive sessions to support text input and language services.
Public reporting and the researcher's own release indicate that the exploit abuses object manager and namespace behaviour to create arbitrary memory section objects in locations that are normally writable only by SYSTEM. This creates a pathway by which a low-privileged user may be able to influence trusted services or drivers that assume those paths cannot be user-controlled, opening the door to escalation into a higher-privilege context.
The version published by the researcher is intentionally incomplete and does not provide a fully weaponised, turnkey SYSTEM shell under default conditions. However, this limitation should not be interpreted as low risk. Even incomplete proof-of-concept code reduces the barrier to exploitation by giving capable attackers a credible post-compromise primitive they can refine, test, and integrate into broader intrusion chains. This is particularly relevant because GreenPlasma targets a trusted native Windows component, meaning exploitation may blend more effectively with legitimate system behaviour and evade controls that rely too heavily on signed or Microsoft-native process trust.
At the time of reporting, no CVE or official Microsoft patch had been publicly issued for GreenPlasma. As a result, organisations were left to rely on compensating controls rather than vendor remediation, including strict least-privilege enforcement, application allowlisting, execution prevention, and behavioural monitoring for suspicious interactions involving CTFMON and unusual object or section creation activity. Although GreenPlasma is not believed to be a standalone initial access vector, its value lies in what it enables after compromise, elevated execution, interference with security tooling, credential theft opportunities, persistence, and a stronger platform for lateral movement.
Community Detection Opportunities
MDE_DeviceRegistryEvents_MiniPlasma_GreenPlasmaCTFMonSpawningUnusualProcess - Detects modifications to GreenPlasma registry keys, which are required for the exploit to work.
CTFMON Suspicious Process Execution
DeviceProcessEvents
| where InitiatingProcessFileName =~ "ctfmon.exe"
| where FileName in~ (
"cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "wscript.exe", "cscript.exe",
"mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe",
"bitsadmin.exe", "net.exe", "net1.exe", "whoami.exe", "nltest.exe",
"tasklist.exe", "systeminfo.exe", "ipconfig.exe", "quser.exe",
"query.exe", "wmic.exe", "bash.exe", "conhost.exe"
)
| project
Timestamp,
DeviceName,
FileName,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine,
AccountName
On the 15th of May 2026, the same researcher released MiniPlasma, another Windows local privilege escalation proof-of-concept, this time targeting the Windows Cloud Files Mini Filter driver (cldflt.sys). According to the researcher and subsequent reporting, the flaw resides in the HsmOsBlockPlaceholderAccess routine and appears to revive or expose the continued exploitability of an issue originally reported by Google Project Zero researcher James Forshaw in 2020, which Microsoft had previously associated with CVE-2020-17103 and reported as fixed in December 2020.
MiniPlasma is notable because, unlike GreenPlasma, it has been independently validated as successfully producing a SYSTEM shell on fully patched Windows 11 systems running the latest May 2026 Patch Tuesday updates. Reporting confirms the exploit worked from a standard user account on a fully updated Windows 11 Pro system, and security researcher Will Dormann separately reported reliable exploitation on the latest public Windows 11 release, while noting that it did not appear to work on the latest Insider Preview Canary build — suggesting Microsoft may already be testing a fix internally, though no formal patch has been announced at the time of writing.
The exploit is reported to abuse the way the Cloud Filter driver handles registry key creation through the undocumented CfAbortHydration API, enabling arbitrary keys to be created in the .DEFAULT user hive without proper access checks. This provides a path for a low-privileged local user to cross a critical privilege boundary and obtain SYSTEM-level execution, giving an attacker full control of the local machine. Reports have also noted that exploitation involves a race condition, meaning reliability may vary across systems, but the public release of both source code and a compiled executable significantly lowers the barrier for adoption by threat actors — the pre-compiled binary in particular removes the need for any development capability, making this accessible to a broader range of actors.
MiniPlasma is significant because it demonstrates that a vulnerability believed to have been resolved years earlier may still be reachable on current production systems, raising concerns around incomplete remediation or regression in legacy code paths. The public release and validation of the exploit against fully patched systems increases the likelihood of rapid weaponisation, mirroring the trajectory seen in earlier Nightmare-Eclipse disclosures that moved quickly from publication to operational use. As with other local privilege escalation flaws, MiniPlasma is most dangerous when chained with an existing foothold, enabling attackers to turn limited access into full compromise, disable protections, access sensitive data, and establish stronger persistence.
At the time of reporting, Microsoft had not yet issued a new CVE or patch specifically for MiniPlasma. Until formal remediation becomes available, organisations should treat the issue as a high-risk post-compromise enabler and prioritise preventive controls around execution, least privilege, monitoring for suspicious .DEFAULT hive modifications, and rapid containment of low-privileged user compromise before escalation opportunities can be exploited.
Community Detection Opportunities
MDE_DeviceEvents_MiniPlasma_USBConnectedAndRecoveryRestartFlowInShortSuccession - Detects a USB device being connected and a device restart occurring within a 10-minute period, indicating physical access potentially being YellowKey.
USB + Restart Correlation
let UsbInsertions =
DeviceEvents
| where ActionType == "UsbDriveMount" or ActionType == "PnpDeviceConnected"
| where AdditionalFields has_any ("USB", "RemovableMedia", "USBSTOR")
| project UsbTime = Timestamp, DeviceId, DeviceName, UsbActionType = ActionType,
UsbDetails = AdditionalFields, ReportId;
let ShiftRestarts =
DeviceProcessEvents
| where FileName =~ "shutdown.exe"
| where ProcessCommandLine has "/o" and ProcessCommandLine has "/r"
| project RestartTime = Timestamp, DeviceId, DeviceName, ProcessCommandLine;
UsbInsertions
| join kind=inner (ShiftRestarts) on DeviceId
| where RestartTime between (UsbTime .. (UsbTime + 10m))
| project UsbTime, RestartTime,
TimeDelta = datetime_diff('second', RestartTime, UsbTime),
DeviceName, DeviceId,
UsbActionType, UsbDetails, ProcessCommandLine
Kyber is an active ransomware operation first reported in 2025, associated with double-extortion tactics, Tor-based communication infrastructure, and the ability to target both Windows and Linux/ESXi environments. In March 2026, Rapid7 analysed Windows and ESXi encryptor payloads recovered from the same victim during an incident response engagement, confirming coordinated cross-platform deployment. This makes Kyber particularly relevant to organisations with virtualised infrastructure, where compromise of privileged access can quickly lead to widespread service disruption.
The Windows variant, identified as a 64-bit Rust binary, requires a target path parameter and, when executed with elevated privileges, performs additional actions to inhibit recovery and obstruct investigation. These include stopping services, tampering with backups, clearing logs, and encrypting files with the .#~~~ extension. It also drops a ransom note (READ_ME_NOW.txt) into affected directories and modifies the registry to assign a custom icon to encrypted files, increasing visibility of the impact to users and administrators. Notably, execution logic differs based on privilege level, with more destructive behaviours triggered when administrative access is obtained.
The ESXi variant, delivered as a 64-bit ELF binary, is tailored to VMware environments and introduces additional impact capabilities. Reporting indicates it can enumerate files, terminate virtual machines, and encrypt datastores, significantly increasing its operational impact in virtualised estates. The malware also performs staged file renaming during encryption and modifies SSH login banners and VMware Web UI pages to display ransom messages directly to administrators. This combination of encryption and defacement demonstrates an effort to maximise disruption and accelerate ransom pressure.
Kyber is significant because it reflects an increasingly mature ransomware model that targets both Windows systems and virtualisation platforms within a single campaign. While it is not a vulnerability requiring patching, its effectiveness is closely tied to the attacker obtaining elevated privileges. As such, organisations should prioritise hardening of virtualisation management planes, restricting ESXi SSH access, enforcing MFA, protecting backups from domain-level compromise, and monitoring for suspicious use of native tools commonly abused in ransomware activity, including vssadmin.exe, wbadmin.exe, wmic.exe, bcdedit.exe, and wevtutil.exe.
Community Detection Opportunities
MDE_DeviceFileEvents_KyberRansomware_ESXiVariant_EncryptionRoutine - For the Linux / ESXi variant of this ransomware, it performs a different encryption routine. Before encrypting the file, the binary creates a .locksignal file and renames the original to .processing to prevent concurrency. A redundant copy is also saved as .cryptdata_backup. On success, the file is renamed from .processing to .xhsyw. Any files left with the .processing suffix indicate an interrupted or failed encryption attempt. This query looks for evidence of files being processed and eventually, encrypted by looking for file names indicating at least 2 out of 4 encryption states and where more than 3 files were modified in a 60 second window.
ESXi Encryption Activity Detection
DeviceFileEvents
//Files move between four encrypted extension states.
| where FileName endswith ".locksignal"
or FileName endswith ".processing"
or FileName endswith ".cryptdata_backup"
or FileName endswith ".xhsyw"
//Aggregate activity by file extension, or unknown if none of them.
| extend fileExtension = case(
FileName endswith ".locksignal", "locksignal",
FileName endswith ".processing", "processing",
FileName endswith ".cryptdata_backup", "cryptdata_backup",
FileName endswith ".xhsyw", "Final Encrypted State",
"Unknown"
)
//Group by Device and Folder in a 2 minute window. We want to identify how many files were modified, how many "file states" (extensions) were seen and how many total files were found.
| summarize
FilesModified = count(), //Count how many files were modified in total.
FileExtensionsFound = dcount(fileExtension), //Count how many unique extensions were found.
ObservedStates = make_set(fileExtension), //Show which file extensions were seen.
ImpactedFilesSample = make_set(FileName, 10) //Show list of files that have been impacted.
by bin(Timestamp, 2m), DeviceName, DeviceId, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
//Look for a folder experiencing at least 2 out of the 4 unique states rapidly and where more than 3 files were modified.
| where FilesModified >= 3 and FileExtensionsFound >= 2
| project Timestamp, DeviceName, DeviceId, FolderPath, FilesModified, FileExtensionsFound, ObservedStates, ImpactedFilesSample, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
