Getting a complete and accurate overview of all your online assets is key to protect your external attack surface from bad actors. Knowing what you have exposed online is always the first step. Wildcard domains can pose a challenge to External Attack Surface Management (EASM) solutions in this regard.

But what exactly are wildcards and how can you distinguish “real” domains from false positives in EASM?

What is a wildcard domain?

A wildcard domain is a domain name that uses a wildcard character (usually an asterisk “*”) to represent one or more subdomains. This allows all subdomains of a given domain to be matched and handled by a single DNS record or SSL certificate. For example, a wildcard domain like *.example.com would cover www.example.com, mail.example.com, blog.example.com, and any other subdomain under example.com, but it would not include example.com itself unless specifically configured.

Wildcard domains are commonly used to simplify DNS management and secure multiple subdomains with one wildcard SSL certificate. This is especially useful for large organizations or web applications that dynamically generate subdomains. However, they can also introduce security and configuration complexities.

How does a wildcard work?

A wildcard domain responds to requests for any subdomain under a specified domain. Typically, this is configured using a leading dot, such as .domain.com or .sub.domain.com. This setup ensures that any subdomain request — no matter what precedes the domain — will be handled correctly, as if the subdomain exists. For example, a request to asdndfhgoihcnlkwer.domain.com would be matched and resolved using the DNS records defined for *.domain.com.

However, it is possible to find configurations that answer with partial records, too.  

 For example, we can show a wildcard setup: 

• *.partial_records.domain.com has records A
  • 1.1.1.1   
  • 0.0.0.0
  • 173.56.48.5
  • 252.26.3.15
• random.partial_records.domain.com answers with 1.1.1.1 and 0.0.0.0 as the A record
• random2.partial-records.domain.com answers with 1.1.1.1 and 252.26.3.15 as the A record
• a second request random.partial_records.domain.com answers with 0.0.0.0 and 173.56.48.5 as the A record 

In this case, the attack surface result would be changing per scan. In the end, all the subdomains will resolve to the same result. The existence of a wildcard doesn’t stop a subdomain from being actually real and intended to be there by the company. 

As a comparison, the example above without the use of wildcards would look like this: 

• mydomain.partial_records.domain.com has records A
  • 1.1.1.1 
  • 0.0.0.0 
  • 173.56.48.5 
  • 252.26.3.15
• random.partial_records.domain.com doesn’t answer
• random2.partial-records.domain.com doesn’t answer
• a second request random.partial_records.domain.com doesn’t answer either 

As we can see in this case, only the real domain will answer, making discovery and information gathering generally easier than in the example above. 

Understanding subdomains and wildcard behavior

A subdomain is the child domain or zone of a domain. In DNS, all records and DNS zones are hierarchical, so, for example, www.domain.com is a subdomain of domain.com, and domain.com is a subdomain of com.

A wildcard domain makes every subdomain — or subdomain of a subdomain — exist in an unintended way. We call these inadvertent domains. A domain that exists by design is an advertent domain. There are different ways you can create advertent domains. Each creates a different scenario for wildcard, domain and subdomain detection. This will be detailed more in the technical section. 

Advantages and disadvantages of wildcard domains

Wildcard domains offer a practical way to manage subdomains, particularly in dynamic or large-scale environments. By using a wildcard DNS entry (e.g., *.company.com), any subdomain, whether it currently exists or not, will resolve as valid. This is highly convenient for IT teams, as it allows for flexibility and scalability without requiring manual DNS updates for every new subdomain. It also ensures that any potential subdomain needed now or in the future is already accounted for within the DNS configuration.

However, while wildcards simplify infrastructure management, they introduce complexity in security and discovery efforts. For automated External Attack Surface Management (EASM) solutions, wildcard domains can obscure the true scope of an organization’s exposed assets. Every subdomain appears to exist, even if it hasn’t been intentionally configured. For example, both blog.company.com (a legitimate subdomain) and jkzfjozjoabc.company.com (a non-existent one) return a positive DNS response. This makes it difficult to distinguish real subdomains from false positives created by the wildcard rule.

Wildcard domain security challenges

From a security perspective, wildcard domains can function as both a benefit and a barrier. On one hand, they provide a layer of “Security Through Obscurity“, hiding real subdomains within a sea of possible names. This can slow down attackers, as they struggle to identify which subdomains are valid targets.

On the other hand, this same obscurity can hinder defensive security tools. Discovery (which is one of the most critical phases in external attack surface mapping) becomes more difficult, as every domain seems active. This reduces the quality of OSINT (Open Source Intelligence) sources and complicates efforts to detect expired or unused domains, or identify new threats.

