If you’re tired of reacting to alerts and are looking for ways to get proactive with your security posture, you might be considering threat hunting. Threat hunting is an active form of cyber defense that allows your team to proactively identify abnormal behavior or vulnerabilities and mitigate these before any harm is done.  But how do you know what to hunt for? Knowing where to begin and what to look for can be the greatest challenge; that’s why we’ll be sharing a series of the threat hunting use cases we use, developed and refined over years and across different environments, to help you get started.

What is your mission? 

Think about going to the grocery store with a shopping list as opposed to going in with no list or plan in mind. You probably find that listing out your groceries and grabbing exactly what you need is far more efficient than searching the entire store for “something”. With no goals in mind you may leave the grocery store missing something important that you needed, leave with too much, or even find that you were not in a grocery store the entire time. 

The practice of knowing your mission or defining your objectives is essential for every threat hunt campaign. In our Threat Hunting Use Case Blog Series, we’ll walk through some of the most common and critical threat hunt campaign objectives, covering log source requirements, expected outcomes, and sample analysis per use case.  To kick off the series, we’ll start by covering the common threat hunting use case, “Firewall Targeting DNS.” 

When you decide to start hunting… 

How do we decide what to hunt for? ​How do you identify similar threats or vulnerabilities that can be identified within the same dataset? ​ How do we overcome difficulties with pulling data? Over the years we have developed a methodology to assist with answering these questions. 

When developing a threat hunting use case, we look at tactics mapped to the MITRE ATT&CK framework and associate them to log sources that would output indicators of that attack. As an example for our Firewall Targeting DNS use case, Exfiltration Over Alternative Protocol (T1048) and Exfiltration over a Non-Standard Port (T1571) are mapped to Mitre ATT&CK and would be logged by a firewall. We call these “Threat Analysis” objectives or outcomes for our use case.  

In addition to looking for actual attacks, we are also looking for the hygiene issues or weaknesses in security posture that lead to those attacks. This means we are looking for the active attacks while ensuring that the vulnerabilities that lead to them are patched which would prevent the attacks from occurring in the first place. 

Use Case: Firewall Targeting DNS 

Objective: Direct client access to Internet DNS servers, rather than controlled access through enterprise DNS servers, can expose an organization to unnecessary security risks and system inefficiencies. This hunt involves reviewing DNS traffic captured by firewall logs in order to provide recommendations and findings focused on improving security posture related to outbound DNS queries and responses. 

Log Source & Requirements: Firewall Allow & Firewall Deny from Application/Protocol-aware Firewall logs (Ex. Palo Alto, Cisco ASA, Checkpoint). 

Duration: 30-90 Days 

Related MITRE Techniques: T1048 and T1571 

Outcomes: 

Baseline/Hygiene 

Objective Why?
Baseline normal outbound firewall traffic to better identify abnormalities in your environment (countries/businesses). Slowly learning and understanding what “normal” looks like in your environment will exponentially improve your capabilities to identify “abnormal” when it happens.
Correlate firewall policy rule names with the actions taken (traffic allowed vs traffic blocked) to audit policy strictness and identify any anomalies or deviations. Auditing firewall policy actions will assist with validating if ACL rules need to be more/less strict. For example, if we have a specific policy, “Allow all port 53 traffic,” that allows all traffic over port 53, we should look to add more granularity to that rule to ensure that only truly authorized outbound DNS traffic is allows to/from approved DNS servers and external DNS resolvers (Ex. Open DNS, Google DNS).
Identify approved external DNS resolvers such as OpenDNS and Google DNS to ensure your hosts are not bypassing your internal or Internet-based resolvers. $When internal hosts can use any Internet-hosted DNS server, they expose the organization to potential malicious activity.  Organizations lack control over resolution of Internet-hosted DNS servers.  The end goal is to block port 53 outbound except for Internal DNS servers connecting to authorized external resolvers.

Threat Analysis

Objective Why?
Review uncommon port/protocol usage for anomalies and potential increased risk. Attackers can tunnel data using TCP/53 to exfiltrate data.
Filter on critical hosts for anomalous activity and look for targeted attacks based on your industry (ex. APT groups). Searching for more sophisticated attacks that usually fall outside the scope of static rule logic will assist with identifying active attacks and/or validate that those attacks (TTPs) are not occurring.
Look for firewall traffic to high-risk countries that may be known for cyberattacks or do not regularly communicate with your business operation. Traffic should only be allowed to specific geolocations and IP addresses that serve a legitimate business purpose. All other traffic should be implicitly denied if a geolocation or specific IP addresses from a geolocation do not serve a business purpose.
Hunt for suspicious or unauthorized data exfiltration by looking for large amounts of outbound traffic with high bytes out or long session lengths to suspicious destinations. Tunneling data using 53, which is a common open port on border firewalls exposes the organization to a potential exfiltration using file transfer tools over port 53.
Cross-reference Open Source Intelligence (OSINT) reputations to identify any hosts connecting to potentially malicious IPs. Outbound connections to a threat host can be an indication of active or attempted Command and Control traffic that should be investigated immediately.

ReliaQuest GreyMatter DNS Traffic HuntMake threat hunting a reality at your organization with ReliaQuest GreyMatter.

By aggregating and normalizing your data from disparate tools, such as SIEM, EDR, multi-cloud, and third-party applications, ReliaQuest GreyMatter allows your team to run focused hunt campaigns, both packaged and freeform that are strategic and iterative. Use ReliaQuest GreyMatter to analyze indicators of compromise retrospectively or perform behavior assessments to visualize abnormal from normal activity.

To learn more about building a threat hunting program at your organization, check out our blog, “5 Threat Hunting Guidelines to Transition Your Team From Reactive to Proactive.”  And stay tuned for our next threat hunting use case in the series!