This report is the latest installment in Howler Cell's ongoing coverage of NightmareEclipse. The Threat Research Team has tracked this researcher's toolkit release by release, from BlueHammer to RedSun through UnDefend, YellowKey, and GreenPlasma, and continues that coverage here.
Most people picture a hacker breaking in from the outside. LegacyHive is the opposite problem. It is the person already sitting at the computer next to yours. On any machine where more than one person logs in, a shared workstation, a Remote Desktop server, a virtual desktop, Windows keeps each user’s private data walled off from everyone else. LegacyHive knocks that wall down. It quietly tricks Windows into handing a low-privileged user another person’s private data, and Windows never notices it broke its own rule.
For three months, one anonymous researcher has published a new way to break Windows roughly every ten days. Most of those tools hand an attacker the keys to the entire machine. The ninth, LegacyHive, is quieter and in some ways more unsettling. It does not take over the computer. It reaches across the wall Windows builds between users and reads data that was supposed to belong to someone else.
LegacyHive is an insider threat twice over. It is a tool for the user already on your machine to reach a coworker’s data, and it comes from someone who claims they were once on the inside at Microsoft.
LegacyHive is the release NightmareEclipse had promised for July 14, 2026. The researcher pledged a large drop timed to Microsoft’s July Patch Tuesday and delivered it hours after the updates shipped, a Patch Tuesday that Microsoft used to fix a record number of flaws and three actively exploited zero-days. Publishing immediately after the monthly updates is a deliberate choice. It buys the longest possible window before Microsoft can respond, and LegacyHive remains unpatched on every supported version of Windows.
LegacyHive did not appear in isolation. It is the latest release from a researcher operating under the aliases Nightmare-Eclipse, Chaotic Eclipse, and MSNightmare, publishing to GitHub and to mirrors at git.projectnightcrawler[.]dev/NightmareEclipse and git.churchofmalware[.]org. Since April 3, 2026, this researcher has dropped nine Windows exploits with no coordinated disclosure, no advance notice to Microsoft, and in most cases no patch available at release.
The releases share a target pattern. They hit the components Microsoft positions as security guarantees.
Read together, the set maps to a full Windows attack chain with deliberate redundancy at the most valuable links. Four independent paths to SYSTEM, two ways past BitLocker, and a tool to suppress the telemetry the rest would generate. That is not a scattershot bug dump. It is the shape of an operator’s toolkit.
The researcher’s public persona adds a dimension the code does not. As reported by Krebs on Security, NightmareEclipse claims to be a former Microsoft employee, a claim Microsoft has not confirmed. Rapid7 noted a recent post from the researcher carried an image of Albert Wesker, the Resident Evil character who worked as a researcher for a technology company before turning on it. Microsoft publicly weighed legal action, then clarified it would report law-breaking to authorities rather than pursue researchers. Whether or not the insider claim holds, the targeting reads like it. The cluster hits the exact components Microsoft markets as security guarantees, with the precision of someone who knows where the seams are.
LegacyHive breaks the pattern in one way that matters. The eight tools before it were mostly finished exploits, complete paths from a standard account to SYSTEM or past encryption. LegacyHive ships a building block instead. It does not escalate anything on its own. It gives an attacker reliable control over which registry hive Windows mounts and where, and that control is what larger attacks are assembled from. A researcher who has spent three months shipping finished exploits releasing a raw primitive is a signal worth watching. This is where threat hunting earns its place. A platform detection catches the finished exploit it was written for. It does not catch the primitive that has not been wired into an exploit yet. Finding that requires hunting for the behavior, not waiting for the signature.
LegacyHive targets a flaw in the Windows User Profile Service (ProfSvc). The flaw lets an attacker influence where Windows looks for a user’s UsrClass.dat registry hive when a profile loads.
Normally, this process is safe. When a user logs in, Windows loads that user’s registry hives from trusted paths inside the user’s own profile directory, then maps them into the right spot under the HKEY_USERS (HKU) namespace. Each user’s hive lands in that user’s own namespace. That is the boundary LegacyHive breaks. Figure 1 shows the normal profile load beside the redirected one.
The root cause is that the profile load path is built from configuration the attacker can control. Windows reads the Local AppData value from NTUSER.DAT to determine where the profile’s data lives. The PoC opens the authenticated user’s unloaded NTUSER.DAT, uses the Offline Registry Library to redirect Local AppData to an attacker-controlled Object Manager path, and swaps in the modified hive. On its own that is not enough, so the PoC adds two more pieces. The full chain combines three mechanisms.
1. Offline NTUSER.DAT modification. The PoC opens the authenticated user’s unloaded NTUSER.DAT and modifies the Local AppData value to point to an attacker-controlled Object Manager path using the Offline Registry Library, then swaps in the modified hive.
2. Object Manager symbolic link redirection. A symbolic link in the Windows Object Manager namespace redirects the path the profile service trusts, so the service resolves the attacker’s path during the load.
3. Synchronized oplock. A batch opportunistic lock (oplock) times the attack against the profile load. It pauses the load at the right moment, so the redirected path is used before Windows moves on.
Together, these three mechanisms induce the User Profile Service to load an unintended UsrClass.dat hive during profile initialization. The hive that gets mounted is not the one Windows intended to load.
Figure 1: Normal vs. Vulnerable Profile Loading
The publicly released LegacyHive proof-of-concept exploits the User Profile Service through a sequence of coordinated operations during profile initialization. Rather than exploiting a single vulnerable API, the PoC combines offline registry hive modification, Object Manager namespace redirection, user impersonation, and synchronized profile loading to influence how Windows resolves and loads the UsrClass.dat hive. The full workflow is shown in Figure 2 and runs in six steps.
Figure 2: LegacyHive Exploitation Workflow
1. Validate Input. The PoC validates the command-line arguments supplied by the operator: the username and password of the low-privileged account, and the username of the target account.
2. Prepare Environment. The PoC generates a GUID, creates a work directory, and constructs the Object Manager namespace and symbolic links used to redirect the Windows profile path. The symbolic links are created beneath \BaseNamedObjects\Restricted.
3. Modify NTUSER.DAT. Using the supplied credentials, the PoC authenticates as the low-privileged user with LogonUserW, impersonates that user, opens an offline copy of the user’s NTUSER.DAT with the Offline Registry Library, changes the Local AppData value to reference the attacker-controlled Object Manager path, and replaces the hive.
4. Trigger Race Condition. The PoC copies the target user’s UsrClass.dat and places a batch opportunistic lock (FSCTL_REQUEST_BATCH_OPLOCK) on the copy to synchronize profile loading. A helper thread starts the target user process. The single call that drives this is CreateProcessWithLogonW with LOGON_WITH_PROFILE, which forces Windows to load the supplied user’s profile during process creation, and CREATE_SUSPENDED, which leaves the new process frozen while the PoC controls timing through the oplock and the symbolic links.
5. Load Target Hive. During profile initialization, the User Profile Service follows the modified configuration and resolves the path through the Object Manager redirection. When the oplock fires, the PoC closes one symbolic link, and the service loads the target user’s UsrClass.dat into the low-privileged user’s HKU\<SID>_Classes namespace instead of the expected hive.
6. Validate Success. The PoC confirms the redirection by opening the low-privileged user’s classes root (RegOpenUserClassesRoot) and reading a registry marker that exists only in the target user’s hive.
The goal was to confirm the arbitrary hive loading behavior for ourselves rather than take the PoC at its word. The test set out to answer one question. Can the User Profile Service be pushed into loading a target user’s UsrClass.dat hive into a low-privileged user’s HKU\<SID>_Classes namespace? If the hive crosses that boundary, the primitive works as described.
We built the lab with three separate local accounts, each playing a role in the attack. The PoC operator is the account that runs the exploit and drives the profile load. The authenticated low-privileged user is the account that should never see the target’s hive, and the account where the redirected hive would land if the attack succeeded. The target user is the account whose UsrClass.dat the attacker is trying to pull into the wrong namespace. Figure 3 shows the lab environment.
To prove the redirection happened, we planted a unique marker inside the target user’s UsrClass.dat before running the PoC. The marker was our ground truth. If it turned up inside the low-privileged user’s namespace after the exploit ran, the hive had been redirected across the user boundary, and the primitive was confirmed.
Figure 3: Laboratory Environment Used for LegacyHive Validation
Before executing the proof-of-concept, we created a unique registry value named LegacyHive_Admin2_Marker with the data ADMIN2_HIVE_CONFIRMED inside the target user’s UsrClass.dat hive, as shown in Figure 4. Because this value existed only in the target user’s profile, it served as a validation artifact for whether the hive was redirected during exploitation.
Figure 4: Creation and Verification of the Registry Validation Marker
During execution, the PoC established a batch oplock on the copied UsrClass.dat as a synchronization point. When the oplock triggered during profile loading, the PoC closed one symbolic link, forcing the profile service to load the target user’s UsrClass.dat into the low-privileged user’s registry namespace, as shown in Figure 5.
Figure 5: Successful Execution of the LegacyHive Proof-of-Concept
Runtime monitoring with Process Monitor and Process Explorer confirmed the workflow, as shown in Figure 6. The monitoring showed access to the modified NTUSER.DAT, the target UsrClass.dat, and the Object Manager namespace created beneath \BaseNamedObjects\Restricted.
Figure 6: Runtime Activity During LegacyHive Execution
After execution, we examined the redirected hive through the low-privileged user’s HKU\<SID>_Classes namespace, as shown in Figure 7. The marker LegacyHive_Admin2_Marker, created exclusively within the target user’s UsrClass.dat before exploitation, was retrieved from the redirected hive. The presence of ADMIN2_HIVE_CONFIRMED is direct experimental evidence that Windows loaded the target user’s UsrClass.dat during profile initialization. This independently validates the arbitrary registry hive loading behavior the PoC demonstrates.
Figure 7: Verification of Successful Registry Hive Redirection
There is no patch, so detection of the behavior is the defense. Static signatures alone are not enough, because an attacker can recompile from modified source and defeat sample-based detection. The behaviors below hold regardless of implementation. The following table maps the observable steps of the chain to what defenders should watch for. The step numbers match Figure 2.
|
Step |
What to watch for |
Why it is suspicious |
|
2. Prepare Environment |
Creation of Object Manager symbolic links beneath \BaseNamedObjects\Restricted by a user-context process |
Legitimate applications rarely create symbolic links in this namespace. Placement here is central to the redirection. |
|
3. Modify NTUSER.DAT |
Offline modification of an NTUSER.DAT hive and changes to the Local AppData value outside of profile provisioning |
A user process rewriting an unloaded profile hive to redirect a profile path has no normal explanation. |
|
4. Trigger Race Condition |
A process that creates a child under a different SID via CreateProcessWithLogonW with LOGON_WITH_PROFILE, where the child starts suspended and is a common Windows binary such as notepad.exe with no reason to remain suspended |
This is the core EDR signal. The combination of cross-SID process creation, profile load, and a suspended benign binary has no benign use. |
|
5. Load Target Hive |
A UsrClass.dat belonging to one user loaded into another user’s HKU\<SID>_Classes namespace |
A hive mounted in the wrong user’s namespace is the impact itself. Its presence is the highest-confidence indicator that redirection succeeded. |
The PoC drives the attack with a single call to CreateProcessWithLogonW using two flags. LOGON_WITH_PROFILE forces Windows to load the supplied user’s profile during process creation, triggering the vulnerable profile initialization path. CREATE_SUSPENDED leaves the primary thread suspended after creation, keeping the process frozen while the PoC controls timing through the batch oplock and the Object Manager symbolic links.
|
if (!CreateProcessWithLogonW(_creds->username, NULL, _creds->password, LOGON_WITH_PROFILE, L"C:\\Windows\\notepad.exe", NULL, CREATE_SUSPENDED, NULL, NULL, &si, &pi)) |
Tune on the combination, not on individual signals. CreateProcessWithLogonW and CREATE_SUSPENDED each appear in legitimate tooling. The full chain involves cross-SID process creation with a profile load, a suspended benign binary, and registry hive redirection occurring in close temporal proximity to modifications of NTUSER.DAT, access to UsrClass.dat, and Object Manager path creation beneath \BaseNamedObjects\Restricted. That combination has no benign explanation.
This is also where hunting and detection engineering divide the work. The cross-SID suspended process is high enough fidelity to drive a SOC detection. The offline hive modification and the symlink placement are lower-signal on their own and are better run as hunts across shared and multi-user hosts, where a foreign hive in the wrong namespace is the artifact to chase.
LegacyHive exposes a registry hive loading primitive in the User Profile Service. It combines an offline NTUSER.DAT modification, Object Manager namespace redirection, and a synchronized profile load to change how Windows resolves and loads the UsrClass.dat hive at profile initialization. The public release does not ship a full privilege escalation chain. It stops at the primitive. The primitive is the hard part, and it is what a larger attack would be built on.
The Howler Cell Threat Research Team reproduced the PoC in a controlled Windows 11 lab and confirmed the behavior. We planted a unique marker in the target user’s UsrClass.dat, ran the exploit, and found that marker accessible through the low-privileged user’s HKU\<SID>_Classes namespace. The hive crossed a boundary it was never meant to cross. That confirms the redirection the PoC claims and gives us a basis for further work on abuse scenarios and detection.
The exposure is highest on the systems that pack the most users onto one machine: Remote Desktop hosts, virtual desktop infrastructure, and shared workstations. On those systems the separation between users is the security control, and LegacyHive shows it can be forced open by an account with no special privileges. A low-privileged user should never see another user’s hive. Until the profile service validates the resolved path more strictly, the defense is detecting the activity itself: the cross-user suspended process, the symlink placement, and the out-of-place hive load. NightmareEclipse has now shipped nine tools against the parts of Windows customers were told to trust. Treat additional releases against this same surface as probable, and hunt for the primitives before they are wired into finished exploits.
Zero-Day PoC
Related NightmareEclipse mirrors and channels
Host and behavioral indicators
Validation artifact used by Howler Cell (not attacker-supplied)
No file hashes are provided. LegacyHive is distributed as source, not as a compiled binary, so hash-based indicators do not apply. Detection should focus on the behavioral indicators above.