gobuster vhost scan fails with wildcard certificate false positives on authorized domain

TL;DR

The server answers every Host header with the same certificate, so connection success means nothing. Baseline the wildcard response with a nonsense Host header, filter it by length and status, and confirm remaining candidates by distinct content, cross-checked against DNS and certificate transparency data.

wildcard certificate false positives

Use this when

• Gobuster vhost mode reports hits for obviously fake hostnames.
• The target serves a default certificate for any SNI/Host value.
• The engagement covers virtual host discovery on the domain.

Not for this skill when

• The server presents distinct certificates per vhost. Then connection success is meaningful.
• You are doing DNS enumeration instead. Use DNS tooling for that.
• The domain is out of scope. Do not enumerate its vhosts.

Steps

1. Baseline the wildcard: curl -s -o /dev/null -w "%{http_code} %{size_download}" -H "Host: definitely-not-real-12345.target.com" YOUR_TARGET_HOST. Verify: you have the wildcard signature.
2. Filter it: add --exclude-length matching the wildcard size (and -b for its status if constant). Verify: the fake hostname no longer reports as a hit.
3. Rerun the vhost scan with the filter in place. Verify: remaining candidates are far fewer.
4. Confirm each candidate by content: fetch it and diff against the wildcard baseline. Verify: the body differs, not just timing.
5. Cross-check survivors against DNS records and certificate transparency logs. Verify: candidates resolve or appear in CT independently.

Variant phrasings

gobuster vhost wildcard false positive

Compact phrasing.

gobuster vhost scan all hosts succeed

Symptom-level search.

vhost enumeration wildcard certificate

The technique-level search.

Compatibility: gobuster v3.x vhost mode. --exclude-length filtering applies to vhost mode as well as dir mode.

Why it happens

Many servers present a default certificate when SNI does not match a configured vhost, and the TLS handshake succeeding says nothing about whether the vhost exists. Gobuster's default vhost logic counts distinctive responses as hits, but a wildcard-everything server makes every guess look distinctive-free yet "successful".

Edge cases / pitfalls

• Some apps vary the wildcard page per request (timestamps, nonces). Size filtering gets brittle; add content matching.
• A real vhost can share the wildcard's size by coincidence. Content diffing, not size alone, is the confirmation.
• Do not report unconfirmed vhost candidates as findings. An unconfirmed vhost is a lead, not a vulnerability.
• CT logs only show publicly trusted certs; internal vhosts will not appear there. Note the limitation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H9XQXJpzsG2R7Iz9Fn3sxg