Because of the reasons listed above, the Outpost24 EASM platform, previously known as Sweepatic, faced the same challenge with wildcard domains. How could we distinguish the configured subdomains that are truly part of the external attack surface of an organization from the false positives? By constantly improving and adjusting our search techniques and methods, including reviewing the wildcard domains thoroughly, the Outpost24 EASM team ensures optimal insights into the external attack surface of our customers.

Example wildcard scenarios in EASM

To understand how wildcard domains can be tackled in EASM, it’s valuable to investigate how exactly they work. Below, we list and explain four wildcard scenarios the Outpost24 EASM team encountered in their years of experience mapping external attack surfaces.  

1. Basic DNS setup 

This is the standard case for a domain wildcard created at the DNS level. The DNS server will always respond with the same records for the inadvertent subdomains, and normally they won’t fully overlap with the advertent subdomains. Let’s take a look at the following: 

• domain.com is a domain bought by a company and purposefully targeted to an audience. 
• www.domain.com is a subdomain created to host the main website of the company.
• *.www.domain.com is a wildcard that the company set up below to avoid multiple configurations or for security.
• staging.www.domain.com is the staging environment of the main website. 

 The DNS zone would look as follows: 

• domain.com NS 1.1.1.1
• www.domain.com A 1.1.1.1
• *.www.domain.com CNAME www.domain.com
• staging.www.domain.com A 1.1.1.2 

 When resolving and enumerating results for this case, the results would be as follows: 

• domain.com -> 1.1.1.1
• www.domain.com -> 1.1.1.1
• random.www.domain.com -> www.domain.com -> 1.1.1.1
• random2.www.domain.com -> www.domain.com -> 1.1.1.1
• …
• anything_else.www.domain.com -> www.domain.com -> 1.1.1.1
• staging.www.domain.com -> 1.1.1.2 

2. More advanced DNS setup (subsets) 

In this case, the DNS server will answer the requests for different subdomains (or even different requests for the same subdomain) with random subsets of records from a predefined pool of records. This means the returned inadvertents might contain the same records or different ones following the behavior of a random environment. This will complicate any advertent detection, since the discovery of the full pool of records would always be a struggle. 

Let’s take a look at the example of following the A record, which could be also applied to any other kind of record accordingly.  

• domain.com is a domain bought by a company and purposefully targeted to an audience.
• www.domain.com is a subdomain created to host the main website of the company.
• *.www.domain.com is a wildcard that the company set up below to avoid multiple configurations or for security.
• staging.www.domain.com is the staging environment of the main website. 

The DNS zone would be as follows: 

• domain.com NS 1.1.1.1
• www.domain.com A 1.1.1.1
• *.www.domain.com a pool of records for the DNS A record:
  •  [1.1.1.3, 1.1.1.254]
  •  2.2.2.0/24
• staging.www.domain.com A 1.1.1.2 

When resolving and enumerating results for this case, the results would be:

• domain.com -> 1.1.1.1  
• www.domain.com -> 1.1.1.1
• random.www.domain.com -> 1.1.1.56, 1.1.1.85
• random2.www.domain.com -> 1.1.1.56, 2.2.2.25 
• …
• anything_else.www.domain.com -> www.domain.com -> 2.2.2.2, 2.2.2.3
• staging.www.domain.com -> 1.1.1.2 

3. More advanced DNS setup II (record generation based on request) 

In some cases, DNS records might be created on the fly based on the requested domain. This case is quite different from the previous one, even though it is normally also set up at the DNS level. The wildcard in this case is set to return one or multiple sections of the subdomain as part of the answer to the request. This is normally used for NS, MX, TXT, or other text-based records. 

Below you can see a basic example of record generation based on request. Accordingly, complex variations are also possible. 

• domain.com is a domain bought by a company and purposefully targeted to an audience.
• www.domain.com is a subdomain created to host the main website of the company.
• *.www.domain.com is a wildcard that the company set up below to avoid multiple configurations or for security.
• staging.www.domain.com is the staging environment of the main website. 

 The DNS zone would look as follows: 

• domain.com NS 1.1.1.1
• www.domain.com A 1.1.1.1
• *.www.domain.com a TXT record generated on the fly: “%s.domain.com”
• staging.www.domain.com A 1.1.1.2 

When resolving and enumerating results for this case, the results would be:

• domain.com -> 1.1.1.1  
• www.domain.com -> 1.1.1.1
• random.www.domain.com -> random.domain.com
• random2.www.domain.com -> random2.domain.com 
• …
• anything_else.www.domain.com -> anything_else.domain.com
• staging.www.domain.com -> 1.1.1.2 

 4. Non DNS advertence creation 

