The Detection Gap: MITRE ATT&CK T1562.001

• Attackers who target your EDR agent, disable logging, or tamper with security tools are telling you exactly where to look.
• A killed process, deleted registry key or abused signed driver can be more than enough to blind your defenses.
• CBX’s Tamper Protection throws a wrench in attackers’ plans, stopping them from using these techniques against your security tools. 

The Detection Gap is a breakdown for security practitioners who have to make quick calls under tight time constraints. In each post, we walk through what one MITRE ATT&CK technique looks like when it's legitimate activity vs. when it's actually an attacker in your environment. 

The alert that never fired

An attacker lands on an endpoint with local admin rights. Before they do anything else (before credential theft, lateral movement, or any of the techniques we’ve covered in this series), they go after your security tooling directly. It starts with a killed process. Then, a registry value gets flipped. And suddenly, logging stops. If that attempt succeeds, everything that happens next on that machine happens in the dark.

That ordering matters. This technique often comes first, not last, in a real intrusion, because an attacker who can blind your visibility early buys extra time to get further downstream. RansomHub's EDRKillShifter tool did exactly this in 2024, deploying a known vulnerable driver to gain kernel-level access and terminate EDR and antivirus processes outright before the ransomware payload ever ran. Far from a sophisticated custom exploit, it used a legitimate driver with a known vulnerability, abusing it to do something it wasn’t designed to do. By now, this should sound familiar to those who’ve been following this series.

Security tools aren't just processes an attacker can kill outright either. Some attackers target the artifacts a security tool depends on rather than the tool itself. One documented example involves modifying the Start and Enable registry values tied to Sysmon's event logging, leaving the Sysmon process running while its actual data collection goes dark. The tool looks alive, but it can’t see anything anymore. While this particular example targets a third-party logging tool, not a vendor's own agent, it's a useful reminder that this technique's real scope can include anything a defender relies on. And understanding where that line sits in your environment is the first step toward understanding what your existing defenses can actually catch. 

The legitimate case 

Security tooling routinely gets modified, stopped, or reconfigured for entirely legitimate reasons. Compared to other techniques, it happens at much higher volumes too.

Here’s what legitimate activity typically looks like: 

• Actor: An IT admin performing planned maintenance, a software update process that briefly stops an agent to apply a patch, or an approved uninstall tied to a hardware refresh or platform migration
• Scope: A single, documented action, an update, a licensed uninstall, a policy change pushed through your management console
• Context: Tied to a change ticket, a patch cycle, or a known deployment tool, and reversible or self-restoring within an expected window
• Surrounding activity: Isolated, with the tooling coming back online on a predictable timeline

The malicious case 

The same general category of action can look real different when an attacker is trying to disable your defenses. 

Keep a watchful eye on the following:

• Actor: A process with no administrative context behind it, particularly one connected to a process chain already flagged for suspicious activity 
• Scope: An abrupt and often total attempt to kill the agent process outright, modify its registry keys, or interfere with its files
• Context: No supporting ticket, no maintenance window, but frequently paired with other defense evasion activity happening in the same general timeframe
• Surrounding activity: Usually starts early, right after initial access, clearing the way before anything else happens, or immediately before a more damaging action like a shadow copy deletion technique. Either timing will tell you something about how much runway you may or may not still have left to respond. 

But there’s one part above all else that betrays attacker intent: the mechanism itself. Legitimate security tool changes come through your own management plane. Malicious ones come through a process trying to reach the tool directly, a kill command, a registry edit, or an attempted file modification, none of which resemble how your own administration actually touches that tooling.

One more important scoping note before looking at detection: these direct process-kill and registry-tamper attempts are exactly what a security platform's own tamper resistance is built to catch. A kernel-level driver attack, like the EDRKillShifter style mentioned earlier, is a different animal, and it's caught by a different layer entirely. It’s worth understanding both, especially when conflating them can lead to a false sense of coverage.

Where the signal comes together

This is the first technique in our series where the story isn't primarily about reconstructing a chain after the fact. Instead, we’re focusing on whether the attempt succeeds at all.

Tamper Protection exists specifically to answer that problem. It protects the CBX agent itself, including its processes, registry settings, and files, from unauthorized modification, deletion, or shutdown. That protection has a defined scope. Our previous example, where a third-party tool's logging pipeline goes dark through registry tampering, the Sysmon-style example, sits just outside what Tamper Protection covers. That’s because it protects the platform's own resources, not arbitrary third-party tooling. Catching that kind of tampering against a different tool in your stack is a job for behavioral detection policy, not this specific control. Knowing exactly where that line sits matters, because assuming broader coverage than a control actually provides is its own kind of blind spot.

Within its defined scope, Tamper Protection offers direct protection. A tamper attempt against the agent generates a high-severity alert. That alert automatically links to an investigation, so the attempt itself and the chain around it show up together instead of two things you have to connect yourself. The value here comes from detecting the attempt itself, regardless of whether the attacker's next move would otherwise go unnoticed.

The kernel-driver scenario from the opening, the EDRKillShifter style of attack, is a genuinely different detection path. 

What to look for

Start by checking whether a tamper alert fired at all, and treat it with real weight regardless of what else is happening on the endpoint. An attacker doesn't attempt this technique casually, so a triggered event, even a blocked one, is a meaningful signal on its own. 

From the alert, follow the process chain around the attempt. Check which process initiated the action and what it connects to. A management console or a known patch tool reads nothing like an unfamiliar process with no deployment context behind it. And if a kernel driver was involved rather than a direct process or registry attack, remember that's a separate detection layer doing the catching, so it’s worth confirming that layer is actually enabled and current rather than assuming tamper resistance alone has it covered.

A quick posture check

Before you close out, consider these questions about your own environment.

1. Can a local admin stop or uninstall the agent without supplying a configured client password, or is that barrier actually enforced across your fleet?
2. Have you added exclusions to accommodate a third-party scanner or tool that repeatedly triggered tamper events?
3. If so, do you know exactly what those exclusions allow to access or modify the agent?
4. If a third-party logging tool elsewhere in your stack went dark tomorrow through registry tampering, would a different control in your environment catch that?

There’s a difference between a control that's technically enabled and one that's actually enforced as intended. A configuration detail that nobody's revisited since deployment can leave a gap in an otherwise sound security posture. But now you know how to catch it. 

Next, we'll look at another ATT&CK technique using the same approach: what's normal, what's not, and what tool can help you make that distinction faster.

To see how Symantec CBX can help strengthen your security posture, request a 1:1 demo.