DNS as Facilitator – A Naïve Resolver for Malware

This blog is the second in a four-part series, 3 Personas of DNS in Cyber Security

Hackers are resourceful. They know that helpful DNS will always work to naively return an IP address when queried. DNS exists to connect clients to backend services by acting as the internet’s phone book. If you’re in the business of spreading malware, DNS may be your best tool.

In fact, the more inventive cyber hackers leverage DNS in different ways for specific kinds of breaches, like planting ransomware, launching botnet command and control offensives or setting the bait for phishing scams. All use DNS as a naïve resolver, just doing its job.

In a DNS query, applications may return one or many IP addresses. This is common for cloud-scale applications distributed globally, or may simply offer alternate IP addresses based on the health or availability of the specific service.

So how do you know if an IP address represents a potential threat?

When DNS resolves a network query, it taps into additional intelligence about the IP address itself, the domain, and the returned answer of the application or service, all shedding light on the level of trust or risk associated with the domain.

This intel, extracted from three sources, plays an important role in identifying potential cyber threats:

1. What is being asked?
2. Who is being asked?
3. What is the Answer?

Let’s have a closer look at the information.

1. What is being asked?

When DNS looks up a domain, it locates the address of the backend of the service. The domain itself contains useful information that informs whether it is a trusted address. Details such as the length of the domain, number of unique characters, the name of the domain itself, all provide helpful clues that inform levels of risk.

2. Who is being asked?

DNS relies on registrars to make domains publicly available – and there is a great deal of information that can be leveraged from the registration to help identify a threat or compromise. The most obvious is whether the domain is known. If a domain exists on a blacklist, for example, it’s easy to know to block that request.

Another consideration: Is the registrar itself a trusted organization? Many have great reputations, while others seem to exist to facilitate malicious cyber behavior. Based on these clues, a reasonable threat assessment can be made.

Information collected at the time of registration also provides risk insight:

• Is the domain registered to an individual or a corporation?
• Is it registered anonymously?
• What is the physical address associated with the registrant?
• What is the address of the DNS server?

3. What is the answer?

What is the IP address that is returned? There is important threat assessment data to glean here. In the query answer, we may identify whether that IP address is associated with other malware.

Is the IP address of the domain changing often? Trusted services do have IP addresses that change, like Salesforce or Office 365, but they legitimately fluctuate because these applications are built to be highly scalable and distributed. Suspicions rise when IP addresses change too often.

To add more complexity, there is the fact that the DNS server itself has an IP address. If that moves, it is odd, and may be evidence of someone trying to keep the DNS server mobile to prevent it from being shut down or blocked.

The irony of DNS in malware

If a client is compromised, and the case is that malware is exfiltrating data, that data must go somewhere. That somewhere, in many cases, will be distributed locations around the world. Ironically, malware engineers need to make sure their backends are distributed to create resilience and scalability, and to avoid a single point of failure. The bad guys don’t want their servers to go down, either!

Many, many thousands of new domains are created every day. It is unclear what the backend service is or if it even exists in these new domains. The perfect time to do a risk assessment is at the time of that initial query.

What is being asked, who is asking, and what the actual answer is, all provide useful information for us to assess. If we don’t know definitively whether a query can be trusted, we have tools to understand whether it’s good or bad – and whether it should be blocked. Depending on the risk tolerance of an enterprise, that gauge can be set higher or lower.

Threat intelligence is critical for DNS security. What we know, we can block. Leveraging all information available during a query is vital to quickly assess whether a domain is good or bad – and that’s good security practice.