BlueHammer — Exploit Analysis

https://github.com/Nightmare-Eclipse/BlueHammer

This is a proof-of-concept for a privilege escalation / credential theft vulnerability targeting Windows Defender (MsMpEng). It chains several Windows internals techniques together to steal the SAM hive and gain SYSTEM-level code execution. Here’s how it works end-to-end:

Stage 1 — Waiting for a Windows Defender Signature Update

The exploit begins by polling the Windows Update API (IUpdateSearcher) waiting for a pending Defender signature update to become available. It downloads the update CAB file manually via WinInet, extracts the signature files (mpasbase.vdm, etc.) into a temp directory, and holds onto them. This is critical because the attack is timed around Defender’s own update process.

Stage 2 — Freezing Defender Using a Volume Shadow Copy + Oplock Race

This is the clever core of the exploit, a race condition using three interlocking primitives:

2a. Trigger a VSS Shadow Copy

The PoC writes an EICAR test file to disk, which causes Defender to scan it.
Simultaneously, it registers itself as a Cloud Files sync provider (CfRegisterSyncRoot / CfConnectSyncRoot) for the directory containing the EICAR file.
When Defender’s process queries the directory (enumeration triggers the CF_CALLBACK_TYPE_FETCH_PLACEHOLDERS callback), the exploit detects this by PID-matching the callback caller against the Defender service PID.
At that moment, before completing the callback, it requests a batch oplock (FSCTL_REQUEST_BATCH_OPLOCK) on a file inside the same directory.
This oplock forces Defender to pause — it cannot proceed with the file operation until the oplock is released.
While Defender is frozen, Windows creates a Volume Shadow Copy (VSS). The exploit detects the new HarddiskVolumeShadowCopy* device appearing in the object manager’s \Device directory.

Why is this important? Normally, C:\Windows\System32\Config\SAM is locked and cannot be read by non-SYSTEM processes. But via a VSS snapshot, a copy of the SAM hive is accessible at \Device\HarddiskVolumeShadowCopyN\Windows\System32\Config\SAM with no lock.

Stage 3 — Directory Junction + Object Manager Symlink (the “File Leak” Trick)

This stage makes Defender itself open the SAM hive on behalf of the attacker:

The exploit calls Proc42_ServerMpUpdateEngineSignature — an undocumented RPC method on Defender’s ALPC port (IMpService77BDAF73...) — telling Defender to install the update from the temp directory the exploit controls.
Defender creates a new subdirectory under C:\ProgramData\Microsoft\Windows Defender\Definition Updates\ and starts reading files from the attacker-controlled directory.
The exploit places a batch oplock on mpasbase.vdm inside its temp directory. When Defender tries to open this file for the update, the oplock fires — Defender is paused again momentarily.
During that pause window, the exploit:
- Renames the original temp directory (with the real update files) out of the way.
- Recreates a directory at the same path, but this time as a mount point (junction) pointing to \BaseNamedObjects\Restricted — a namespace inside the Windows Object Manager.
- Creates an Object Manager symbolic link at \BaseNamedObjects\Restricted\mpasbase.vdm pointing to the VSS path of the SAM hive (\Device\HarddiskVolumeShadowCopyN\Windows\System32\Config\SAM).
The oplock is released. Defender resumes, follows the directory junction → object manager link chain, and opens the SAM file from the shadow copy — effectively opening it as the SYSTEM-privileged Defender process. The exploit then opens the same file handle that Defender has made accessible.

Stage 4 — Parsing the SAM and Dumping Credentials

With the SAM hive bytes in hand, the exploit:

Reads the boot key from HKLM\SYSTEM\CurrentControlSet\Control\Lsa (the JD, Skew1, GBG, Data subkeys, which together form the syskey).
Uses the boot key + AES-128-CBC to decrypt the Password Encryption Key (PEK) stored in SAM\Domains\Account\F.
Iterates all user subkeys under SAM\Domains\Account\Users, extracts the encrypted NT hash blobs, and decrypts them using a two-stage process: AES-128-CBC (new format, type 2) followed by DES-ECB with a key derived from each user’s RID.
Prints every user’s plaintext NTLM hash.

Stage 5 — Lateral Movement & SYSTEM Shell

For each local account whose NTLM hash it recovered:

It temporarily changes the user’s password using the internal SamiChangePasswordUser SAM API (passing the old NTLM hash it just dumped, so it can authenticate and then restore the password).
It logs on as that user (LogonUserEx).
If the account is in the Administrators group, it impersonates the token at Medium integrity, then creates and starts a Windows service (CreateService / StartService) running itself. Since SCM runs services as SYSTEM, this gives SYSTEM-level execution with a shell in the calling session.
After launching the shell, it restores the user’s original password via SamiChangePasswordUser again (using the new→old NTLM hash swap).

Summary of the Vulnerability Chain

Step	Technique	Purpose
1	Windows Update API polling	Wait for Defender update to trigger
2	Cloud Files + oplock race	Freeze Defender to allow VSS creation
3	VSS	Access locked SAM hive without SYSTEM rights
4	Directory junction + Object Manager symlink	Redirect Defender’s own file access to SAM
5	Defender RPC (`ServerMpUpdateEngineSignature`)	Cause Defender to open attacker-controlled path as SYSTEM
6	Offline Registry (offreg.lib) + boot key + AES/DES	Decrypt and dump all local NTLM hashes
7	SAM API password swap + SCM service creation	Escalate to SYSTEM and spawn shells as all local users

The root cause is that Defender’s signature update RPC endpoint does not sufficiently validate the update source path, and the combination of directory junctions and Object Manager symbolic links allows an unprivileged user to redirect that path to arbitrary locations — including VSS copies of files that are otherwise access-controlled.

# BlueHammer — Exploit Analysis