Expanding the Attack Surface: Analyzing Nightmare-Eclipse's Latest PoCs

In our previous blog, we explored a series of disclosures from the leak persona Nightmare-Eclipse that focused heavily on Microsoft's ecosystem, including Windows Defender, Cloud Files, and core operating system functionality.

In this article, we analyze HardBreacher, PrettyPrague, GreenSection, and FalconFlank, assessing their implementation, practical impact, detection opportunities, and relevance to enterprise defenders.

While the techniques and affected products differ, the proofs of concept (PoCs) collectively highlight how functionality exposed by trusted and highly privileged software can create security risks when assumptions about access, trust boundaries, or intended usage break down.

HardBreacher: Turning Kaspersky's Loader Against Itself

Every Windows logon session has a private object directory inside the kernel's namespace – \Sessions\0\DosDevices\{AuthId}\, and any standard user process can place symbolic links inside their own session's directory without any special privilege. Those links shadow the global device namespace. Place a link named C: in there, and every path beginning with C:\ in that session resolves through your link instead.

HardBreacher uses this to ambush Kaspersky's UI process at the moment it first loads DLLs. The attacker builds a fake filesystem tree — a KASPERSKY-{GUID} directory containing symlinks to all of Kaspersky's real files, with one exception. The link for avpuimain.dll, the primary DLL host loaded by the Kaspersky UI at startup, points to a payload DLL dropped in %TEMP%. avpui.exe is spawned suspended, the C: redirect is activated, and the thread is resumed. The OS loader, doing exactly what it is supposed to do, loads the attacker's DLL.

//Build session-specific C: redirect pointing to attacker's fake tree
wsprintf(maindrvtarget, L"%ws\\%ws", currdosdv, ksdospath);
NtCreateSymbolicLinkObject(&hmaindrv, MAXIMUM_ALLOWED,
 &_maindrvobjattr, &_maindrvtarget);

// Resume avpui.exe — its DLL loader now sees the fake C: drive
ResumeThread(hThread);
WaitForSingleObject(hnotify, INFINITE); // wait for payload confirmation
CloseHandle(hmaindrv); // tear down redirect immediately

Figure 1. The C: redirect is live for only the milliseconds between ResumeThread and the payload's callback — then silently removed with no persistent namespace change.

The second technique is layered on top. HardBreacher does not spawn avpui.exe via CreateProcess. It calls the native NtCreateUserProcess with PS_ATTRIBUTE_PARENT_PROCESS set to a handle of explorer.exe. The process tree recorded by Windows — and by most endpoint detection and response (EDR) telemetry — shows avpui.exe as a child of Explorer, as if the user had simply launched it normally. The actual initiating process leaves no parent-child trace.

// Spoof PPID: avpui.exe will appear as a child of explorer.exe
AttributeList->Attributes[1].Attribute = PS_ATTRIBUTE_PARENT_PROCESS;
AttributeList->Attributes[1].ValuePtr = GetExplorerProcess(); // handle to explorer

// Spawn suspended — C: symlink activated before thread resumes
NtCreateUserProcess(&hProcess, &hThread, MAXIMUM_ALLOWED, MAXIMUM_ALLOWED,
 NULL, NULL, NULL, THREAD_CREATE_FLAGS_CREATE_SUSPENDED,
 ProcessParameters, &CreateInfo, AttributeList);

Figure 2. NtCreateUserProcess with PS_ATTRIBUTE_PARENT_PROCESS set to explorer.exe. EDR process-tree telemetry records Explorer as the parent, breaking parent-chain anomaly detections.

Figure 3. Kaspersky reports 'No active threats found' while HardBreacher.exe and the Kaspy staging folder (containing mrkaspy.jpg and a Windows\System32 subtree) sit on the desktop in plain view. The session-namespace redirect is active only during process startup, leaving nothing on disk for Kaspersky's file scanner to find.

Figure 4. PowerShell confirms JPG and DLL share an identical SHA-256 hash — two names pointing at one inode via an NTFS hardlink. The bait file embedded in HardBreacher and the 'DLL planted in System32' are the same bytes.

Once inside avpui.exe, the payload (SolidSnake.dll) does something that reveals a real understanding of how Kaspersky works operationally. It enters an EnumWindows loop, waiting for a window titled "Notification from Kaspersky Endpoint Security" to become visible. When found, it hides the popup before any user sees it, then kills avpui.exe from the inside. The security product terminates itself.

