When anti-virus goes rogue – A trifecta of Defender zero-days

Anti-virus as a target

These days, the collective term for what used to be known as anti-virus software is EDR, short for endpoint detection and response, but you’ll still hear it informally called anti-virus, as we’ve done here.

(If we can still dial phone numbers, even though telephones haven’t had dials for about 40 years, we can surely still use anti-virus as a convenient shorthand term for the sea of software that aims to find and stop cyberthreats on our devices.)

One of the big challenges facing anti-virus tools is that they need to protect the entire computer, not just the current user’s account, in case rogue code tries to compromise the operating system itself.

Loosely speaking, EDR tools such as Microsoft Defender need system-level privileges, and even kernel-level access, to track the full range of background malicious activity that aggressive criminals and attackers know how to initiate.

And many organizations these days rely on Defender because Microsoft’s licensing terms allow it to leverage its huge range of system software – Windows, Windows Server, Active Directory, Office, IIS, SQL Server, Intune, Entra, and so on – to undercut third-party security vendors by bundling Defender into the deal.

As a result, security flaws in the ubiquitous Microsoft Defender toolset pose a serious global risk.

After all, what could be handier for a busy cybercriminal than having their malware officially tagged as “safe for use” by Defender, or tricking Defender itself into launching their malware, or telling Defender to stop fetching updates, so that new malware samples won’t get detected or blocked?

Unfortunately, three different zero-day holes of this sort in Defender have been published recently, under what can only be described as confrontational circumstances.

If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.

Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.

Forms of disclosure

We shan’t go into details about the low-level working of these exploits here, because that would require a lengthy and technical treatise involving functionality such as registry hives, reparse points, Windows account impersonation, and more.

But the important public message from this trifecta of Defender exploits is that they have more in common with the cybercrime-as-showing-off era of the 1980s and 1990s, before anyone figured out how to make money from malware without being caught․․․

․․․than with the state-sponsored attacks and ultra-aggressive money-making cybercriminal scammery of the 2010s and 2020s.

All three bugs were published openly – what’s known in the trade as full disclosure, where everyone gets the bug details at the same time, including the vendor, users, IT teams and SOCs, criminals, and intelligence agencies.

Some researchers argue that full disclosure, despite the downside of alerting criminals and attackers at the same time as defenders and users, is justified on the grounds of its intellectual and social simplicity.

Everyone gets the same information at the same time, and no one gets a chance to exert any sort of commercial advantage from being in a self-selecting oligarchy of insiders who share bugs privately to patch or detect them ahead of competitors in the field.

Nevertheless, full disclosure is unusual these days, because responsible disclosure is the most common sort of bug report, where the vendor is given some private time up front (90 days is common) to work on and release fixes before the bug-finders go public and claim their fame and glory.

When taunts go public

As you can probably imagine, researchers who don’t care about money, or who are more interested in creating publicity for themselves or provoking embarrassment for the vendor in the case of a commercial product, sometimes choose full disclosure primarily for the drama it can create.

That’s what happened in this case, when a coder going by the name Nightmare Eclipse published not one but three Defender zero-days in quick succession: BlueHammer, RedSun, and UnDefend.

Ironically, the researcher chose Microsoft’s very own GitHub service as their publishing medium, creating three source code repositories on the popular code-sharing service to document and distribute the exploits.

Microsoft, for its part, can’t very well ban or censor those repositories (which have already been widely copied anyway), as much as it might like to, given that the company routinely and officially permits the posting of malicious code and cyberattack tools elsewhere on GitHub.

Existing GitHub repositories that can be downloaded by attackers and defenders alike include: malware samples and explainers; password harvesting and cracking software; automated phishing kits; authentication token stealers; keyloggers; and much more.

As much as you might dislike this approach, full disclosure does level the defensive playing field, as idiom might put it, for all that it also plays into the hands of cybercriminals.

Better the devil you know and can defend against for yourself, say full-disclosure proponents.

Two tricks to steal SYSTEM privilege

