Table of Contents

• Brief Introduction of Subdomain Enumeration
• Goals
• Ethical Considerations
• Demonstration
  • Search Engine Dorking
  • Certificate Transparency Lookup
  • Passive Aggregation with Sublist3r
  • Virtual Host Discovery with ffuf
  • Active DNS Brute Force with Gobuster
• Key Findings
• Summary

Brief Introduction of Subdomain Enumeration

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.

Goals

• Find subdomains from public data sources like search engines and certificate logs.
• Check how certificate data can show extra infrastructure using crt.sh.
• Compare passive enumeration with Sublist3r and active DNS brute forcing with Gobuster.
• Run virtual host fuzzing with ffuf to find hostnames not visible in DNS records.

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 TryHackMe below so you can see how this technique works.

TryHackMe query:

site:*.tryhackme.com -site:www.tryhackme.com

Indexed results include subdomains such as careers, help, and store. 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
• jercarlocatallo.com

One source (VirusTotal) blocked requests during collection, but output was still returned. 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:

Some words (autos, soap, chemie) produced i/o timeouts, which is expected resolver noise. The scan completed over 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.

Key Findings

• No single method is complete by itself.
• Search engines are fast but limited to indexed assets.
• crt.sh provides deeper hostname visibility through certificate history.
• Sublist3r found 3 publicly known subdomains.
• Gobuster found 8 subdomains, including infrastructure names not visible in passive results.
• Using --protocol tcp with -t 1 improved reliability and reduced miss risk.
• ffuf identified HTTP virtual hosts that may not appear in DNS records.

Key observation:
We can see that Sublist3r discovered m.jercarlocatallo.com from third-party data, but it missed infrastructure subdomains (dev, admin, vpn, api, staging, uat, mail) that Gobuster found through direct DNS resolution.

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. For defenders, the takeaway is clear: monitor certificate logs, clean up unused DNS records, and use split-horizon DNS to keep internal names private.