DNS is a critical protocol for the success of security operations. It contains valuable indicators that identify malicious activity such as malware command and control, data exfiltration points, crypto-jacking, ransomware, and Trojans/rootkits. As data analytics, machine learning, and data processing power continues to improve, the value of DNS continues increase despite the fact it is an old protocol.
DNS operates in plain text, there is no encryption or encoding. While this may be a bit disconcerting the privacy conscience, it is supremely helpful in security operations as correlation with more IP based and endpoint focused alerts and analytics are relatively intuitive. Integrating DNS logs in the SOC and building use cases and analytics around it increases the accuracy and fidelity of your SOC findings, decreases false positives, and decreases the number of alerts generated (particularly if the SOC moves from an IP to a DNS focus).
Improving Security Operations
Among the largest challenges in SOC’s is the inundation of alerts that are generated. SOC’s across the globe are moving towards automating tier-1 analysis functions by building analytics that can prioritize alerts and move the most important ones to the top. This is an area, for example, that Security On-Demand does very well through our ABCD methodology and advanced correlation engine. However, there are still thousands of alerts per day and when you are dealing with hundreds or even thousands of customers as a managed service even the most effective automated triage and prioritization technology will still generate a lot of noise.
Focus on DNS is not a standalone solution to this problem but it can decrease both the number of alerts the SOC is generating and the number of false positives. The largest perpetrator of alert generation is IP reputation alerting. There are hundreds of both free and paid services that provide anyone with non-contextual lists of bad IP addresses. The problem with IP address lists is that they do not stay valid very long and not all bad IPs are created equal; some may simply send spam email other may be tied to ransomware. Without thorough and effective threat intelligence (which is either costly to set up right away or takes a long time to develop), it is almost impossible to tell the difference. Thus, when you are inundated with IP Reputation based alerts, the natural inclination is to just ignore them unless they correlate with other alerts such as firewall, IDS/IPS, etc.
Moving from an IP reputation to a DNS reputation focus is valuable because in most cases – with one significant notable exception we will address below – domain names remain valid for much longer than IP addresses. Threat intelligence around the domain name is still important for context though.
When an alert fires based simply on communicating with a bad domain name (especially if it is outbound communication), it is much easier to validate that it is indeed bad than an IP address. Many IP addresses tagged as malicious are large domain hosts. A single IP address may have a hundred-thousand domains pointing to it, 95% of which are perfectly legitimate and safe. Without DNS how are you supposed to know if the IP activity you are seeing is bad?
Thus, moving to a DNS focus and away from an IP focus both increases the fidelity of the alert in that usually a domain that is bad is always bad. It will also decrease the false-positive alerts generated from all the communications on your network with those large domain providers. Simply decreasing the number of IP reputation databases you rely on and increasing the DNS reputation lists is a wise strategy.
Nevertheless, reliance on reputation lists alone are insufficient. DNS reputation alerts can and will generate more false-positives than you want. So employing DNS Use-cases is critical to maximizing your detection of malicious activity. Here are just a few use case ideas (and when it comes to DNS use cases you are really only limited by your imagination and the resources you have to build the more advanced ones).
This is the exception I referenced above, fast-flux domains are domains that rapidly change names in order to avoid blocks and detection. If you see communications in a single session or
series of sessions in a given period of time that are quickly changing, this may be indicative of malicious activity.
Use of Newly Created Domain
There are services and lists out there that can update your system with domains that have been registered in the last hour, day, week, or month – however recent you need. If a system on your network is communicating with a domain name that has just recently been created, it should be looked into. The newer the domain the higher likelihood it is that something nefarious is going on.
Random Character Domain Names
Similar to the previous use cases, some hackers use an algorithm to create and register domain names. They are not particularly worried about what the domain is actually titled. So you may see something like “dkei3989938dkke.tv” and there is really no legitimate reason as to why any system – especially user – should be communicating with such a domain. Any such communication should be investigated.
Outbound regular communication for a bad or suspicious domain
This is essentially a malware beaconing use case in which malware that successfully compromised a device calls home regularly until the command and control point sends back information. If you see outbound communication to a bad domain name – especially if it is occur in relative regular intervals – it should be investigated.
Domain Resolving to Loopback
While an attack is in planning or in progress, often hackers will not assign a domain an IP address or is purposely spoofed to return a loopback (127.0.0.1) IP address. If a DNS request comes back with a loopback IP for an unknown domain name, it is highly suspicious. Additionally, if you see a domain that was resolving to loopback and then resolves to a legitimate IP addresses, it is a sign that further exploitation may be imminent.
Uncommon Domain Names
It is rare that any system or user (especially) in your enterprise is going to communicate with a second-level domain that is not in the top 50,000 most common in the world. Therefore, this is a good indicator of suspicious activity and should be reviewed. There is a high propensity for false-positives, so it may be wiser – as we do at Security On-Demand – to require that this alert correlate with other DNS or activity alerts.
Most of the above examples are pretty simple and basic. There is a lot of more advanced rules you can build or analytics that you can implement that will dive deeper into the DNS data and provide even stronger high-fidelity alerts. Making a move to a DNS focus and away from an IP focus will be well worth the time and effort to get you there.