LegacyHive: Windows 2000 called. It wants its registry file back

Was I hacked?

Finding UsrClass.dat on a Windows computer does not mean you were hacked. Every normal Windows user profile has one. It is the filing cabinet in which Windows keeps user-specific file associations and COM registrations; removing it because an alarming article mentioned its name is an excellent way to convert a security check into a help-desk incident.

Your computer deserves investigation when these facts overlap:

1. it ran a Windows build older than the August 2026 fix for CVE-2026-62832;
2. an untrusted person or process already obtained a low-privileged local account or code execution on it; and
3. telemetry shows copies of UsrClass.dat or NTUSER.DAT in odd locations, unusual profile-loading activity, or persistence beneath another user's *_Classes registry hive.

This is a local privilege-escalation vulnerability. It is not a magic packet that attacks a Windows laptop directly from the Internet, and receiving an email does not trigger it by itself. The attacker must already be able to run code locally with limited rights. LegacyHive is what may turn that foothold into access to another user's registry settings and, with a suitable persistence entry or follow-on technique, privileged code execution.

If you already suspect exploitation:

• isolate the device through your EDR or network controls;
• do not delete the suspicious hive copies or staging directories;
• preserve EDR telemetry, memory and disk evidence according to your incident process;
• stop using privileged accounts on that device;
• revoke affected sessions and rotate exposed credentials from a clean device;
• hunt for the same staging pattern and initial-access payload elsewhere.

The vulnerability is the lift, not the person entering the building. You still need to determine who reached the ground floor and what they carried upstairs.

The short version

CVE-2026-62832, commonly called LegacyHive, is a high-severity elevation-of-privilege vulnerability in Windows User Profile Service. Microsoft describes it as improper link resolution before file access. Its CVSS score is 7.8: local attack, low complexity, low privileges required, no user interaction, and high potential impact to confidentiality, integrity and availability.

The public research showed a standard user coercing the profile service into opening another user's registry hive. The service performs part of its work as NT AUTHORITY\SYSTEM. By carefully changing what a path resolves to between checks, the attacker can make that privileged service load a hive it should not expose to the caller.

The central file is:

C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat

On Windows 2000 and XP the path looked different, but the job was recognisable: this hive backed the user-specific classes registry. Microsoft still supports old registry-hive formats for compatibility. Twenty-five years of compatibility is marvellous when opening an ancient line-of-business application. It is less charming when the compatibility layer carries somebody else's registry into your session.

Microsoft patched LegacyHive on 11 August 2026 and assigned it CVE-2026-62832. At release it was publicly disclosed and assessed as more likely to be exploited, but Microsoft had not reported exploitation in the wild. Publicly known is not the same as publicly exploited; defenders should preserve that distinction even when headlines have misplaced it.

What is UsrClass.dat?

Windows Registry data is divided into hives. A hive is a logical group of registry keys backed by files on disk and loaded when Windows starts or a user signs in.

NTUSER.DAT backs most of HKEY_CURRENT_USER. UsrClass.dat backs the user-specific portion of the classes registry, broadly visible as:

HKEY_CURRENT_USER\Software\Classes
HKEY_USERS\<SID>_Classes

That area contains, among other things:

• file-extension associations;
• ProgIDs describing how document types are opened;
• per-user COM class registrations, including CLSIDs;
• shell integration and other user-specific application behaviour.

Microsoft documents that HKEY_CLASSES_ROOT is a merged view of machine-wide and user-specific class registrations, and that the user's settings take precedence. This is useful: a user may choose a different application for a file type without rewriting the whole machine. It is also why write access to a privileged user's classes hive can become code execution. If an attacker can alter what an administrator's shell or COM client launches, the poisoned setting may activate when that administrator next signs in or performs an ordinary action.

The hive file is not malicious. The broken trust decision is allowing one security context to influence which user's hive a SYSTEM service loads and where it becomes visible.

The attack path, without the exploit code

The public proof of concept combined four ordinary Windows facilities:

• a low-privileged local account;
• Windows User Profile Service (ProfSvc);
• Object Manager path redirection or symbolic-link behaviour;
• synchronisation that pauses file access at a useful moment.

