Fortra Intelligence and Research Experts (FIRE) have conducted a deep technical analysis of BlueHammer, a highly sophisticated Windows zero-day exploit chain that achieves Local Privilege Escalation (LPE) to NT AUTHORITY\SYSTEM. To help security teams better navigate the advanced threat landscape, we are sharing this technical deep dive into how the exploit operates and how to defend against it.
BlueHammer is dangerous not because it uses a simple bug, but because it chains together several legitimate Windows components in a clever and unexpected way. It tricks trusted features into exposing sensitive system information without relying on obvious malware behavior. Specifically, the exploit abuses Windows Defender’s signature update mechanism, the Volume Shadow Copy Service (VSS), the Cloud Files API, and a Time-of-Check to Time-of-Use (TOCTOU) race condition to read the system's SAM database.
Once this happens, an attacker with local access can use the exposed data to take over the device as SYSTEM. To combat threats like this, defenders must look beyond traditional signatures and focus on suspicious behavior patterns, especially unusual account changes, file redirection activity, and the misuse of trusted Windows services.
After analyzing the BlueHammer Proof-of-Concept (PoC) and the vulnerability used to develop an exploit for CORE Impact, we have broken down exactly how this threat works. Below is a detailed look at how the exploit operates step-by-step, the precise conditions required for its success, and the artifacts it leaves behind for defenders.
Exploit Execution Chain
The BlueHammer exploit operates in nine distinct phases, sequentially manipulating system state, file locks, and directory junctions to force a privileged process into redirecting its read operations.
Phase 1: Polling for Signature Updates
The exploit utilizes the Windows Update Agent COM API (IUpdateSession) to poll for a pending Windows Defender Definition Update. Platform updates are explicitly skipped. The polling loop retries every 30 seconds for a maximum of 5 minutes until a valid signature update is available.
Phase 2: Payload Extraction
Once an update is identified, the exploit downloads mpam-fe.exe from the Microsoft CDN (go.microsoft.com/fwlink/?LinkID=121721). The downloaded PE file’s .rsrc section is parsed to extract an embedded Cabinet file entirely in memory. Using the FDI (File Decompression Interface) Cabinet API with custom in-memory I/O callbacks, it decompresses the cabinet's contents to obtain the .vdm signature definition files.
Phase 3: Triggering Volume Shadow Copy Creation
To access restricted system files, the exploit forces the creation of a VSS snapshot. It drops a file containing a reversed EICAR test string into a temporary directory to trigger a Windows Defender scan. Concurrently, it acquires a batch oplock on RstrtMgr.dll to block Windows Defender during its file-access phase. This lock causes Windows to generate a new Volume Shadow Copy. A background thread monitors the Object Manager (\Device\) via NtQueryDirectoryObject, waiting for the HarddiskVolumeShadowCopyN device to populate.
Phase 4: Suspending Windows Defender via Cloud Files API
A second worker thread registers a Cloud Files sync root and drops a placeholder lock file. When Windows Defender enumerates the sync root directory and triggers the CF_CALLBACK_TYPE_FETCH_PLACEHOLDERS callback, the exploit sets a second batch oplock. This suspends Windows Defender's execution while it holds a SYSTEM-level file handle.
Phase 5: Initiating the Update Engine via RPC
The extracted .vdm files are written to a temporary directory. A thread then calls ServerMpUpdateEngineSignature over ALPC-RPC, passing the temporary directory to Windows Defender. Running as NT AUTHORITY\SYSTEM, Defender creates a new subdirectory under C:\ProgramData\Microsoft\Windows Defender\Definition Updates\.
Phase 6: TOCTOU Race Condition and Path Redirection
The exploit monitors ReadDirectoryChangesW on the Definition Updates folder to detect the newly created subdirectory. It sets a batch oplock on mpasbase.vdm inside the temporary update directory. When Windows Defender opens the file and triggers the oplock, the exploit executes the following operations within the race window:
Renames mpasbase.vdm out of the directory (e.g., to <dir>.WDFOO).
Renames the update temporary directory itself (e.g., to <dir>.foo).
Recreates the original directory path as a mount-point reparse point (directory junction) targeting \BaseNamedObjects\Restricted.
Creates an Object Manager symbolic link at \BaseNamedObjects\Restricted\mpasbase.vdm pointing to \Device\HarddiskVolumeShadowCopyN\Windows\System32\Config\SAM.
When the oplock is released, Windows Defender resumes its read operation on <newdefupdatedir>\mpasbase.vdm. It follows the junction and Object Manager link into the VSS copy of the SAM hive, reading the file with SYSTEM privileges.
Phase 7: Extracting the SAM Hive
The exploit opens the path Windows Defender used to copy the update file, reads the full SAM database into memory, and writes it to a temporary file.
Phase 8: Decrypting SAM Password Hashes
The exploit retrieves the Windows boot key from HKLM\SYSTEM\CurrentControlSet\Control\Lsa\{JD,Skew1,GBG,Data}. It then opens the saved SAM hive offline via offreg.dll (OROpenHive), decrypts the SAM password encryption key from SAM\Domains\Account\F (AES-128-CBC), and enumerates accounts under SAM\Domains\Account\Users\. Each account's NT hash is decrypted (AES-128-CBC for modern accounts, DES-ECB for older accounts).
Phase 9: Privilege Escalation and Execution
For every local user account (excluding the current user and WDAGUtilityAccount), the exploit:
Temporarily replaces the password with a hardcoded string ($PWNed666!!!WDFAIL) using SamiChangePasswordUser from samlib.dll.
Calls LogonUserEx with the temporary password to obtain a logon token.
If the account belongs to the Administrators group, it impersonates the token and creates a temporary Windows service that executes the exploit binary.
The Service Control Manager (SCM) executes the binary as NT AUTHORITY\SYSTEM, which then uses CreateProcessAsUser to spawn a CORE Impact agent.
Finally, the exploit restores the original password hashes via samlib.dll.
Environmental Prerequisites and Failure
Conditions
The exploit execution is highly deterministic and will fail if the following conditions are not met:
Windows Defender State: The WinDefend service must be running with real-time protection enabled to process the definition update and scan the EICAR trigger.
Update Availability: A signature update must be available. The exploit actively polls for an update; if not available, it waits 30 seconds and tries again.
Network Access: The host must be able to reach the Microsoft CDN via WinINet to download mpam-fe.exe.
VSS Subsystem: VSS must be enabled and functional. If VSS is disabled, blocked by policy, or if storage constraints prevent snapshot creation, the harddisk volume lookup will fail.
File Locks: RstrtMgr.dll must be available for a batch oplock. Conflicting handles from other processes will cause this step to fail.
Cloud Files API: CfAPI must be available and unrestricted by policy (requires Windows 10/Server 2019+).
Privileges: The caller token must allow the creation of object-manager symlinks in \BaseNamedObjects\Restricted. Environments restricting SeCreateSymbolicLinkPrivilege for standard users will block the TOCTOU redirection.
File System Permissions: Standard user write access to %TEMP% and read/write access to “C:\ProgramData\Microsoft\Windows Defender\Definition Updates” is required.
Account Availability: At least one other local account with administrative privileges must exist on the machine. If none exists, the final SCM service creation will fail.
Execution Timing: The batch oplock and VSS suspension rely on Windows Defender’s update thread reaching specific I/O points. Variations in timing (e.g., due to system load or different Defender engine versions) can cause the race condition to fail.
Detection Observables
The execution chain introduces several distinct artifacts and behavioral anomalies that can be monitored via EDR or Windows Event Forwarding:
SAM Database Manipulation: Rapid, temporary password changes across local accounts using samlib.dll. The presence of the hardcoded password string $PWNed666!!!WDFAIL in credential alteration events is a direct indicator.
Abnormal Defender I/O: Unusual ALPC-RPC calls triggering Defender updates, accompanied by rapid directory creation, deletion, and renaming inside “C:\ProgramData\Microsoft\Windows Defender\Definition Updates\”.
Reparse Point Anomalies: The creation of directory junctions targeting "\BaseNamedObjects\Restricted\” by standard user processes.
Suspicious Oplocks and VSS: Unexpected VSS snapshot creation (HarddiskVolumeShadowCopy) immediately following batch oplocks on RstrtMgr.dll or Cloud Files placeholder lock events.
Network Activity: Downloads of mpam-fe.exe initiated by standard user processes rather than the standard Windows Update service context.
Final Thoughts
The BlueHammer zero-day highlights a growing trend in advanced vulnerability exploitation: weaponizing complex OS mechanics and race conditions rather than relying on traditional memory corruption. By abusing trusted processes like Windows Defender to bypass file access restrictions, attackers can achieve full SYSTEM compromise with built-in tools.
Although the exploit chain is fragile and requires a "perfect storm" of environmental prerequisites to succeed, it demonstrates why organizations must continuously evaluate their security posture. Relying solely on static indicators is no longer sufficient; defenders must implement robust behavioral monitoring to detect the subtle anomalies—such as unexpected reparse points, VSS manipulation, and rapid credential changes—that betray this level of advanced tradecraft.
