MITRE’s data sources
- API monitoring
- File monitoring
- Windows Registry
- Process command-line parameters
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.
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 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