)
On April 3, a security researcher publicly released working exploit code for an unpatched Windows zero-day dubbed BlueHammer.
The vulnerability allows a standard local user to escalate privileges to NT AUTHORITY\\SYSTEM, the highest privilege level on a Windows machine.
No patch exists. No CVE has been assigned. Microsoft has acknowledged the issue but has not published mitigation guidance.
To help you respond while the industry waits on a fix, Automox has built two Worklets that harden Windows endpoints and detect exploitation attempts across your fleet. Automox customers can deploy them directly from the console.
Automox Worklets™:
If you're not an Automox customer, the source code is freely available on GitHub to review and run manually
Here's what BlueHammer does, what you can do about it, and how to put those Worklets to work.
What BlueHammer does
BlueHammer is a local privilege escalation (LPE) vulnerability that targets the Windows Defender signature update process. It chains together multiple legitimate Windows features, including Volume Shadow Copy Service (VSS), the Cloud Files API, and opportunistic locks (oplocks), to exploit a time-of-check to time-of-use (TOCTOU) race condition.
The exploit does not require kernel bugs, memory corruption, or admin privileges. When successful, it leaks the Security Account Manager (SAM) database through a VSS snapshot, extracts NTLM password hashes, takes over a local administrator account, and spawns a SYSTEM-level shell. It also restores the original password hash afterward to avoid detection.
Will Dormann, a principal vulnerability analyst at Tharros, independently confirmed the exploit works. While the published proof-of-concept contains bugs that affect reliability, multiple researchers have resolved them and verified full end-to-end exploitation.
Why it matters to your environment
No patch available. You can't deploy a fix because one doesn't exist yet.
Public exploit code. Ransomware operators and APT groups routinely weaponize public LPE proof-of-concept code within days of release.
Low barrier to entry. The exploit requires only standard user privileges and a slightly stale Defender signature definition.
Composable techniques. The exploit contains six independent primitives that can be recombined against different targets even after Microsoft patches this specific vulnerability.
Detection and mitigation recommendations
Until Microsoft ships a patch, your response should focus on two tracks: reducing exploitability (hardening) and detecting exploitation attempts.
Hardening
Enforce application control. This is the single strongest mitigation. BlueHammer requires executing a binary on the target machine. If you block unsigned and user-space executables from running in %TEMP%, Downloads, and other user-writable paths using WDAC or AppLocker, the exploit chain breaks at the first step. WDAC must be in enforcement mode, not audit mode.
Keep Defender signatures current. The exploit requires a version gap between installed definitions and what Microsoft's CDN has published. Force signature updates on a frequent cadence (every four to eight hours). This shrinks the window of exploitability but does not eliminate it, because there will always be a brief gap between publication and update.
Verify Tamper Protection is enabled. While BlueHammer does not attempt to disable Defender, an attacker could manually roll back definitions to create the version gap if Tamper Protection is off.
Detection
Deploy Sigma rules for your SIEM. The BlueHammerFix repository on GitHub provides seven Sigma rules covering indicators across the exploit chain: non-LSASS samlib.dll loads, rapid password change-logon-restore cycles, junction creation to BaseNamedObjects, GUID-named temporary services, exclusive handles on RstrtMgr.dll, Cloud Files API abuse by non-provider processes, and LSA boot key registry access.
Monitor for Cloud Files sync root anomalies. BlueHammer abuses the Cloud Files API to register a sync root with a callback that identifies Defender by PID and selectively freezes it. This technique is novel, and most EDR products do not monitor for it today. Check for unexpected entries in the SyncRootManager registry key.
Watch for GUID-named temporary services. The final stage of the exploit creates a short-lived Windows service with a random GUID name. These should not exist on production endpoints.
Configure EDR for behavioral telemetry. Deeper exploit chain behaviors like oplock abuse, RPC interception, and junction/symlink redirection require kernel-level or ETW-level visibility. Make sure your EDR is tuned for privilege escalation detection patterns.
How Automox helps you respond at scale
Automox has developed two Automox Worklet™ automations you can deploy to all managed Windows endpoints immediately. These Worklets automate hardening and detection checks that would otherwise require manual effort across your fleet.
The source code of these scripts is publicly available.
Worklet 1: BlueHammer hardening
This Worklet evaluates three conditions on every managed Windows endpoint and auto-remediates where possible:
Defender signature freshness. Flags endpoints where definitions are more than eight hours stale and forces an immediate signature update as remediation.
Tamper Protection status. Verifies Tamper Protection is enabled. If it's off, the Worklet flags the endpoint and logs an advisory. Tamper Protection requires Intune or Group Policy to enable; the Worklet cannot toggle it by design.
Application control policy. Checks whether WDAC or AppLocker is enforced (not merely in audit mode). Endpoints without enforcement are flagged so you can prioritize policy deployment.
Worklet 2: BlueHammer detection
This Worklet runs as a lightweight detection canary and collects forensic context if indicators are found:
Cloud Files sync root anomalies. Inspects the registry for sync root entries that don't match known providers (OneDrive, SharePoint, Dropbox, iCloud, Box, Google Drive). Unknown registrations are flagged as potential BlueHammer indicators.
GUID-named temporary services. Enumerates services matching the random GUID naming pattern used by the exploit's final escalation stage. These should not exist in normal operations.
If either indicator is found, the Worklet's remediation phase collects detailed forensic context: sync root registry properties, service details, Defender status, VSS snapshot inventory, and recent service installation events from the System event log. It does not take destructive action, because a positive detection may indicate active exploitation that your incident response team should investigate.
What these Worklets don't cover
Transparency matters. These Worklets are useful, but they have gaps you should understand before deploying them.
Signature freshness is a narrowing control, not a blocking one. There will always be a window between when Microsoft publishes definitions and when the endpoint updates. The Worklet shrinks the window but cannot close it entirely.
Detection is point-in-time, not real-time. Both indicators (sync roots and GUID services) are transient. The exploit can create and remove them faster than a scheduled Worklet scan runs. On a standard cadence, a fast exploitation could complete between scans and leave nothing for the Worklet to find.
Five of seven exploit stages are invisible to the Worklets. Oplock abuse, EICAR-triggered remediation, VSS snapshot creation, junction/symlink redirection, and the password change-logon-restore cycle all require kernel-level or ETW-level telemetry. Those detections belong in your EDR and SIEM layers.
The Cloud Files allowlist needs maintenance. If your fleet uses a sync provider not in the default allowlist (for example, Egnyte or Citrix Files), it will generate false positives until you add it.
Deploy both Worklets for the coverage they provide, but don't treat them as your complete detection and response strategy. Pair them with Sigma rule deployment in your SIEM and behavioral detection tuning in your EDR.
Get started now
Both Worklets are available now. If you're an Automox customer, you can deploy them to all managed Windows endpoints through the Automox console under Policies → Worklets → Create. Paste the evaluation and remediation scripts, set your preferred schedule, and assign to your target device groups.
If you're not yet an Automox customer, these scripts can be run manually, and the source is available on GitHub.
)
)
)
)