Field Manual

Virtual Hosts

4 min read

🛡️ Methodology Checklist

  • Check if IP serves different content with different Host headers
  • ffuf vhost fuzz: ffuf -w [WORDLIST] -H "Host: FUZZ.[DOMAIN]" -u http://[TARGET_IP] -fs [DEFAULT_SIZE]
  • gobuster vhost: gobuster vhost -u http://[TARGET_IP] -w [WORDLIST]
  • Check TLS cert SANs for additional vhost names
  • Add all discovered vhosts to /etc/hosts for testing
  • Test each vhost independently — different apps may have different vulns

🎯 Operational Context

Use when: Target IP hosts multiple web applications differentiated by Host header — Nginx/Apache virtual hosting is the norm for shared infrastructure. Think Dumber First: Always fuzz Host header against the main IP after finding it. Dev, admin, and internal portals frequently live on vhosts not in DNS. ffuf -H "Host: FUZZ.target.com" is the first move. Skip when: Single-host deployment confirmed via Shodan/Censys — vhost fuzzing wastes time on dedicated servers.

⚡ Tactical Cheatsheet

CommandTactical Outcome
gobuster vhost -u http://[DOMAIN] -w [WORDLIST] --append-domainVHost brute-force
gobuster vhost -u http://[DOMAIN] -w [WORDLIST] --append-domain -t 50VHost brute-force with 50 threads
gobuster vhost -u http://[DOMAIN]:[PORT] -w [WORDLIST] --append-domain -t 50VHost on non-standard port
gobuster vhost -u http://[DOMAIN] -w [WORDLIST] --append-domain --exclude-length [SIZE]Filter out false positives by response size
ffuf -w [WORDLIST]:FUZZ -u http://[TARGET_IP] -H "Host: FUZZ.[DOMAIN]" -fs [SIZE]ffuf VHost fuzzing with size filter

🔬 Deep Dive & Workflow

VHost vs. Subdomain

ConceptDNS Record?Access Method
SubdomainYes — public DNS recordStandard browser access
Virtual HostNot necessarilyMust send correct Host header or set /etc/hosts

Key insight: A VHost may have no public DNS record. It’s only accessible by sending the right Host header → can only be found by fuzzing, not passive DNS recon.

Types of Virtual Hosting

  1. Name-Based (Most Common) — Uses Host header to serve different content on same IP/Port → primary fuzzing target
  2. IP-Based — Unique IP per site (rare due to IP scarcity)
  3. Port-Based — Different sites on different ports

VHost Fuzzing Tools

ToolKey Feature
gobuster--append-domain flag — appends base domain to each wordlist entry
ffufAdvanced filtering (-fs, -fw, -fl) for false positive removal
feroxbusterRecursive, Rust-based, fast

gobuster Command Breakdown

  • -u http://[DOMAIN] — use domain name, not IP (after adding to /etc/hosts)
  • --append-domain — converts dev → dev.inlanefreight.htb
  • -t 50 — 50 threads for speed
  • -k — ignore SSL/TLS errors (internal HTTPS)
  • --exclude-length [SIZE] — filter default “catch-all” responses

Adding to /etc/hosts

echo "[TARGET_IP]   [DOMAIN]" | sudo tee -a /etc/hosts

Troubleshooting

  • Thousands of results (all 200) → server returns default page for everything → note response size → use --exclude-length or -fs
  • 0 results → did you scan IP instead of domain? Map domain in /etc/hosts first
  • 0 results → check actual web port — may be 8080, 443, or a random high port

Grep Results for Exam

grep "web" gobuster_vhosts.txt
grep "vm" gobuster_vhosts.txt
grep "admin" gobuster_vhosts.txt

🛠️ Troubleshooting & Edge Cases

ProblemCauseFix
All vhost responses return same sizeWildcard vhost configuredBaseline with default response size then filter: -fs [default_size]
ffuf vhost fuzz misses resultsHost header format wrongTry both FUZZ.target.com and FUZZ as Host values; some configs use short names
Valid vhost returns 302 redirect loopRedirect to HTTPS but no certAdd -u http://[TARGET_IP]/ and manually follow redirect; add -r flag
Cannot reach vhost from attack boxDNS not resolvingAdd vhost to /etc/hosts: [TARGET_IP] discovered-vhost.target.com
gobuster vhost mode returns 400 errorsHTTP/1.1 Host header requiredUse curl -H 'Host: admin.target.com' http://[TARGET_IP]/ to verify manually

📝 Reporting Trigger

Finding Title: Internal Virtual Hosts Exposed on Public-Facing IP Impact: Internal web applications (admin panels, dev environments, API backends) accessible via Host header manipulation bypass intended access restrictions tied to DNS resolution. Root Cause: Network-level access controls applied at DNS/domain level rather than IP/firewall level. Internal vhosts share IP space with public-facing services. Recommendation: Apply authentication and network-level ACLs at the vhost level, not just DNS. Restrict internal vhost access by source IP. Audit all virtual host configurations for unintended exposure.

🔗 Related Nodes

Graph View

Backlinks