Nightmare Season: Nightmare-Eclipse Turns Its Zero-Days on CrowdStrike, NVIDIA, Avast, and Kaspersky

Key Findings

• Nightmare-Eclipse has shifted targets. Every prior release from this persona, from BlueHammer in April 2026 through ShieldBreak in August 2026, targeted Microsoft Defender, BitLocker, or another native Windows component. This batch targets the third-party security and driver software organizations layer on top of Windows: CrowdStrike Falcon, NVIDIA GPU drivers, Gen Digital Avast Antivirus, and Kaspersky Endpoint Security.
• Four zero-day proof-of-concept exploits were published between August 29 and September 3, 2026. None were coordinated with the affected vendors. No CVEs have been assigned.
• FalconFlank escalates a standard user to NT AUTHORITY\SYSTEM against CrowdStrike Falcon Sensor. It abuses a TOCTOU race via Transactional NTFS to atomically replace a legitimate file with a malicious payload, which a built-in Windows scheduled task then loads as SYSTEM. Exposure requires the Microsoft Office file malicious macro removal capability to be enabled.
• GreenSection corrupts memory in NVIDIA's GPU display driver stack. A globally shared named memory section is created with SECTION_ALL_ACCESS granted to the Everyone SID, so any unprivileged user can overwrite GPU telemetry structures consumed by rendering processes. Observed impact is a crash. An arbitrary write primitive is a plausible refinement, not a demonstrated one.
• PrettyPrague escalates a standard user to NT AUTHORITY\SYSTEM against Gen Digital Avast Antivirus. It abuses Avast's sandbox filesystem virtualization to extract the SAM hive, recovers credentials offline, temporarily hijacks a local administrator account, and reaches SYSTEM through a short-lived Windows service. The researcher states the PoC works against any version of Avast Antivirus and suspects other Gen Digital products, including AVG and Norton, are affected.
• HardBreacher achieves code execution inside Kaspersky Endpoint Security v14.0.0.504. It redirects the avpuimain.dll load by avpui.exe through NT Object Manager namespace manipulation. The PoC is unstable and the researcher states it can be made reliable. Kaspersky is the only vendor in this batch to report the issue resolved, and the remediation ships as a database update rather than a new product build.
• Kevin Beaumont independently confirmed that the FalconFlank, HardBreacher, and PrettyPrague exploit code works. Beaumont assessed GreenSection as a crash rather than a privilege escalation. No confirmed in-the-wild exploitation of any of the four has been identified as of September 4, 2026.
• This is Howler Cell's seventh report on the Nightmare-Eclipse cluster, which now spans fourteen public zero-day releases across five months.

The Actor Behind the Batch

Nightmare-Eclipse is a single researcher operating under a rotating set of handles. Current reporting attributes Nightmare-Eclipse, Chaotic Eclipse, Infinite Nightmare, and MSNightmare to the same person, and prior Howler Cell coverage recorded Dead Eclipse as well. The GitHub account is MSNightmare, with parallel mirrors on the self-hosted Git servers at git.projectnightcrawler[.]dev and git.churchofmalware[.]org.

The pattern is consistent across all fourteen releases. Nightmare-Eclipse does not hunt memory-safety bugs. Each release is a design-level abuse of trusted functionality, chained out of legitimate operating system features, and published without coordination or a CVE. The motivation reads as grievance against vendor disclosure handling rather than financial gain. Prior releases were aimed at components Microsoft positions as defensive guarantees.

This batch is the first departure from that focus. The four new targets are products customers buy specifically to strengthen their security posture. Two of the four are endpoint protection platforms. The assessment that follows from the previous six reports still holds: the release cadence has not slowed, the targeting is expanding rather than narrowing, and the next round should be expected to hit other endpoint security vendors, driver stacks, or third-party components that run with elevated privileges on Windows.

The Four Releases

Stage 3 is where the four diverge most usefully for defenders. FalconFlank and HardBreacher both redirect a path and both fall back on the same trick: clean up the temporary structure, swap in a junction or symbolic link, and let the security product's SYSTEM-level response follow it into a real system directory. PrettyPrague does not need a redirect because Avast's own virtualization layer produces a readable copy of a protected file. GreenSection does not need one either, because the target object is already writable by Everyone. The Howler Cell Threat Research Team analyzed the publicly released proof of concept for FalconFlank, published September 3, 2026. FalconFlank is a local privilege escalation from standard user to NT AUTHORITY\SYSTEM targeting CrowdStrike Falcon Sensor's Microsoft Office file malicious macro removal response action.