// SolidSnake.dll (reconstructed from .text disassembly): hide popup, kill KES UI
if (wcsncmp(buf, L"Notification from Kaspersky Endpoint Security", len) == 0) {
   ShowWindow(hwnd, SW_HIDE);
   Sleep(1000);
   // ... CreateToolhelp32Snapshot / Process32NextW to find avpui.exe ...
   TerminateProcess(OpenProcess(MAXIMUM_ALLOWED, FALSE, avpui_pid), 0);
   ExitProcess(0);
}

Figure 5. The payload's sole purpose: silence the Kaspersky notification popup and terminate the host process. In the default KES v14 configuration, avpui.exe does not automatically restart — leaving the endpoint without its user-facing notification channel for the remainder of the session.

Figure 6. Kaspersky correctly identifies HardBreacher as UDS:Trojan.Win32.Exploit.a when the endpoint is online and signature databases are current. In offline or update-delayed configurations , the detection does not fire, which is the scenario the exploit targets.

PrettyPrague: When Avast's Sandbox Becomes the Attacker

PrettyPrague is a different class of exploit — both technically and in terms of what it leaves behind. Where HardBreacher is stealthy and targeted, PrettyPrague, out of box, is loud and conclusive: when it works, it spawns a full SYSTEM shell, dumps all local NTLM password hashes, and logs in as every local administrator account on the machine. It also, as a matter of operational hygiene, changes those passwords back when finished.

The target is Avast's sandbox subsystem. Avast ships a kernel driver accessible via the device \\.\aswSnx that provides its behavioral sandbox. When Avast runs a suspicious file inside the sandbox, it operates in a virtualized filesystem — including its own copy of C:\Windows\System32\config\SAM, the Windows Security Account Manager database that stores encrypted local user password hashes.

Figure 7. The avast! sandbox directory appearing at the C:\ root during exploitation. PrettyPrague instructs Avast's kernel driver to execute the exploit binary within this isolated virtualized environment, giving the sandboxed process write-level access to a copy of the SAM database.

Figure 8. Inside C:\avast! sandbox— the snx_rhive files are Avast's virtualized registry hives for the sandboxed session. The exploit's outside instance monitors this directory with ReadDirectoryChangesW, racing to open the SAM copy before Avast's cleanup routine removes the sandbox environment.

The vulnerability is that a standard user process can send IOCTL 0x82AC0054 directly to the aswSnx driver to request that a chosen executable be run inside the sandbox. PrettyPrague sends its own executable. Avast, doing its job, runs it — and inside the sandbox, that process can open C:\Windows\System32\config\SAM with write access, because the sandbox's virtualized Windows directory is not protected by the real SAM's ACLs.

// Register this process for Avast sandbox execution via kernel IOCTL
HANDLE hsnx = CreateFile(L"\\\\.\\aswSnx", GENERIC_READ, ...);
buff[0] = 0x1 | 0x20;
wcscpy((wchar_t*)&buff[2074], sbxapp); // path to self
DeviceIoControl(hsnx, 0x82AC0054, buff, sizeof(buff), buff, sizeof(buff), &retb, NULL);

// Spawn a suspended copy of self — Avast will run it in the sandbox
CreateProcess(sbxapp, NULL, ..., CREATE_SUSPENDED, ..., &pi);
NtResumeProcess(pi.hProcess);

Figure 9. The exploit instructs Avast's kernel driver to sandbox its own copy. Avast's protection mechanism becomes the delivery vehicle for the SAM read.

The outside process watches C:\avast! sandbox for the SAM file via ReadDirectoryChangesW, then opens it with read and write access while Avast is still populating it. It copies the SAM hive to a %TEMP% path using a Kernel Transaction Manager transaction, which is rolled back at the end — leaving no permanent file on disk. The SAM is then parsed entirely in memory using an offline registry library, and NTLM hashes are decrypted using the LSA boot key, derivable from four registry subkeys any process can read.

// Watch for SAM to appear in Avast's sandbox directory
ReadDirectoryChangesW(haswdir, buff, sizeof(buff), TRUE,
 FILE_NOTIFY_CHANGE_FILE_NAME, &retbytes, &ovp, NULL);
