How T1685 disable or modify tools blinds a SOC
T1685 Disable or modify tools sits in the Defense Impairment tactic (TA0112), whose purpose, in MITRE's wording paraphrased, is to break the security mechanisms, pipelines and tooling that let defenders see and trust what is happening. In this technique, an adversary disables or alters the tools a SOC relies on to observe its networks and hosts, so the resulting gaps can look like ordinary operations. The first sign is often a SOC lead noticing that security agents or collectors have gone quiet on a set of systems, with no change ticket and no obvious cause.
Defense Impairment became its own tactic in ATT&CK v19, released April 28, 2026, when the Enterprise Defense Evasion tactic was split into Stealth (TA0005) and Defense Impairment (TA0112). Dashboards and reports tagged to Defense Evasion may need re-mapping to reflect this. Intrusions that use T1685 often occur before or alongside other activity, because reduced visibility makes later steps harder to detect. Illustrative example: a Linux fleet reports telemetry normally for weeks, then a subset of hosts stops reporting while the rest continue. Confirm with your vendor and in your own environment which agent and collector events remain visible when a service stops, and whether the loss of telemetry itself raises an alert.
ATT&CK v20.0, released October 13, 2026, is the version these pages target, and T1685 has seven sub-techniques under it. Those sub-techniques are covered in the sections that follow, so this section does not list them. ATT&CK can rename, deprecate or revoke techniques between releases, so any detection mapping should name its version and be re-checked when MITRE publishes a new one. Before writing rules, download the enterprise-attack 20.0 STIX bundle and confirm the current names and relationships for T1685 yourself. The ATT&CK updates page records the change history across releases.
Which telemetry reveals changes to security tooling
This table maps each telemetry source relevant to T1685 Disable or Modify Tools to the change it can reveal and the open-source collector that gathers it. Read each row as a starting point: the signal names are a detection design choice, and the exact fields and coverage must be confirmed in your own environment before you rely on them.
| Telemetry source | Signal to look for | Open-source collector |
|---|---|---|
| Process Creation (DC0032) | Execution of stop, disable or uninstall actions against EDR, logging or monitoring services on Windows hosts | Sysmon, Wazuh agent (Windows event collection) |
| Command Execution (DC0064) | Service control or package removal commands run against security agents on Linux or ESXi hosts, captured by shell or audit rules | Auditd, Wazuh agent, Velociraptor |
| Windows Registry Key Modification (DC0063) | Changes to registry values that set security agent startup type, tamper protection or logging policy | Sysmon registry events, Wazuh agent, Velociraptor |
| File Modification (DC0061) | Edits or deletion of security agent configuration files, certificates or exclusion lists on Linux and container hosts | Auditd file watches, Wazuh file integrity monitoring, Falco where deployed |
| Container and orchestration events | Deletion or modification of sidecar or security DaemonSet workloads, or privileged pod changes that disable monitoring | Kubernetes audit logs, Falco, Wazuh agent on nodes |
| ESXi and hypervisor management logs | Stopping of host agents or changes to logging and syslog settings on ESXi hosts | Syslog forwarding to Wazuh or Security Onion, Zeek where traffic is visible |
| IaaS control plane activity | Changes to cloud logging, monitoring agents or security service configuration on virtual machines or accounts | Cloud provider audit logs forwarded to Wazuh or Security Onion |
| Agent heartbeat and health data | Loss of agent check-ins, sudden silence from a host, or alert volume dropping to zero on a monitored asset | Wazuh manager agent status, Security Onion host health views |
Detection ideas for disabled or modified security tools
T1685 Disable or modify tools covers any attempt to switch off or alter the software that defenders rely on to see activity. The four ideas below look at the same problem from different telemetry: service state, configuration files, platform security settings and the health of the agents themselves. Each one is written as a logic description that can be expressed as a Sigma rule and tuned in your own environment.
Security agent service stops
Watch for the stop, disable or failure of endpoint security agent services, using service control events and Process Creation telemetry from the host. The logic is simple: a stop or disable action against a protected agent name, outside an approved change window, raises an alert. Start with a threshold of one event per host per hour for a critical agent, then tune. Expect false positives from patch windows, agent upgrades and planned maintenance, so correlate with your change calendar and the software deployment tool's job records before paging anyone.
Security tool configuration file changes
Alert on writes or deletions to configuration files that hold the security tool's policy, exclusions and tamper protection flags. File Modification telemetry on the agent's install path is the main source, and the useful signal is a change made by a process or account that does not normally manage that product. Track exclusions in particular, because adding a path exclusion can quietly remove visibility without stopping the agent. Known false positives come from configuration management runs and vendor policy pushes, so baseline the expected writer for each file.
Container and ESXi security settings
Monitor changes to the security settings that govern containers and hypervisors, such as admission or runtime policy, host firewall and logging configuration on ESXi hosts, and the security context of workloads. Command Execution logs from the hypervisor shell and orchestrator audit logs are the main sources. Flag any command that lowers an enforcement mode or removes a logging target, and compare it with a known baseline of approved settings. Planned hardening rounds and new cluster builds are the usual false positive sources, so require a change ticket reference in the event.
Agent heartbeat and log volume drops
Detect silence rather than an action. Alert when an endpoint stops sending agent heartbeats or when its log volume falls well below its own historical baseline for a set window. This catches tampering that does not leave a clean command trail, and it also catches agents that were removed by other means. Set the baseline per asset group, since laptops and servers behave differently. Expect false positives from powered-off devices, network outages and scheduled downtime, so suppress known maintenance windows and alert on unexplained gaps only.
How to validate that the T1685 detection fires
This sequence proves, in a private lab or cyber range, that the T1685 detection raises an alert for each named tool modification and that the team can trace every action back to a timestamped record. It also shows which gaps need tuning before the detection is trusted in production.
Approve the emulation plan and scope
The detection owner and the security lead write a documented emulation plan that names the security tools in scope, such as the endpoint agent, the log forwarder and the Wazuh or Sigma-based rules that watch them. The plan lists which T1685 sub-techniques apply to each platform in the lab, such as Linux, Windows or the container hosts, and which are out of scope. Done means the plan is signed off by the CISO delegate and the platform owner, and the test is confined to the cyber range or an isolated lab segment.
Scope the test to named tools
Each test case targets one named security tool or agent on one named host, so a failed alert can be traced to a specific control. The test team records the tool name, host, platform, sub-technique and the ATT&CK version the rule targets, for example v20.0 as released by MITRE. Done means every test case has a unique identifier and a single, named target, and no case touches production systems or shared monitoring infrastructure.
Agree the change window and rollback
The lab operations lead and the SOC agree a change window, a named contact for each system and a rollback owner who can restore every tool to its prior state. The team confirms that configuration backups exist before the window opens and that the SOC knows the window is active so that analysts do not mistake the exercise for a live incident. Done means the window, contacts and rollback steps are written into the emulation plan and acknowledged by both teams.
Record the time of each action
The test operator logs the start and end time of every action in a shared exercise log, using a single time source across the lab so timestamps line up with the logs collected by Wazuh, Security Onion or the SIEM in use. Each entry names the test case, the target host and the expected telemetry, such as command execution or process creation events. Done means every action has a timestamp that can be matched to the raw log lines in the next step.
Check the alert in the SIEM
The SOC checks whether the expected T1685 rule fired for each test case, then confirms that the alert carries the host, the user, the tool name and the time that were recorded in the exercise log. The analyst also verifies that the raw events are present in the case record so the alert can be investigated. Done means each test case is marked as detected, detected with incomplete context, or not detected, with the alert or event identifier attached.
Measure heartbeat-loss alerts
The team checks whether agent heartbeat-loss alerts also fire when a security tool is disabled, since a stopped agent may generate a separate signal even when the modification rule is silent. The result is recorded per test case, with the time between the action and the heartbeat alert, so the SOC can compare the two signals. Done means the team can state for each tool whether the modification alert, the heartbeat alert, both or neither fired.
Log gaps as tuning tickets
Each missed detection, late alert or alert missing context becomes a tuning ticket with the test case identifier, the rule name, the expected and observed telemetry, and a proposed owner. The detection engineer reviews each ticket, adjusts the rule or data collection, and reruns the same test case to confirm the fix. Done means every gap is either closed with a passing rerun or accepted in writing by the risk owner.
Mitigations that make disabling security tools harder
T1685 succeeds when someone can change or switch off a security tool without leaving a trace or needing approval. The two ATT&CK mitigations below, Audit and User Account Management, work together: one makes changes visible, the other limits who can make them. Confirm which of these controls each tool in your estate actually supports before you count on them.
Audit logging of tool configuration
Log every configuration change to security tooling, including agent settings, detection rules, log forwarding targets and exclusion lists. Audit mitigation means the platform records who changed what and when, so a silent change becomes a searchable event. For T1685, check that the audit trail covers the security tools themselves, not only the operating system, and that events are forwarded off the host so an attacker with local rights cannot erase them. Confirm with each vendor which configuration objects generate audit events and whether those events can be retained separately.
Restricted administrative accounts
Limit who holds administrative rights over security agents and their consoles. User Account Management mitigation means accounts are created, scoped and removed deliberately, with dedicated administrator identities separate from daily-use accounts. For T1685, review which accounts can stop an agent service, edit a policy, or disable a sensor, and remove standing rights that nobody uses. Confirm whether your platform supports role-based access, separate administrator and viewer roles, and periodic access reviews.
Alerting on agent and logging service stops
Treat a stopped agent or silenced log source as an alert, not a maintenance event. When a host stops reporting, the absence of expected telemetry is itself a signal. Build a heartbeat check that compares active agents against the asset inventory and raises an alert when a host goes quiet beyond your agreed tolerance. Pair this with alerts on changes to agent configuration files. Confirm how your monitoring platform detects missing agents, because some tools only report hosts that have never checked in.
Change control for security tool policies
Require a documented approval before security policy changes take effect. Pair Audit with a workflow in which exclusions, tuning changes and agent upgrades are requested, reviewed and tied to a ticket. Illustrative example: a new exclusion for a backup path is approved by the security team, and any exclusion that appears without a ticket is flagged for review. Confirm whether your tooling can enforce approval steps or whether this control depends on process and periodic review.
Separation of logging and administration
Keep the people who administer security tools apart from the people who can edit the log store. If one account can both disable an agent and delete its evidence, a single compromise defeats both controls. Store audit records in a location with separate credentials and write-only forwarding from the source. Confirm with your platform team whether log retention can be locked and whether administrators of the monitoring stack can alter historical records.
Triage steps when a security tool alert fires
Start by establishing whether the silence or change was sanctioned. When an alert shows that a security control stopped reporting, changed its configuration or lost its agent, the first question is not what the attacker did but whether a change ticket, maintenance window or agent upgrade explains it. Check the change record, the configuration management history and the platform team's deployment log for the affected tool, such as the Wazuh agent, the Suricata sensor or the Zeek node. Confirm the exact time the telemetry gap began, because a gap that starts minutes after an unexplained process launch on the same host carries far more weight than one that lines up with a scheduled patch. Record the answer in the case file before going further, including who was contacted and what evidence they supplied.
Next, widen the view from the affected host or container to its neighbours. Look at the host's last heartbeat from the manager, its recent process creation and command execution events, changes to the tool's configuration files and service state, and any authentication activity around the same timestamps. On container platforms, check the orchestrator events for the affected workload and its node, and on ESXi or other hypervisor hosts, check the management plane for configuration edits. Compare the gap with the same window on hosts in the same network segment, role or image. If several hosts lost the same control at once, treat it as a campaign-level signal rather than a local fault. Preserve volatile and host evidence with Velociraptor or an equivalent forensic collector before rebooting, reimaging or restarting the agent, because a restart can erase the state you need to explain the gap.
Decide on isolation based on what the evidence shows, not on the alert alone. If the change was unsanctioned, or the neighbour review shows suspicious execution, move the host to a restricted network segment through the controls your team has already approved, and keep the monitoring path open where possible. Escalate to incident response with a short written summary, the preserved artifacts and the open questions. Throughout, keep a timeline with one line per event: the observed time, the source, the value observed, the person who recorded it and the time it was recorded. Store the timeline in the case system with its evidence hashes so reviewers can later separate what was observed from what was assumed. Confirm your organization's internal retention and chain-of-custody requirements before the first collection, since those rules, not this page, decide how long evidence must be kept.
Rehearsing T1685 detection in a private cyber range
Build a range that mirrors your production Linux fleet and container platform, including the host agent, the container runtime, the orchestrator and the log pipeline that forwards events to your SIEM or Wazuh manager. Keep at least one node in each trust zone that matters to you, so the exercise tests attribution across boundaries and not only on a single host. Facilitators schedule injects that alter a security agent's configuration or service state on one node, then change the workload's logging settings on another, so responders must correlate both events to the right node and namespace. Good detection raises an alert within the window your SOC has agreed for that data source, and the alert names the correct host, container ID and image rather than only the management node that forwarded the log. Good response means triage confirms whether the change was authorized, containment isolates the affected node without disrupting unrelated workloads, and communication reaches the platform owner and the application team with the same timeline.
- Agent and service tampering: Inject a stop or config change to a host security agent and confirm that the heartbeat loss or configuration drift alert fires.
- Logging disruption inside containers: Schedule a change to container log settings and verify that the gap is detected from missing log volume, not only from a parsed field.
- Attribution checks: Require alerts to carry host name, namespace and image identifiers so responders do not chase the wrong node.
- Containment drill: Ask the team to isolate one node and prove that other tenants keep running.
- Timing review: Record the time from inject to first alert and to analyst acknowledgment, and compare against the detection target your team set.
Check that every inject maps to a documented detection strategy and that your rehearsal names the ATT&CK version you target.
Build a range with a non-production ESXi host or cluster, a vCenter-style management plane if your estate uses one, and an IaaS tenant with a representative mix of compute, identity and logging services. Confirm that hypervisor and cloud audit logs flow to your analytics platform in the same schema you use in production. Facilitators schedule injects that disable or reconfigure a monitoring or security tool on a hypervisor host, and separately modify a tool's settings through the cloud control plane using a test identity, so responders must decide whether the two events are related. Good detection flags the change on the management or control-plane record, identifies the acting principal and the target host or resource, and fires within the agreed window even when the guest workloads remain healthy. Good response means triage pulls the audit trail for the principal, containment revokes or constrains the identity and restores the tool from known-good configuration, and communication includes the cloud or virtualization owner, the identity team and the security lead.
- Hypervisor tool change: Schedule a change to a host-level monitoring agent and verify the alert names the ESXi host, not only the vCenter object.
- Control-plane change: Use a test identity to alter a security tool's setting and confirm that the audit event carries the principal and resource identifiers.
- Identity pivot check: Ask responders to determine whether the test identity has other rights that the change could have used.
- Restoration drill: Require teams to restore the tool from a documented baseline and record how long verification takes.
- Log completeness test: Confirm that audit events arrive at the SIEM and are not dropped during a simulated log pipeline degradation inject.
Confirm with your cloud provider and virtualization vendor which audit events are retained by default and for how long in your configuration.
Build a range with a small Active Directory domain, Windows endpoints and servers joined to it, and the endpoint telemetry agent, event forwarding and SIEM rules you run in production. Include at least one server that is managed by a configuration baseline tool so the exercise can test whether drift is caught by audit or only by the baseline tool. Facilitators schedule injects that stop or change a security service, modify a tool's configuration key, and alter the audit policy for a host, each on a different machine, so that responders must separate routine administration from deliberate impairment. Good detection raises an alert from process or service events and registry change events, attributes the event to the correct computer and account, and does so within the window your SOC has agreed. Good response means triage checks the account's recent activity and change tickets, containment restores the security service and the audit policy while preserving evidence, and communication reaches the endpoint team, the domain administrators and the business owner of any affected server.
- Service and tool change: Stop a security service on one endpoint and confirm the alert fires from service-state and process events.
- Registry-based change: Modify a tool's configuration key and verify the registry change event is captured and attributed to the right host.
- Audit policy change: Alter audit settings on a server and confirm the change is itself logged and alerted.
- Admin versus attacker triage: Give responders a change ticket for one of the injects and require them to explain why the other is unexplained.
- Evidence preservation: Ask the team to export the relevant logs and registry state before restoring the affected settings.
Confirm your event forwarding and audit policy settings against the Microsoft documentation for your Windows version before you rely on the results.
Questions detection engineers ask about T1685
How do I tell a legitimate security agent upgrade from tampering?
Start with change records: a legitimate upgrade should match an approved change, a known package version, a maintenance window and a run in your deployment pipeline. Tampering usually lacks one or more of these. Build an allowlist of the exact commands and parent processes your deployment tooling uses, then alert on any stop, replacement or configuration edit of an agent service that falls outside it. Correlate Command Execution and Process Creation events with Windows Registry Key Modification on endpoints, and confirm the agent reports back afterward. Illustrative example: an agent stopped at 2 a.m. by an account that does not belong to the patch group should page the on-call analyst. Confirm the exact event fields with your own endpoint tooling before you write the rule.
How do we detect silent telemetry gaps from security agents?
A telemetry gap is a period when a host or log source stops sending events without raising an alert. Track a heartbeat for each host and each log source, compare the last-seen time against an expected interval you set, and alert on silence rather than waiting for a bad event to arrive. Also watch for sudden drops in event volume from a source, configuration changes that lower logging levels, and hosts that move from steady activity to none. Health and status data from your agent manager and sensors can feed these checks, but confirm the field names and behavior in the documentation for your installed version. Test the logic in the cyber range by stopping a forwarder and checking that an alert fires within the window you agreed.
How should we handle ATT&CK version changes between v18, v19 and v20?
Pin every detection mapping to a named ATT&CK version and record that version in the rule metadata. v18, released October 28, 2025, replaced detections in technique pages with detection strategies and analytics, updated data components and deprecated some data sources. v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112). v20 was released October 13, 2026. When you move between versions, compare the technique and sub-technique lists, re-check data component references, and review any renamed, deprecated or revoked items. Keep the mapping table in version control so each change has a reviewer and a date.
Which data components should we prioritize for T1685 detection?
Prioritize Command Execution and Process Creation first, because they show who stopped or changed a security tool and how. Windows Registry Key Modification comes next for Windows agents, since many tool settings live in the registry. File Modification is useful for configuration files and binaries on Linux and other platforms. Each of these data components needs a source that is collected centrally, retained long enough to investigate, and parsed into consistent fields. Check the data component definitions in the ATT&CK STIX bundle for the version you target, since data component IDs were updated in v18. Then confirm each one is actually collected in your environment, because a listed data component without collection gives you no coverage.
How do we keep Sigma rules mapped to ATT&CK technique IDs?
Put the technique and sub-technique IDs in each Sigma rule's tags, using the lowercase attack namespace, for example attack.t1685 for the parent technique. Store the targeted ATT&CK version in the rule's metadata so reviewers know which mapping they are reading. Add a continuous integration check that fails when a rule references an ID that does not exist in the pinned ATT&CK version, and another that flags rules whose referenced data sources are not present in your log pipeline. Review mappings whenever you upgrade ATT&CK, and keep rule titles stable so dashboards and alert history remain comparable over time.
Can our own team run T1685 detection work without an outside partner?
Many teams can build a first version internally if they have log coverage and an owner for detection content. Most of the effort sits in onboarding log sources, tuning rules and writing repeatable test plans, so the question is whether that owner has time and the skills to maintain it. A partner can help where you need extra capacity. DeployOpen plans, implements, customizes and documents self-hosted open-source platforms inside your own infrastructure, and it runs cyber range exercises. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask any provider what they will hand over, including rules, test evidence, runbooks and training for your staff.
What does a cyber range rehearsal for T1685 detection require?
The range needs an isolated network, copies of the agent versions you run in production, a small set of monitored Linux and Windows hosts, and the same log pipeline your SOC uses. Write the expected alerts down before the exercise, including the gap alert. Run only the approved emulation steps inside the range, then measure time to alert, whether the expected events reached the SIEM, and whether analysts followed the response runbook. Record the results as evidence, and repeat the exercise after each detection change or ATT&CK version update so you can see what moved.
How DeployOpen builds T1685 detections and range exercises
Every T1685 build starts with a fixed-scope plan that is agreed in writing before any work begins. The first decision is which of the technique's 7 sub-techniques apply to the platforms the client actually runs, such as containers, ESXi hosts, IaaS control planes, Linux servers and any other in-scope platforms. The plan then checks where command execution, process creation and Windows registry key modification events are already collected and where they are missing. It also tests two ATT&CK mitigations, Audit and User Account Management: whether audit logging is enabled on each platform, and who can change security agents, logging configuration and tool settings. Each gap becomes a named decision for the client, such as which Wazuh agent deployment or log pipeline will carry the events and how long they are retained.
The build then moves into a private cyber range hosted in the client's environment or an isolated lab. The range mirrors the agreed platforms and runs the same self-hosted open-source tooling the production team uses, so detections are tested against the telemetry they will receive. DeployOpen and the client's security engineers run purple team exercises together. For each in-scope sub-technique, the team plans test cases, runs them under a written rules-of-engagement document, and checks whether the expected events arrive and whether the Sigma or Wazuh rules fire. Each result is recorded as detected, partially detected or missed, along with the tuning change that followed. Because the exercise is rehearsed end to end, the response runbook is tested at the same time.
The deliverable is a mapping document that names ATT&CK 20.0 as the target version and records the technique and sub-technique IDs used. For each detection, it lists the data components, log source, rule identifier, owner and known gaps. Coverage must be re-checked whenever MITRE publishes a new version, because ATT&CK releases can rename, deprecate or revoke techniques. DeployOpen prepares this evidence for compliance readiness, but it does not issue audit reports or certifications. Before the exercise, the client should ask its independent auditor which evidence format and sampling approach they expect. Ongoing tuning and periodic re-testing can be scoped as a retainer after the initial build.
