DET0497: Detection of Defense Impairment through Disabled or Modified Tools across OS Platforms.
DET0497 is a detection strategy for identifying when defensive tools are disabled, degraded, or modified. The business significance is visibility loss: if...
Analyst context for executives and security teams
DET0497 is a detection strategy for identifying when defensive tools are disabled, degraded, or modified. The business significance is visibility loss: if EDR, antivirus, IDS, logging agents, sensors, or their configurations are stopped or tampered with, the organization may lose the evidence needed to contain an incident, prove compliance, or make reliable executive decisions during a crisis.
Executive priority
Treat this as a resilience and assurance control, not just a SOC alert. Leaders should ask whether critical security tools are monitored for health and tamper events across the environments in scope for the related ATT&CK technique, including Containers, ESXi, IaaS, and Linux. Priority should go to validating that outages or configuration changes in defensive tooling create timely, actionable escalation paths for incident response and audit evidence.
Technical view
This detection strategy is related to ATT&CK technique T1685, Disable or Modify Tools, under defense-impairment. SOC and IR teams should validate monitoring for stopped services, killed security processes, deleted or modified tool configuration files, modified Registry keys where applicable to tool management, failed or blocked updates, and sensor/logging degradation. Because the official DET0497 object does not provide a detailed detection analytic, teams should map the strategy to their own security-tool inventory and confirm which control-plane and host-level events prove tool health or tamper state.
Likely telemetry
- Security tool health and heartbeat events
- Endpoint, server, container, ESXi, IaaS, and Linux service/process status events where applicable
- Security agent configuration change logs
- Logging agent, sensor, IDS, antivirus, and EDR operational logs
- Update failure or policy enforcement logs for defensive tools
Detection direction
- Inventory defensive tools and define expected running services, processes, sensors, update behavior, and configuration baselines.
- Alert on unexpected stoppage, restart failure, process termination, configuration deletion/modification, or loss of heartbeat for security tooling.
- Correlate tool-impairment signals with administrative activity to reduce false positives from approved maintenance, upgrades, or policy changes.
- Validate blind spots where the monitored system is also the source of telemetry; independent health monitoring may be needed when agents are disabled.
- Use the relationship to T1685 to focus tuning on defense-impairment behavior rather than ordinary software failures alone.
Mitigation priorities
- Establish ownership and baselines for all critical defensive tools and logging/sensor components.
- Restrict and monitor administrative access capable of stopping, modifying, or updating security tools.
- Implement tamper protection, change control, and configuration monitoring where supported by the deployed tools.
- Create incident response runbooks for unexpected loss of security telemetry or tool health.
- Review evidence retention so compliance and investigation teams can prove when visibility was lost and restored.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description or detection text, so this take is driven by the object name, external reference, and its relationship to T1685 Disable or Modify Tools. Local tool inventory, management architecture, and maintenance processes are required to turn this into concrete analytics.
Platforms and tactics are not specified on DET0497 itself. Platform and tactic context comes only from the related T1685 technique: defense-impairment across Containers, ESXi, IaaS, and Linux. No active exploitation, actor attribution, impact level, or guaranteed detection coverage is stated by the supplied fields.
Detection of Defense Impairment through Disabled or Modified Tools across OS Platforms.
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1685 | Disable or Modify Tools | This object detects Disable or Modify Tools. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 153f698627b9… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0497Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.