In all practicality, threat hunting is hard. Either you don’t have data you need, or you have too much data with little or no resources to work with it. However, DNS is one of the best indicators for a wide range of threat activity that could impact your network. DNS also generates a huge amount of data. So how do you start working with it?
DNS is one of the best indicators for a wide range of threat activity that could impact your network
I’m not going to talk about math, or scripting, or AI and decision trees, or periodicity of beaconing and domain generation algorithms. There are tons of resources on the web to work with these concepts using DNS data to find threats. Let's go ahead and strip this all back and simplify it.
What is the goal of threat hunting? To find adversary activity in the most expedited way possible.
When you view the gigantic amount of DNS requests generated in an environment, it seems insurmountable. Referring back to Threat Hunting 101, segmentation saves the day when it comes to identifying what is normal and what isn’t.
What is the goal of threat hunting? To find adversary activity in the most expedited way possible.
Quick and easy wins
SecurityCenter Continuous View™ (SecurityCenter CV™) includes several tools that enable you to programmatically filter through your DNS information and automatically pull out useful, actionable information right away. This quickly enables you to show results from threat hunting activities and ultimately justify the time you spend working on it.
If you have SecurityCenter CV in your environment, its network sensors are already at work passively capturing DNS requests off the wire without having to enable any logging on the DNS server itself.
#1 - Known bad communications
A quick win when beginning to work with communications is to apply threat intelligence of known bad external hosts. In SecurityCenter CV, this is included as the Threatlist event type. External threat intelligence is compared against all of the hosts involved in communications both inbound and outbound from your organization. This runs by default, against all types of communications, including DNS. Communications to hosts that are known to be infected with malware, or botnet controllers, are highly reliable to determine if a threat is active on your network. It’s not technically hunting, but it gets results and can weed out the really low hanging threats already impacting you.
#2 - Suspicious event patterns
Isolating known patterns of actions that are likely malicious is also essential to detecting them. As stated in Verizon’s 2016 Data Breach Investigations Report, most attacks that result in breaches have a fairly well defined pattern:
Unfortunately, the simplest point of access into a network is often the humans who run it. Tenable includes pre-built logic to find these kinds patterns of suspicious activity in the Indicator event type. These run on a cumulative scale from 1-20 based on the number of suspicious actions in the event chain. Using events not commonly monitored such as statistical anomalies in communications, DNS errors, authentication attempts, and other activities, we tie these together and send up indicator events for review. You can find more information about how they work in our Discussion Forum. They’re a great place to start catching adversary actions on your networks:
#3 - Vulnerable DNS configurations
Stating the obvious, vulnerabilities in your DNS configurations make it substantially easier for attackers to slip in unnoticed. Some of the configurations that should be addressed before moving forward should be:
- Ensuring that DNS servers are defined in your environment. In Windows environments, domain controllers will always be the default DNS servers for their clients. If you don’t want that to be the case, architect a tiered DNS service where your domain controllers aren’t actively querying name servers on the internet. The fewer servers talking on the internet, the better.
- Restricting zone transfers. If you don’t want someone to extract your internal network names, don’t allow your internal DNS servers to perform zone transfers. +1 for a tiered model where your internal name servers simply don’t talk to the internet.
Address other vulnerabilities as pertinent to your environment. It comes down to knowing what the DNS servers are, and making sure they’re configured in as secure a manner as possible.
Stay tuned to the Tenable blog for more tips on hunting threats in your environment with SecurityCenter Continuous View.
For more information on threat hunting with Tenable, check out these other resources: