Virtual Host Enumeration for Bug Bounty Hunters
One IP can host dozens of websites. The web server decides which application to return from the HTTP Host header and TLS SNI, so DNS is not a complete inventory. A hostname may have no public record yet still work when sent to the right address. That is why virtual-host enumeration regularly finds internal dashboards and pre-production copies sitting beside a public app.
Choose an IP already tied to an in-scope hostname. Record the normal response, then request the same IP with a nonsense host such as does-not-exist-8472.example.com. That nonsense response is your baseline. Note its status code, body size, line count, title, redirect target, and a stable content hash. Servers often return 200 for every unknown name, so status alone is a terrible filter.
Now build a focused wordlist. Start with names suggested by the product and its stack: admin, api, staff, partner, dev, staging, region codes, old brand names, and names seen in JavaScript or certificate logs. A million generic words mostly produce noise and rate-limit alerts.
ffuf -w names.txt -u https://203.0.113.10/ -H "Host: FUZZ.example.com" -fs 4242
Use --resolve or a proxy rule when TLS requires SNI for each guessed hostname. Some tools connect by IP and send the right Host header but keep the wrong TLS server name, causing every request to hit a default certificate or fail before HTTP.
Filter by shape, then inspect by hand
Useful hits differ from the baseline in body size, words, title, cookies, redirect location, or headers. A 302 to /login, a session cookie with a new name, or a branded 403 often matters more than a clean 200. Run several nonsense controls because dynamic request IDs can make every response appear unique.
Wildcard behavior causes another trap. A reverse proxy may reflect any supplied hostname into a redirect, making each candidate look real. Follow the redirect carefully and compare page content. If random-123.example.com behaves exactly like admin.example.com, you have not discovered admin.
Establish that the host belongs in scope
A hidden name resolving only through your manual mapping is not automatically authorized. Check the program's scope language, parent-domain rules, acquisitions, and exclusions. Tie the service to the organization through certificates, branding, known IP ownership, application links, or matching account systems. When ownership is uncertain, ask the program before aggressive testing.
Once confirmed, treat the host as a fresh application. Look for debug modes, default credentials only where credential testing is allowed, stale software, relaxed CORS, exposed API documentation, and authorization differences from production. Keep your first pass read-only. A staging database may contain production data even when the hostname sounds disposable.
A report needs a bug
Most programs will not reward hostname discovery by itself. Lead with the vulnerability on the newly found host and explain vhost enumeration as the discovery path. Include the target IP, required Host header, baseline comparison, ownership evidence, and minimal reproduction. Avoid publishing the host if it exposes a sensitive operational system.
Remediation usually means removing unused routes, authenticating non-public environments, separating them from production data, and maintaining an asset inventory that includes reverse-proxy configurations—not just DNS records. If a virtual host must remain private, enforce that at the network or identity layer. An obscure Host header is not access control.