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.


Heading into the cloud?

See how your network can thrive in the complexity of the cloud.

Find answers to all your cloud-related questions.

Access cloud resources

Read more

Everything you need to know about shadow IT

When users implement their own solutions behind the IT team’s back, that’s shadow IT. Learn about the risks and how to manage and reduce it with BlueCat.

Read more
Five network pros’ manual error horror stories

Members of BlueCat’s Network VIP community detail the errors they committed, the resulting fallout, and what important lessons they learned.

Read more
10 best Ansible modules for infrastructure as code

10 (plus a bonus) Ansible automation modules that anyone—from a beginner to a power user—can leverage to transform their network infrastructure to code.

Read more
How an agency IT chief innovated amid bureaucracy

Government IT innovation isn’t easy, but Chad Sheridan did it at the USDA by removing silos, earning top-level buy-in, and moving to a product mindset.

Read more