Exposure conditions. The researcher states the PoC requires the Microsoft Office file malicious macro removal capability to be enabled, and reports successful execution on fully updated Windows 11 25H2 and Windows Server 2025 running Falcon with Phase 3 Optimal Protection active. The README also states that Falcon likely detects the released PoC as written, and that testing it requires either an exclusion or obfuscating the code and changing the DLL load technique. That is a real constraint on the sample as published. It is not a constraint on the underlying design weakness, which a modified build would still reach.

FalconFlank: Crowdstrike Falcon Sensor Local Privilege Escalation

The Howler Cell Threat Research Team analyzed the publicly released proof of concept for FalconFlank, published September 3, 2026. FalconFlank is a local privilege escalation from standard user to NT AUTHORITY\SYSTEM targeting CrowdStrike Falcon Sensor's Microsoft Office file malicious macro removal response action.

Exposure conditions. The researcher states the PoC requires the Microsoft Office file malicious macro removal capability to be enabled, and reports successful execution on fully updated Windows 11 25H2 and Windows Server 2025 running Falcon with Phase 3 Optimal Protection active. The README also states that Falcon likely detects the released PoC as written, and that testing it requires either an exclusion or obfuscating the code and changing the DLL load technique. That is a real constraint on the sample as published. It is not a constraint on the underlying design weakness, which a modified build would still reach.

Stage 1. Setup

The exploit raises its process and thread priority to the highest available levels, then creates a named pipe at \\?\pipe\FALCONFLANK as a callback channel for the payload.

A temporary directory tree mirroring the PowerShell path is created at %TEMP%\Flanker_<GUID>\WindowsPowerShell\v1.0\. Into v1.0\ the exploit writes a known-malicious OLE compound document containing a VBA macro, saved under the filename bcrypt.dll. The macro payload is a download-and-execute dropper and its contents do not matter. Its only job is to guarantee that Falcon's macro remediation flags the file and acts on it.

Stage 2. Product engaged

An opportunistic lock with read and handle caching is placed on the staged file. A second read handle is opened to the same file and immediately closed. The exploit blocks until the oplock breaks, then closes the original handle. This sequence serves as a synchronization barrier. Whether the break is triggered by the same-process handle open or by CrowdStrike's scanner accessing the file is ambiguous from the code alone.

Stage 3. Path redirect

The v1.0\ directory is deleted using POSIX semantics in a retry loop, removing it from the namespace immediately. A junction is then set on the parent WindowsPowerShell\ directory, also in a retry loop, redirecting it to \SystemRoot\System32\WindowsPowerShell. After this point, any path traversal through the temporary WindowsPowerShell\ resolves into the real system directory.

Stage 4. Privileged action

The exploit sleeps for two seconds. A kernel transaction is created and the exploit opens C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll through the Transactional NTFS API with read and write access and OPEN_EXISTING. If the call fails, the exploit reports failure and exits. If it succeeds, the file is truncated, memory-mapped, overwritten with the payload DLL, and the transaction is committed atomically.

Transactional NTFS is used rather than regular file I/O because transactional isolation prevents CrowdStrike's real-time file monitor from observing intermediate write states. At commit, the file flips from clean to malicious in a single atomic operation with no scannable window.

Stage 5. Outcome

The exploit connects to the Task Scheduler via COM and runs the MareBackup scheduled task at \Microsoft\Windows\Application Experience\MareBackup. This is a built-in Windows task that executes as NT AUTHORITY\SYSTEM and ultimately launches powershell.exe as SYSTEM. The task's DACL grants BUILTIN\Users full control, so any standard user can start it. PowerShell starts from its home directory at C:\Windows\System32\WindowsPowerShell\v1.0\ and the standard Windows DLL search order checks the application directory first. A bcrypt.dll now exists there, so the loader picks up the malicious copy instead of the legitimate one in System32\.

Figure 2: Launching MareBackup through COM.

