Using a Threat-based Approach for Detections: Understanding Bad Actors

Now let’s take a closer look at each phase of this process.

Discover and Learn Adversary Tradecraft

Security practitioners are continually discovering, learning, and testing new tradecraft. These are the three stages used to learn about adversary behavior as we work towards building detections and providing context and next action: past incident data, threat research, and threat emulation.

Past Incident Data

Start by using valuable data gathered from past investigations to prioritize what is known about our environment and what has been seen firsthand, such as:

• The delivery techniques are our users seeing
• Groups that have been targeted
• Systems and applications that have been hit with and/or fallen victim
• Types of techniques being used

For each investigation, we look at:

• Indicators obtained externally or those we obtained ourselves through analysis
• Scripts, queries, and tools successfully utilized during the investigation
• Methods used for scoping and containment

All of these techniques are extremely valuable to an analyst who is working on an incident that is similar to, or possibly even related to, a past investigation.

Threat Research

In the second phase, it’s time to build on this knowledge using anything we can find about the techniques that could be used against us, such as security blogs, technical reports, and proof of concepts.

One of the best resources available is the MITRE ATT&CK Knowledge Base, a library of known tradecraft with corresponding detections and mitigations. MITRE’s Technique Matrix contains hundreds of techniques categorized by different phases of the adversary lifecycle.

For each technique, resources are provided explaining:

• How it works and how it’s used
• Groups that have used it successfully
• Guidance for developing detections and mitigations for the technique

Threat Emulation

The third phase includes testing our enterprise security posture by using or simulating the techniques we’ve learned, and identifying:

• Gaps in current tools, processes, or configurations
• Analysis tools and techniques that give the best visibility of the technique in use
• How best to scope and contain the threat in the environment if these techniques are being used

This phase is also where detection content is developed, tested and tuned for use in the next phase. Everything learned in these three stages helps develop more accurate detections and determine the most effective actions to take to reduce the overall impact of incidents involving these techniques.

Build High-fidelity Detections

Once techniques have been studied and tested, it’s now time to configure the tools to reliably detect them being used. Here’s how we do that:

Configuring Tools for Detection

The diagram below shows how the four detection types can be used to create detection content for three different tools–Splunk, FireEye HX, and Cisco IDS:

Splunk is used to search through indexed logs and data, FireEye HX monitors endpoints, and Cisco IDS monitors the network. Each tool allows us to provide detection content specific to what we’re looking for. Each time we provide a tool with content, and it detects activity based on that content, it’s called a detection. And every detection falls into one of the four detection types:

• Threat behavioral analytics: Patterns in logs and data resulting from overall tradecraft used.
• Configuration changes: New changes on a system, such as new processes, connections, or protocols.
• Threat indicators: IP addresses, domain names, file hashes, etc., known to be malicious.
• Modeling: Baseline anomalies that stand out from normal activity in the environment.

Each type has its own strengths and weaknesses, so let’s dive into each one.

Threat Behavioral Analytics

These are patterns in data resulting from adversaries doing what they do. A common technique used in phishing attacks is emailing the victim a link to an HTA file which will run a malicious PowerShell command on the victim’s system. The mshta.exe process spawning a powershell.exe process is a unique pattern that indicates that particular technique in use and we can use that pattern to search for every time this happens in our environment.

Here is an example using Splunk:

Configuration Changes

These are new changes that occur in the system. Using the same example, when a malicious powershell.exe process runs, it will most likely attempt to download malicious code from an attacker-owned IP address and run it in memory. The new network connection is a configuration change we can search for across all systems.

We can use the base64-encoded version of the string “IEX ” to look for network connections from powershell.exe processes:

Here is an example using Splunk:

Threat Indicators

These are files and infrastructure known to be associated with malicious activity. In our same example, good indicators would be the URL used to host the HTA file, the IP address used to deliver the malicious code, or a file hash of the HTA file. We can search for or configure our tools to alert each time the hash/ip address/domain is seen in our environment.

Here is an example using Splunk:

Modeling

These are baseline anomalies, events or groups of events not considered normal for the environment. Keeping with our example, when the powershell.exe process runs an implant in memory, this could be used to run a module that attempts to log on to every host discovered on the network. This would create an unusually high number of logon attempts for different hosts which we could search for across our environment.

Here is an example using Splunk:

Building High-Fidelity Detections

