Virtual Host Fuzzing

Un servidor web puede alojar varios sitios sobre una misma IP y decidir cuál sirve según el nombre de host que el cliente pide en la cabecera Host: de la petición HTTP. Esto se llama virtual hosting. La consecuencia para quien enumera es importante: la página que ves al entrar por la IP (o por el dominio principal) puede no ser la única; otros nombres pueden devolver aplicaciones completamente distintas.

Por eso, además de fuzzear directorios y ficheros, conviene fuzzear nombres de host. La técnica consiste en mandar muchas peticiones a la misma IP variando la cabecera Host: con candidatos de un diccionario y quedarse con los que devuelven una respuesta distinta de la del comodín (un host que no existe). Una diferencia en el código de estado o, sobre todo, en el tamaño de la respuesta delata un virtual host real.

# gobuster en modo vhost
gobuster vhost -u http://permx.htb \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
  --append-domain -t 50

# equivalente con ffuf, filtrando por tamaño del comodín
ffuf -u http://10.10.11.23 -H "Host: FUZZ.permx.htb" \
  -w subdominios.txt -fs 19347

Cada candidato que responda hay que añadirlo a /etc/hosts apuntando a la IP para poder navegarlo:

echo '10.10.11.23 lms.permx.htb' | sudo tee -a /etc/hosts

Por qué importa. Aplicaciones de administración, paneles internos o instalaciones de software de terceros suelen colgar de subdominios poco visibles (dev., lms., admin., internal.). El vector de explotación muchas veces no está en el sitio principal, sino en uno de estos virtual hosts.

Cómo detectarlo. La firma en el log de acceso es una ráfaga de peticiones a la misma IP variando la cabecera Host: (cientos de valores distintos en segundos), la mayoría devolviendo el mismo tamaño de respuesta (el comodín) o 404, un patrón que un cliente real jamás produce; el User-Agent de gobuster/ffuf lo refuerza. Un WAF o una regla de rate-limit sobre el número de Host: distintos por origen lo detecta. Peticiones con un Host: que no corresponde a ningún vhost publicado son el indicio.

Defensa. No confiar en que un subdominio sea "secreto" por no estar enlazado: si responde, se encuentra. Los vhosts sensibles deben protegerse con autenticación o filtrado por red, no fiarlo todo a la oscuridad.