This is the first blogpost of my “Tales from a Threat Hunter” (TfaTH) series. The main goal of the series is to design and construct a threat hunting lab from scratch. The lab is primarily designed to hunt for attack patterns and develop custom detections based on (the emulation of) real-world attacks. Before we move on to building our own threat hunting lab, I first want to acknowledge the necessity of threat hunting in today’s security operations.
Threat hunting is much more than just a buzzword. It serves as an essential alteration in the approach used today, to actively search for ‘evil’ in computer networks. Where the traditional SOC member has a reactive mind-set and awaits for alerts to trigger, the evolved threat hunter is more people-centric, innovative and searches proactively for new threats. He or she is less interested in mastering detection and prevention technology (e.g. SIEM and IPS), instead he or she is reliant on advanced knowledge of adversarial tactics, techniques and procedures (TTPs). In a nutshell, this is the difference between threat hunting and threat detection. Let’s zoom into this:
Threat Detection
Threat detection focuses on identifying and responding to known threats. It basically consists of the following four steps:
Threat detection tools such as IDS/IPS, AV and web proxy solutions can analyze, detect and respond on anomalous activity that is indicative of a threat. These technologies can prevent common malware infections based on known signatures and block connections to known malicious domains. They rely on low-valued indicators that can easily be changed by adversaries (e.g. infrastructure and tool-sets used). Don’t get me wrong here, threat detection tools are still very useful. In fact, threat detection supplements threat hunting. The output from threat hunting exercises can be used to improve the detection capability of automated defense technologies.
Threat Hunting
Threat hunting focuses on identifying detection gaps and unknown threats. The process that I like to use, involves the following five steps:
Let’s look at the process from a different perspective. Threat hunting is all about ‘assume-compromise’ - finding the adversary that already got in - despite the defenses that were put into place. The adversary will not show itself in plain sight, it might even impersonate another user in the environment. You need to come up with theories based on common tactics that adversaries use. A hypothesis can be derived from situational awareness, threat intelligence, adversary emulation or by utilizing attack lifecycle frameworks. My personal favorite is the MITRE ATT&CK Framework, which focuses on post-compromise, threat-agnostic techniques. Hunting for TTPs is invaluable as illustrated by David Bianco’s Pyramid of Pain.
Once you have defined a hypothesis, you can start validating it by looking for evidence that (dis)proves your hypothesis. The hunter will analyze the selected datasets and uses analytical, offensive and/or investigative techniques to search for anomalies. Discovered anomalies can serve as leads to further investigation – what other techniques were used and against which targets? The output can be used to define new hypotheses.
Example hunt
Let’s take a look at an example threat hunting case, by going through each step in the threat hunting process. We will hunt for the behavior of “DCSync” which is a subfeature of Mimikatz. It utilizes the Directory Replication Service (DRS) to ‘impersonate’ a domain controller and retrieves password hashes from the ntds.dit file - the Active Directory database.
| Hunting step | Description |
|---|---|
| Step 1: Choose an adversarial tactic | Credential Access (TA0006) |
| Step 2: Define a hypothesis | Adversaries could initiate a domain replication request to dump credentials of domain user accounts. |
| Step 3: Select required data to validate hypothesis | • Windows Security Event Logging (EventID 4662) • DCE/RPC (DRSUAPI) network traffic |
| Step 4: Apply filters and hunt for anomalies | • Filter valid replication requests between known domain controllers. • Hunt for replication requests from source (e.g. user account) that is NOT a valid domain controller. |
| Step 5: Review results - (dis)prove or refine hypothesis | • Refine - If the volume of the dataset is too high / high amount of results - refine hypothesis by going back to step 2. • Prove - If the hypothesis can be proven with the dataset - gather investigative leads, hunt for those attack patterns and go back to step 2. • Disprove - If the hypothesis still cannot be proven after refinement (e.g. missing certain data attributes), go back to step 2. |
Requirements threat hunting lab
Our threat hunting lab requires indexed metadata from both the endpoint and network perspective. The data must be stored in a system, capable of ingesting and storing large volumes of data, while also enabling support for real-time searches to query the data. In order to get the most of our threat hunting lab, the technology stack (endpoint, network and data store) must generate and retain the following information:
• User creation and authentication events
• Creation and modification of registry items
• Process creation activity
• File (integrity) monitoring
• Persistence entries: AutoRuns
• Command Line and PowerShell activity
• Network connections (e.g. DNS, HTTP and SMB requests)
We covered the fundamentals of threat hunting and gathered data requirements for our threat hunting lab. In part 2 we are going to address the importance of hunting for DNS-based threats.