BlueHammer: Exploiting Microsoft Defender Update Workflow to Leak SAM and Escalate to SYSTEM

BlueHammer: Exploiting Microsoft Defender Update Workflow to Leak SAM and Escalate to SYSTEM

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:

  1. Check for Microsoft Defender signature updates
  2. Download the official update package
  3. Extract update files from the CAB archive
  4. Trigger Defender activity to create a new VSS snapshot
  5. Freeze Defender operations using Cloud Files callbacks and oplocks
  6. Invoke a Defender RPC function to process an attacker-controlled update directory
  7. Replace the update directory with a reparse point
  8. Redirect file resolution to a VSS snapshot
  9. Cause Defender to open the redirected file
  10. Leak the SAM hive
  11. Extract NTLM hashes
  12. Replace passwords and log in as local users
  13. 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.

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:

  1. Obtain an elevated token
  2. Open the Service Control Manager
  3. Create a temporary service pointing to the current executable
  4. Start the service
  5. 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.

Comments are closed.