The simplified sequence is:

attacker already runs as a standard user
                  |
                  v
prepares a registry hive and a replaceable path
                  |
                  v
asks User Profile Service to load a profile
                  |
                  v
service checks one path, then retries as SYSTEM
                  |
        attacker changes the path target
                  |
                  v
SYSTEM opens another user's UsrClass.dat
                  |
                  v
attacker gains access to that user's classes hive
                  |
                  v
file-association or COM persistence can execute later

This is a link-following or time-of-check/time-of-use family of problem. The service believes it is continuing work on the object it checked, while the attacker's redirection causes the later privileged access to reach a different object.

The stripped public demonstration required credentials for another standard account and a target username, and concentrated on UsrClass.dat. Researchers noted that the underlying primitive was broader. That does not mean every person downloading the demonstration instantly obtained SYSTEM; it means defenders should treat the service boundary as broken on an unpatched host and should not use the limitations of one public demonstration as a security control.

Who is affected?

Microsoft supplied fixes for supported Windows 10, Windows 11 and Windows Server releases. The following build numbers are useful minimums from the original August advisory; a later cumulative security update is also acceptable.

Use Microsoft's CVE page as the final authority, particularly for servicing branches, Extended Security Updates and hotpatch configurations. A matching major build with a lower UBR—the digits after the full stop—is still below the listed fix.

Unsupported Windows editions deserve a migration or isolation decision rather than an archaeological search for a random update package. A security update copied from an unofficial mirror is simply another untrusted executable wearing a reassuring filename.

Step 1: check one Windows device

Run this in PowerShell. It reports the product, build and update revision without changing the machine:

$os = Get-CimInstance Win32_OperatingSystem
$cv = Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'

[pscustomobject]@{
  ComputerName = $env:COMPUTERNAME
  Caption      = $os.Caption
  ProductType  = $os.ProductType
  DisplayVersion = $cv.DisplayVersion
  Build        = [int]$os.BuildNumber
  UBR          = [int]$cv.UBR
  FullBuild    = "$($os.BuildNumber).$($cv.UBR)"
  LastBoot     = $os.LastBootUpTime
}

ProductType is 1 for a workstation, 2 for a domain controller and 3 for another server. That matters because Windows 11 24H2 and Windows Server 2025 share build 26100 but have different update-revision numbers.

This second block compares the detected build against the original fixed build:

$os = Get-CimInstance Win32_OperatingSystem
$cv = Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$build = [int]$os.BuildNumber
$ubr   = [int]$cv.UBR

$minimumUbr = switch ($build) {
  19044 { 7663 }
  19045 { 7663 }
  20348 { 5499 }
  22631 { 7517 }
  26100 { if ($os.ProductType -eq 1) { 9168 } else { 33296 } }
  26200 { 9168 }
  28000 { 2704 }
  default { $null }
}

if ($null -eq $minimumUbr) {
  "Build $build is not in this article's original advisory table; check MSRC."
} elseif ($ubr -ge $minimumUbr) {
  "At or above the original CVE-2026-62832 fixed build: $build.$ubr"
} else {
  "BELOW the original fixed build: $build.$ubr; minimum is $build.$minimumUbr"
}

The script is a triage aid, not a replacement for Intune, Configuration Manager, WSUS, Defender Vulnerability Management or another authenticated patch-inventory platform. Use the platform that can prove coverage across every workstation, server, VDI image and offline laptop—not the spreadsheet whose owner left in 2023.

Step 2: find suspicious hive staging on disk

Normal locations include:

C:\Users\<user>\NTUSER.DAT
C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat

Copies with these names in a drive root, temporary folder or newly created GUID-like directory deserve review. The following local PowerShell search is read-only. It may take several minutes on a large drive, so use it during incident triage rather than in a five-minute fleet-wide logon script:

$expectedUsrClass = '(?i)^C:\\Users\\[^\\]+\\AppData\\Local\\Microsoft\\Windows\\UsrClass\.dat$'
$expectedNtUser   = '(?i)^C:\\Users\\[^\\]+\\NTUSER\.DAT$'

