Blue-Hammer Analysis (Defender LPE)

The BlueHammer exploit for Windows Defender, recently disclosed by Nightmare Eclipse, probably won’t be added to Exploit Pack unless there’s strong demand for it.

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

Thanks to Moise Alexandru for helping with the analysis and bringing this LPE to our attention.

I tested it locally, and the main practical limitation is reliability. The PoC (Proof of Concept) depends on Microsoft Defender update behavior: it waits for a Defender Antivirus definition update to appear through Windows Update metadata, then downloads Defender update content from Microsoft and abuses the update flow.

That means the timing and availability of the required signature/update path are not fully controlled by the attacker. If Microsoft changes the update package, timing, Defender behavior, or patches the path server-side/client-side, the exploit can simply stop working or become inconsistent.

From what I’ve seen in code, the bug chain is a TOCTOU (Time-of-Check to Time-of-Use) race combined with path confusion during the Defender signature update process. More specifically, the PoC uses an oplock and a path-confusion race around Defender’s expected mpasbase.vdm update file.

Once Defender reaches the vulnerable update path, the PoC moves/renames the original update file and directory, recreates the update directory as a reparse point, and creates an Object Manager symbolic link so Defender’s privileged read resolves to a VSS-backed (Volume Shadow Copy Service-backed) path for the SAM hive (Security Account Manager database) instead of the expected Defender update file.

After that, it copies the leaked SAM hive to %TEMP%, walks the SAM data, extracts local account hash material in a Mimikatz-like style, and if it finds a usable local administrator account, it temporarily changes that account’s password and uses it to escalate toward SYSTEM (LocalSystem, one of the highest local Windows privilege contexts).

The the PoC then logs-in with a temporary password, checks token elevation state, looks for an elevated linked token, administrator membership, and then attempts to create/start a Windows service to gain SYSTEM.

How it works, from my code analysis:

1. Check whether the process is already running as LocalSystem.
2. If not LocalSystem, wait for a Microsoft Defender Antivirus definition update to be available.
3. Download Defender update content from Microsoft.
4. Create a VSS (Volume Shadow Copy Service) setup used for reading protected files.
5. Trigger Defender’s update RPC (Remote Procedure Call) path, specifically the Defender update-signature path.
6. Prepare Defender update files in a temporary update directory.
7. Watch C:\ProgramData\Microsoft\Windows Defender\Definition Updates for Defender creating a new definition update directory.
8. Open the expected Defender update file, mpasbase.vdm.
9. Set an oplock (opportunistic lock) on mpasbase.vdm to catch Defender’s access at the useful race point.

10. When the oplock triggers, move/rename the update file and move the temporary update directory out of the way.
11. Recreate the temporary update directory as a reparse point targeting \BaseNamedObjects\Restricted.
12. Create an Object Manager symbolic link at \BaseNamedObjects\Restricted\mpasbase.vdm.
13. Point that symbolic link to the VSS-backed target path for \Windows\System32\Config\SAM.
14. Let Defender’s privileged read resolve through the manipulated path so the resulting copied file is the SAM hive rather than the expected update file.
15. Copy the leaked SAM hive to %TEMP%.
16. Parse SAM data and recover local account hash material, Mimikatz-style.
17. Temporarily change a local account password.
18. Log on with the temporary password and check token elevation / administrator membership.
19. If the account is administrator-capable, create/start a Windows service to get SYSTEM execution.
20. Attempt to restore the original password hash.

And in a note of humor, might the reason why the PoC is called FunnyApp, is that the hard-coded temporary password is: $PWNed666!!!WDFAIL and the Cloud Files provider name is: IHATEMICROSOFT

In my local test, the exploit primitive worked: the Defender update race succeeded, the SAM hive was leaked, and the PoC was able to parse the local Administrator account hash material. However, it did not reach SYSTEM. The post-exploitation stage failed at LogonUserEx with an error, which indicates the target account was disabled or restricted, as expected.

BlueHammer demonstrated the privileged SAM read and password-change behavior, but the final SYSTEM escalation path failed because the local account state did not satisfy the PoC’s assumptions.

Overall, this is an interesting PoC from a vulnerability-research perspective, but not something I would classify as a clean or reliable Exploit Pack module yet.

The primitive is useful, but the current implementation is tightly coupled to Defender update timing, Microsoft-hosted signature content, local account state, and a post-exploitation flow that temporarily modifies passwords. That makes it fragile and potentially disruptive in red teaming/pentesting scenarios.