Abstract
BlueHammer is a Windows proof-of-concept exploit that demonstrates how Microsoft Defender’s update pipeline can be abused to obtain access to protected system files and ultimately escalate privileges. The technique chains together several Windows internals primitives including Defender RPC calls, Volume Shadow Copy discovery, Cloud Files callbacks, oplocks, mount-point reparse points, and NT object manager symbolic links.
By manipulating Defender’s signature update process, the exploit redirects privileged file access toward a Volume Shadow Copy snapshot of the SAM registry hive, allowing offline extraction of NTLM hashes. These hashes are then operationalized using SAM RPC routines to take over local accounts and potentially obtain a SYSTEM shell.
BlueHammer is a good example of modern Windows exploitation: not a single vulnerability, but a carefully orchestrated chain of subsystem interactions.

Introduction
Security products often operate with extremely high privileges. Because of this, even small logic flaws in their workflows can sometimes be converted into powerful exploitation primitives.
The BlueHammer project demonstrates such a scenario by abusing the Microsoft Defender update pipeline. The exploit causes Defender to access attacker-controlled paths while processing a signature update. At a precise moment, the attacker swaps those paths with carefully crafted NT namespace redirections that point to sensitive files inside a newly created Volume Shadow Copy (VSS).
The end result is the leakage of protected files such as:
\Windows\System32\Config\SAM
Once the SAM hive is obtained, the exploit performs offline credential extraction, recovers NTLM password hashes, and attempts to pivot into administrative accounts before escalating to SYSTEM.
Architecture of the PoC
The project consists of a main executable and several supporting components.
Key files
FunnyApp.cpp
windefend.idl
windefend_h.h
windefend_c.c
windefend_s.c
offreg.lib
The IDL file defines an RPC interface used by Microsoft Defender. MIDL-generated files implement client stubs that allow the exploit to call Defender functions locally.
Linked libraries
The project links several Windows internals libraries:
ntdll.lib
Rpcrt4.lib
Cabinet.lib
CldApi.lib
Wuguid.lib
Shlwapi.lib
ktmw32.lib
wininet.lib
offreg.lib
These reveal the exploit’s building blocks:
- RPC communication
- Defender update processing
- CAB extraction
- Windows Update API
- Cloud Files API
- NT native functions
- offline registry parsing
Exploit Overview
At a high level the exploit performs the following sequence:
- Check for Microsoft Defender signature updates
- Download the official update package
- Extract update files from the CAB archive
- Trigger Defender activity to create a new VSS snapshot
- Freeze Defender operations using Cloud Files callbacks and oplocks
- Invoke a Defender RPC function to process an attacker-controlled update directory
- Replace the update directory with a reparse point
- Redirect file resolution to a VSS snapshot
- Cause Defender to open the redirected file
- Leak the SAM hive
- Extract NTLM hashes
- Replace passwords and log in as local users
- Attempt SYSTEM privilege escalation
+-----------------------+
| Microsoft Defender |
| Signature Update RPC |
+-----------+-----------+
|
| Proc42_ServerMpUpdateEngineSignature()
v
+---------------------------+
| Attacker Update Folder |
| (mpasbase.vdm) |
+------------+--------------+
|
| Oplock triggered
v
+---------------------------+
| Directory Swap / Race |
| Rename + Move directory |
+------------+--------------+
|
| Mount-point reparse
v
+---------------------------+
| Junction → Object Manager |
| \BaseNamedObjects\... |
+------------+--------------+
|
| NT Symbolic Link
v
+---------------------------+
| Volume Shadow Copy (VSS) |
| HarddiskVolumeShadowCopyX |
+------------+--------------+
|
| Redirected file access
v
+---------------------------+
| SAM Registry Hive |
| \System32\Config\SAM |
+------------+--------------+
|
| Offline parsing
v
+---------------------------+
| Extract NTLM Hashes |
+------------+--------------+
|
| LogonUser / SAM RPC
v
+---------------------------+
| Privilege Escalation |
| SYSTEM Shell |
+---------------------------+
Stage 1 — Microsoft Defender RPC Abuse
The exploit communicates with Defender through a local RPC endpoint:
UUID: c503f532-443a-4c69-8300-ccd1fbdb3839
Protocol: ncalrpc
Endpoint: IMpService77BDAF73-B396-481F-9042-AD358843EC24
Using the generated RPC stubs, the exploit calls:
Proc42_ServerMpUpdateEngineSignature()
This function is responsible for processing Defender engine signature updates.
The attacker supplies a custom directory containing extracted update files. Defender then processes that directory with elevated privileges.
This behavior becomes the entry point for path manipulation.
Stage 2 — Downloading Defender Updates
The exploit interacts with the Windows Update COM API:
Microsoft.Update.Session
IUpdateSearcher
IUpdateCollection
It searches for updates categorized as:
Microsoft Defender Antivirus
Definition Updates
Once found, it downloads the update package directly from Microsoft:
https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64
Instead of launching the update installer, the exploit extracts its embedded CAB resource.
Extraction is implemented using the Cabinet FDI API:
FDICreate
FDICopy
The update files are reconstructed into memory and written to a temporary directory which will later be supplied to Defender.
Stage 3 — Creating a Volume Shadow Copy
The exploit needs a stable copy of protected files.
To achieve this, it provokes Defender into activity by creating a file containing the EICAR test signature.
Defender scanning activity often causes Windows to create a new Volume Shadow Copy.
A monitoring thread continuously enumerates NT object manager entries under:
\Device
using:
NtOpenDirectoryObject
NtQueryDirectoryObject
It waits for a new object such as:
HarddiskVolumeShadowCopyX
When a new snapshot appears, the exploit records the path:
\Device\HarddiskVolumeShadowCopyX
This path provides read-only access to protected files.
Stage 4 — Freezing Defender with Cloud Files
One of the most unusual parts of the exploit involves the Cloud Files API.
The exploit registers its working directory as a Cloud Files sync root:
CfRegisterSyncRoot
CfConnectSyncRoot
It installs a callback for:
CF_CALLBACK_TYPE_FETCH_PLACEHOLDERS
When Defender interacts with this directory, the callback triggers.
At the same time, the exploit places an oplock on a critical file:
FSCTL_REQUEST_BATCH_OPLOCK
The oplock allows the attacker to pause Defender at a predictable moment.
This controlled pause makes the following race condition far more reliable.
Stage 5 — Preparing the Fake Update Directory
After extracting update files, the exploit constructs a temporary directory containing legitimate Defender update artifacts.
It then monitors:
C:\ProgramData\Microsoft\Windows Defender\Definition Updates
using ReadDirectoryChangesW() to detect when Defender creates a new update directory.
Simultaneously, the exploit calls the Defender RPC function instructing it to process the attacker-supplied directory.
Once Defender begins the update process, the race phase begins.
Stage 6 — Directory Swap and Namespace Redirection
This is the core exploitation primitive.
Step 1 — Oplock trigger
Defender attempts to open:
mpasbase.vdm
The oplock triggers when the file is accessed.
Step 2 — Rename file
The exploit renames the file away:
mpasbase.vdm → mpasbase.WDFOO
Step 3 — Move the directory
The entire update directory is moved:
updatepath → updatepath.foo
Step 4 — Replace the directory
A new directory is created at the original path.
A mount-point reparse point is applied pointing to:
\BaseNamedObjects\Restricted
Step 5 — Create NT symbolic link
The exploit then creates:
\BaseNamedObjects\Restricted\mpasbase.vdm
pointing to:
\Device\HarddiskVolumeShadowCopyX\Windows\System32\Config\SAM
Now when Defender accesses:
updatepath\mpasbase.vdm
the path resolves to the SAM hive inside the VSS snapshot.
Stage 7 — Leaking the SAM Hive
Defender’s privileged update process accesses the redirected file.
The exploit repeatedly attempts to open the resulting file located in:
C:\ProgramData\Microsoft\Windows Defender\Definition Updates\<dir>\mpasbase.vdm
Once successful, the file contents are copied and saved to a temporary path.
The exploit reports success when the SAM hive has been written to disk.
Stage 8 — Extracting Password Hashes
The dumped SAM file is parsed using the Offline Registry API.
The exploit reconstructs the boot key from:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
keys:
JD
Skew1
GBG
Data
It then decrypts the Password Encryption Key (PEK) and uses it to recover per-user password hashes.
The parser handles:
- SAM record structures
- AES encrypted hash blobs
- RID-based DES obfuscation
- NTLM hash extraction
The result is a list of users and their NTLM hashes.
Stage 9 — Taking Over Local Accounts
Instead of only printing the hashes, the exploit uses SAM RPC functions:
SamConnect
SamOpenDomain
SamOpenUser
SamiChangePasswordUser
The recovered hash is used to temporarily change the user’s password.
The exploit then calls:
LogonUserEx
to obtain an interactive token for that account.
This allows the program to execute commands under other local user contexts.
Stage 10 — Escalation to SYSTEM
If an administrator account is obtained, the exploit escalates further.
The process:
- Obtain an elevated token
- Open the Service Control Manager
- Create a temporary service pointing to the current executable
- Start the service
- Delete the service entry
When the executable runs as a service it runs as LOCAL SYSTEM.
The program then launches:
conhost.exe
in the interactive session, producing a SYSTEM console.
Why This Exploit Is Interesting
BlueHammer demonstrates how modern Windows exploitation often works.
The exploit does not rely on a single bug. Instead it chains together:
- Defender update internals
- VSS snapshot mechanics
- Cloud Files callbacks
- oplocks
- mount-point reparse points
- NT object manager symbolic links
- SAM cryptography
- service-based privilege escalation
The critical concept is path confusion across namespaces.
A file path expected to reference a legitimate Defender update file is redirected across the filesystem → object manager boundary into a shadow copy of a protected registry hive.
Security Impact
If reliable, the exploit allows:
- extraction of SAM credentials
- recovery of NTLM password hashes
- takeover of local user accounts
- potential escalation to SYSTEM
The technique highlights how interactions between security software and Windows subsystems can introduce unexpected attack surfaces.
Conclusion
BlueHammer is a complex Windows privilege escalation PoC that abuses Microsoft Defender’s signature update workflow to leak protected system files. By combining RPC manipulation, filesystem races, NT namespace redirection, and offline credential extraction, the exploit transforms a security product’s trusted operations into a powerful attack primitive.
The project serves as a reminder that modern exploitation rarely depends on a single vulnerability. Instead, it often emerges from subtle interactions between trusted components operating with high privileges.