Until now, we described how the DNS records can be used to set up wildcards and advertent subdomains. This makes the detection of these setups work on a single dimension. However, this is not always the case. Over the years, our team encountered more “creative” scenarios like the one described below. In this case, the wildcard is set at the DNS level pointing to a specific server, and the advertence is set up in a reverse proxy only returning specific web apps for particular domains. 

The setup at the DNS level is as follows: 

• domain.com NS 1.1.1.1
• www.domain.com A 1.1.1.1
• *.www.domain.com A 1.1.1.2 

The setup at the reverse proxy level would be: 

• staging.www.domain.com -> web app 2 

How do EASM solutions detect wildcards and inadvertent domains?

Most EASM solutions attempt to detect wildcards and inadvertent domains by comparing DNS responses across a set of subdomains at the same level. Typically, they scan the current domain alongside several other generated subdomains. If a particular subdomain responds differently from the majority, it is likely a real, intentionally configured (advertent) domain.

However, this method has limitations in certain scenarios. For example, if DNS records vary even among inadvertent (wildcard-generated) domains, or if all responses are identical regardless of configuration, the comparison becomes unreliable. These edge cases require more advanced detection techniques.

In the sections that follow, we will walk through how wildcard domains can be detected and explain how to distinguish between advertent and inadvertent subdomains.

1. Detecting a wildcard

The simplest and most effective technique for detecting a wildcard domain is by analyzing the intersection of DNS records across a set of randomly generated subdomains. This method involves the following steps, using example.com as our example:

1. Create “random” subdomains of the domain under investigation: We quote “random” because any word is as random as any other, and the use of www or ww2 as random subdomains would break this technique. To do this, we look for more pure random looking domains like iAiZRcK2gT or xo9b5Z1kpr. The size of the set of subdomains will make it possible to cover more or fewer cases, but it will drive up the traffic and cost of the detection since we have to resolve more domains. 
2. Resolve the random domains: Try to resolve the random domains that we obtained. With the set of resolved records, we can start analyzing and deciding if a specific domain is a wildcard or not. 
3. Analysis and detection: There are some clear cases and some more specific results that are easy to analyze:

• • If all subdomains fail to resolve, it shouldn’t be a wildcard.
  • If all subdomains resolve to the same set of records, we can confidently conclude that a wildcard is in place.
  • There are thousands of other possibilities besides the two described above, but it’s not the purpose of this article to analyze every specific case. 

2. Differentiating an inadvertent from an advertent domain 

How do we know if a given domain — let’s say advertent.domain.com — is advertent or not? 

Most solutions will start by checking if the parent is a wildcard. We have to remember that an inadvertent domain can only exist underneath a wildcard domain. If the parent is not a wildcard, we can confidently assume the domain is advertent. 

If the parent is a wildcard — for example, we are checking advertent.wildcard.domain.com and wildcard.domain.com is a wildcard domain — how do we distinguish between an advertent and an inadvertent domain?

The solution has a lot of parallels with the detection of a wildcard, and follows these steps: 

1. Create “random” domains: Create a set of randomly generated subdomains at the same level as the domain under investigation. Use the same precautions for randomness as outlined in the wildcard detection process.
2. Resolve the domain under analysis: Perform a DNS resolution for the domain you’re analyzing. This result will be compared against the resolutions of the random subdomains.
3. Resolve the random domains: Try to resolve the random domains that we obtained. With the set of resolved records, we can start analyzing and deciding if a specific domain is a wildcard or not. 
4. Analyze and compare: There are some clear cases and some more specific results that are easy to analyze: 
   • If only the target domain resolves and all random domains fail, it’s most likely an advertent domain.
   • If the target domain fails to resolve, it’s not active and can be disregarded.
   • If all random domains resolve to the same set of records, and the target domain matches that exact response, it’s most likely an inadvertent domain generated by a wildcard.
   • There are thousands of other possibilities besides the ones described above, but it’s not the purpose of this article to analyze every specific case. 

Accurately identify wildcard domains in your attack surface

Identifying and managing wildcard domains is a difficult challenge in External Attack Surface Management. At Outpost24, we’ve spent years refining our approach to make sure that wildcard domains are no longer a blind spot. Our EASM platform uses advanced detection logic, AI-powered domain discovery, and continuous monitoring to accurately separate real, exposed assets from misleading wildcard responses.

By reviewing wildcard domains with precision, we make sure only true, vulnerable subdomains — those actually part of your attack surface — are flagged. This leads to a complete and accurate view of your organization’s online exposure.

From automated asset discovery and risk-based prioritization to real-time alerting and threat intelligence enrichment, the Outpost24 EASM platform gives you the visibility and control needed to secure your external perimeter. Curious to see how this could work for your organization? Request a personalized demo today.