This article was co-authored by Gary Katz and Jason Deyalsingh
In the prior article, we examined how Visibility, Detections, the Environment, and Threat Intelligence can each serve as starting points for identifying new detection opportunities, as well as how they can be used to filter and prioritize the detections worth pursuing. Having identified an opportunity, the next question is how best to detect it. This follow-on article delineates the different detection capabilities available to detection engineers, providing a framework for evaluating which technique is most appropriate for a given activity. There is no clear-cut answer. Different detection techniques require different types of data and levels of effort, while offering different tradeoffs in robustness, coverage, and complexity.
Bianco’s Pyramid of Pain primarily focuses on atomic indicators and signatures, but today’s detection engineering discipline encompasses a much wider range of techniques for identifying malicious activity. The goal of this article is not to provide in-depth instruction on any one technique, but rather to provide detection engineers with an overview of the tools available in their toolbox, along with their strengths, limitations, and data requirements. By understanding the options available, detection engineers can make more informed decisions about which tool is best suited to the task at hand, rather than defaulting to the approach they know best. This article is also not specifically about the use of GenAI. While GenAI can support detection engineering at multiple points in the process, it does not fundamentally change the process itself; rather, it changes how that process can be implemented.
We will start by grouping detections efforts into two categories:
- Malicious Activity: What have we seen the adversary previously do which might be applicable to our organization?
- Unexpected Activity: What should our systems or software be doing and what would be deemed unusual and potentially malicious
These categories can be further divided into separate types of detections or activities, each of which require varying levels of effort and resources. Below we will introduce these types and identify their advantages and limitations. Then we will provide a mapping between the detection types and what source data is usually the impetus for creating them.
Malicious Activity:
Tool-Based Detections:
These are detections usually based upon a malware signature, or network signature. These detections are mostly divorced from the procedure the adversary is performing and instead focus on the bespoke tool used by the adversary. While still important, they become less effective as adversaries have migrated more to living off the land and AI reduces the cost for building unique capabilities.
Limitations:
- Less effective in identifying living-off-the-land activities since no malicious tool is required.
- Adversary can bypass signature-based detections by changing the code upon which the signature is based.
Procedure-Instance Detections:
We will add a layer between tool-based detections and procedure-based detections called procedure-instance detections. These detections focus on the procedure we observed the adversary perform. While tool-based detections identify the tool itself, the procedure-based detection identifies the action taken. This allows us to include adversaries using non-malicious tools for malicious purposes within this type of detection.
Limitations:
- The adversary can alter their activity to perform a variation of the observed instance and thus avoid the detection while achieving a similar goal.
Precondition and Postcondition Detections:
In some circumstances, it can be easier to identify the preconditions or the postconditions to procedure rather than the procedure itself. For example, there may be multiple ways to update the Windows Registry Run key, HKCU\Software\Microsoft\Windows\CurrentVersion\Run as a persistence mechanism but rather than identifying the actual procedure of updating the key, we can instead monitor Sysmon Registry Events (Events 12, 13, and 14), which capture registry object creation/deletion, registry value changes, and registry key/value renames.
While detecting the preconditions or postconditions can allow us to detect multiple procedures achieving the same objective, we still need to examine whether other procedure could avoid these conditions. In the example above we identified by the postcondition any procedure an adversary would take to change the Windows Registry Run key for persistence, but a similar could be achieved without generating a RegistryEvent by simply replacing an existing executable referenced by a Windows Registry Run key.
Limitations:
- It may be possible for the adversary to avoid the expected pre or post condition.
- The pre or post conditions may not be well defined or observable
Behavior-Based Detections:
These detections identify behaviors or patterns of activity associated with adversary activity. The individual behaviors may not be inherently malicious or may not be required to perform the malicious activity, but when considered in the aggregate, they can provide a valuable indication of malicious activity. These detections may look for specific actions performed in a specific order or could identify when an aggregate of micro-behaviors cross a threshold.
Limitations:
- If the detection is not flexible, the adversary could alter a portion of the behavior, resulting in the false-negative.
- Changes in the timing or ordering of the activity could result in a false-negative
- The activity may occur across multiple systems, resulting in issues correlating telemetry across these devices.
AI Categorization:
We’re going to lump all AI/ML methods of characterization together here. Whether we are using a neural net or an LLM, we are still using some type of artificial intelligence to categorize the activity as malicious or non-malicious. This approach can result in a detection capability identifying a wider type of activity. For example, a signature-based approach can identify a single type of malware (or malware capability), while an ML based approach can identify a wide variety of malware variants using a classification approach.
Limitations:
- Traditional ML approaches can require significant expertise, large amounts of training data and time to build and tune.
- Traditional ML approaches may provide a categorization without explainability
- LLM based approaches can have larger costs or response times
- LLM based approaches may not be deterministic, creating quality and testing issues
Procedure-Based Detections:
These detections identify the underlying steps that the adversary must take to achieve their objective. When deployed at the endpoint they usually require an understanding of the system API calls executed by any tools or scripts implementing the procedure. The tired-labs repository mentioned in the previous segment contains detection strategies for building these types of detections. While procedure-based detections are usually the most robust, they cannot always be achieved. Especially when there is an overlap between the procedure being used for malicious or non-malicious purposes. Consider one of the most prevalent initial access techniques, phishing. There is no procedure-based detection for phishing because the actions taken, clicking on a link or downloading a file, etc. overlap with legitimate user activity.
Limitations:
- Usually require in-depth analysis to identify the underlying procedures performed by malicious tools
- Not all techniques have a limited number of procedures which can be used to generate a robust detection
- Logging may not exist to identify the chokepoint of the malicious procedure, even if it is well understood.
The below diagram provides a more nuanced view of the top section Bianco’s pyramid. These delineations are made against the general detection types which is useful when determining which detection type to utilize for a task. CTID provides an approach for evaluating the robustness of individual detections.
Unexpected Activity:
In addition to detecting malicious activity, we can take a converse approach in identifying unexpected activity. This did not fit neatly into the above diagram, and thus was broken out separately. Anomaly detection starts with a baseline, which defines what expected activity looks like allowing us to alert when deviations from that baseline occur. Since anomaly detection is mostly divorced from how the adversary performed an activity, it can detect a wide variety of procedures or tools, including unknown ones. This is a core approach for identifying insider threat activity and has significant appeal as genAI lowers the cost for building new tooling or identifying new vulnerabilities.
The approach does not come without limitations or downsides. Consider the word ‘mostly’, used above. In a simple example, anomaly detection could be used to identify exfiltration by looking for higher than normal outbound traffic. This would identify exfil irrespective of the C2 protocol, but would miss adversaries with the tradecraft to move low volume and slow, or miss those using email or other approaches for their exfil.
In addition, simply because something is an anomaly, does not necessarily mean it is malicious. This can result in higher false positive rates and higher investigation times since there is little explanation for why the anomaly occurred.
Limitations:
- Requires baselining normal activity to identify anomalous activity
- Higher false positive rate
- Limited explainability
Policy Violations
Each company has their own definition of how it should operate technology. Policies are governance artifacts that attempt to guide how users interact with the technical environment. Typically a policy that prohibits certain activity indicates some constraint that makes it infeasible or impossible to implement a preventative control for that activity. Threat actors, unlike internal employees, are not familiarized with internal company policies, and frequently cross these invisible governance boundaries. Designing detections around policy breaches can not only surface employees who might be using systems incorrectly, but also help identify malicious activity.
Consider a fairly trivial example where you want to prevent users from cloning internal repositories from unmanaged devices. This can be difficult to control from a technical standpoint (blocking the clone operation might be unfeasible). A policy can be designed to formally prohibit the activity, but recording clone operations, as well as the source systems can be used to develop detections to alert relevant teams of policy breaches, some of which may be related to threat actor activity.
Limitations:
- May require additional research to distinguish between internal user and malicious actor violating policy
Configuration Changes
When designing detections, you will encounter preventative controls that seem to eliminate the need for detective controls:
— Users cannot upload files to file sharing sites because those are blocked at the proxy.
— standard user workstations cannot RDP to domain controllers because it is blocked at the firewall
— the local anti-virus will block any malware from being executed.
It is not uncommon for threat actors, with the right valid credentials, to manipulate preventative controls which might obstruct their operation. Blocklists are modified, firewall configurations are changed, and security tools are impaired or disabled entirely. With this in mind, it is reasonable to develop detection strategies around changes to critical configurations, specifically the changes that might relax the preventative controls within the environment.
Limitations:
- Requires deconfliction with legitimate configuration changes
It is easy to get tunnel vision when creating detections day in and day out. Taking a step back and evaluating what you want to detection, as defined in our previous article, is a good first step. Identifying which detection approach to use can be equally important. Just like adversaries can be prone to reusing tools and capabilities to attack, defenders can equally find themselves returning to the same detection approach as a solution. Each approach though has their strengths and their limitations. The above breakdown provides a reference for choosing the right approach for the task, rather than falling back on familiar habits.
This is the follow on article to Where do Detection Ideas Come From
Choosing the Right Detection Approach was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: https://detect.fyi/choosing-the-right-detection-approach-b72a2bac69ff?source=rss----d5fd8f494f6a---4