Get-ChildItem -Path C:\ -Force -File -Recurse `
  -Include UsrClass.dat,NTUSER.DAT -ErrorAction SilentlyContinue |
  Where-Object {
    ($_.Name -ieq 'UsrClass.dat' -and $_.FullName -notmatch $expectedUsrClass) -or
    ($_.Name -ieq 'NTUSER.DAT'   -and $_.FullName -notmatch $expectedNtUser)
  } |
  Select-Object FullName, Length, CreationTimeUtc, LastWriteTimeUtc

Do not convict a file merely because it is outside those two paths. Profile migration tools, backup software, forensic collections and administrators can make legitimate copies. Ask who created it, which process wrote it, whether there is a matching change record, and what happened immediately before and after.

For each unexplained file, preserve metadata and a cryptographic hash before moving anything:

$file = 'C:\SuspiciousPath\UsrClass.dat'

Get-Item -LiteralPath $file -Force |
  Select-Object FullName, Length, CreationTimeUtc, LastWriteTimeUtc

Get-FileHash -LiteralPath $file -Algorithm SHA256

Hash comparison helps correlate copies across devices. It does not prove that the hive is harmless or malicious; a registry hive is data, and its meaning lies in the keys it contains.

Step 3: hunt with Microsoft Defender XDR

DeviceFileEvents records file creation and modification events from Microsoft Defender for Endpoint. This query looks for hive files outside their expected user-profile directories:

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName in~ ("UsrClass.dat", "NTUSER.DAT")
| extend LowerPath = tolower(FolderPath)
| where not(
    (FileName =~ "UsrClass.dat" and
     LowerPath matches regex @"^[a-z]:\\users\\[^\\]+\\appdata\\local\\microsoft\\windows$")
    or
    (FileName =~ "NTUSER.DAT" and
     LowerPath matches regex @"^[a-z]:\\users\\[^\\]+$")
  )
| project Timestamp, DeviceName, ActionType, FileName, FolderPath,
    SHA1, InitiatingProcessAccountName, InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

Then pivot from each result to the initiating process and account:

• Was the file created by approved backup or profile-migration software?
• Did the same process create a directory directly under C:\?
• Did it interact with another user's profile immediately afterwards?
• Was there a recent suspicious browser, Office, archive or script process that supplied initial access?
• Did a privileged user log on after the hive activity?

This second query supplies the privileged-logon side of the timeline. Adjust account naming for your environment:

DeviceLogonEvents
| where Timestamp > ago(30d)
| where ActionType == "LogonSuccess"
| where IsLocalAdmin == true
| project Timestamp, DeviceName, AccountDomain, AccountName,
    LogonType, RemoteIP, InitiatingProcessFileName
| order by Timestamp desc

IsLocalAdmin availability can vary with data and product configuration. If the column is not populated, join the timeline with your privileged-account inventory instead of declaring the query broken and going for lunch.

Step 4: inspect the classes hives that are already loaded

On a contained device or forensic copy, list the user class hives currently mounted beneath HKEY_USERS:

Get-ChildItem 'Registry::HKEY_USERS' -ErrorAction SilentlyContinue |
  Where-Object { $_.PSChildName -match '_Classes$' } |
  Select-Object PSChildName, Name

Map the SID to a local profile:

Get-CimInstance Win32_UserProfile |
  Select-Object SID, LocalPath, Loaded, LastUseTime

Focus review on user-controlled launch points, especially if an administrative account logged on after suspicious hive staging:

HKEY_USERS\<SID>_Classes\CLSID\<class>\InprocServer32
HKEY_USERS\<SID>_Classes\CLSID\<class>\LocalServer32
HKEY_USERS\<SID>_Classes\<extension>
HKEY_USERS\<SID>_Classes\<ProgID>\shell\open\command

Do not bulk-delete unfamiliar COM registrations. Windows and ordinary applications create many of them. Export the relevant hive for evidence, compare it with a known-good endpoint of the same role, validate referenced binaries and signatures, and use Sysinternals Autoruns or your EDR's persistence view to reduce the haystack.

Useful questions for any suspicious value are:

• Does it point into %TEMP%, %APPDATA%, Downloads, a user's writable folder or a network path?
• Is the referenced executable or DLL unsigned or newly created?
• Is the parent CLSID normally machine-wide but unexpectedly overridden per user?
• Does the command include PowerShell, cmd.exe, mshta.exe, a script host or an encoded argument?
• Is there a legitimate installer, policy or support ticket explaining it?

Step 5: build the complete incident timeline

LegacyHive is normally a second-stage technique. If you find evidence of it, the investigation cannot begin and end with the registry file.

Work backwards to initial access:

• phishing attachment or link;
• browser download;
• malicious archive or installer;
• exposed remote-management service;
• stolen local or domain credentials;
• another vulnerability that first provided code execution.

Work forwards from the likely escalation time:

• privileged interactive or remote logons;
• new services, scheduled tasks and WMI event subscriptions;
• security-tool exclusions or stopped services;
• LSASS access, credential dumping or DPAPI access;
• new local administrators;
• outbound connections to unfamiliar infrastructure;
• remote service creation or lateral movement.

On one device, collect a concise account and logon snapshot:

Get-LocalUser |
  Select-Object Name, Enabled, LastLogon, PasswordLastSet

Get-LocalGroupMember -Group 'Administrators' |
  Select-Object Name, ObjectClass, PrincipalSource

$start = (Get-Date).AddDays(-14)
Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4624,4672,4720,4732
  StartTime = $start
} -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message

Event 4624 records successful logons, 4672 special privileges assigned to a logon, 4720 account creation and 4732 membership added to a local security group. Logging configuration and retention determine what exists. An empty result may mean the evidence rolled over on Tuesday, not that Tuesday was peaceful.

Step 6: patch properly

Install the applicable August 2026 Windows security update or any later cumulative security update, then reboot if the update requires it. Verify the resulting full build rather than trusting “installation successful” in one console.

Prioritise:

1. administrator workstations and jump hosts;
2. servers where ordinary users or service identities can run code;
3. shared desktops, RDS hosts and VDI pools;
4. developer machines, where local execution is practically the job description;
5. golden images and devices that were offline during Patch Tuesday.

After patching, run the build check again and make your management platform report the actual device state. A compliant policy attached to an offline laptop is an aspiration, not a patch.

There is no sensible general workaround that makes the affected profile service trustworthy while leaving it unpatched. Restricting local logon, removing unnecessary local accounts, using application control and reducing administrator sign-ins on ordinary endpoints all reduce opportunity, but they do not repair the vulnerable path resolution.

If a supported machine cannot be patched promptly, isolate it from privileged workflows and sensitive credentials. If an unsupported machine must remain, segment it, deny ordinary user access, apply compensating application controls and set a replacement deadline with an owner. “Temporary exception” is a phrase that has survived more operating systems than UsrClass.dat.

Step 7: validate the fix and the detection

Use a lab or canary device, not a production domain controller and not the public exploit.

Validation should prove four separate things:

• the device reached the fixed Windows build;
• it rebooted where required;
• normal user sign-in and profile creation still work;
• your telemetry detects suspicious hive staging.

To test only the file-detection rule, create a harmless empty file with the suspicious name on an isolated test endpoint:

New-Item -Path 'C:\IR-Detection-Test' -ItemType Directory -Force
New-Item -Path 'C:\IR-Detection-Test\UsrClass.dat' -ItemType File -Force

Confirm that the Defender query or SIEM rule produces the expected event, then remove the test directory:

Remove-Item -LiteralPath 'C:\IR-Detection-Test' -Recurse -Force

That validates telemetry, not exploit prevention. Do not rename a live user's hive, redirect profile paths or execute a public proof of concept on a business system. A vulnerability test that corrupts the finance director's profile is technically memorable but operationally unhelpful.

A compact response checklist

First 30 minutes

• Check the full Windows build against the MSRC advisory.
• Isolate the host if initial compromise or hive staging is suspected.
• Preserve suspicious files, EDR telemetry and relevant logon data.
• Identify every privileged account used on the device.
• Search for UsrClass.dat and NTUSER.DAT outside expected profile paths.

First two hours

• Hunt across the estate using the MDE query or equivalent SIEM data.
• Review privileged logons after suspicious profile activity.
• Inspect per-user COM and file-association persistence.
• Determine initial access and search for its indicators elsewhere.
• Revoke sessions and rotate exposed credentials from a clean device.

Remediation

• Install the August 2026 or later Windows cumulative security update.
• Reboot where required and verify the full build.
• Patch golden images, VDI pools and offline devices.
• Remove persistence and rebuild a compromised endpoint when confidence is insufficient.
• Record evidence, scope, decisions and validation results.

Common mistakes

“We found UsrClass.dat, so the machine is compromised.”

No. It is a normal Windows profile component. Location, creator, timing and contents provide the context.

“The attack is local, so it is not important.”

Local privilege escalation is how a browser or phishing foothold becomes administrator-level control. Attack chains are fond of teamwork.

“Our users are not administrators, therefore we are safe.”

That limits damage before escalation; it does not fix the escalation vulnerability. Standard users are the starting condition described by the CVE.

“The public PoC needs extra credentials, so nobody can exploit it.”

The released demonstration was deliberately constrained. Defensive decisions should follow the underlying primitive and Microsoft's advisory, not the politeness of one researcher.

“We installed the KB, so investigation is finished.”

Patching prevents future exploitation of this flaw. It does not remove persistence or undo actions performed before the patch.

“We will block UsrClass.dat.”

Windows needs it. Blocking or deleting legitimate hives damages profiles and applications. Detect unusual copies and access patterns instead.

Questions people ask

Can LegacyHive attack a computer directly over the Internet?

Not by itself. Microsoft rates the attack vector as local. An attacker must first obtain local code execution or an authenticated foothold, commonly through another vulnerability, malware, stolen credentials or physical access.

Does it provide SYSTEM immediately?

The vulnerable operation occurs in a service running as SYSTEM, and Microsoft rates the technical impact as total. The constrained public demonstration exposed another user's classes hive and showed a path to privileged execution when that user acted. Treat the boundary as broken, but do not describe every public demonstration as an instant one-click SYSTEM shell.

Is UsrClass.dat really from Windows 2000/XP?

The user-classes hive and its supporting file existed in that era, and Microsoft documents that Windows retains the Windows 2000 registry-hive format for backward compatibility. The file's location changed after XP; the compatibility idea did not retire.

Is Windows 7 affected?

The original Microsoft CVE update table governs supported affected products. Unsupported versions may not receive normal fixes even when similar components exist. Do not infer safety from absence in a current servicing table; migrate or isolate unsupported Windows.

Did Microsoft observe attacks in the wild?

At the August 2026 release Microsoft marked the issue as publicly disclosed and exploitation more likely, but not detected. Public proof-of-concept availability raises urgency without proving that a specific organisation was attacked.

Should I run the public proof of concept to test our machines?

No, not on production systems. Verify the fixed build, validate normal profile behaviour in a lab, and test your detection with harmless synthetic files. An exploit is not a patch-management scanner.

The lesson

LegacyHive is not evidence that old file formats are automatically evil. It is evidence that compatibility code still crosses modern security boundaries and must be threat-modelled as modern code.

Windows correctly wants a user to control that user's preferences. It must not let one user persuade a SYSTEM service to fetch another user's filing cabinet, leave it on the wrong desk and then act surprised when the stationery goes missing.

Patch the operating system, hunt for the pre-patch activity, and remember the order: first access, then escalation, then whatever the attacker actually wanted. Fixing only the middle step leaves a rather important first and third act unexamined.

References

• Microsoft Security Update Guide: CVE-2026-62832
• NVD: CVE-2026-62832
• Microsoft: Registry Hives
• Microsoft: HKEY_CLASSES_ROOT and per-user class registrations
• Microsoft Defender XDR: DeviceFileEvents schema
• 0patch technical analysis of LegacyHive
• BleepingComputer: LegacyHive disclosure and independent validation
• Sigma rule: registry hive staged outside a normal profile path

Editorial safety boundary

This article provides defensive identification, patch verification, hunting and incident-response guidance. It intentionally omits proof-of-concept code, race orchestration, Object Manager redirection instructions and persistence payloads. Test only systems you own or are explicitly authorised to assess.