"The most durable zero-days don't always need a bug. [BlueHammer] turns Microsoft Defender's own update workflow into a credential theft mechanism by chaining five legitimate Windows features in a sequence their designers never intended." [1]
About this post: I'm the author and maintainer of bluehammer-analysis, the repository this entry documents. It is an ethics-first archival study of the BlueHammer artifact set — not an exploit, not a detection tool, and deliberately not a reproduction guide.
Who this is for: intermediate developers and CS students who are comfortable reading code and Windows terminology (RPC, oplocks, VSS, MIDL) but have never had to think about the ethics of publishing technical work. No prior exploit-development experience is assumed or required.
On April 3, 2026, a security researcher published full proof-of-concept source code for an unpatched Windows local privilege escalation vulnerability called BlueHammer [2]. The exploit chains race conditions in the Windows Defender update process with Volume Shadow Copy abuse to escalate a standard user to NT AUTHORITY\SYSTEM, the highest local privilege context on a Windows machine [3]. Microsoft issued a patch on April 14, 2026, tracked as CVE-2026-33825. The initial response was a Defender signature update that flags the original compiled binary but does nothing about the underlying technique [3].
Within days of the disclosure, multiple research teams began publishing their own forks, detection rules, and analysis repositories on GitHub [4], [5]. Several of these repositories, including the one that forms the subject of this post, demonstrate a practice that is far less dramatic than the zero-day itself, but arguably more important to students of computer science: the methodical, ethics-first documentation of exploit artifacts.
This log describes the construction of bluehammer-analysis, a public GitHub repository I built to study and document the BlueHammer artifact set without reproducing, enhancing, or operationally detailing the exploit chain. The project is not a security tool. It is a documentation exercise: an attempt to answer a deceptively difficult question: How do you study something dangerous without making it more dangerous?
What BlueHammer Does
BlueHammer is not a buffer overflow, a heap spray, or a kernel exploit. It is a design-level race condition that manipulates how several legitimate Windows subsystems interact under specific timing conditions [6]. The exploit targets the Windows Defender signature update mechanism, abusing its interaction with the Volume Shadow Copy Service, Cloud Files callbacks, and opportunistic locks to leak the Security Account Manager (SAM) database, the file containing password hashes for local accounts [7]. If a usable local administrator account is found, BlueHammer temporarily changes the account password, logs in, escalates to SYSTEM, and then restores the original hash to cover its tracks [8].
High-Level Attack Chain
STANDARD USER PROCESS
|
+----------+----------+
| |
[STAGE 1] [STAGE 2]
Check for WD Download WD
signature updates update files
| |
+----------+----------+
|
[STAGE 3]
Trigger WD scan to
force VSS snapshot
(via EICAR + oplock
on RstrtMgr.dll)
|
[STAGE 4]
Freeze WD via Cloud
Files API oplock trap
(CfApi callback +
batch oplock)
|
[STAGE 5]
Hijack WD signature
update via RPC call
(Proc42_ServerMpUpdateEngineSignature)
|
[STAGE 6]
Race condition:
oplock fires when WD
reads update file ->
swap symlink to point
at VSS copy of SAM
|
[STAGE 7]
WD writes "update"
(actually SAM copy)
to Definition Updates
directory
|
[STAGE 8]
Open leaked SAM via
transacted file I/O
|
[STAGE 9]
Extract NTLM hashes
from SAM using offline
registry (offreg.h)
|
[STAGE 10]
For each user:
change password ->
logon -> spawn shell ->
restore original password
|
[STAGE 11]
If admin user found:
create Windows service ->
run as SYSTEM -> spawn
SYSTEM shell in user session
|
SYSTEM SHELL
How a Few of the Stages Actually Work
The diagram above collapses a lot of interesting Windows internals into single lines. Three stages are worth expanding on, because they are the ones that make this a design-level race condition rather than a memory-corruption bug.
Stage 3 — Forcing a VSS snapshot via a scan. Volume Shadow Copy Service (VSS) is a Windows feature that creates point-in-time, read-only snapshots of a volume so that backup tools can copy files that are otherwise locked, including SAM. Normally, a standard user has no authority to trigger a VSS snapshot. The chain sidesteps this by causing Windows Defender itself to scan a crafted EICAR test file while an opportunistic lock (oplock) is held on RstrtMgr.dll. Defender's scan path, running as SYSTEM, ends up being the component that requests the snapshot the attacker wants. The privileged action is performed by a privileged process on behalf of an unprivileged one.
Stage 4 — Freezing Defender with a Cloud Files callback. The Cloud Files API (CfApi) is the kernel-mode plumbing behind OneDrive's "files on demand." When a process touches a placeholder file, the kernel calls back into user mode to "hydrate" it. Combined with a batch oplock, that callback becomes a controllable stall point: Defender can be suspended mid-operation at a moment of the attacker's choosing. This is not a bug in CfApi; it is a legitimate feature used as a synchronization primitive the designers never intended.
Stage 6 — The symlink swap. With Defender frozen in a known state, the exploit swaps a filesystem reparse point so that the "update file" Defender is about to read now resolves to the VSS copy of SAM. Defender, still running as SYSTEM and still trusting its own update pipeline, writes the contents of SAM into its Definition Updates directory. From the attacker's perspective, a standard-user process has just coerced a SYSTEM-level antivirus into exfiltrating the local password-hash database into a readable location.
The reason BlueHammer is instructive is that none of these primitives are exploits on their own. Oplocks, VSS, CfApi, MIDL-generated RPC stubs, and Defender's update workflow are all documented, legitimate Windows components. The vulnerability lives in the composition.
Usage Trace
wmain
-> CheckForWDUpdates
-> GetUpdateFiles
-> TriggerWDForVS
-> ShadowCopyFinderThread
-> FreezeVSS
-> CfCallbackFetchPlaceHolders
-> WDCallerThread
-> CallWD
-> Proc42_ServerMpUpdateEngineSignature
-> open redirected file handle
-> DoSpawnShellAsAllUsers
-> GetLSASecretKey
-> UnprotectPasswordEncryptionKey
-> UnprotectNTHash
-> ChangeUserPassword
-> CreateProcessWithLogonW / CreateService / StartService
For a computer science student, BlueHammer is instructive not because of what it does; privilege escalation exploits are a well-established category; but because of how it does it. The entire chain relies on timing, path confusion, and the assumption that components designed independently will behave safely when composed together. This is a systems-level failure, and understanding it requires systems-level thinking: the ability to trace dependencies across files, distinguish authored logic from generated transport code, and classify artifacts by their role in a build graph rather than by their filename alone.
The Repository: An Archival Documentation Project
The bluehammer-analysis repository (https://github.com/zcalifornia-ph/bluehammer-analysis) is structured around a single principle: read the artifact set as a map, not as an execution guide. The repository preserves the historical file names from the original proof-of-concept, such as FunnyApp.cpp, windefend.idl, offreg.h, and so on, but the files themselves are redacted placeholders.
The full bluehammer-analysis, complete with file-by-file usage maps is kept private for now as Bluehammer is still relatively new. The full analysis will be released in the same repository 30-50 days after the patch is issued for safety.
The operational content has been removed. What remains is the documentation layer: a set of study guides under learn/ that explain the role, type, and dependency relationships of each file without transferring the method needed to reproduce the exploit.
ROOT REPOSITORY
-> README.md / CHANGELOG.md / SECURITY.md / CONTRIBUTING.md / CODE_OF_CONDUCT.md
-> docs/ : version-level public documentation
-> learn/ : directory guide plus file-level archival summaries
-> repo/images/project_screen.png : README image asset
bluehammer-analysis/
-> placeholder files preserving historical names only
Historical relationship map
-> FunnyApp.vcxproj : build contract
-> FunnyApp.cpp : authored source file
-> windefend.idl / *_h / *_c / *_s
: generated interface and transport bundle
-> offreg.h / offreg.lib : offline-registry dependency boundary
-> FunnyApp.rc / resource.h : resource scaffolding
The core insight that organizes the entire repository is a classification scheme. Every file in the original proof-of-concept falls into one of a small number of categories:
-
Authored source (
FunnyApp.cpp): the hand-written logic and orchestration that constitutes the actual exploit reasoning. -
Interface contract (
windefend.idl): the MIDL definition that declares the RPC interface used to communicate with Windows Defender. -
Generated transport glue (
windefend_h.h,windefend_c.c,windefend_s.c): files produced by the MIDL compiler from the IDL contract, containing marshalling metadata and stub code. -
Dependency boundary (
offreg.h,offreg.lib): the offline-registry API declarations and import library that mark where the project consumes an external Microsoft component. -
Build metadata (
FunnyApp.vcxproj,FunnyApp.vcxproj.filters): MSBuild project files that define compilation settings, link dependencies, and file membership. -
Resource scaffolding (
FunnyApp.rc,resource.h): minimal Visual Studio resource-pipeline files that participate in the build graph but contain no exploit logic.
This classification is not novel in security research, but it is rarely taught as a standalone skill. Most students encounter exploit analysis either as full operational walkthroughs (which transfer too much method) or as abstract threat-model descriptions (which transfer too little structure). The bluehammer-analysis repository occupies the space between those extremes: enough structure to build a real mental model, not enough detail to lower the cost of reproduction.
BlueHammer/
bluehammer-analysis/ redacted placeholder files preserving historical paths
docs/ version-level public documentation
learn/ directory guide and scoped study-guide subfolders
repo/images/ README assets
README.md repository-wide study guide and public overview
CHANGELOG.md documented repo changes
SECURITY.md coordinated reporting policy
CONTRIBUTING.md contribution process and safety expectations
CODE_OF_CONDUCT.md collaboration norms
LICENSE.txt Apache-2.0 license
What I Learned Building It
The most surprising lesson was how much of the work had nothing to do with security. The majority of my time was spent on documentation hygiene: writing study guides that accurately described file roles without accidentally including operational detail, structuring a changelog that tracked documentation-only changes across six versioned releases, and building governance documents (SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md) that explicitly rejected operational writeups as contributions.
Version control discipline became a first-class concern. Each of the six releases (v0.0.1 through v0.0.6) addressed a specific documentation defect: stale references to internal workflow paths, a broken table-of-contents link, inconsistencies between the README and the actual working tree, and, most significantly, a full rewrite in v0.0.6 that converted the learn/ corpus from stage-by-stage teaching structure to summary-level archival guides. That last change was the hardest. It required reading every study guide and asking a single question: Does this paragraph help someone classify an artifact, or does it help someone execute a chain? Anything that leaned toward the latter was rewritten or removed.
I also used AI-assisted development workflows throughout the project. The repository was developed and sanitized using a combination of Claude, Qwen, Codex, and Ollama agents running on my homegrown agentic workflow along with a structured directory containing numerous skills, reference templates, and PowerShell tooling scripts I developed while learning cybersecurity. These were not afterthoughts; they were load-bearing infrastructure. The agentic workflow enforced commit conventions, developed document scaffolds, ran documentation linting, and maintained traceability between versioned releases. This is a pattern I expect to use in future research work: treating AI agents not as code generators but as documentation co-pilots with explicit rules about what they may and may not produce.
Why Exploit Documentation Matters
Cybersecurity is often taught, and marketed, as a set of cool tools and cinematic techniques: run Nmap, pop a shell, exploit a vulnerable VM. In practice, a large fraction of real security work looks nothing like that. It is log review, patch tracking, asset inventory, writing detection rules that nobody will thank you for, reading other people's code very carefully, and producing documentation that stays correct six months after the incident is over.
The exciting parts, novel research, red-team engagements, zero-day analysis, sit on top of a much larger base of unglamorous, repetitive, careful work. Exploit documentation lives in that base layer. It is tedious on purpose.
Those same valuable hands-on skills, however, do not prepare you for the harder meta-problem: what to do when you encounter something dangerous in the wild and need to document it without making it worse.
BlueHammer is a live example. It is a zero-day with public exploit code, and as of this writing, multiple research teams are racing to document it. Some of those documentation efforts are careful and ethics-first. Others have already been criticized for including too much operational detail [5]. The difference between a responsible analysis repository and an irresponsible one is not the subject matter: it is the documentation discipline applied to it.
For computer science students and early-career engineers, this project demonstrates three transferable skills. First, artifact classification: the ability to look at a codebase and determine what each file does, whether it was hand-written or generated, and how it relates to its neighbors in the build graph. This skill applies to any software project, not just exploit analysis. Second, publication safety: the judgment to know what to include and what to redact when making technical work public. This matters for open-source contributions, research papers, and even job applications where you need to describe sensitive work without disclosing protected information. Third, versioned documentation as a deliverable: the practice of treating documentation changes with the same rigor as code changes: tracked, reviewed, and released with clear rationale.
What I Enjoyed Most
There is a particular satisfaction in building something whose value lies in what it does not contain. The bluehammer-analysis repository is, by design, incomplete.
When I was made aware of the exploit, and the leak of the proof-of-concept code, my first instinct was to read the code and try to understand how it worked. But I quickly realized that doing so would be a double-edged sword: I could learn a lot, but I would also be learning how to reproduce the exploit. Keeping my ethical stance in mind, I decided to build something that would help others understand the structure of the exploit without giving them the recipe.
In doing my analysis, I found that publicly available AI models appropriately reject requests to explain exploit source files directly, so I shifted to using locally run models under my own oversight for this purpose. The end result is a repository that is like a map with missing roads, and that's intentional. Getting that balance right: enough to be useful, not enough to be harmful, required more careful thinking than any full-stack project I have built. And that, I think, is the point.
Conclusion
The BlueHammer disclosure is a case study in what happens when vulnerability disclosure breaks down: a researcher frustrated with a vendor's response process releases unpatched exploit code to the public, and the security community scrambles to document, detect, and defend. Within that scramble, there is room for students to contribute meaningfully: not by building exploits, but by building the documentation infrastructure that helps defenders understand what they are facing.
This repository is my contribution to that effort. It is small, deliberately limited, and focused on a single thesis: that the ability to classify, document, and safely publish technical artifacts is as important as the ability to write code. If this post encourages even one reader to think of documentation as a skill worth practicing — on par with writing code — it will have done its job.
Resource Link
GitHub Repository: https://github.com/zcalifornia-ph/bluehammer-analysis
References
- B. Hussey, quoted in Z. Ljakovic, "BlueHammer: Windows zero-day exploit leaked," Help Net Security, Apr. 8, 2026. Available: https://www.helpnetsecurity.com/2026/04/08/bluehammer-windows-zero-day-exploit-leaked/
- B. Toulas, "Disgruntled researcher leaks
BlueHammerWindows zero-day exploit," BleepingComputer, Apr. 7, 2026. Available: https://www.bleepingcomputer.com/news/security/disgruntled-researcher-leaks-bluehammer-windows-zero-day-exploit/ - R. Ramesh and R. Jayapaul, "BlueHammer: Inside the Windows Zero-Day," Cyderes Howler Cell, Apr. 9, 2026. Available: https://www.cyderes.com/howler-cell/windows-zero-day-bluehammer
- technoherder, "BlueHammerFix: Analysis and detection engineering for the BlueHammer vulnerability," GitHub, Apr. 2026. Available: https://github.com/technoherder/BlueHammerFix
- atroubledsnake, "SNEK Blue-War-Hammer: Vulnerability Documentation & Reimplementation," GitHub, Apr. 2026. Available: https://github.com/atroubledsnake/SNEK_Blue-War-Hammer
- SOCRadar, "BlueHammer Windows Zero-Day: Privilege Escalation Risk," SOCRadar Blog, Apr. 7, 2026. Available: https://socradar.io/blog/bluehammer-windows-zero-day-privilege-escalation-risk/
- Cyber Security News, "BlueHammer PoC for Windows Defender Exploited by Researchers to Escalate Privileges," Apr. 7, 2026. Available: https://cybersecuritynews.com/bluehammer-poc-for-windows-defender/
- Exploit Pack, "Blue-Hammer Analysis (Defender LPE)," Apr. 7, 2026. Available: https://www.exploitpack.com/blogs/news/blue-hammer-analysis-ms-defender-lpe
AI Use Disclosure
This post was written by me. Anthropic's Claude was used in a limited, assistive capacity for menial Markdown typesetting (list and code-block formatting, heading hierarchy, link syntax), grammar and punctuation checks, and rewording for tone consistency across sections. All technical claims, the thesis, the attack-chain and stage explanations, the repository design decisions, and the ethical framing are my own; AI assistance was applied to presentation, not substance.
Separately, and as described in the body of this post, AI agents (Claude, Qwen, Codex, Ollama) were used during the construction of the bluehammer-analysis repository itself under explicit rules about what they were and were not permitted to produce. That operational use is distinct from the editorial assistance disclosed here.
Top comments (0)