Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2022.

Why do adversaries disable or modify tools?

Adversaries disable or modify security tools to evade preventive, detective, and other security controls. One tool might stand in the way of initial access, hindering an adversary early on, while another blocks exfiltration later on. In these cases and countless others, adversaries often choose to disable, uninstall, or kill the process associated with a given security control, thereby subverting it.

How do adversaries disable or modify tools?

This technique is broad, and adversaries target many different tools in many different ways. Targets of tampering are numerous but include the following kinds of security products:

• Antivirus
• Host-based firewalls
• Endpoint detection and response (EDR)
• Virtual private networking (VPN) configurations
• Platform security interfaces, such as the Antimalware Scan Interface (AMSI) on Windows
• Logging mechanisms
• Security-related kernel extensions

The most commonly observed techniques include disabling local security controls, such as antivirus or host-based firewalls. This may be done via software or manually by an adversary in an interactive shell or other session. To that point, we detect adversaries leveraging PowerShell cmdlets—specifically Set-MpPreferenece and Add-MpPreference—to disable components of Microsoft Defender Antivirus or stop it from scanning certain files and paths. We also commonly detect adversaries leveraging the MpCmdRun utility (mpcmdrun.exe) to remove definitions and evade signature-based antimalware controls.

Some other creative methods include:

• An adversary could identify DNS names or relevant IP information of a security tool or service and then use firewall rules to block outbound connections to the tool or service or to modify the host’s file to point the domain to localhost.
• A sufficiently privileged adversary can simply terminate services associated with a tool altogether.
• A sufficiently privileged adversary can modify service configurations for relevant tooling.
• An adversary can delete the service registry keys associated with a given tool.
• An adversary can also simply uninstall the security tool in question.
• A sufficiently permissioned adversary could potentially write bogus event log entries or prevent logs from receiving events.
• For certain security tools, it’s possible that an adversary could delete certain relevant files and diminish the efficacy of or render a tool altogether useless.

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Visibility into disabled or modified tools can be tricky, especially when the tools that offer you visibility are also the tools that an adversary seeks to modify or disable. Beyond that, and unlike most other techniques listed in this report, observing a disabled tool may be akin to looking for the absence of something. That said, redundancy is your friend (we’ll explore many overlapping tools and log sources in the collection section) and the act of disabling or modifying the tool is often revealed in numerous different data sources.

Process monitoring

An adversary with sufficient permissions will have many native executables capable of manipulating security tools at their disposal. We mentioned PowerShell and the MpCmdRun utility in the analysis section above. If an adversary is running either of these binaries (or any number of others), you should be able to collect a record of that process execution. Further, some telemetry sources will offer visibility into process termination events as well, which will help defenders identify instances where an adversary has killed a relevant security process.

Command monitoring

It’s almost always the case that an adversary must issue some kind of command in order to effectively disable or modify a security tool. In one of the PowerShell examples mentioned earlier, adversaries use the Set-MpPreference cmdlet to turn off various functions of Windows Defender.

File monitoring

File monitoring offers a reliable way to determine if an adversary has manipulated the configuration file—or simply added a new configuration file—for a particular security tool.

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

As we noted earlier, redundancy is your friend when it comes to monitoring for tool manipulation or disablement. If you’re reliant on Sysmon for visibility and an adversary revises your Sysmon configuration to evade it, then it’s good to have a backup plan in the form of Windows Event Logs or some other tool to observe the adversary’s behavior.

Endpoint Detection and Response (EDR)

Commercial EDR products provide a rich array of telemetry that can be used to observe, detect, and even prevent tool disablement. As an example, we commonly leverage EDR tooling to gain visibility into adversaries who are attempting to disable antivirus or other endpoint security controls. Unfortunately, we also observe adversaries attempting to kill EDR processes in order to evade analysis.

Windows Security Event ID 4688: A new process has been created

Insofar as you can track tool modification and disablement via process creation and command execution, Windows Security Event ID 4688 offers visibility into both, assuming you’ve configured it to capture command lines.

Sysmon Event ID 1: Process creation

Again, if the adversary is leveraging a process to disable a tool, then anything that logs Process creation is going to offer value—and Sysmon Event ID 1 does just that.

Sysmon Event ID 5: Process terminated

As disabling a tool commonly involves an adversary actively terminating processes, tracking process termination events may offer important visibility into adversaries as they disable security tools. Sysmon Event ID 5, depending on how you configure it, will capture a record of every process termination.

Sysmon Event ID 11: FileCreate

Sysmon Event ID 11 tracks whenever a file is created or overwritten, offering defenders a way of keeping track of configuration files for certain security tools. That said, configuring this properly—and, in particular, setting the right exclusions—is crucial, as tracking file creation events can get extremely noisy.

Sysmon Event ID 16: ServiceConfigurationChange

Sysmon Event ID 16 tracks changes to your Sysmon configuration, and will create a record anytime anyone modifies your Sysmon configuration.

How an organization goes about detecting the disablement or modification of security tools depends on the tools they’re running and the optics they have available to them. For the purposes of this report, we’ll assume you’re running some kind of EDR solution, and we’ll focus on just a few prolific behaviors that affect extremely prevalent tools.

Abusing PowerShell to disable Defender components

One of the most common patterns of behaviors we’ve observed involves adversaries leveraging PowerShell’s Set-MpPreference cmdlet to disable components of Windows’s native antivirus software, Defender. The following pseudocode should work to detect this activity, but you may need to consider alternative options in the likely event that an adversary encodes this PowerShell command.

Abusing PowerShell to modify Defender components

Similar to the previous pseudo-detector, sometimes adversaries use the Add-MpPreference cmdlet to add exclusions for certain filetypes to Windows native Defender antivirus, effectively allowing them to load malicious files that would otherwise be blocked.

Start testing your defenses against adversaries who disable or modify tools using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View Atomic tests for T1562.001: Disable or Modify Tools. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using an elevated PowerShell prompt:

Useful telemetry will include: