Discover virtual hosts and hostname-selected applications

Needs: A destination listener, relevant domain candidates and controlled Host/SNI routing

Shell commands

# Baseline
gobuster vhost -u http://DOMAIN:PORT/ --append-domain -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -o vhosts.txt

# Alternative with automatic calibration
ffuf -w WORDLIST -u http://TARGET:PORT/ -H 'Host: FUZZ.DOMAIN' -ac -o ffuf-vhosts.json

Failure cue: uniform status/length may be the default vhost. Compare each candidate with a random host header before adding it to the application map.

Verify → Compare candidate and nonexistent-host responses, including content and redirects; resolve to the intended scoped address.

If it fails → A default response for every host or an SNI mismatch makes the result inconclusive; do not treat every guessed hostname as a real application. More detail ↓

If → then

An HTTP endpoint, redirect or hostname-dependent response → Establish scheme, host, redirects and request state
Needs: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons
Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
Needs: A normal request baseline and the relevant account/role; authorized accounts for role comparisons
A DNS server, domain name or host aliases → Expand names through DNS records and zone transfers
Needs: Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Discover virtual hosts and hostname-selected applications

USE WHEN: DNS names, redirects, certificate names or a default virtual-host response
STARTING ACCESS: A reachable HTTP application and recorded anonymous or authenticated request state
RESULT: Additional verified applications on the same address

Recognize the clue

Collect hostnames from redirects, certificates, DNS and source; compare named requests against an invalid-host control.

curl -sk --resolve HOSTNAME:PORT:TARGET https://HOSTNAME:PORT/

SYNTHETIC EXAMPLE OUTPUT

Host HOSTNAME: application login page
Host INVALID_HOST: default server page

Means: A reproducible hostname-selected application is a new mapping target on the same address.

Confirm: Send a random Host header as a negative control, compare the candidate's real response, then browse it with the correct hostname. A different status caused only by redirects or a default site is not a confirmed vhost.

After validation: The named application has distinct verified behavior: give it its own session/function map.
Ruled out in this context: All candidate hosts receive the same default body: discard the claimed distinct application.
Still inconclusive: TLS routing or local DNS is wrong: fix that context before deciding a vhost is absent.

Troubleshooting: A default response for every host or an SNI mismatch makes the result inconclusive; do not treat every guessed hostname as a real application.

Alternative with automatic calibration:

Failure cue: uniform status/length may be the default vhost. Compare each candidate with a random host header before adding it to the application map.

Why it works

Virtual-host routing uses the requested hostname. DNS resolution, HTTP Host and TLS SNI must be aligned when the server selects behavior at more than one layer.

Worked example · hypothetical

Observation: a certificate suggests an internal application name. Test: resolve it to the assigned address while preserving SNI. Illustrative output: a separate administration interface. Interpretation: give it its own request and credential map.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