Thoughts on Host-based Detection Techniques

Introduction

A few weeks ago I released a post that described our methodology for creating behavior-based detections for attack techniques chronicled in the MITRE ATT&CK Matrix. I think the concept of what a “detection” is can mean a lot of different things to a lot of different people. Many would argue that a single “detection” is not sufficient for detecting a specific attack technique all by itself and that a layered approach is more reliable. I think there is value in defining what is meant when we say “detections”. In this post, I want to introduce three different concepts we use to describe detections. I will describe the detection type, provide some pros and cons, and give a couple examples of things that I think fall in each category.

Types of Host-based Detections

At SpecterOps, we like to consider the timespan for which a given detection strategy can be successful. Specifically, we look at a particular detection and identify situations where it can catch the targeted attack technique and where it may miss it. Many times we come to the conclusion that time plays a big factor in determining the success of the detection. Does evidence of this technique stick around for a long period of time? Do we have some sort of logging that keeps track of evidence relating to this activity? These types of questions led us to determine that detections can be broken into three categories: point-in-time, historical, and real-time.

Point-in-time

Overview

A logical starting point in terms of detection is something I refer to as point-in-time detection. I’m defining this detection type as being able to detect an active use of a technique. For example, if an attacker has an agent currently injected into a process, then my DLL Injection detection technique should find it or at least gather information to help find it.

Pros

Point-in-time detection techniques (PIT) provide a simple, low overhead way to search your environment for threats. This technique is also nice for building an understanding of the underlying attack technique. When I look at the MITRE ATT&CK Matrix and decide to investigate detections for Access Token Manipulation (ATT&CK: T1134 — Privilege Escalation/Access Token Manipulation) my first thought is “How can I detect this activity if it were happening right now?” Naturally, this thought process lends itself to PIT. Can we enumerate current access tokens? If so, can we identify when an access token is being abused? Another benefit of this detection type is its independence. There’s little or no need to install another agent on every endpoint. I often have customers tell me that they already have numerous agents deployed and that they don’t want to add any more. PIT, where we sweep the environment, can help address this problem.

Cons

While PIT benefits from its low overhead cost, there are definitely some aspects of this technique that leave you wanting more. First, and possibly most important, is the question of coverage. What happens if the activity that I’m looking for is only present for a small period of time, like we might expect from a Network Connection? Well, if you only scan every 30 minutes and the activity is only active for 30 seconds, then you are very likely to miss it. Some types of artifacts only last while the attacker is actively using them, and then are disposed of immediately after. This factor makes PIT more suitable for activity that is relatively persistent (Persistence Mechanism, User Session Information, Processes). Another “con” PIT faces is the factor of scale. This technique relies on a one-to-many scanning relationship, which get more complicated as networks grow. Personally, I’ve had relatively good success on networks as large as 60,000 endpoints, but it can easily become an engineering challenge. A similar problem to scale is that of coverage. Many organizations use network coverage as a metric, but this technique is only as good as the network and host access it has. This means a system will be missed if it isn’t online during a sweep, if there is network segmentation blocking the scan, or if proper credentials are not used.

Examples

Windows Management Instrumentation (WMI)

PowerShell Remoting

Historic

Overview

Now that we’ve established PIT, the next logical step is to identify if we are tracking this data in some sort of log source, which we refer to as historical detection techniques (HDT). HDT solves the issue we have with ephemeral data by keeping track of this data in a log. For example, if we want to identify malicious use of PowerShell, then we should enable the PowerShell logging options detailed here.

Pros

In our discussion about the cons of point-in-time, we discussed the issue with ephemeral data points. HDT provides a way for us to fill some of those gaps through logging. All operating systems have some sort of built-in logging that can be used to provide context between scans. Windows specifically has a number of standard logged events and also has the ability to add additional event types to provide more information. PowerShell can be used to query Windows Event Logs or Windows Event Forwarding (WEF) can be setup to forward desired events to a central location, like a SIEM, for investigation.

Cons

While HDT fills in some of the inevitable gaps of PIT, it still leaves a bit to be desired. First, event logs don’t cover every possible event type. Additionally, logging without forwarding is innately susceptible to attacker tampering or deletion, which means we must get the logs off the originating system as soon as possible. WEF provides a great option, but requires a bit of setup, making it a difficult option from the perspective of an external party. Additionally, HDT only collects/logs the information that was previously configured and is only as good as how far back the logging goes. If systems are not set to log valuable information then it will not be available for HDT. To maximize the benefit of HDT it is necessary to identify all desired logging activity and enable prior to detection.

Examples

Windows Event Logs

Anti-Virus Logs

Host-Based Firewall Logs

Real-time (Agent Based)

Overview

Lastly, I want to touch on a technique that is becoming more and more popular in the commercial Endpoint Detection and Response (EDR) space, which I call real-time detections techniques (RT). The idea here is to collect data and identify attack techniques as they are happening, in real-time. For example, if you want to use an RT to detect mimikatz credential dumping, you might monitor calls to the OpenProcess API for any process attempting to read from the Local Security Authority Subsystem (lsass.exe) process. I realize that the difference between HDT and RT may seem nuanced, but in my opinion it is worth making. In my mind, RT is characterized by data collected in real time, above and beyond HDT by an endpoint agent.

Pros

RT is typically viewed as the best case scenario because it reports on activity as it is happening with no blind spots. Earlier, we talked about PIT detection techniques and their issue with detecting short-lived network connections or processes. RT solves this issue by persistently monitoring host-based activity.

Cons

On the other hand, RTs usually rely on some sort of agent being in place. Because of this installation requirement, it is quite difficult for me as a contractor to depend on this type of detection. RT implementations must have a carefully planned data management plan to avoid issues like running out of hard drive space or filling up SIEM quotas. Additionally, agent-based detections are vulnerable to being discovered and subsequently tampered with by attackers. For instance, if an attacker identifies that Sysmon is running on a target endpoint, they can take precautions to operate where Sysmon isn’t looking or disable Sysmon altogether. Some EDR agents are even taking attacker-esque precautions, like remaining memory resident or hooking Windows API functions, to avoid being noticed by attackers. Lastly, RT implementations are often not as flexible as the often script-based implementations of PIT techniques, which lend themselves to creating ad-hoc queries and detections.

Examples

API Hooking — Commercial Tools

Event Tracing for Windows — Sysmon or krabsetw

Permanent WMI Event Subscriptions — Uproot

Conclusion

There are many ways to skin the proverbial cat. It’s important to consider all of the different ways to detect an attack technique. The strategy/strategies that you choose should be based on your situation and flexibility. If you are a member of an internal security team, it may be easier to implement real-time detection techniques. If you are a consultant on the other hand, you may be forced to do your best with point-in-time detections. If, for some reason, you cannot use a specific technique, I recommend still going through the exercise of learning how that technique could add to your capabilities. Over time, you may build a case for overcoming whatever obstacles stopped you from using the technique in the first place.