Passive DNS is the Wrong Way to do Attack Surface Mapping

This post is the seventh of a short series of posts that we have dubbed “Attack Surface Mapping the Wrong Way,” showing the wrong ways that people/companies/vendors attempt to do attack surface mapping. Next up is passive DNS and why it is the wrong way.

Passive DNS only is flawed

A handful of companies provide passive DNS sources, and many companies create their own DNS servers to monitor the DNS traffic of their end-users. This has many benefits regarding identifying malicious traffic, abuse, infractions of generally acceptable use, and general usage of applications. However, it is not the be-all-end-all of ways to identify the entirety of a corporate attack surface.

The problem really stems from the fact that companies do not consistently enforce what DNS server that every employee uses, and not all systems are built/maintained by internal staff.  Let us dig into the two problems.

  • People use their own equipment like laptops and cell phones. This equipment is very often not regulated by corporate technical controls.
  • People change their DNS server to test things or due to DNS outages. Companies will often allow UDP port 53 to route out of their network, so there is nothing preventing this.
  • People have other people do their work for them, and those people do not use DNS that you monitor. This is especially the case with 3rd party agencies that build web applications.
  • People can use a local DNS resolver (like the host’s file, for instance) instead of a remote DNS system. This happens quite often for test/dev/staging type servers, where host headers need to be “spoofed” to elicit the application logic or to prevent SSL/TLS errors in the browser while testing.

That is bad, but it is worse when dealing with a 3rd party passive DNS provider. Most passive DNS sources cannot see your company’s traffic, so they may entirely miss the DNS lookup in question that would alert you to the presence of the asset in question.  If it is an asset that only internal employees ever visit yet publicly accessible, the chances of a passive DNS provider finding it is lower unless your employees happen to traverse a network that is monitored.

Also, if the site never does get traffic, but the asset, service, and DNS entry all exist, does that mean that the asset shouldn’t be monitored and tracked? Of course not.  But if a passive DNS source is all you use to identify your assets, you will surely miss such sites, which can and do occur quite often. The last issue is that IP is not DNS, and if the user is contacting something by way of IP address versus DNS, a DNS server will only see the in-arpa lookup at best.  Therefore, for IP-based traffic, passive DNS is not of much value.

I said all that to back into what I really think: passive DNS, while not comprehensive, is an incredibly useful set of data to augment your analysis of the environment. It is just that I would never suggest to anyone with a straight face that it is going to be comprehensive. Like many of the technologies we have discussed in this series, it is a piece of the puzzle. Passive DNS has a place and is quite useful, but it should augment a more holistic program.


Post by Robert Hansen

May 13, 2021