Home Blog Nightmare-Eclipse Tooling Moves From Public PoC to Real-World Intrusion Published: April 20, 2026 Nightmare-Eclipse Tooling Moves From Public PoC to Real-World Intrusion By: Anna Pham Michael Tigges Key Takeaways Huntress observed BlueHammer, RedSun, and UnDefend activity during a live intrusion investigation. We linked the activity back to compromised FortiGate SSL VPN access tied to multiple suspicious source IPs. The most notable artifacts were staged in user-writable directories, including a user’s Pictures folder and short subfolders under Downloads. The observed activity included hands-on-keyboard reconnaissance like whoami /priv , cmdkey /list , and net group . Despite the execution of these tools, none of them appear to have succeeded during the incident. Further, the threat actor made a series of blunders during the intrusion that indicates that they are not very familiar with UnDefend. A suspicious agent.exe binary, which we dubbed BeigeBurrow, appeared to provide tunneling functionality for follow-on access. Table of Contents Background The terrible trio BlueHammer RedSun UnDefend Intrusion details Likely initial access through FortiGate SSL VPN BeigeBurrow: A Go-based Yamux reverse tunnel agent Mitigation guidance What is Huntress doing? Detections Indicators of Compromise Acknowledgments: Special thanks to Dani Lopez, Tanner Filip, Anton Ovrutsky, Lindsey O’Donnell-Welch, and John Hammond for their contributions to this investigation and write-up. This article was also written with AI assistance. TL;DR : Huntress has observed the use of Nightmare-Eclipse tooling, including BlueHammer, RedSun, and UnDefend, during a real-world intrusion investigation. In the clearest case, the activity included suspicious binaries staged in user-writable directories, hands-on-keyboard reconnaissance, likely compromised FortiGate SSL VPN access, and follow-on tunneling behavior. Organizations should review VPN logs, investigate the artifacts and paths below, and treat any confirmed execution as high-priority incident activity. Background To understand the activity Huntress observed, it helps to start with the public backstory. Chaotic Eclipse, also referred to in some places as Nightmare-Eclipse, is an alias for a security researcher who became frustrated with how Microsoft was handling the vulnerability disclosure processes. As a result of that frustration, they published a series of local privilege escalation techniques, dubbed BlueHammer, RedSun, and UnDefend. As part of its April 2026 updates, Microsoft rolled out a patch for the BlueHammer vulnerability (tracked as CVE-2026-33825 ). However, as of the publication of this blog (April 20, 2026) the other two flaws remain unpatched. At a high level, BlueHammer is an abuse of a race condition/Time Of Check, Time Of Use (TOCTOU) vulnerability in Windows Defender, and Huntress' investigation indicates that BlueHammer and RedSun can be used as privilege escalation techniques to take an attacker from an unprivileged account to SYSTEM. In practice, that kind of elevation can give an operator the ability to dump credentials, establish persistence, and blend into normal system activity while moving further through an environment. Against that backdrop, Huntress first observed suspected in-the-wild use of BlueHammer activity in mid-April 2026 during customer investigations. As the investigation developed, Huntress correlated related activity involving BlueHammer, RedSun, and UnDefend, all tied to public Nightmare-Eclipse tooling. The activity also appeared to be part of a broader intrusion rather than isolated proof-of-concept (PoC) testing. Huntress identified suspicious FortiGate SSL VPN access tied to the compromised environment, including a source IP geolocated to Russia, with additional suspicious infrastructure observed in other regions. Those findings are covered in more detail below. The terrible trio Nightmare-Eclipse’s two primary PoC scripts focus on achieving SYSTEM-level access in updated Windows environments. Both BlueHammer and RedSun share strong thematic ideals, like the use of oplocks (or operation locks) that attempt to hold files ‘open’ as a way to identify when Defender is actively performing an action, whether that’s scanning files, remediating malware, etc. Because Defender can actively remove these oplocks, this primarily becomes the synchronization method to know when a precondition for the race condition may be met. Additionally, Nightmare-Eclipse focuses heavily on the Volume Shadow Copy system. When Defender attempts remediation of a given malicious file or enters certain update paths, a Volume Shadow Copy is created as a method to ensure system integrity. And lastly, there’s a heavy focus on race conditions. By watching for specific actions, either through oplocks (BlueHammer and RedSun) or through Directory Change monitoring (UnDefend), Nightmare-Eclipse’s tooling often ‘races’ to perform some action once they’ve identified a window where the system is vulnerable to unanticipated actions. While the first two PoCs can be considered a TOCTOU vulnerability (more on this below), UnDefend simply takes advantage of a very benign and necessary system action leading to exclusive locks on files. BlueHammer BlueHammer (CVE-2026-33825) is a local privilege escalation exploit against Windows Defender, released by Nightmare-Eclipse publicly on April 2, 2026. BlueHammer primarily takes advantage of two novel concepts to achieve an arbitrary read handle to the Security Account Manager (SAM) database, which houses credential materials in the Windows system. Figure 1: Microsoft update page for CVE-2026-33825 The first is Common Weakness Enumeration (CWE) 367, a concept known as Time Of Check, Time Of Use (TOCTOU). TOCTOU vulnerabilities, classified overarchingly as race conditions, are a race to perform an action/modify a value between the time a value is checked and the time a value is actually used by the code. A conceptual example of TOCTOU involves someone clicking on a link to open a file, but by the time the file is actually ‘executed’ by Windows, an adversary has swapped it to be some malicious executable, thus executing the file. In reality, TOCTOU is often significantly more subtle, and has caused some of the most significant vulnerabilities in history, such as the 2016 Linux kernel privilege escalation flaw Dirty COW and numerous Linux symlink vulnerabilities. The second concept has no particular CWE, but instead takes advantage of the ability for the exploit author to ‘pause’ Windows Defender with its Volume Shadow Copy exposed. TOCTOU vulnerabilities are often difficult to mitigate, but accepted to some degree because the window to generate a valid race condition is exceptionally small. This is not the case with BlueHammer; by pausing the Defender process with the Volume Shadow Copy open, an adversary is able gain control of the timing of this very narrow window. By combining these two novel techniques, the exploit author demonstrates how an unauthenticated user can read a typically sensitive file location. Sequentially, BlueHammer is weaponized in the following stages to gain control of (any) currently logged out user on the host: Update reconnaissance BlueHammer polls the Windows Update API for a pending update and obtains its own copy of the update files. Force VSS creation & freeze Windows Defender BlueHammer writes a standard AV test string to disk – one Defender is guaranteed to flag. This triggers Defender to create a frozen volume snapshot as part of its remediation process; BlueHammer monitors for that snapshot's creation before proceeding. To confirm Defender is actively scanning, BlueHammer places a lock on a system file Defender accesses mid-scan. When that lock breaks, the scan is confirmed in progress. BlueHammer then registers a fake cloud sync provider, structurally identical to OneDrive, in its own directory and places a file inside it. The sync provider fires a callback any time a process enumerates the directory, and includes the caller's identity. When Defender enumerates it and triggers that callback, BlueHammer confirms the identity matches Defender specifically. This is the synchronization point. A lock is placed on the file, and only then does the callback deliver Defender the directory listing, which includes the file. Defender attempts to open it for scanning. That open suspends operations silently. Defender's scan thread now waits indefinitely on a file BlueHammer controls. The race to SAM BlueHammer holds two things: a frozen volume snapshot containing an unlocked copy of the system's password database, and a suspended Defender. What remains is getting a read on that database, one that would ordinarily require system-level access. BlueHammer constructs a redirectable path to its staged update files and instructs Defender, through its own internal update interface, to import a signature update from that location. Defender scaffolds a new definition update directory and begins reading the staged files. When Defender opens the primary definition file, a lock fires. In that window, the path is swapped: it now points into the frozen volume snapshot, directly at the system's password database. A second redirect maps the expected filename to that target. The lock releases. Defender continues along the now-redirected path and reads the password database, believing it to be a definition file. Defender writes it to its own output directory. BlueHammer opens the destination and receives a handle to the password database. This, in essence, is BlueHammer. What follows is implementation details. We could pause here, copy the rogue SAM database through any number of techniques, and the exploit would be valid. BlueHammer takes this a step further, and parses the SAM hive itself, and decrypts each user’s NT hash (password representation). Armed with valid hashes, BlueHammer then temporarily changes each user’s password to $PWN