Domains, subdomains, and the IP space

You were given one hostname. The company runs dozens. This lesson is about turning that one doorway into the whole neighbourhood: finding the subdomains, understanding how a name becomes a server through DNS, and seeing which of those servers is worth your time.

A name is not a server#

When you type www.example.com, your machine does not magically know where that is. It asks the Domain Name System: DNS, to translate the name into an IP address, the actual number that identifies a server on the network. Only then does your browser open a connection to that number.

Two ideas come out of that picture and both matter for recon.

One organisation owns many names. www.example.com, api.example.com, mail.example.com, dev.example.com are all subdomains of example.com. Each can point to a different server running different software with different bugs. The company polished the front door; the side doors are where you often get in.

Different names can share one server, and one name can move. api. and dev. in the diagram resolve to the same IP, they are two apps on one box, and a bug in one may expose the other. Names also change over time, which is why archives and certificate logs, which remember old mappings, are so useful.

Finding subdomains#

There are two families of technique, and good testers use both.

Passive enumeration pulls names from the public sources you met last lesson, and it is where to start because it touches nothing. Certificate transparency logs are the star: query crt.sh for a domain and read off every hostname that has ever appeared in a certificate. Tools like subfinder and amass (in passive mode) automate pulling from dozens of such sources at once. The command shape is simple:

subfinder -d example.com -silent | sort -u > subs.txt

You now have a candidate list, gathered without a single packet reaching the target.

Active enumeration tries names against the target's DNS to see which resolve. The most common form is brute forcing: take a wordlist of likely prefixes (www, api, dev, staging, vpn, admin, test, portal…) and ask DNS whether each exists. Tools like puredns or dnsx do this quickly. This does touch DNS infrastructure, so it belongs in the active phase and in scope.

From a list of names to a list of live web apps#

A resolved name is not the same as a live web application. mail.example.com might be a mail server that speaks nothing you can test in a browser. So the next step is to check which of your hostnames actually serve HTTP, and get a first glance at each. httpx is the usual tool:

cat subs.txt | httpx -sc -title -tech-detect

For each host it tells you the status code, the page title, and a guess at the technology. In a few seconds a list of eighty names becomes "these thirty serve a web app, here is each one's title and stack." Now you can see the shape: twenty-nine say "Example, Home" and one says "Staging, Login (Debug)". You know where to look.

Reading the results like a tester#

The value is not in the size of the list, it is in the outliers. Scan your results for:

• Non-production names: dev, test, staging, uat, qa, demo, beta, old, legacy, or a year. These are frequently less hardened, run older code, and sometimes have debugging on or authentication off.
• Interesting functions named in the hostname: admin, internal, api, vpn, git, jenkins, jira, grafana, s3, files, upload. Each hints at what the box does and therefore what could go wrong.
• Odd status codes and titles: a 401 or 403 proves a host exists and is protecting something. A default title like "Welcome to nginx" or "It works!" suggests a forgotten default install.
• Shared IPs: several names on one address means several apps on one server; a foothold in one may reach the others.

A note on scope and DNS#

Passive subdomain enumeration is reading public data and is generally safe. The moment you start resolving names against the target, probing them with httpx, or brute forcing DNS, you are making requests the target can see, so the same rule applies as everywhere: do it only where you are authorised. One more caution: subdomain enumeration can turn up hosts that belong to third parties (a name pointing at a SaaS provider, say). Confirm a host is actually in your scope before you test it, the scope defines the target, not your wordlist.

Where this goes next#

You now have a mapped neighbourhood: the hostnames, which serve web apps, and a first guess at each one's stack. The next lesson zooms into a single app and reads everything it hands out for free, the files and headers that tell you about the application before you have really started poking at it.