The most privileged program on a Windows endpoint is often the one you installed to keep it safe. An antivirus or endpoint detection agent runs with SYSTEM rights, loads kernel drivers, and touches files that nothing else on the box can reach. That privilege is exactly what makes it worth attacking. A researcher who spent this spring turning Microsoft Defender into a privilege-escalation tool has now done the same thing to Kaspersky, and the newest exploit works on a fully patched Windows 11 machine because the flaw sits in the security agent, not the operating system.
The exploit is called HardBreacher, released at the end of August by a researcher who goes by Nightmare-Eclipse, also known as Chaotic Eclipse. Kaspersky told SecurityWeek it had already addressed the underlying issue, and independent coverage from Security Affairs confirmed the release. Here is what a defender needs to weigh, and why patching the operating system is not the number that matters.
What HardBreacher actually does
HardBreacher targets Kaspersky Endpoint Security version 14.0.0.504, tested against a fully updated Windows 11 25H2 build. A standard, low-privileged local user coerces one of Kaspersky's own user-interface processes into writing a file into C:\Windows\System32, a directory a normal account cannot write to. In the public proof of concept, that file is a DLL the current user then owns outright. Writing attacker-influenced content into a protected system folder is the whole game. It is the primitive an attacker builds on to get code running at a higher privilege than they started with.
Two caveats keep this from being a five-alarm fire today. The proof of concept is unstable, terminates with errors, and often needs several attempts and a reboot to land. And no CVE has been assigned. The flaw has not been publicly confirmed by Kaspersky beyond its statement that it was fixed, and there are no reports of exploitation in the wild. This is a local escalation, not a remote one, so an attacker needs a foothold on the machine first. None of that makes it noise, for reasons the pattern makes clear.
Why is a fully patched Windows 11 machine still exposed?
Because the flaw is not in Windows. HardBreacher targets Kaspersky's agent, which updates through the vendor's own channel, not Windows Update. A host can report full operating-system patch compliance and still run the vulnerable agent build, so the metric most teams track on a dashboard does not cover the software that is actually exposed here.
That gap is the practical lesson. Patch-compliance reporting is usually built around the operating system and a short list of common applications. The security agent, ironically, is often left out of that scrutiny because everyone assumes it keeps itself current. When the vulnerable component is the agent, "fully patched" on the operating-system view and "exposed" on the host are both true at the same time.
One researcher, one playbook, many vendors
HardBreacher is not a one-off. Over roughly six weeks in April and May, the same researcher released a run of Windows and Microsoft Defender zero-days, documented by Barracuda: BlueHammer (assigned CVE-2026-33825 and patched in April 2026), RedSun (a Defender privilege escalation reported as silently fixed), and UnDefend (a defense-evasion tool reported as still unpatched), plus a BitLocker bypass and two more local-escalation tools. Barracuda reported that Huntress observed some of them used in hands-on-keyboard intrusions from April 10, so the flaky-proof-of-concept stage did not last long. The researcher has publicly framed the releases as retaliation against Microsoft over a disclosure dispute.
The technique is consistent across every one of them, and that consistency is the real story. The move is not to evade the security tool. It is to weaponize it: coerce a high-privilege component of the defensive software into an attacker-influenced write or action, and let its own privilege do the escalation. HardBreacher is that same play run against a different vendor. The specific bug will get patched. The playbook will not.
| Exploit | Target agent | CVE | Status |
|---|---|---|---|
| BlueHammer | Microsoft Defender | CVE-2026-33825 | Patched (Apr 2026) |
| RedSun | Microsoft Defender | None assigned | Reported silently fixed |
| UnDefend | Microsoft Defender | None assigned | Reported unpatched |
| HardBreacher | Kaspersky Endpoint Security | None assigned | Vendor says fixed |
The detection that survives the next drop
Chasing a signature for one proof of concept is a losing game here, because the researcher's whole pattern is to ship a fresh binary against a fresh target every few weeks. The behavior generalizes even when the exploit does not. The high-signal event is a security agent's process, or a standard user driving it, writing executable content such as a DLL or EXE into C:\Windows\System32 or another protected directory outside a real install or update window. A legitimate agent almost never does that on its own.
This is the same blind-spot problem that shows up when attackers reboot Windows into Safe Mode to shut off security tools, when ransomware runs where antivirus cannot see it, or when a crafted archive strips a Windows security warning. The control you trust becomes the thing turned against you. Watch your defensive software for tampering, unexpected child processes, and writes into locations it has no business touching, and treat local privilege escalation as a live threat even on a patched box, exactly as you would a kernel escalation bug with a public exploit.
What should defenders do right now?
-
Verify the running version of every endpoint agent, not just that it is installed. Confirm auto-update is on and that agents are actually pulling updates.
-
If you run Kaspersky Endpoint Security, force a product and database update, confirm the build afterward, and track Kaspersky's advisories for a CVE and formal confirmation.
-
Add the behavioral detection above, and treat an unstable public exploit as "not yet productized," not as "safe." This actor's earlier unstable releases turned up in real intrusions within days.
-
Put your security agents in the threat model as privileged, third-party code, and monitor them like any other SYSTEM-level service.
Managed detection and response earns its keep on exactly this kind of behavior: not a signature for HardBreacher, but an alert when a program does something a program of its kind should never do. The endpoint agent is privileged code you did not write and cannot audit. The next drop against it is already being written, so watch it now.