As we said above, we’re not going to explain these new exploits in detail – there are numerous places, including Nightmare Eclipse’s own GitHub pages, where you can dig into the gory details if you like.

But we’ll set out the underlying tricks that the researcher came up with, as a reminder of the complexity of today’s anti-virus, ahem, EDR software.

This complexity unavoidably means that the very software we use to protect our systems from intruders sometimes opens up security holes instead – a sort-of gamekeeper turned poacher situation, to mix irony and metaphor.

Loosely speaking, the first two exploits, BlueHammer and RedSun, rely on deliberately triggering a Defender detection by wilfully writing a known malware sample to disk.

In the first exploit, the malware waits for Defender to start an update, during which Defender temporarily creates what’s known as a Volume Shadow Copy Service (VSS) backup.

That’s the Windows name for a live system snapshot that includes vital operating system files and data, presumably generated by Defender as an insurance policy for rolling back in case something breaks during the update.

Triggering a malware detection and tracking Defender’s response to it then gives the BlueHammer malware an opportunity not only to discover the location where Defender has stored its shadow copy, but also to trick Defender into leaking the shadow copy’s contents, even though the backup was created with all-powerful SYSTEM privileges.

Because the VSS copy includes a backup of the system registry, it contains the super-secret password hash of the all-powerful SYSTEM account.

The malware therefore has back-door read access to the most privileged parts of the registry, so it can extract this hash and upgrade its access to SYSTEM level.

By now, you may be wondering, “But won’t the deliberately triggered malware detection give the game away, making this exploit easy to spot?”

In theory, yes; but in practice, no.

The malware cunningly writes out the widely-used EICAR test file, a non-malicious anti-virus trigger that was originally devised back in about 1990 as a standardized way of testing that malware-blocking software is properly installed and will report detections correctly.

Thus the activation of the exploit shows up in system logs as if it were a harmless test event, meaning that it’s likely to be ignored.

Fortunately, the Defender bug that made BlueHammer possible (CVE-2026-33825) was patched  in the April Patch Tuesday update on 2026-04-13.

Until the cybersecurity industry first agreed to accept a single “test-trigger” file, each vendor would typically supply users with an executable test file of their own, sometimes using real malware that had been lightly modified so it would crash rather than run, but would still provoke an alert. This caused incredible confusion, so an early group of community-focused researchers decided to fix this problem. If you’ve ever downloaded the EICAR file yourself, you may have seen mention of the name Paul Ducklin on the page that describes it. If you will pardon me sounding conceited, that Paul Ducklin is I.

A follow-up exploit

In the RedSun exploit, a similar but simpler trick is used.

While investigating the detection-time behavior that led to the BlueHammer exploit, the researcher found a less complex way to subvert Defender, without needing to wait for a Defender update that would produce the shadow copy file from which to exfiltrate the SYSTEM password hash.

Nightmare Eclipse noticed that if their malware triggered an EICAR detection event on a file that was deliberately tagged as a Windows Cloud File, rather than as a regular disk file, Defender would first read in the file to scan if for malware, and then, on finding that it had malware in it, immediately write it back to disk.

Why Defender does this isn’t clear, and as N. Eclipse themselves wrote in a critically unpunctuated complaint in their GitHub repository, “I think antimalware products are supposed to remove malicious files not be sure they are there but that’s just me.”

The RedSun malware exploits this apparently unnecessary file rewrite by tricking the privileged Defender code into rewriting an operating system service file in the Windows SYSTEM32 directory, instead of the EICAR file originally dropped by the exploit.

At this point, RedSun itself has overwrite access to this incorrectly-dropped system file, rather than to the original file that it created, so it cunningly replaces the system service executable with a copy of its own code.

The malware then asks Windows to activate this now-compromised Windows service – something that would be an innocent enough request, were it not for the fact that the official Windows service software code has by now been replaced with RedSun itself.

As a result, of course, the code that gets loaded is another copy of the malware, but this time it’s running under the Windows SYSTEM account, and has therefore effectively taken full control of the computer.

