Post cover image

July 16, 2026

Breaking Down LegacyHive

LegacyHive is a local privilege escalation vulnerability that exploits a Time-of-Check to Time-of-Use (TOCTOU) race condition in the way…

By Chen Aviani

5 min read

LegacyHive is a local privilege escalation vulnerability that exploits a Time-of-Check to Time-of-Use (TOCTOU) race condition in the way the Windows User Profile Service (ProfSvc) resolves and loads user registry hives.

At the time of disclosure, the published PoC was reported to work on all currently supported Windows desktop and server versions, including fully patched systems running the latest July 2026 security updates.

The vulnerability was publicly disclosed on July 15, 2026, by security researcher Nightmare-Eclipse (MSNightmare), who is known for researching Windows internals and publishing Windows privilege-escalation vulnerabilities. The public proof-of-concept (PoC) is available on GitHub:

https://github.com/MSNightmare/LegacyHive

According to the researcher, the published PoC was intentionally stripped down to reduce the risk of public abuse. The original exploit reportedly did not require additional user credentials and was not limited to loading UsrClass.dat; however, those capabilities were intentionally omitted from the public release.

This article focuses on the published PoC, explaining how it works, the Windows mechanisms it abuses, and why convincing a privileged Windows service to load an unintended registry hive is considered a powerful privilege escalation primitive.

The following sections walk through the exploitation flow of the published LegacyHive PoC in detail.

Windows Components Behind the Exploit

Before examining how the exploit works, it is important to understand the Windows mechanisms it relies on. The following sections briefly introduce the key components used throughout the exploitation process.

User Profile Service (ProfSvc)

ProfSvc (User Profile Service) is the Windows service responsible for loading and unloading user profiles, including the user's registry hives and profile specific settings, when users log on and log off.

The service runs as NT AUTHORITY\SYSTEM, making any operation it performs on behalf of a user security sensitive.

Windows contains an internal namespace called the Windows Object Manager, which stores system objects such as devices, symbolic links, named pipes, mutexes, and many other kernel managed objects.

An Object Manager symbolic link redirects one Object Manager path to another location. Unlike a normal filesystem symbolic link (which redirects files or directories on disk), the redirection occurs inside the Object Manager namespace and is transparent to the component accessing the path.

Opportunistic Lock (Oplock)

An Opportunistic Lock (Oplock) is a Windows synchronization mechanism that notifies a process whenever another process attempts to access a file.

For example: An application places an oplock on C:\Temp\file.txt. When another process attempts to open the file, Windows immediately notifies the first application before allowing the access to continue.

GLOBALROOT

Normally, Windows accesses files through standard Win32 paths such as:

C:\Users\Bob\AppData\Local

LegacyHive instead uses:

\\.\GLOBALROOT\

GLOBALROOT provides direct access to the Windows Object Manager namespace, allowing the exploit to redirect profile paths (such as the location of UsrClass.dat) through Object Manager symbolic links rather than normal filesystem directories.

Exploitation Overview

At a high level, the exploit temporarily modifies the victim user's profile configuration stored in NTUSER.DAT, specifically the Local AppData registry value so that ProfSvc initially accesses an attacker controlled copy of UsrClass.dat. It then uses Object Manager symbolic links to redirect where Windows looks for the hive and an opportunistic lock (oplock) to notify the exploit's process when ProfSvc service attempts to access the copied UsrClass.dat, allowing the symbolic-link redirection to occur at the correct moment, causing the SYSTEM service to load a registry hive different from the one it originally intended to access.

None

How the Exploit Works

According to the researcher, the original exploit did not require additional user credentials, but the published PoC does and expects three arguments:

LegacyHive.exe <username> <username's_password> <target_user_hive>

Throughout this article, these arguments correspond to the following example users:

Current user (attacker): Alice
Helper user (<username> / <username_password>): Bob
Target user (<target_user_hive>): Administrator

The objective of the published PoC is to make ProfSvc load Administrator's UsrClass.dat while it is actually loading Bob's user profile. Although the PoC demonstrates the vulnerability using UsrClass.dat, the underlying vulnerability is not limited to this hive.

Preparing the Environment

The exploit begins by creating a temporary working directory with a random name, for example:

C:\A1B2C3D4\

It then copies Bob's existing UsrClass.dat into that directory:

C:\A1B2C3D4\UsrClass.dat