The payload DLL exports BCryptCloseAlgorithmProvider, hijacking the real bcrypt API surface. On load it checks whether the hosting process is running as SYSTEM. If not, it returns silently. If SYSTEM, it connects to the FALCONFLANK named pipe, retrieves the exploit process's desktop session ID from the pipe server metadata, duplicates the current SYSTEM token, stamps it with that session ID, and spawns conhost.exe as SYSTEM on the user's desktop. The result is an interactive SYSTEM console window.

Figure 3: SYSTEM token duplication.

One limit is worth stating. SYSTEM on the endpoint does not let an attacker author Falcon exclusions, because those are managed in the CrowdStrike cloud console rather than on the host, and sensor uninstall still requires a maintenance token. What SYSTEM does grant is credential access, persistence, and the ability to interfere with local agents that lack tamper protection.

GreenSection: NVIDIA GPU Display Driver Memory Corruption

The Howler Cell Threat Research Team analyzed the publicly released proof of concept for GreenSection, which demonstrates a memory corruption condition affecting NVIDIA's GPU display driver stack on Windows. GreenSection is the outlier in this batch. It is not a privilege escalation, and independent assessment from Kevin Beaumont is that it crashes the system rather than granting elevated access.

Stage 1. Setup

The condition stems from a globally shared named memory section at \BaseNamedObjects\{52813408-3561-4705-820a-2b3b78be92ba}. This section is created by nvtopps.dll, an NVIDIA component loaded by the NVIDIA Display Container service, and is shared across all GPU-accelerated processes on the system.

Figure 4: Nvtopps.dll creating the shared memory section.

Stage 2. Product engaged

NVIDIA user-mode components consume this section with only an initial one-time validation. Analysis of one such component, nvoglv64.dll, shows the consumer path opening the section with FILE_MAP_ALL_ACCESS via OpenFileMappingA and mapping the entire region into the calling process.

Once the section is mapped, the driver caches the mapped pointer and trusts the section contents unconditionally on every subsequent access, with no re-validation between reads. There is no per-access checksum, no signature re-verification, and no bounds checking on the structures being consumed at runtime. That creates a time-of-check-to-time-of-use window.

Figure 5: Nvoglv64.dll consumer path mapping the section via OpenFileMappingA without integrity validation.

Stage 3. Path redirect not required

The section is not created with default or inherited permissions. NVIDIA's own security attributes builder explicitly constructs a DACL containing a single Access Control Entry that grants SECTION_ALL_ACCESS (0xF001F) to the Everyone SID (S-1-1-0), and applies the same pattern to the associated mutex with MUTANT_ALL_ACCESS (0x1F0001). Every security principal on the system, including unprivileged users, guest accounts, and anonymous logon sessions, can open, map, read, write, and delete the shared section and its mutex without any access-denied restriction. No redirect or race is needed to reach the target object.

Figure 6: DACL construction granting SECTION_ALL_ACCESS to the Everyone SID (S-1-1-0).

Stage 4. Privileged action

The PoC resolves native NT API functions from ntdll.dll and calls NtOpenSection on the hardcoded GUID path with full read and write access. If the section exists, which requires at least one GPU application to be running, the PoC queries its size, creates a private backup copy of the entire section contents, and stores it as a restore point. On keypress, the PoC calls memset across the entire mapped view, overwriting every byte with 0x41 and destroying the internal pointer tables, length fields, and frame telemetry structures in the shared region.

Figure 7: GreenSection PoC obtaining a handle to the shared section via NtOpenSection and corrupting it.

Stage 5. Outcome

Because the section is writable by Everyone and no lock is held during reads, the write lands between two unguarded reads by a victim process. The next time any GPU-accelerated application calls into the rendering or present path, it dereferences corrupted pointers and lengths from the overwritten section. The demonstrated result is a crash.

The attacker controls both the content and the extent of the overwrite. The PoC uses a blunt full-section memset for demonstration. Howler Cell assesses that a targeted approach could craft fake structures to redirect internal pointers or manipulate length fields, which would put an arbitrary write primitive inside whatever process consumes the corrupted data next, including dwm.exe. That is an assessment of where the design weakness leads. It is not demonstrated by the published code, and the currently observable impact is denial of service.

PrettyPrague: Avast Sandbox Local Privilege Escalation 

