Subdomain Enumeration: How Attackers Find What You Forgot to Hide

Subdomain enumeration is the process of finding all subdomains that belong to a target domain. Each subdomain is a potential entry point, making this a key step in external reconnaissance. In this write-up, we walk through the subdomain enumeration techniques tested in a hands-on lab, so you can see the tools, commands, and results along the way.

There are two main approaches:

• Passive enumeration: Uses public data sources like search engines, certificate transparency logs, and third-party APIs. This method does not send direct requests to the target, so it has low risk of detection.
• Active enumeration: Sends direct requests to DNS servers or web servers using wordlists. This method finds more results but creates network traffic that can be logged or detected.

We demonstrate both approaches below, so you can see how they complement each other and why relying on only one method leaves blind spots.

Ethical Considerations

Subdomain enumeration is a reconnaissance activity. It has legal and operational impact. You should follow these rules in every engagement:

• Authorization is mandatory. Active DNS brute forcing or host-header fuzzing without written permission can break laws such as CFAA and local statutes.
• Passive does not always mean harmless. Passive OSINT can still show sensitive information, so handle it with care.
• Rate limiting matters. Use low thread counts (for example, -t 1) and wait between requests to avoid service disruption.
• Scope validation is required. A discovered host is not automatically in scope. Always check every asset against the approved scope list.
• Responsible disclosure applies. Report unintended exposed infrastructure through proper authorized channels.

All activity in this write-up ran against:

• Personal domain (jercarlocatallo.com), owned by the author.
• TryHackMe lab environments, authorized training infrastructure.

Demonstration

Search Engine Dorking

Search engine dorking is the simplest passive technique. By using the site: operator, you can ask Google which subdomains it has indexed for a domain. No traffic reaches the target, and results are available in seconds.

We use HackTheBox below so you can see how this technique works.

HackTheBox query:

site:*.hackthebox.com -site:www.hackthebox.com

Indexed results include subdomains such as roadmap, jobs, ctf, status, and trust. This confirms indexing-based visibility and helps you prioritize deeper checks.

Takeaway: Search engines know only what they have crawled. Results are quick to get but limited to indexed assets. This technique alone will miss subdomains that search engines never discovered.

Certificate Transparency Lookup

Certificate Transparency (CT) logs record every SSL/TLS certificate issued by participating authorities. crt.sh is a public search interface for these logs. Unlike search engines, CT logs can reveal hostnames that were never indexed or are no longer active.

We check tryhackme.com below so you can see how CT logs compare to search engine results.

tryhackme.com:

https://crt.sh/?q=tryhackme.com

Certificate entries show wildcard and service-specific names. You can see that CT logs include historical names not currently indexed by search engines.

Takeaway: CT logs provide deeper hostname visibility through certificate history. They often reveal names that search engines miss, including wildcard entries and expired certificates. However, CT logs cannot find subdomains that never had a certificate issued.

Passive Aggregation with Sublist3r

Sublist3r automates passive enumeration by querying multiple third-party sources (search engines, DNS aggregators, VirusTotal, and more) in a single run. We run it against a personal domain so you can see what public data sources know.

Command:

sublist3r -d jercarlocatallo.com

We can see 3 unique subdomains were discovered:

• www.jercarlocatallo.com
• m.jercarlocatallo.com
• wwww.jercarlocatallo.com

Note that wwww.jercarlocatallo.com (four w's) is a misspelled typo domain, which is interesting because it shows up in third-party data sources, possibly from a crawl or a misconfigured link somewhere.

Two sources failed during collection: DNSDumpster (CSRF token error) and VirusTotal (blocking requests). Passive output quality depends on source availability and rate limits.

Remediation:

• Monitor certificate transparency logs for your domains to detect unauthorized subdomain creation.
• Remove unused or forgotten subdomains from DNS to reduce attack surface.

Takeaway: Sublist3r is efficient for gathering what third-party sources already know, but it cannot discover subdomains that no source has indexed. Infrastructure names like dev, admin, and vpn often do not appear in passive data because no one has publicly referenced them.

Virtual Host Discovery with ffuf

Not all subdomains resolve in public DNS. Some exist only as virtual hosts behind a single IP address. ffuf can find these by fuzzing the Host header in HTTP requests and filtering out default responses.

We run this in a TryHackMe lab environment so you can see the technique in action.

Command:

ffuf -w /usr/share/wordlists/SecLists/Discovery/DNS/namelist.txt \
  -H "Host: FUZZ.acmeitsupport.thm" \
  -u http://10.48.142.81 \
  -fs 2395

We can see two virtual hosts were found: delta and yellow. This confirms that HTTP-layer discovery can expose hosts not visible in public OSINT datasets.

Remediation:

• Configure web servers to return consistent responses for unknown Host headers.
• Use a default catch-all virtual host that does not leak information about other hosted services.

Takeaway: Virtual host fuzzing reveals assets that DNS and passive sources cannot find. It is an active technique that requires sending real HTTP requests, so it is more detectable but more complete for web-hosted infrastructure.

Active DNS Brute Force with Gobuster

Gobuster sends direct DNS queries for each word in a wordlist, resolving subdomains that passive sources never collected. We run this against a personal domain to find subdomains that Sublist3r missed.

Command:

gobuster dns \
  -d jercarlocatallo.com \
  -w subdomains-top1million-5000.txt \
  -t 1 \
  --resolver 8.8.8.8 \
  --protocol tcp

Standard DNS typically uses UDP, which can drop packets under load. TCP reduces timeout noise and improves consistency for wordlist-based enumeration.

You can see 8 subdomains resolved:

www returned two public IPs (64.29.17.65 and 216.198.79.65), which suggests a round-robin or load-balanced setup. Some words (autos, soap, chemie) produced i/o timeouts, which is expected resolver noise. The scan completed all 4,989 words. Loopback results indicate locally configured DNS entries that may map to non-public infrastructure.

Remediation:

• Use split-horizon DNS to separate internal and external DNS records.
• Avoid exposing internal infrastructure names (dev, staging, uat, admin) in public DNS.
• Implement DNSSEC to prevent DNS spoofing and cache poisoning attacks.

Takeaway: Active brute forcing found 8 subdomains where Sublist3r found only 3. The 5 additional names (mail, dev, admin, vpn, api, staging, uat) were not indexed by any passive source. As you can see, this gap shows why active enumeration is necessary for full coverage.

Summary

Passive techniques show what public data sources know. Active techniques show what DNS and application behavior expose. When you combine both approaches, you improve attack surface visibility and reduce blind spots.

Sublist3r found 3 publicly known subdomains from third-party data, including a typo domain (wwww.jercarlocatallo.com). Gobuster found 8 subdomains through direct DNS resolution, adding infrastructure names like dev, admin, vpn, api, staging, uat, and mail that no passive source had indexed. That gap between passive and active results is why using both methods together matters.

For defenders, the takeaway is clear: monitor certificate logs, clean up unused DNS records, and use split-horizon DNS to keep internal names out of public resolvers.

If you found this helpful, drop a like and share it with someone learning security. If you have questions, ran into something different in your own lab, or want to share your results, leave a comment below. Always happy to connect and talk about security, recon techniques, or anything AppSec related.

Feel free to connect with me on LinkedIn

Always open to connecting with people in security, development, or both. Whether you are building something, breaking something, or just getting started, feel free to reach out.