The copied UsrClass.dat serves as the initial hive that ProfSvc accesses before the exploit redirects it to the target user's original UsrClass.dat.

Note: A copy is used instead of the original file so the exploit has a controlled hive on which it can place an oplock and reliably win the race condition.

Redirecting the Profile Path

The exploit creates Object Manager symbolic links that initially redirect:

\BaseNamedObjects\Restricted\Microsoft\Windows

to

C:\A1B2C3D4

Therefore, when ProfSvc attempts to access:

Microsoft\Windows\UsrClass.dat

Windows transparently redirects the request to:

C:\A1B2C3D4\UsrClass.dat

ProfSvc is completely unaware that this redirection has taken place.

Waiting for ProfSvc

Before triggering the vulnerability, the exploit places an oplock on:

C:\A1B2C3D4\UsrClass.dat

It then calls:

CreateProcessWithLogonW(
  _creds->username,
  NULL,
  _creds->password,
  LOGON_WITH_PROFILE,
  L"<any_windows_application (the Poc uses notepad.exe)>",
  NULL,
  CREATE_SUSPENDED,
  ...
);

CreateProcessWithLogonW is a Windows API that authenticates a user using the supplied credentials (_creds->username and _creds->password) and creates a new process under that user's security context.

The important argument is LOGON_WITH_PROFILE, which instructs Windows to load the user's profile before creating the process. As a result, Windows asks ProfSvc to load Bob's profile, causing it to access UsrClass.dat and trigger the exploit.

As ProfSvc begins loading the profile, it follows the redirected path and attempts to access:

C:\A1B2C3D4\UsrClass.dat

The moment this happens, Windows breaks the oplock and immediately notifies the exploit's process.

This notification is essential because it indicates that ProfSvc has begun accessing the copied UsrClass.dat, allowing the exploit to safely redirect the remaining file accesses to the target hive.

Changing the Destination

Immediately after receiving the oplock notification, the exploit removes the Object Manager symbolic link that initially pointed to the temporary working directory and replaces it with a new one that points to Administrator's profile.

Originally it resolved to:

C:\A1B2C3D4

After the symbolic-link change, it resolves to:

C:\Users\Administrator\AppData\Local\Microsoft\Windows

Although ProfSvc is still accessing the same logical Object Manager path, the destination is now Administrator's profile directory.

The oplock is what makes this possible.

Note: Changing the symbolic link before ProfSvc begins loading the profile would likely cause the operation to fail because Windows performs multiple internal operations while resolving and opening the profile. The exploit therefore waits until ProfSvc has already started accessing the hive before changing the destination, making the race significantly more reliable.

Loading the Wrong Hive

ProfSvc continues the operation and ultimately loads:

C:\Users\Administrator\AppData\Local\Microsoft\Windows\UsrClass.dat

instead of Bob's UsrClass.dat.

The public PoC verifies that the unintended hive has been successfully loaded into the Registry.

At this point, the vulnerability has been successfully demonstrated.

Why It Is Powerful

The published PoC intentionally stops after demonstrating that ProfSvc can be tricked into loading a registry hive it was never intended to load.

Although this does not immediately provide a SYSTEM shell or execute arbitrary code, it gives an attacker control over which registry hive a SYSTEM service loads and trusts.

This becomes powerful if it can be combined with another vulnerability or privileged operation that relies on registry data. For example, a SYSTEM component that loads a DLL, launches an executable, or performs another sensitive action based on values stored in the loaded hive.

While the researcher did not disclose the complete exploitation chain, this ability to influence the registry data trusted by a privileged service is what makes LegacyHive a powerful privilege escalation primitive.

Conclusion

LegacyHive exploits a Time-of-Check to Time-of-Use (TOCTOU) race condition in the way the Windows User Profile Service (ProfSvc) resolves profile paths while loading user registry hives.

By combining offline registry modification (modifying a registry hive file directly on disk), GLOBALROOT, Object Manager symbolic links, and opportunistic locks, the published PoC manipulates ProfSvc into loading a registry hive different from the one it originally intended to access.

Although the public PoC intentionally stops after demonstrating this behavior, it shows how multiple legitimate Windows mechanisms can be combined to influence the behavior of a privileged service. This ability to make ProfSvc, running as SYSTEM, load an unintended registry hive is what makes LegacyHive a powerful privilege escalation primitive.