High-fidelity detections must be actionable and universal. Actionable means they produce something of value or an activity that we need to respond to. Universal means they catch the full spectrum of the adversary’s skill and effort.

Making Your Detections Actionable

Two or more detection types must be used together in one detection to produce actionable alerts for the analyst. Here are some ways to do this:

• Build in four detection types: then if at least three hit, it fires an alert
• Build in severity: two hits produce a low alert, three hits are medium, and four is high
• Build in detection types in order of their IDC phase:
  • First, the Behavioral detection (Exploitation Phase)
  • Then the Configuration Change detection (Installation)
  • Then the Threat Indicator detection (C2)
  • Finally, the Modeling detection (Actions on Objective)

Each technique will be different, and you’ll need to try different combinations to get the best results. Then it’s time to make sure the detection is universal.

Making Your Detections Universal

We must use the right combinations of detection types to catch the low hanging fruit as well as top tier operators and everything in between. To do this, it’s necessary to understand the difference between the top two types and bottom two types.

Modeling and threat indicators are easily avoidable by a skilled or determined adversary. Most actors know if they create anomalies in the environment, they’re likely to be caught so they’ll try to leverage legitimate programs, utilize approved protocols, and disguise their traffic to look like it originated from a legitimate application.

They also know if they use known malicious files or infrastructure, they’re likely to be caught. Adversaries use VirusTotal too, and if someone is serious about targeting an enterprise they will not use a file or domain that returns 40 hits on VT. They won’t use anything known to be malicious by reputation. Instead, they will use completely unknown tools and infrastructure to avoid detection.

However, configuration changes and threat behavioral analytics are different and almost impossible for the adversary to get around. As an adversary attempts to manipulate and control systems, they will be forced to create configuration changes such as new network connections, new processes, and new events on the system. As they use the various techniques they’ve become accustomed to, they will create observable patterns in logs and data that we can search for with our tools and use to detect them. So, to make our detections universal we should include one or more of these two types.

Here is an example using Splunk:

This simple example below of a Splunk search requires both behavioral detection and configuration detection. Multiple requirements makes it more actionable and including behavioral and configuration changes makes it more universal.

Using Effective Combinations

Many security operation centers (SOCs) don’t make a distinction between the different types of detections or the proper way to use each type, which can be the difference between stopping the adversary at the door and having them embedded in your environment. One of the most common mistakes we see is relying solely on anomalies and indicators which can be misleading at best, and at worst, contaminate every phase of IR.

Relying solely on these two types for detections produces false positives that consume an analyst’s time and prevent them from working actionable alerts. Using only those detections for scoping and containment produces false negatives—that means hosts are checked with the detections and established as clean when they are not. When this happens, the SOC doesn’t have a way to find the adversary on a system and therefore can’t kick them out.

We must understand how each detection type can best be utilized and which combinations work for the specific techniques we’re studying. When we’re confident we can reliably detect the use of these techniques, we then deploy our detections to our tools and wait for a detection to trigger an investigation.

When this happens, analysts have questions that need answers—What does it mean? What is the impact? What do I need to do? At this point, we need the information we’ve acquired to counter the threat into the hands of the analyst so they can quickly and accurately respond.

Provide Threat Context and Next Actions

The impact of an incident largely depends on how quickly and accurately we move from the identification to the containment phase. The goal is to shrink this window by enabling the analyst to respond with maximum speed and accuracy.

We improve speed by having our research, scripts, queries, and response actions staged and ready to provide to the analyst working an incident. This way the analyst doesn’t waste time researching the technique, building the same scripts and queries already built, or trying to determine the best responses for the technique being used.

We improve accuracy by ensuring the correctness and completeness of the information provided to the analyst. The queries, scripts, and response actions have already been tested and verified as the most effective methods to use in our environment. These are developed over days and weeks, not created as the incident unfolds.

We also ensure consistency with this method by providing all analysts with the same resources, scripts, queries, and response actions. All technical documentation and OSINT sources are carefully selected based on their value to an incident responder. When everyone is on the same page using the same resources and analysis techniques, the results stay consistent and are more easily used and understood.

With these improvements in speed and accuracy, the analyst is able to quickly get a clear picture of the incident and is immediately equipped with the most effective actions to take that will reduce its overall impact.

Contact Phoenix Cyber today to learn how to implement this type of threat-based approach to detection in your network.