LegacyHive: a standard user mounts the admin's hive, and there is no patch

What the exploit actually does

In Windows a hive is a file that holds a fragment of the registry. Your settings live in NTUSER.DAT and UsrClass.dat, the settings of the colleague in the next account live in their own files, and the system makes sure the two of you cannot read into each other's.

LegacyHive gets around that guardrail. The attacker swaps the value that points to the application data path, redirects the service into the object manager namespace, and then waits for the moment ProfSvc reaches for the file. It catches that moment with an oplock, an opportunistic lock on a decoy file, and in a split second swaps in a symbolic link. The service runs as SYSTEM, so it opens whatever was placed in front of it. The victim's hive lands in the attacker's classes root, with write access.

A classic file race, except the side that should never have made the start line wins it.

In short, the logic of the attack comes down to one thing: convince the service to load a planted file into the profile branch. The outline below shows the idea only, not working code.

// Uproszczony schemat logiczny ataku LegacyHive
// Atakujący manipuluje usługą profili, aby załadować celowy plik hive
// do gałęzi HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
void TriggerLegacyHive() {
    std::string targetUser = "Administrator";
    std::string maliciousHivePath = "C:\\temp\\fake_hive";

    // Próba wymuszenia załadowania ula w kontekście obecnego procesu
    if (LoadUserHive(targetUser, maliciousHivePath)) {
        printf("Success: Target hive mounted in current user classes root.\n");
    }
}

The real exploit is far more convoluted, because everything hard about it comes down to synchronizing the link swap with the exact moment the service reaches for the file. The outline skips that part on purpose.

Microsoft patched a similar bug back in 2015 as CVE-2015-0004. Same class, a new way in.

What the exploit does not do

Here is the part most headlines skip.

The published PoC is deliberately cut down. It needs the credentials of one more ordinary user and the name of a third account, and it mounts only UsrClass.dat. The author claims the original version needed no extra passwords and took any hive, but that version he never showed.

Matei Badanoiu of Pentest-Tools put it plainly: for someone who already has a foothold in the environment this is a genuinely useful primitive, while stitching it together with credential theft and persistence into one 'full takeover' is more ambition than what actually shipped.

I agree. On its own LegacyHive does not make anyone a Domain Admin and does not drive in from the internet. You already have to be on the machine, have an account, and have a second account to use.

So why care at all

Because that precondition is trivial in practice. An account taken over by phishing, a laptop handed on after someone left, a lab workstation half the department logs into, a service account three people share. A foothold at ordinary-user level is rarely the hard part; it is the starting point.

And once you have it, write access to another user's classes branch is surprisingly strong. Will Dormann, who tested the exploit, showed it with an example: you can associate .txt files with the calculator, so the admin logs in, opens a note, and runs your code. The calculator is a joke, of course. In its place you can put anything, including things that do not require the victim to click on anything.

So the mechanism is this: you hold an intern's account, you wait until someone with local admin rights logs into the same machine, and you get code execution in their context. From there LSASS, credentials, lateral movement. Known for years, only the way in is new.

For the board it comes down to one sentence: the separation of accounts on shared workstations, the thing many of us base our risk model on, does not hold in this scenario, and Microsoft has not shipped anything yet that would change it.

What to do when there is no patch

The standard advice to patch your systems will not help this time, because you already have the updates and the exploit runs on exactly those. What is left is narrowing the preconditions and detection.

Start with an inventory of the workstations more than one person logs into. Those are the target here, not the servers. Shared desks, machines in training rooms, service laptops, anything with a history of several local profiles.

Check where administrative accounts log in interactively on ordinary workstations. Every such login leaves a profile, and a profile is a hive that can be mounted. If a domain admin logs into a user's machine to 'quickly check something', you have a problem older than LegacyHive.

Set an EDR alert on user processes trying to load registry hives and on unusual changes to profile path values in ProfileList. You will not block the race, but it leaves a trace.

Review who holds local admin and whether it still has a reason. Not because it stops this particular exploit, but because it shortens the chain after it.

And drop the idea that the release will disappear from the internet. This researcher's accounts have already been taken down from GitHub and GitLab, and he comes back with the next tool. Of his six earlier zero-days, three were used in attacks before the fixes came out.

One last thing

I am writing this on a day when Microsoft is still silent, so some of the above may go out of date within a week. If an advisory comes out, we will update the post.

That leaves a question worth answering before Monday: how many workstations do you have where, in the last six months, both an ordinary user and someone with admin rights logged in? If you do not know, that is exactly the number we start from in an internal test.