In the sample code on GitHub, the RedSun exploit deliberately opens up a foreground command prompt window with system-level access, by way of visibly proving its point.

In a real attack, however, the attack code could be almost anything at all, and would most likely go out of its way to run quietly in the background to escape notice.

RedSun hasn’t yet been patched by Microsoft.

Staying undetected

The final exploit, UnDefend, interferes with Defender’s operation rather than grabbing system-level access.

It doesn’t turn Defender off altogether, as the name might at first suggest, but instead prevents Defender from updating.

Protection is therefore still turned on, and will therefore appear to a well-informed user to be working, but it will steadily fall behind on what it can detect.

Ironically, Microsoft’s immediate response to both BlueHammer and RedSun was to push out Defender updates to block the execution of these exploits, or at least to block exploits that were close enough to the GitHub versions for the Defender signatures to detect.

(Signature-based detections are often easy to bypass, even by cybercriminals who don’t understand the original attack code, as long as they have the experience or the automated tools needed to rework the code just enough that it still works in the same way as before, but sidesteps detection.)

In other words, combining the elevation-of-privilege vulnerabilities exploited in BlueHammer or RedSun with the security bypass vulnerability exposed in UnDefend would greatly improve the chance that the exploit would not only work in the first place, but then remain undetected indefinitely.

UnDefend comes with two attack-level choices, intruigingly named passive, which blocks routine signature updates, and aggressive, which blocks all updates, including code upgrades and new features, though it might be more likely to be spotted for that reason.

Fascinatingly, if worryingly, Nightmare E. signed off their UnDefend GitHub write-up by claiming that they have a fourth exploit up their sleeve that tricks Defender’s management console into reporting that your protection is current, even if UnDefend has been used to prevent it from updating:

Now funnily enough, I found a way to lie to the EDR web console to show that [D]efender is up and running with the latest update even if it’s not. I was thinking about publishing the code but after thinking about it, it will cause waaay too much damage so I think I’ll keep that stuff stashed for now.

Why the publicity?

Early reports suggest that Nightmare Eclipse’s beef with Microsoft, and their unwillingness to disclose the original BlueHammer exploit responsibly, started when Microsoft demanded a video showing the exploit in action before it would accept the report and the sample code.

You can understand why Microsoft might ask for what you might call a “proof-of-proof-of-concept” video of this sort, by way of eliminating the many ill-formed or incomplete reports it undoubtedly receives.

But dropping three different zero-days in succession suggests that N. Eclipse’s resentment may run deeper than mere annoyance over being asked for a video, an impression that is supported by some of the comments in the exploit code:

What to do?

• Make sure you’re patched, and if you are using Defender, check that it’s running and updating as you would expect. If you want to avoid the Defender console, the command powershell Get-MpComputerStatus will do the trick, as shown below. (If you are already in a PowerShell window, you can omit the powershell prefix, but the full command will work in both PowerShell and in CMD.EXE, the old-school Windows Command Prompt.)
• Consider asking your IT team or SOC if they are looking for IoCs, or indicators of compromise that could suggest a sequence of system events that matches the known behavior of these exploits in the wild. This could include the combination of an EICAR detection followed by various other specific but unusual system calls needed for BlueHammer or RedSun to work.
• Remember that this is an elevation-of-privilege exploit, not a full remote code execution hole. In other words, attackers can’t use this malware to break into your computer in the first place, but could use it to make an existing attack much more dangerous. Ransomware crooks, in particular, commonly use this chain-of-exploits approach.
• If you don’t have a SOC, or you would rather regain time to focus on your core business instead of keeping your eye out for attacks of this sort, why not contact SolCyber and ask for help?

SolCyber’s human-centric SOC team can not only detect and remediate exploits before the attackers get in, so you don’t have to, but also engage with your and your staff to ensure that you have the best levels of human resilience, for those moments – like the ones described here – where your EDR itself turns out to be the weakest link.

Sample output from the Get-MpComputerStatus PowerShell command:

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!