The Howler Cell Threat Research Team analyzed the publicly released proof of concept for PrettyPrague, a local privilege escalation from standard user to NT AUTHORITY\SYSTEM targeting Gen Digital Avast Antivirus. The chain interacts with the Avast sandbox, creates and locates a virtualized copy of the SAM hive, processes credentials offline, temporarily takes over a local administrator account, and transitions from administrator to SYSTEM.

Exposure conditions. The researcher states the PoC is compatible with any version of Avast Antivirus and reports it working against a fully patched Avast install on Windows 11 25H2. The researcher further states a belief that other Gen Digital products including AVG and Norton are affected. Gen Digital has confirmed the issue affects a subset of Gen products including Avast Antivirus.

Stage 1. Setup

PrettyPrague opens Avast's \\.\aswSnx device and sends IOCTL 0x82AC0054. It then launches another copy of itself in a suspended state. This places the child process into Avast's sandbox and virtualization environment.

Figure 8: Triggering Avast sandbox processing through aswSnx.

The child checks whether snxhk.dll is loaded to determine whether it is running inside the Avast sandbox. If the module is present, execution switches to SandboxedMain(), where the filesystem operations for the next stage are performed.

Stage 2. Product engaged

Inside the sandbox, PrettyPrague attempts to access C:\Windows\System32\config\SAM. Because the access occurs through Avast's sandbox environment, the protected SAM is handled through Avast's filesystem virtualization rather than being read directly from the live Windows location.

Figure 9: Sandboxed process accessing the protected SAM hive.

The sandboxed code also opens the Windows, System32, and config directories with WRITE_DAC permissions. It builds a DACL granting FILE_ALL_ACCESS to the Everyone SID and applies it using NtSetSecurityObject(), which makes the virtualized filesystem objects easier for the parent process to access.

Stage 3. Path redirect

While the sandboxed child accesses the SAM, the parent process monitors C:\avast! sandbox using ReadDirectoryChangesW(). When a newly created object ending in SAM appears, PrettyPrague builds its full path and opens the sandbox-generated copy.

Figure 10: Detecting the virtualized SAM created inside the Avast sandbox.

The SAM contents are copied into a transaction-backed temporary file under C:\Windows\Temp using CreateTransaction() and CreateFileTransacted(). This provides a usable file handle for offline processing without permanently committing the temporary SAM copy. The transaction is later removed with RollbackTransaction().

Stage 4. Privileged action

PrettyPrague opens the copied SAM with OROpenHiveByHandle() and reconstructs the key material needed to process its protected credential data. It enumerates local account entries and decrypts their available NTLM hashes from the offline hive.

Figure 11: Temporary account authentication and administrator token validation.

Rather than recovering plaintext passwords, the PoC temporarily changes an account's NT hash to the hash corresponding to a known value, authenticates with that known password using LogonUserEx(), and checks the resulting token to identify whether the account has administrator privileges. The original hash is restored after use.

Stage 5. Outcome

Once PrettyPrague identifies a local administrator account, it obtains another logon token and impersonates that security context. It opens the Service Control Manager and creates a temporary service whose binary path points back to the PrettyPrague executable.

Figure 12: Temporary service creation used to reach LocalSystem.

Because no separate service account is specified, the service runs as LocalSystem. PrettyPrague starts the service, waits briefly, and immediately deletes it, making the service a short-lived mechanism for moving from administrator privileges to SYSTEM.

When the service-launched instance starts, PrettyPrague detects that it is running as LocalSystem and follows a separate execution path. It connects to the named pipe \\.\pipe\PRETTYPRAGUE and obtains the session ID associated with the original interactive process.

Figure 13: Moving SYSTEM execution into the interactive session.

The SYSTEM process duplicates its access token and updates the duplicated token's TokenSessionId to match the interactive user session. Using that modified SYSTEM token, PrettyPrague launches a process inside the logged-on user's desktop session rather than remaining confined to Windows Session 0, where service processes normally execute.

HardBreacher: Kaspersky Endpoint Security DLL Hijack and Namespace Manipulation

The Howler Cell Threat Research Team analyzed the publicly released proof of concept for HardBreacher, targeting Kaspersky Endpoint Security v14.0.0.504. The exploit achieves code execution inside the Kaspersky UI process, avpui.exe, by redirecting a DLL load through NT Object Manager namespace manipulation. The PoC also includes a WannaCry-styled file encryption component that encrypts a single decoy file with AES-128-CBC and renames it with a .WNCRY extension.