// ... wait until a file ending in 'SAM' is added ...

// Open it for read + write before Avast removes it
NtCreateFile(&hsamfinal, GENERIC_READ | GENERIC_WRITE | DELETE | SYNCHRONIZE,
 &samobjattr, &iostat, NULL, NULL,
 FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_OPEN, ...);

Figure 10. The race: open the sandbox SAM file before Avast cleans up. The exploit polls file size until nonzero, ensuring the copy is complete before proceeding to offline hash decryption.

After decrypting the NTLM hashes, the exploit calls SamiChangePasswordUser — a SAM internal API that, from a SYSTEM context, can change any user's password without knowing the current one — and sets every local admin account's password to a single hardcoded string. After spawning shells, it changes them back using the original hashes.

// Change all admin passwords to PRETTY_PRAGUE, get shells, then restore
char newpassword[] = "PRETTY_PRAGUE";
for (int i = 0; i < numofentries; i++) {
  ChangeUserPassword(username, realNTLMHash, NULL, newNTLM); // set PRETTY_PRAGUE
  LogonUserEx(username, NULL, newpassword_unistr, ...);
  // if admin token: CreateService -> StartService (SYSTEM) -> DeleteService
  CreateProcessWithLogonW(..., L"C:\\Windows\\System32\\conhost.exe", ...);
  ChangeUserPassword(username, newNTLM, NULL, realNTLMHash); // restore original
}

Figure 11. The password change is temporary by design. The original NTLM hash extracted from the SAM dump is used to restore the account — the window where credentials are altered is seconds wide.

Figure 12. End result: two shells opened simultaneously from a single standard user account (OpsIntel). Top: testing\localaddy via LogonUser with the extracted admin password hash. Bottom: NT AUTHORITY\SYSTEM via the transient service.

Figure 13. Process Monitor trace: PrettyPrague.exe (PID 8120) loading samlib.dll while lsass.exe (PID 728) performs rapid SAM registry operations against the LocalAddy account RIDs — a cross-process behavioral pattern directly linking the exploit to LSASS activity in EDR telemetry.

Figure 14. lsass.exe (NT AUTHORITY\SYSTEM) enumerating SAM domains and opening LocalAddy's registry entries. The rapid sequential RegOpenKey / RegEnumKey / RegQueryValue sequence across multiple RIDs in a short window is a high-fidelity hunting signal distinct from normal LSASS activity patterns.

Figure 15. Sysmon Event ID 17 capturing the \\PRETTYPRAGUE named pipe creation. PipeName, image path (OpsIntel's Desktop), and NT AUTHORITY\SYSTEM as the account — all visible. Hardcoded in the released PoC: zero false positives on this string in the current implementation.

To obtain the SYSTEM shell that makes the password change possible, PrettyPrague uses a well-known UAC bypass via the undocumented CMLuaUtil COM interface (CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7}), combined with PEB masquerading to make the process appear to be explorer.exe to the UAC auto-elevation check.

Figure 16. Registry telemetry from the avast! sandbox directory during execution shows a deleted key related to cmstplua.dll — a forensic artifact of the UAC bypass's COM object instantiation occurring inside the sandboxed environment before the SYSTEM shell is handed back out.

Figure 17. Process Monitor events highlighting the CMSTPLUA COM object (CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7}) and its ICMLuaUtil interface (IID {6EDD6D74-C007-4E75-B76A-E5740995E24C}) being invoked by PrettyPrage.exe, and DllHost.exe in turn.

Notably, the actor also claims the vulnerability may affect additional GenDigital products, including AVG and Norton, which share common ownership and portions of their security technology stack.

While we have not independently validated impact beyond Avast, our assessment is that the claim is technically plausible because the exploit targets sandbox architecture and trust relationships rather than a narrowly tailored product configuration. However, differences in driver implementations, sandbox components, and product-specific hardening could significantly affect exploitability across individual GenDigital offerings.

GreenSection & FalconFlank: Drivers, EDRs, and the Limits of Trust

While HardBreacher and PrettyPrague target security products directly, GreenSection and FalconFlank focus on trusted third-party software and privileged system components, reinforcing a recurring theme across Nightmare-Eclipse research: security boundaries often fail when trusted software performs actions on behalf of less-privileged users.

