Wildcard Subdomains and Their Effect on Attack Surface Mapping

Everything has its pros and cons. For web administrators, wildcard subdomains help simplify domain management and dealing with multisite applications. For cybersecurity professionals, they are a source of regular headaches. They can make an organization’s attack surface look much bigger (or smaller) than it actually is. 

In this post, we look at wildcard subdomains from the security perspective: how they affect attack surface mapping, why it happens, and how you can see through the noise.

What Is a Wildcard Subdomain?

A wildcard subdomain is created when web administrators set up a wildcard DNS record instead of creating individual records in the Domain Name System (DNS) for every subdomain. The wildcard DNS record, represented by an asterisk (aka wildcard character), serves as a catch-all for any non-existent or undefined subdomains under a primary domain. Here’s an example:

*.example.com A 196.3.2.1

The wildcard DNS record above directs all requests for subdomains that don’t have their own DNS record to the IP address 196.3.2.1. When a user sends a request for abc123.example[.]com, the user is directed to that IP address. 

In this case, abc123.example[.]com is a wildcard subdomain, and in some cases, *.example.com is called a wildcard domain. 

It’s worth noting that if a wildcard is used, you can still make specific subdomains point to other places by specifying an A record (or an AAAA, or a CNAME) for them. For example, if you want blog.example[.]com to point to a different IP address (say, 196.3.4.5), then your DNS zone would look like this:

*.example.com A 196.3.2.1
blog.example.com A 196.3.4.

While in reality, wildcard DNS records are the only origin of wildcard subdomains, cybersecurity products that manage attack surfaces often mistakenly generate wildcard subdomain false positives from another source – wildcard SSL/TLS certificates.

Wildcard DNS vs. Wildcard SSL: Their Role in Subdomain Discovery

As we’ve discussed above, a wildcard DNS record is a routing mechanism. It tells the internet where to send traffic for a subdomain that doesn’t have a specific DNS record. 

On the other hand, a wildcard Secure Sockets Layer (SSL) certificate provides security and encryption for an unlimited number of subdomains residing on one domain name. A wildcard SSL for *.example[.]com can secure www.example[.]com, login.example[.]com, shop.example[.]com, and any other subdomain that will be created in the future. 

Both wildcard DNS and wildcard SSL serve different purposes. However, they have one thing in common — they result in a lot of wildcard subdomains (which are essentially false positives) being added to an organization's attack surface during subdomain enumeration, one of the main steps (and, perhaps, the most difficult one) in attack surface management (ASM).

The Problem of Wildcard Subdomains in Attack Surface Management

Subdomain enumeration is no easy task even without wildcard subdomains. There’s no technique that can give you a complete list of subdomains. But wildcard SSL or DNS records just add to the noise and uncertainty, as they give an unrealistic list of assets (many of which are false positives).

Why Wildcards Result in False Positives

Wildcards give off misleading signals that can confuse subdomain enumeration tools and ASM platforms. Here’s why that happens:

How Wildcard Subdomains Affect ASM

When they encounter wildcard certificates, whether SSL or DNS, subdomain lookup tools often give a large number of false positives. Brute-forcing, for one, returns subdomains as long as they resolve – and with a wildcard DNS record, they all do. But most of those are fake, just artifacts of a wildcard record. 

On the other hand, subdomain enumeration tools that use CT logs may exclude everything when they see a wildcard certificate, which is also incorrect behavior.

However, there are ways to overcome this challenge and find real and active subdomains only. Here’s one way to do it. 

Using DNS Lookups to Verify the Existence of Wildcard Subdomains in ASM

1. Check if a Wildcard Is Present 

The first step is to confirm the presence of a wildcard. You can do this by running DNS lookups for randomly generated subdomains under the target domain name. For example, you can query foo123.example[.]com and asdfghjkl.example[.]com. If all of them resolve to an IP address, then a wildcard record is likely in place. You should record the IP address or CNAME that these random subdomains resolve to and keep it as the wildcard signature.

Alternatively, you can use the DNS Chronicle API, a tool that retrieves a domain’s historical A and AAAA records and also checks if a target domain is part of a wildcard entry. If you see “wildcard: true” in the output, you know that you’re dealing with a wildcard DNS record. Similarly, in our historical DNS database, you’ll find a wildcard column with values of either TRUE or FALSE.

2. Identify the Wildcard Signature

The wildcard signature is the IP address (A/AAAA record) or CNAME record that all non-existent subdomains resolve to. This is the "catch-all" destination. It's the unique identifier that will help you filter out the noise.

3. Use the Wildcard Signature as a Filter

Now, when you perform your actual subdomain enumeration, you can use the wildcard signature as a filter. As you perform DNS lookups for a list of potential subdomains (e.g., www.example.com, blog.example.com, admin.example.com), compare the returned record with your recorded wildcard signature. 

If the record for a specific subdomain matches the wildcard signature exactly (e.g., same IP or CNAME target), it means that it’s a wildcard hit — and therefore a false positive. You should exclude this result from your final asset inventory.

4. Find Subdomains That Stand Out

A valid and explicitly configured subdomain will have a unique DNS record, and it will stand out from the noise of the wildcard. A DNS lookup on a valid subdomain is likely to return:

• A unique A record (or an AAAA record).
• A CNAME pointing to a different target, not the wildcard signature.
• TXT or MX records specific to that subdomain, indicating it serves a unique purpose (e.g., email verification).

Conclusion

The catch-all nature of wildcards creates a breeding ground for false positives when doing subdomain enumeration, making it difficult to distinguish between real assets and the artifacts of a wildcard DNS record or wildcard SSL certificate. 

Additional steps during the subdomain enumeration process, such as identifying the wildcard signature and filtering out subdomains based on that signature, can help you come up with a more accurate asset inventory.