- Qualys argues, from lab work on Defender flaw CVE-2026-33825, that an affected version does not mean an attacker can exploit the host.
- The chain needs a pending signature update and other host conditions. The full chain was shown on one lab host; TruConfirm evidence came from a separate asset.
- Ask whether your tools separate affected from exploitable, and which endpoints run Defender platform versions older than 4.18.26030.3011.
A list of affected machines is not a list of exposed ones
Security teams keep lists of machines that run vulnerable software. Those lists say which machines are affected. They do not say where an attacker could succeed.
Security vendor Qualys has published a case study on that gap. It covers CVE-2026-33825, which Qualys calls BlueHammer. The flaw sits in Windows Defender, the security tool built into Windows.
What Qualys found
Microsoft set 4.18.26030.3011 as the fixed version of the Defender Antimalware Platform. Older builds are affected. Qualys's lab host ran version 4.18.2104.10.
BlueHammer is not a way in. An attacker first needs to run code as a standard user. Qualys names phishing, malicious content and misuse of valid accounts as possible routes.
From there, Qualys says, its lab chain reached SYSTEM, the highest local privilege level in Windows. The team then found domain administrator credentials already held in memory. It used pass-the-hash, a method that logs in with stolen credential material, to reach the domain controller. That is the server that manages logins. Finally it extracted NTDS.dit, the file that stores the directory's account data. All of this happened in a lab.
How the attack works
Qualys says this is not a memory-corruption bug. It chains ordinary Windows features across eight stages. Each stage prepares the next. Qualys rebuilt the chain by reverse-engineering the public proof-of-concept program, FunnyApp.exe.
Stage one is a check. The program looks for a pending Defender signature update. If none is waiting, it stops. If one is, it downloads Microsoft's signed update package and swaps in one altered file, mpasbase.vdm. The other files match the signed originals, so Defender's signature checks still pass.
Stage two is timing. The program drops a harmless test virus file to trigger a Defender scan. It uses a file lock to learn when the scan begins. It also records the path of a shadow copy, a disk snapshot that Defender often creates.
Stage three pauses Defender. The program registers as a cloud-file provider, the kind of service OneDrive is. When Defender scans a decoy file, a Windows driver holds Defender's scanning thread until the provider answers. Qualys notes that the wait has no set time limit. The stall lets the program carry out its work in stages four to six without Defender getting in the way.
In stage four, the program creates a redirect, called a symbolic link, in the Windows object namespace. It points to the altered update files. In stage six, Qualys says, the program swaps that redirect after Defender has accessed it. Defender's file access is then steered to the account database, the SAM file, on the shadow copy recorded in stage two.
Qualys's argument: exploitability belongs to the host
Qualys's reasoning is that exploitability depends on a machine's current state, not on its software version. It lists the conditions. They are a pending signature update, a running Defender service with real-time protection, certain filter drivers, available shadow copies, and a reachable cloud-file path.
Qualys describes the first check as a soft-target filter. A host that installs updates fast gives the exploit little time to work.
Taken at face value, the logic is sound, though the evidence behind it is limited, as the next section shows. If no update is pending, the chain stops at stage one. For anyone ranking patches, that matters. A version scan can only say "affected." It cannot say which of two similar laptops the attack would work on.
This is the argument for host-level checks. Teams ranking patches from version data alone cannot tell similar-looking hosts apart.
Read the evidence with care
Qualys sells TruConfirm, a product built on this idea. Qualys says it marks a host "Exploit Validated" only after environment checks and a safe simulation of the freeze in stages two and three. The test does not extract account data, reset passwords, create services or open a SYSTEM shell.
Several limits apply. Qualys describes two test contexts. The full chain was demonstrated on one lab host, named DESKTOP38, that met every condition. It used the original, unmodified proof-of-concept. The report describes no host that was affected but not exploitable.
TruConfirm's validation evidence came from a separate asset, using a modified, non-destructive proof-of-concept. The report gives no count of how many real hosts would be exploitable. So the central point is an argument from a vendor, not a measured result.
Questions to put to your team
First, which of our Windows endpoints run a Defender Antimalware Platform older than 4.18.26030.3011? Qualys says that version and later block the vulnerable path before stage four.
Second, can our tools tell "affected" from "exploitable" on each host, or do they only compare version numbers?
Third, how far could a standard-user foothold reach in our network? In Qualys's lab, domain administrator credentials were already sitting in memory.
A CVE says what could go wrong. The more useful question is whether it can go wrong on a given machine today.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Qualys.
