Security tools are software, and software has bugs. MITRE ATT&CK T1687, Exploitation for Defense Impairment, covers adversaries who exploit vulnerabilities in antivirus, EDR, firewalls, monitoring agents or other defensive components so those tools stop preventing, detecting or reporting. It sits in the Defense Impairment tactic and applies to IaaS, Linux, macOS, SaaS and Windows.
How attackers use it
MITRE describes the pattern at a high level. An adversary takes advantage of a programming error in a security product, a service or the operating system to run code they control, usually to weaken or disable protection. They may first run discovery, such as Software Discovery (T1518), to learn which defensive tools are installed and then pick one to target.
A successful exploit can let them terminate security processes, disable protections, bypass enforcement or reduce the value of a control. MITRE also notes that bugs in cloud or SaaS infrastructure can be used to bypass built-in security boundaries or to disrupt visibility across environments.
How to detect it
The MITRE page offers a detection strategy built around one idea: a defensive component misbehaves right after something suspicious touched it. Look for:
- Service crashes, unexpected restarts, driver unloads or tamper-state changes in a security product.
- Gaps in telemetry, such as an agent that stops reporting while the host stays online.
- On Linux, daemon termination, disabled logging, a kernel module unload or an audit stoppage.
- On macOS, crashes of security extensions, network filters, launch daemons or telemetry agents.
- In SaaS and cloud, disabled alerts, reduced retention, bypassed enforcement, detached agents, changed security groups or unusual admin and API activity that cuts visibility.
The useful move is correlation. A crash alone is noise. A crash that follows odd local execution or network input, and is followed by new process activity, is a story.
How to reduce the risk
MITRE lists no formal mitigations for this technique, so the practical steps come from the nature of the problem:
- Patch security tools on the same schedule as everything else, and track their versions.
- Alert when an agent goes silent. A heartbeat check on every sensor catches the quiet failure.
- Send logs off the host so a disabled local agent does not erase the record.
- Restrict who can change security settings, retention and alert rules in SaaS and cloud consoles.
Quick check
Why correlate a security service crash with other activity?
Crashes happen for dull reasons. A crash that follows suspicious execution or input and is followed by new processes or lost telemetry is much stronger evidence of exploitation than the crash alone.
