DNS as Facilitator – A Naïve Resolver for Malware

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…

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.


Critical conversations on critical infrastructure

Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.

Join the conversation

Read more

SUNBURST/Solorigate Situation Briefing

BlueCat leaders discuss how the malware attack via SolarWind’s Orion platform exploited DNS and how BlueCat Edge could have helped to detect it.

Read more
React faster at the wire with BlueCat and ExtraHop

With the BlueCat ExtraHop Plugin, automatically create missing PTR records, and detect and react to security threats before they reach DNS servers.

Read more
Yes, IT should see what developers do in the cloud

Errors and outages occur when admins lack visibility into DNS and IP allocation in the cloud. With Bluecat, central DDI visibility is within reach.

Read more
Why McMaster University didn’t want another CIO

McMaster’s CTO, Gayleen Gray, highlights the importance of her unique role in a world where expectations of the CIO and CTO are colliding.

Read more