Exposure conditions. The researcher reports testing against a fully patched Windows 11 25H2 host running Kaspersky Endpoint Security for Windows 14.0.0.504, and acknowledges in the README that the PoC is unstable and requires multiple execution attempts. The researcher also states it can likely be refined into a reliable one-click exploit. Kevin Beaumont independently confirmed the exploit code works.

Stage 1. Setup

The exploit creates a working directory at %USERPROFILE%\Desktop\Kaspy with a subdirectory tree mimicking Kaspy\Windows\System32. It drops an embedded image file, mrkaspy.jpg, via UNC loopback and creates a hardlink from it to MY_SNAKE_IS_SOLID.dll inside the fake System32 using NtSetInformationFile with FileLinkInformation.

HardBreacher reads the Kaspersky installation path from HKLM\SOFTWARE\WOW6432Node\KasperskyLab\protected\KES\ProductRoot, locating avpui.exe and its dependencies. An embedded DLL resource, the payload the researcher names SolidSnake, is extracted and written to %TEMP%\<GUID>_avpui.dll.

Stage 2. Product engaged

The core of the exploit is the namespace construction. HardBreacher builds a fake drive namespace inside the user's DOS device directory (\Sessions\0\DosDevices\<AuthenticationId>) using NtCreateDirectoryObject and DefineDosDevice with DDD_RAW_TARGET_PATH. A directory object named KASPERSKY-<GUID> is created, with child objects mirroring the Kaspersky Lab installation path structure. Symbolic links for each of Kaspersky's required files, including product_info.dll, ushata.dll, avpui.exe, and SortDefault.nls, point to the real files on disk via \Device\BootDevice\ paths. The link for avpuimain.dll is the exception. It is redirected to the staged payload DLL.

Stage 3. Path redirect

HardBreacher spawns avpui.exe using NtCreateUserProcess in a suspended state with two key attributes: the image path set to the legitimate Kaspersky binary, and the parent process spoofed as explorer.exe via PS_ATTRIBUTE_PARENT_PROCESS. Before resuming the process, HardBreacher creates a symbolic link for C: in the Object Manager namespace pointing to the fake KASPERSKY-<GUID> directory.

Stage 4. Privileged action

When avpui.exe resumes and resolves its DLL dependencies through C:, every file resolves to its real location except avpuimain.dll, which resolves to the payload. Attacker code now runs inside the Kaspersky UI process context. The payload signals a successful load via a named event, Local\HardBreacher-SolidSnake-Sync-Event.

Stage 5. Outcome

The exploit encrypts only the single decoy image it dropped earlier, using AES-128-CBC with random per-page keys that are never saved. The encrypted file is written with a .WNCRY extension and the original is deleted. The extension and behavior are deliberately chosen to trigger Kaspersky's anti-ransomware engine. No user files are encrypted.

After encryption, the routine deletes the hardlink, removes the inner System32 directory, and sets a junction on the Windows directory to \??\C:\Windows. This is the same pattern FalconFlank uses at its own stage 3: clean up the temporary structure, swap in the junction, and let the security product's SYSTEM-level response follow it into the real system directory.

The researcher states that taking control of avpui.exe can cause Kaspersky to stop functioning correctly and can influence file access decisions. The successful execution path drops MY_SNAKE_IS_SOLID.dll into C:\Windows\System32 with full permissions for the current user. That file is a persistent artifact which survives the exploit session, and it is the most reliable indicator of a successful run.

What Should Defenders Do

The vendor position is the starting point, not the plan. One of the four is reported resolved, one has a patch in development, and two have no fix and no public advisory. Public proof-of-concept code exists for all four. That gap between disclosure and remediation is the window defenders own, and it is where hunting does the work that a platform signature cannot.

The distinction that matters in this batch is between PoC-specific strings and behavioral anchors. The named pipes, the named event, and the working directory names are trivially renamed. The researcher says so directly in the FalconFlank README, which advises obfuscating the code and changing the DLL load technique to get past existing detections. Those strings are worth a high-fidelity detection because they catch the unmodified sample and cost nothing to run. They are not worth relying on. The behavioral anchors are what survive recompilation, and those go to the hunt team.