Pre-Identifying DNS Wildcards: A New Standard of Care

Discovering subdomains is an important practical skill and the first step in attack surface management. Solutions that are both comprehensive and fast (“find ALL the subdomains and do it QUICKLY!”) are particularly prized. But like much of infosec—easier said than done!

Our team won the DEF CON 31 Recon-Aacharva subdomain challenge and our passion for Reconnaissance drove us to go further. A post-hoc review identified an alternative approach that yielded 100 times more raw domains than our original winning submission, and that approach took just a couple of hours. The key? Rather than relying on the open source “subfinder” tool, we used a passive DNS tool that returned only RRnames and RRtypes, along with relatively tight time fencing and parallel query streams. Enumerating subdomains that way is a straightforward task—but there’s a catch!

The real challenge for accurate enumeration turns out to be excluding DNS wildcards—domains that will resolve any arbitrary hostname, even random gibberish. For example, “aiuojad.tumblr.com” resolves because tumblr.com is a DNS wildcard. Typical DNS wildcards usually arise at the 2nd-level, and even some entire TLDs (such as .ph) are wildcarded. What’s less-well known is that “deep” wildcards also exist further left in the FQDN, or exist only for specific RRtypes. While obscure, deep wildcards are surprisingly prevalent and exploitable for reflective DDoS purposes. While they can be used carefully for legitimate objectives, they can also devolve into abusable nuisances, capable of producing large volumes of cache-defeating response traffic when hit with spoofed/randomized DNS queries. They can even be abused to make it appear that a benign site has CSAM content or supports terrorism, etc., since arbitrary queries for such labels will find their way into the passive DNS record for all to see.

If your site has any deep wildcards, they add an attack surface exposure you may not have been aware of; we recommend reconsidering the need for the wildcards and if they are truly necessary, carefully monitoring how those names are getting (ab)used. Our presentation demonstrates some methods for efficiently assessing a domain’s DNS wildcard status, and suggests a new “standard of care” for routine testing and logging of the wildcard status of ALL (FQDN, RRtype) combinations, much as you might log, geolocate, and port scan IPs you interact with. Join us as we share the technique that yielded more than 100x the number of subdomains we found in our winning entry.