10 minmedium
LegacyHive: Hunting Windows Profile Initialization Abuse Through Offline Registry Manipulation
LegacyHive is a proof-of-concept released by the Nightmare-Eclipse disclosure actor that abuses legitimate Windows profile initialization mechanisms rather than exploiting a traditional software vulnerability. By offline-modifying a target account's ntuser.dat hive via the Registry Offline API, redirecting Local AppData into an attacker-crafted NT Object Manager namespace via NtCreateDirectoryObjectEx/NtCreateSymbolicLinkObject, and using a batch oplock plus CreateProcessWithLogonW to force profile reload, the technique hijacks path resolution for a helper account once it authenticates. Each individual API call is legitimate, but their combination within a short window is highly anomalous and forms the basis of the detection guidance provided.
Conf:high
Showing defanged values
- filenameLegacyCalc.exeVariant of the LegacyHive PoC tool observed launching calc.exe under a target account via CreateProcessWithLogonW
- filenameLegacyHive.exePoC binary executed to perform offline registry hive modification and profile hijack against a target helper account
- filenameLegacyWerBlue.exeVariant of the LegacyHive PoC tool observed launching WerFault.exe under a target account via CreateProcessWithLogonW
Detection / HunterAnthropic
What Happened
Security researchers published (and then analyzed) a proof-of-concept tool called LegacyHive that shows how an attacker who already has some foothold on a Windows computer, plus a second set of login credentials, can trick Windows into pointing a key personal data folder (Local AppData) to a hidden, attacker-controlled location instead of the real one. This mainly affects Windows systems and accounts where an attacker has already obtained limited access plus a helper account's password — it is not something that can be used from the outside with no prior access. It matters because the trick uses entirely normal, built-in Windows features in an unusual combination, so it could evade defenses that only look for obviously malicious code rather than unusual behavior patterns. Organizations should have their security teams review the detection guidance in this report (behavioral rules and hunting queries) and watch for the unusual registry and file-access patterns described, rather than trying to patch a specific flaw since none exists here.
Key Takeaways
- LegacyHive is a Windows PoC (not a traditional CVE-based vulnerability) that abuses profile initialization by offline-modifying a user's ntuser.dat/UsrClass.dat hive to redirect Local AppData into an attacker-controlled NT Object Manager namespace.
- The technique chains legitimate Windows APIs (NtCreateDirectoryObjectEx, NtCreateSymbolicLinkObject, Offline Registry API/offreg.dll, batch oplocks, CreateProcessWithLogonW with LOGON_WITH_PROFILE) — none malicious individually, but highly unusual when combined in a short time window.
- Exploitation requires a low-privileged account plus a separate helper account's credentials, making it primarily a post-compromise/lateral capability rather than a standalone remote exploit.
- Strongest forensic artifacts: Volatile Environment registry values resolving into \BaseNamedObjects or .\globalroot\ instead of normal profile paths, offline staging/copying of ntuser.dat or UsrClass.dat outside normal profile directories, and cross-account process creation via CreateProcessWithLogonW/seclogon.
- LevelBlue SpiderLabs provides a YARA rule for the LegacyHive binary and SentinelOne threat hunting queries targeting registry path injection, suspicious hive file paths, seclogon activity, and offreg.dll usage.
Affected Systems
- Windows systems fully patched with July 2026 Patch Tuesday updates
- Windows profile initialization / user registry hive loading (ntuser.dat, UsrClass.dat)
- Low-privileged user accounts with access to a helper account's credentials
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Preparation: Attacker obtains low-privileged access and credentials for a separate helper account
- Namespace Creation: LegacyHive creates a hidden NT Object Manager directory under \BaseNamedObjects\Restricted using NtCreateDirectoryObjectEx
- Path Redirection: Symbolic links are created via NtCreateSymbolicLinkObject to redirect resolution of profile-related paths
- Offline Hive Modification: The helper account's ntuser.dat is opened and modified offline via the Registry Offline API (offreg.dll), replacing Local AppData with the Object Manager path
- Timing Control: A batch oplock (FSCTL_REQUEST_BATCH_OPLOCK) on UsrClass.dat pauses execution until profile load reaches the correct point
- Trigger and Validation: CreateProcessWithLogonW with LOGON_WITH_PROFILE forces the helper account's profile to load the tampered hive, then RegOpenUserClassesRoot confirms the hijack succeeded
- Cleanup: Temporary staging files are deleted while the persistent registry redirection remains active
Detection Availability
- YARA Rules: Yes
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: Yes
- Platforms: LevelBlue SpiderLabs (YARA), SentinelOne (custom threat hunting query language)
The article includes a YARA rule (Appendix A) to detect the LegacyHive binary based on strings referencing NT Object Manager APIs, Offline Registry API functions, and hive/path keywords, and provides four SentinelOne hunting queries (Appendix B) targeting Volatile Environment registry injection, suspicious ntuser.dat/UsrClass.dat file paths, seclogon-related cross-account process activity, and suspicious offreg.dll loading.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR platforms with native API telemetry (NT syscalls) can catch the most distinctive signals (NtCreateDirectoryObjectEx/NtCreateSymbolicLinkObject), but many EDR products do not hook or log these low-level Object Manager APIs by default, requiring supplemental telemetry such as registry and file monitoring. |
| Network Visibility | None | The technique is entirely local/offline, involving no network communication, C2, or external infrastructure, so network-based detection is not applicable. |
| Detection Difficulty | Hard | Each individual API call (registry offline editing, oplock requests, CreateProcessWithLogonW) is legitimate and used by benign software; detection requires behavioral correlation across multiple distinct telemetry sources within a short time window rather than a single signature. |
Required Log Sources
- Registry modification/access logs (e.g., Sysmon Event ID 13, Volatile Environment key monitoring)
- File access/creation logs for ntuser.dat and UsrClass.dat outside standard profile paths
- Process creation logs (Sysmon Event ID 1 / Windows Event ID 4688) capturing parent-child relationships and CreateProcessWithLogonW/seclogon activity
- Module load logs for offreg.dll (e.g., Sysmon Event ID 7)
- Logon session logs to correlate cross-account authentication (Event ID 4624/4648)
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Look for a user's Volatile Environment registry key where LOCALAPPDATA (or similar profile path values) resolves into \BaseNamedObjects or .\globalroot\ instead of a standard filesystem path under the user's profile. | Registry read/write monitoring on HKEY_USERS<SID>\Volatile Environment | Defense Evasion / Persistence (post profile load) | Low — legitimate paths should never reference kernel object namespaces in this key. |
| Hunt for file access or copy operations targeting ntuser.dat or UsrClass.dat from paths outside the standard user profile directory structure. | File creation/access events (e.g., Sysmon Event ID 11) for filenames matching ntuser.dat/UsrClass.dat with non-standard parent paths | Collection / Persistence (offline hive modification) | Low-Medium — some legitimate backup or profile migration tools may access these files outside standard paths, requiring tuning. |
| Investigate svchost.exe (seclogon) spawning processes where the resulting process's user context differs from the parent process's user context, indicating cross-account profile loading via CreateProcessWithLogonW. | Process creation logs correlating parent/child user SID with command-line arguments referencing '-k netsvcs -p -s seclogon' | Execution (profile load trigger) | Medium — legitimate 'Run as different user' functionality and some admin tooling may trigger similar patterns. |
| Consider correlating module loads of offreg.dll by processes outside standard Windows system directories (System32, SysWow64, WinSxS) as an indicator of offline registry hive tampering. | DLL/module load events (e.g., Sysmon Event ID 7) for offreg.dll | Persistence / Registry manipulation | Low — legitimate use of offreg.dll outside system directories or known security software is uncommon. |
| Look for a single process invoking both NtCreateDirectoryObjectEx and NtCreateSymbolicLinkObject in user mode within a short time window, as this combination is rare outside system components or research tooling. | EDR API/syscall telemetry capturing NT native API invocations | Defense Evasion (Object Manager namespace preparation) | Low — if visibility exists, this pairing is a strong, rarely-benign signal. |
Control Gaps
- Traditional signature/hash-based antivirus will not detect this technique since it relies on legitimate Windows APIs and no unique malicious payload beyond the PoC binary itself
- Network-based monitoring (firewalls, IDS/IPS, proxy) provides no visibility since the technique is entirely local/offline
- Standard patch management will not remediate this class of abuse, as no CVE or software flaw is being exploited
- EDR products without native NT syscall visibility (NtCreateDirectoryObjectEx/NtCreateSymbolicLinkObject) may miss the strongest behavioral signal
Key Behavioral Indicators
- Registry values in a user's Volatile Environment key resolving into \BaseNamedObjects or .\globalroot\ rather than a standard profile path
- Access to or staging of ntuser.dat/UsrClass.dat outside standard %USERPROFILE% locations
- Cross-account process creation where the parent process user differs from the resulting child process user, spawned via seclogon/svchost
- Module loading of offreg.dll from processes outside standard Windows system directories
- Batch oplock requests (FSCTL_REQUEST_BATCH_OPLOCK) against registry hive files
False Positive Assessment
Medium — individual signals (offreg.dll usage, seclogon cross-account activity, CreateProcessWithLogonW) can occur in legitimate administrative or profile-migration tooling; detection relying on correlation of multiple signals within a short time window reduces false positives but requires tuning to the specific environment.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting; consider deploying the provided detection queries/rules in your SIEM or EDR platform to hunt for the described registry, file, and process behaviors.
- If your EDR supports host isolation, consider isolating and investigating any host where Volatile Environment registry values resolve into Object Manager namespaces (e.g., \BaseNamedObjects).
- Consider reviewing accounts with shared or widely-known 'helper' credentials, as the technique requires possession of a second account's password to complete.
Infrastructure Hardening
- Evaluate restricting or auditing which processes are permitted to load offreg.dll outside standard system paths where supported by your application control tooling.
- Consider tightening credential-sharing practices and reducing standing helper/service account credential exposure to reduce the prerequisite conditions for this technique.
- Evaluate whether application allowlisting or attestation controls can flag unsigned or unknown binaries invoking CreateProcessWithLogonW with LOGON_WITH_PROFILE.
User Protection
- Consider deploying endpoint monitoring capable of surfacing native NT API calls (NtCreateDirectoryObjectEx, NtCreateSymbolicLinkObject) if supported by your EDR vendor.
- Evaluate file integrity monitoring on ntuser.dat and UsrClass.dat locations to detect offline tampering or staging outside standard profile paths.
Security Awareness
- Consider briefing detection engineering and threat hunting teams on this technique class so that behavioral correlation rules (rather than signature-based detection) are prioritized for this and similar 'living-off-the-land' Windows internals abuse.
- Consider incorporating credential hygiene practices (avoiding shared helper/test account credentials) into ongoing security awareness programs given the technique's reliance on obtaining a second account's password.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping6 techniques
Tactic
Initial Access
Tactic
Privilege Escalation
Tactic
Stealth
Tactic
Defense Impairment
Tactic
Lateral Movement
Additional IOCs
- Registry Keys:
Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders- Registry key within an offline user hive where the 'Local AppData' value is offline-modified to redirect to an attacker-controlled Object Manager path\BaseNamedObjects\Restricted- NT Object Manager namespace created by LegacyHive to host the redirection symbolic link structure
- File Paths:
C:\63485f71-eb67-42c6-a44e-c8fb239f093a\UsrClass.dat
- Command Lines:
- Purpose: Execute the LegacyHive PoC to hijack a target account's profile paths using a helper account's credentials | Tools:
LegacyHive.exe| Stage: Execution / Privilege Abuse |LegacyHive.exe <helper_account> <helper_password> <target_account>
- Purpose: Execute the LegacyHive PoC to hijack a target account's profile paths using a helper account's credentials | Tools:
Stay currentSubscribe via RSS