Technique T1089
Disabling Security Tools
The increased prevalence of adversaries Disabling Security Tools is attributable to specific and highly prevalent threats such as Emotet and TrickBot.
Editors’ note: While the analysis and detection opportunities remain applicable, MITRE has depreciated this technique and this page has not been updated since 2020.
Analysis
Why do adversaries Disable Security Tools?
Adversaries disable or tamper with security tools to enable activities that would otherwise be prevented, to avoid detection, or both. In some cases, tools must be disabled in order to gain initial access to a system. In other cases, they may be disabled to facilitate one or many additional tactics throughout the lifecycle of the intrusion. The security tools that adversaries seek and disable, and the manner in which those tools are affected, vary widely.
How do adversaries Disable Security Tools?
This technique is broad and can be used to capture the intent of many other techniques within the Defense Evasion tactic. As a result, the methods employed by adversaries are not always predictable. The targets of tampering are numerous but commonly include:
- Endpoint protection suites
- 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 endpoint protection (antivirus) or host-based firewalls. This may be done via software or by an operator.
TrickBot and Emotet are two highly prevalent trojans that include a number of features aimed at detecting and disabling Microsoft Windows Defender and Defender ATP, among other endpoint protection suites, rendering these endpoint protection products ineffective through changes to the registry or by leveraging built-in system management utilities, such as PowerShell. Similarly, Carbanak, NanoCore, and countless others will disable or modify local firewalls to ensure that communications are not impeded.
Emerging tactics
More subtle but potentially much more damaging techniques—such as AMSI bypasses and selective tampering of EDR, logging mechanisms, and other low-level controls—are more prevalent in community research than they are in the wild. That said, we do know that they are being leveraged by adversaries. Evidence of this includes the use of tools such as fltMC.exe (a Windows system utility being used to unload minifilter drivers that are often a key pillar of data collection for antivirus), data loss prevention, and other monitoring tools on Windows systems.
Lastly, the two classes of attack that are common among almost all controls are prevention or deletion of local logging and the use of a wide variety of configuration changes that may result in local logs not being submitted to a central data collector, such as a SIEM. Like this technique and others related to this tactic, these classes of attack may be used to affect all logging or log collection, or they may be targeted at collection of only certain event types that the adversary knows to be of concern.
Sighted with
- Masquerading (T1036), for evasion
- Scheduled Task (T1053), likely used as a persistence mechanism to shield execution
- Process Injection (T1055,) useful for unhooking security tools from malicious processes and hiding malicious code within legitimate processes to shield execution
Definition
Detection
MITRE’s data sources
- API monitoring
- File monitoring
- Services
- Windows Registry
- Process command-line parameters
- Antivirus
Collection requirements
Defense evasion techniques are generally non-specific with respect to the types of systems or data that you are trying to protect. Thus, any security tool that produces defensive telemetry—to include event logs or alerts, or logs of the tool’s state and configuration—will be immensely valuable when building detection criteria.
Process monitoring
One data source that we recommend adding is process monitoring, as the presence of running processes or actions taken to stop a running process are both valuable data points.
File monitoring and Windows Registry
File monitoring and Windows Registry will be most useful in determining whether a tool is running or its startup configuration has been changed. Returning to TrickBot as a relevant example, most of the evasions that this tool puts in place will result in a change to relevant data in one of these two locations.
Process command-line parameters
Similarly, monitoring for process command-line parameters will often reveal the act of making these changes, while services will reveal a common result.
Detection suggestions
Detection of this technique can be abstracted into two categories: detection of overt or otherwise known forms of tampering and identification of new techniques.
Detection of overt or known forms of tampering can be effective when you understand how your security tools are deployed, configured, and operated. A simple checklist that you can use to build basic detection use cases might look like this:
- What process is used to install the software, and what changes are made to the system? Understanding the install file structure itself, the name and appearance of the process that executes the installer, and the files and/or Registry changes (“configurations”) that the installer makes is a good baseline.
- Do configurations change under normal circumstances? If so, how do specific configurations change, and under what process and user context do these changes appear?
- What are the process and service names associated with the software? Monitor for use of process and service controls (start, stop, add, remove, change) related to these items, which will vary by platform.
- What other processes will interact with the software? On Windows, monitor for cross-process events, such as injection or thread manipulation.
More advanced techniques can be a challenge, as they rely on detailed knowledge of the software, require that you detect the absence of data, or both.
Like all software, security software contains bugs. Some of those bugs introduce vulnerabilities that can be exploited. Understanding the resources—DLLs, drivers, shared objects, and other kernel-level extensions—required or loaded by the software can help build additional monitoring use cases. Unless the software is intentionally changed, the resources leveraged by the software should not change, be replaced, or appear in new locations.
Lastly, look out for tampering in the absence of any overt behavior. If your EDR platform emits a median of 10 events per endpoint per second, and that drops to five: is there a predictable cause? Would you even notice? Could you practically investigate? Apply this same logic to the presence or contents of log files.
Detecting anything other than the complete absence of data is a challenge for most organizations. Start by keeping it simple and move towards the complex:
- Detect the complete absence of data from a given control
- Detect the absence of a particular data element (e.g., a heartbeat or regularly occurring value)
- Detect the absence of a type of data (e.g., the absence of file modification events when all other events appear as expected)
- Detect on deviations from median event rate
Testing
Start testing your defenses against Disabling Security 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 T1089: Disabling Security Tools. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using PowerShell:
Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender"
-Name DisableAntiSpyware -Value 1
Useful telemetry will include:
Data source | Telemetry |
---|---|
Data source: Process monitoring | Telemetry: powershell.exe |
Data source: Registry modifications | Telemetry: PowerShell manipulating Windows Defender operation |
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.