GreenSection examines an NVIDIA global shared-memory section that can be opened, mapped, modified, and restored from a standard user context. While the PoC does not demonstrate privilege escalation or code execution, it raises concerns around trust assumptions and potential future exploitation paths.

NtOpenSection(
  &hsection,
  SECTION_MAP_READ | SECTION_MAP_WRITE | SECTION_QUERY,
  &objattr);

NtMapViewOfSection(
 hsection,
 GetCurrentProcess(),
 &nvsection,
 NULL,
 NULL,
 NULL,
 &nvviewsz,
 ViewUnmap,
 NULL,
 PAGE_READWRITE);

memset(nvsection, 'A', nvviewsz);

Figure 18. GreenSection opening and mapping an NVIDIA shared-memory section before overwriting its contents. The PoC demonstrates that data within the section can be modified and later restored by a non-privileged user.

Unlike GreenSection, FalconFlank demonstrates a privilege-escalation path through filesystem manipulation techniques, including reparse points, oplocks, and privileged task execution.

Figure 19. FalconFlank after successful completion of the filesystem-redirection stage. The PoC indicates that exploitation has succeeded and is transitioning to DLL loading, while a temporary staging directory is created within %TEMP% to support subsequent payload execution.

Figure 20. CrowdStrike Falcon detection generated during FalconFlank testing. The alert shows the Falcon Sensor identifying and quarantining a file written to a staged WindowsPowerShell\v1.0\bcrypt.dll path within the exploit's temporary working directory. The detection was classified as Medium severity and attributed to the OnWriteOfficeMacroMLMedium machine learning(ML) detection logic, demonstrating that Falcon's prevention controls can identify artifacts generated during the exploitation workflow.

Figure 21. CrowdStrike Falcon’sc loud-based ML engine successfully detecting and quarantining the malicious bcrypt.dll file, referred to FlankerDLL internally. One of the last stages of the attack chain, this detection prevented conhost.exe spawning as system in our testing.

Figure 22. CrowdStrike Policy setting for Microsoft Office file malicious macro removal enabled alongside CrowdStrike’s policy setting recommendations, which shows that this is an optional setting for “Phase 3 – Optimal Protection” settings.

According to Nightmare-Eclipse, the PoC abuses CrowdStrike Falcon Sensor's "Microsoft Office file malicious macro removal" functionality and was reportedly tested against fully updated Windows 11 25H2 and Windows Server 2025 systems running Falcon with Phase 3 Optimal Protection. The threat actor noted that exploitation requires the "Microsoft Office file malicious macro removal" prevention-policy setting to be enabled.

Our review aligns with this claim. For CrowdStrike clients to be susceptible to this local privilege escalation vulnerability, an endpoint must be assigned to a Prevention Policy with the "Microsoft Office file malicious macro removal" setting enabled. This vulnerability does not impact CrowdStrike Falcon Government clients, as the "Microsoft Office file malicious macro removal" setting is not available within Falcon Government policies.

Together, GreenSection and FalconFlank highlight how legitimate functionality can become a security liability when exposed to unintended control paths.

Detection Opportunities

All four PoCs leave distinctive artifacts at various stages of execution. The key principle for hunting them, and for building detections that remain effective after minor modifications, is to focus on behavioral patterns rather than individual indicators. Renaming a pipe, changing a password, or replacing a DLL name can be done in seconds. Eliminating the underlying sequence of privileged operations, namespace manipulation, shared-memory abuse, driver interaction, or trusted-process execution typically requires fundamental changes to the attack itself. As a result, defenders should prioritize detection opportunities tied to the behaviors and trust relationships exploited by HardBreacher, PrettyPrague, GreenSection, and FalconFlank rather than relying solely on static indicators.

Key Takeaways for Defenders

Not all PoCs carry the same practical risk. PrettyPrague demonstrated the most significant security impact prior to remediation, while HardBreacher highlighted opportunities for security-product abuse and evasion. GreenSection is primarily a security design concern, and FalconFlank's operational relevance was limited both by its configuration-dependent exposure and by rapid vendor remediation.

For defenders, the key question is often not whether a patch exists, but whether it has been deployed. Security vendors can typically remediate vulnerabilities far faster than traditional operating system patch cycles, making update coverage and visibility just as important as detection. Organizations with delayed, disabled, or manually managed update processes may remain exposed long after the broader user base has been protected.