Gobuster: Guía Completa de Instalación y Uso

> Disclaimer legal: Todo lo descrito en este artículo aplica exclusivamente a entornos autorizados. HackTheBox, TryHackMe, laboratorios propios o sistemas con permiso explícito por escrito. El uso no autorizado de estas técnicas es ilegal.

Si llevas tiempo en pentesting web y todavía usas dirb como primera opción, este artículo va a cambiar eso. Gobuster es más rápido, más flexible y produce outputs limpios que puedes pipear directamente a otras herramientas. Pero la mayoría de guías se quedan en gobuster dir -u http://target -w wordlist.txt y te dejan solo cuando el servidor empieza a devolver 403 en todo, cuando los subdominios no resuelven o cuando tu wordlist genérica no encuentra nada útil.

Aquí vas a aprender a instalar Gobuster correctamente, entender sus modos de operación, configurar flags que la mayoría ignora y aplicarlo en escenarios reales sacados de CTFs y auditorías controladas. También te digo cuándo no usarlo y por qué a veces ffuf gana la batalla.

Qué necesitas antes de empezar:

  • Kali Linux, Parrot OS o cualquier distro con Go instalado (versión 1.19+)
  • Acceso a un entorno de laboratorio (HTB, THM o una VM propia)
  • Wordlists básicas: SecLists ya instalado o descargado
  • Conocimientos básicos de HTTP (códigos de estado, cabeceras, parámetros)

¿Qué es Gobuster y por qué usarlo?

Gobuster es una herramienta de fuerza bruta escrita en Go que enumera directorios, archivos, subdominios, virtual hosts y buckets S3/GCS mediante diccionario. No hace crawling, no analiza JavaScript, no sigue links — solo toma una lista de palabras y lanza peticiones HTTP concurrentes contra el objetivo.

La razón por la que Go importa aquí: la concurrencia en Go es barata. Gobuster puede manejar 50, 100 o 200 hilos simultáneos sin el overhead de memoria que tendrías con Python o Ruby haciendo lo mismo. En una prueba real contra un servidor de laboratorio, pasé de 8 minutos con dirb a 47 segundos con Gobuster usando la misma wordlist y 50 threads. Eso no es marketing — es la diferencia entre Go y C con libcurl mal optimizado.

Los modos disponibles son:

  • dir — fuerza bruta de directorios y archivos
  • dns — enumeración de subdominios
  • vhost — descubrimiento de virtual hosts
  • fuzz — fuzzing genérico (reemplaza FUZZ en cualquier parte de la URL)
  • s3 — buckets de Amazon S3
  • gcs — buckets de Google Cloud Storage

Para pentesting web cotidiano, vas a vivir en dir, dns y vhost. El modo fuzz lo uso cuando necesito probar parámetros específicos o rutas con patrones variables.

Instalación en Kali Linux, Ubuntu y desde código fuente

Kali Linux

En Kali actualizado ya viene preinstalado. Verifica:

gobuster version

Si no está o está desactualizado:

sudo apt update && sudo apt install gobuster -y

Ubuntu / Debian

sudo apt update
sudo apt install gobuster -y

Si el repositorio no tiene la versión que necesitas (pasa frecuentemente en Ubuntu LTS), instala desde Go directamente.

Desde código fuente (método recomendado para tener la última versión)

Primero, asegúrate de tener Go instalado:

go version

Si no está:

sudo apt install golang-go -y

Luego instala Gobuster:

go install github.com/OJ/gobuster/v3@latest

El binario queda en ~/go/bin/gobuster. Para usarlo desde cualquier lugar:

echo 'export PATH=$PATH:~/go/bin' >> ~/.bashrc
source ~/.bashrc

Verificación de instalación

gobuster --help

Deberías ver algo así:

Usage:
  gobuster [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  dir         Uses directory/file enumeration mode
  dns         Uses DNS subdomain enumeration mode
  fuzz        Uses fuzzing mode. Replaces the keyword FUZZ in the URL, Headers and the request body
  gcs         Uses gcs bucket enumeration mode
  help        Help about any command
  s3          Uses aws bucket enumeration mode
  tftp        Uses TFTP enumeration mode
  version     shows the current version
  vhost       Uses VHOST enumeration mode

Flags:
  -h, --help                 help for gobuster
      --no-color             Disable color output
      --no-error             Don't display errors
  -o, --output string        Output file to write results to (defaults to stdout)
  -p, --pattern string       File containing replacement patterns
  -q, --quiet                Don't print the banner and other noise
  -t, --threads int          Number of concurrent threads (default 10)
  -v, --verbose              Verbose output (errors)
  -w, --wordlist string      Path to the wordlist. Set to - to use STDIN.
      --wordlist-offset int  Resume from a given position in the wordlist (defaults to 0)

Gobuster v3.6.0: Novedades y Cambios

La versión 3.6.0 de Gobuster introduce mejoras significativas en la gestión de sesiones autenticadas y optimizaciones de rendimiento que marcan diferencia en escenarios reales de pentesting.

Mejoras principales en v3.6.0:

  • Soporte mejorado de cookies con –cookies: manejo nativo de sesiones autenticadas sin necesidad de headers personalizados.
  • Mejor manejo de redirects: ahora puedes controlar si seguir o no las redirecciones con mayor granularidad.
  • Optimización de timeouts: mejor gestión de conexiones lentas y servidores que tardan en responder.
  • Output mejorado en modo vhost: detección más precisa de falsos positivos en virtual hosts.
  • Corrección de bugs en modo DNS: resolución más estable con servidores DNS lentos o con rate limiting.

Si vienes de versiones anteriores (3.1 – 3.5), la actualización vale la pena especialmente si trabajas con aplicaciones que requieren autenticación por sesión.

Modos de uso: dir, dns, vhost y fuzz

Modo dir — El pan de cada día

Este es el modo que más vas a usar. La sintaxis básica:

gobuster dir -u http://10.10.10.100 -w /usr/share/seclists/Discovery/Web-Content/common.txt

Pero eso es lo mínimo. En la práctica, siempre agrego estos flags:

gobuster dir \
  -u http://10.10.10.100 \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
  -t 50 \
  -x php,html,txt,bak,old \
  -b 404,403 \
  -o gobuster_dir_results.txt \
  --timeout 10s
  • -t 50: 50 threads. En CTFs puedes subir a 100 sin problema. En auditorías reales, habla con el cliente primero.
  • -x php,html,txt,bak,old: extensiones a probar. El .bak y .old encuentran backups con más frecuencia de lo que crees.
  • -b 404,403: excluye estos códigos del output. Útil cuando el servidor devuelve 403 en todo.
  • --timeout 10s: evita que threads colgados bloqueen el scan.

Modo dns — Subdominios

gobuster dns \
  -d hackthebox.eu \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -t 30 \
  --timeout 5s

Importante: para que el modo DNS funcione correctamente, el resolver del sistema tiene que poder resolver el dominio base. Si estás atacando un dominio interno en HTB o THM, necesitas agregar el servidor DNS del laboratorio a /etc/resolv.conf o usar el flag --resolver.

Modo vhost — Virtual Hosts

Este modo es diferente al DNS. En lugar de consultar DNS, manda peticiones HTTP cambiando el header Host. Útil cuando el servidor tiene múltiples aplicaciones en la misma IP:

gobuster vhost \
  -u http://10.10.10.100 \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -t 30 \
  --append-domain \
  -o vhost_results.txt

El flag --append-domain (disponible desde v3.2) agrega el dominio base a cada palabra de la wordlist, generando admin.target.htb, dev.target.htb, etc.

Modo fuzz

gobuster fuzz \
  -u "http://10.10.10.100/FUZZ/dashboard" \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -b 404 \
  -t 40

La palabra FUZZ puede ir en cualquier parte de la URL, incluso en headers con -H "X-Custom-Header: FUZZ".

Wordlists: cuáles usar y cuándo

La wordlist hace o rompe un scan. Usar rockyou.txt para directorios web es uno de los errores más comunes que veo en juniors — esa lista es para contraseñas, no para paths HTTP.

SecLists — Tu punto de partida

Si no tienes SecLists:

sudo apt install seclists -y

O clona el repo:

git clone https://github.com/danielmiessler/SecLists.git /opt/seclists

Las wordlists que uso con más frecuencia:

| Wordlist | Cuándo usarla |

|—|—|

| Discovery/Web-Content/common.txt | Scan inicial rápido (~4700 palabras) |

| Discovery/Web-Content/directory-list-2.3-medium.txt | Scan estándar (~220k palabras) |

| Discovery/Web-Content/raft-large-files.txt | Cuando buscas archivos específicos |

| Discovery/Web-Content/big.txt | Cuando medium no encuentra nada |

| Discovery/DNS/subdomains-top1million-5000.txt | DNS rápido |

| Discovery/DNS/subdomains-top1million-20000.txt | DNS completo |

Wordlists específicas por tecnología

Esto es lo que separa un scan genérico de uno efectivo. Si identificas que el servidor corre WordPress:

gobuster dir \
  -u http://10.10.10.100 \
  -w /usr/share/seclists/Discovery/Web-Content/CMS/wordpress.fuzz.txt \
  -t 40

SecLists tiene listas específicas para WordPress, Drupal, Joomla, Magento, Jenkins, Tomcat y más en Discovery/Web-Content/CMS/.

Wordlists propias

En auditorías largas, genero wordlists contextuales con cewl:

cewl http://target.com -d 3 -m 4 -w custom_wordlist.txt

Esto extrae palabras del propio sitio web. Si la empresa se llama «Acme Corp» y tiene productos con nombres específicos, esas palabras aparecen en rutas de admin, backups y archivos de configuración con más frecuencia de lo esperado.

Ejemplos reales: CTFs y pentests controlados

Ejemplo 1 — HTB: Trick (Linux, Medium)

En esta máquina, el scan inicial con common.txt no encontró nada útil en el dominio principal. El servidor respondía 200 en todo (un WAF o configuración personalizada de Nginx devolviendo la página de inicio para rutas inexistentes).

Primero identifiqué el comportamiento del servidor:

curl -s -o /dev/null -w "%{http_code}" http://trick.htb/nonexistent_path_12345

Devolvió 200. Eso significa que no puedo filtrar por código de estado de la forma habitual. Necesito filtrar por tamaño de respuesta.

gobuster dir \
  -u http://trick.htb \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
  -t 50 \
  --exclude-length 5480 \
  -o trick_dir.txt

El --exclude-length filtra respuestas por tamaño en bytes. Primero hice una petición manual a una ruta inexistente, vi que el body tenía 5480 bytes, y usé ese valor para excluirlo. Output real del scan:

===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Medhurst (@OJ)
===============================================================
[+] Url:                     http://trick.htb
[+] Method:                  GET
[+] Threads:                 50
[+] Wordlist:                /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] Exclude Length:          5480
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory/file enumeration mode
===============================================================
/assets               (Status: 301) [Size: 185] [--> http://trick.htb/assets/]
/css                  (Status: 301) [Size: 185] [--> http://trick.htb/css/]
/js                   (Status: 301) [Size: 185] [--> http://trick.htb/js/]
Progress: 220560 / 220561 (100.00%)
===============================================================
Finished
===============================================================

Nada útil en el dominio principal. Pivotamos a enumeración DNS y encontramos preprod-payroll.trick.htb, que resultó ser el vector de entrada real.

Ejemplo 2 — Auditoría controlada: panel de administración oculto

En una auditoría de caja gris contra una aplicación PHP, el cliente mencionó que había un «panel de mantenimiento» pero no sabía la ruta. Scan con extensiones específicas para PHP:

gobuster dir \
  -u https://app.cliente.internal \
  -w /usr/share/seclists/Discovery/Web-Content/raft-large-files.txt \
  -x php,php5,php7,phtml \
  -t 30 \
  -k \
  --timeout 15s \
  -o panel_scan.txt

El flag -k ignora errores de certificado SSL — necesario porque el entorno interno usaba un certificado autofirmado. Sin ese flag, Gobuster aborta en el primer intento.

Resultado relevante del scan:

/maintenance_v2.php   (Status: 200) [Size: 4821]
/setup.php            (Status: 200) [Size: 1203]
/config.php.bak       (Status: 200) [Size: 892]

El config.php.bak contenía credenciales de base de datos en texto plano. El archivo backup había quedado expuesto después de una migración. Ese hallazgo solo apareció porque incluí .bak en las extensiones — la mayoría de scans genéricos no lo hacen.

Flags avanzados que la mayoría ignora

--exclude-length — Filtrado por tamaño

Ya lo viste arriba. Es el flag más útil cuando el servidor no devuelve 404 correctamente. Puedes especificar múltiples tamaños separados por coma:

--exclude-length 5480,5481,5482

-H — Headers personalizados

Cuando el servidor requiere autenticación por header o tienes una API key:

gobuster dir \
  -u http://api.target.htb \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." \
  -H "X-API-Key: supersecretkey" \
  -t 30

-c — Cookies de sesión

Para enumerar rutas dentro de una aplicación autenticada:

gobuster dir \
  -u http://target.htb/dashboard \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -c "PHPSESSID=abc123def456; auth_token=xyz789" \
  -t 30

--proxy — Routear por Burp Suite

Útil cuando quieres ver las peticiones en Burp mientras Gobuster escanea:

gobuster dir \
  -u http://target.htb \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  --proxy http://127.0.0.1:8080 \
  -t 10

Baja los threads a 10 cuando usas proxy — Burp puede saturarse con demasiadas peticiones simultáneas.

--random-agent y -a

Para rotar el User-Agent o usar uno específico:

gobuster dir \
  -u http://target.htb \
  -w wordlist.txt \
  --random-agent

O especifica uno manualmente:

Cómo usar Gobuster con Cookies (-c / –cookies)

La enumeración de directorios en aplicaciones autenticadas es uno de los escenarios más comunes en auditorías reales, pero también donde más errores veo. Muchas veces descubres que el panel de administración o rutas críticas solo son accesibles con una sesión válida — si lanzas Gobuster sin autenticación, el servidor te redirige al login o devuelve 403 en todo.

El flag -c (o --cookies) te permite inyectar cookies de sesión en cada petición que Gobuster realiza. La sintaxis básica es:

gobuster dir \ -u http://target.htb/dashboard \ -w /usr/share/seclists/Discovery/Web-Content/common.txt \ -c «PHPSESSID=abc123def456; auth_token=xyz789» \ -t 30

Paso a paso: Obtener y usar cookies de sesión

1. Autentícate manualmente en la aplicación

Abre el navegador (preferiblemente Firefox con las DevTools abiertas), inicia sesión normalmente con credenciales válidas.

2. Captura las cookies de sesión

En Firefox DevTools (F12) → pestaña Storage → Cookies → selecciona el dominio. Verás algo como:

PHPSESSID=r2d4k8m9p1q7s3t5 user_auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

Alternativamente, desde la terminal con curl:

curl -i -X POST http://target.htb/login \ -d «username=admin&password=P@ssw0rd» \ | grep -i «Set-Cookie»

Esto te devuelve los headers Set-Cookie que el servidor envía tras autenticarte.

3. Formatea las cookies para Gobuster

El formato es "nombre1=valor1; nombre2=valor2". Importante: todo entre comillas y separado por punto y coma + espacio.

4. Lanza Gobuster con las cookies

gobuster dir \ -u http://target.htb/admin \ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \ -c «PHPSESSID=r2d4k8m9p1q7s3t5; user_auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…» \ -t 40 \ -x php,html \ -o admin_authenticated_scan.txt

Ejemplo real: CTF con panel autenticado

En un CTF de TryHackMe (sala «Internal»), había un panel de administración en /blog/wp-admin que requería autenticación. Conseguí credenciales válidas mediante fuerza bruta con Hydra (admin:my2boys).

Primero me autentiqué manualmente y capturé la cookie de sesión con las DevTools:

wordpress_logged_in_123abc=admin%7C1234567890%7CaBcDeF…

Luego enumeré el panel autenticado:

gobuster dir \ -u http://internal.thm/blog/wp-admin \ -w /usr/share/seclists/Discovery/Web-Content/CMS/wordpress.fuzz.txt \ -c «wordpress_logged_in_123abc=admin%7C1234567890%7CaBcDeF…» \ -t 30 \ -x php \ -o wp_admin_scan.txt

Resultado relevante del scan:

/theme-editor.php (Status: 200) [Size: 4821] /plugin-editor.php (Status: 200) [Size: 5203] /upload.php (Status: 200) [Size: 3102]

Sin la cookie de sesión, todas esas rutas habrían devuelto redirección 302 al login. Con la sesión válida, Gobuster encontró el editor de temas (theme-editor.php), que usé para inyectar una webshell en el tema activo y conseguir RCE.

Verificar que las cookies funcionan antes del scan completo

gobuster dir \
  -u http://target.htb \
  -w wordlist.txt \
  -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

--no-error y -q — Output limpio

Cuando hay muchos errores de conexión que ensucian el output:

gobuster dir \
  -u http://target.htb \
  -w wordlist.txt \
  --no-error \
  -q \
  -o results.txt

-q suprime el banner y el progreso. Útil cuando pipeas el output a otra herramienta.

Gobuster vs ffuf vs dirsearch: comparativa honesta

Esta es la pregunta que más me hacen, así que voy directo.

Gobuster gana cuando:

  • Necesitas velocidad pura con una wordlist grande y un objetivo estable
  • El output limpio importa (pipear resultados a grep, awk, o scripts)
  • Estás enumerando subdominios DNS o virtual hosts — su modo dns y vhost están mejor implementados que en dirsearch
  • Quieres una herramienta con pocas dependencias que compile en cualquier sistema con Go

ffuf gana cuando:

  • Necesitas fuzzing de parámetros GET/POST con múltiples posiciones simultáneas
  • Quieres filtros más granulares (por palabras en el body, regex en la respuesta, tiempo de respuesta)
  • Estás haciendo fuzzing de APIs REST donde la estructura de la respuesta importa para filtrar falsos positivos
  • Necesitas el modo de calibración automática (-ac) para ajustar filtros dinámicamente

dirsearch gana cuando:

  • Quieres algo que funcione out-of-the-box con configuración mínima para un scan rápido
  • Necesitas recursión automática (dirsearch la maneja mejor nativamente)

Mi observación técnica específica: Gobuster en modo vhost es superior a ffuf para descubrimiento de virtual hosts porque maneja correctamente la diferencia entre una respuesta del vhost por defecto y un vhost real. ffuf con --vhost a veces marca como positivos virtual hosts que simplemente devuelven la misma respuesta que el host base, especialmente cuando el servidor tiene un wildcard DNS configurado. Gobuster compara el tamaño de respuesta automáticamente y es más conservador con los falsos positivos en ese modo específico.

La realidad práctica: tengo los tres instalados y los uso según el contexto. No hay una sola herramienta que gane en todos los escenarios.

Errores comunes y cómo evitarlos

Error 1: No manejar el «soft 404»

El error más frecuente que veo. El servidor devuelve HTTP 200 para rutas inexistentes (redirección a página de inicio, página de error personalizada con código 200, etc.). Gobuster marca todo como encontrado y el output tiene miles de falsos positivos.

Solución: Antes de lanzar cualquier scan, haz una petición manual a una ruta que definitivamente no existe y anota el tamaño de la respuesta:

curl -s http://target.htb/esta_ruta_no_existe_12345abc | wc -c

Luego usa --exclude-length con ese valor. Si el servidor varía el tamaño ligeramente (algunos incluyen timestamps en la respuesta), excluye un rango:

--exclude-length 5480,5481,5482,5483,5484,5485

Error 2: Usar wordlists genéricas para tecnologías específicas

directory-list-2.3-medium.txt es una buena lista general, pero si sabes que el objetivo corre Tomcat, Jenkins o un CMS específico, estás desperdiciando tiempo con una lista genérica y probablemente perdiendo rutas relevantes.

Identifica la tecnología primero con whatweb o revisando los headers HTTP, luego selecciona la wordlist correspondiente:

whatweb http://target.htb

Si devuelve Apache Tomcat, usa:

gobuster dir \
  -u http://target.htb \
  -w /usr/share/seclists/Discovery/Web-Content/tomcat.txt \
  -t 30

Error 3: Ignorar el rate limiting y quemar el acceso

En CTFs esto no importa tanto, pero en auditorías reales es un problema serio. Muchos WAFs y sistemas de detección de intrusiones bloquean IPs que generan más de X peticiones por segundo. Si lanzas Gobuster con 100 threads contra un objetivo con protección, tu IP queda bloqueada y pierdes acceso durante horas o días.

Señales de que te están rate-limiting:

  • Las respuestas empiezan a devolver 429 (Too Many Requests)
  • Los tiempos de respuesta aumentan dramáticamente
  • Empiezas a recibir conexiones rechazadas cuando antes funcionaba

Solución: Empieza conservador con -t 10 y --delay 100ms. Si el servidor aguanta, sube gradualmente. En auditorías reales, coordina con el cliente el horario de los scans intensivos.

gobuster dir \
  -u http://target.htb \
  -w wordlist.txt \
  -t 10 \
  --delay 100ms

Error 4 (bonus): Olvidar el flag -k con HTTPS

Si el objetivo usa HTTPS con certificado autofirmado o caducado, Gobuster falla silenciosamente o con errores de TLS. El flag -k (o --no-tls-validation) resuelve esto:

gobuster dir \
  -u https://target.htb \
  -w wordlist.txt \
  -k \
  -t 30

Limitaciones reales que los tutoriales omiten

Gobuster no hace recursión automática. Si encuentra /admin/, no escanea automáticamente el contenido de ese directorio. Tienes que lanzar un segundo scan manualmente apuntando a esa ruta. dirsearch y feroxbuster manejan esto mejor. Para trabajo recursivo, uso feroxbuster que fue diseñado específicamente para eso.

No analiza el contenido de las respuestas. Si un directorio devuelve 200 pero está vacío, Gobuster lo reporta como encontrado igual. Necesitas verificar manualmente o pipear los resultados a curl para filtrar por contenido.

El modo dns depende completamente de tu resolver. En redes de laboratorio con DNS interno, si tu /etc/resolv.conf no apunta al servidor DNS correcto, el modo DNS no encuentra nada aunque los subdominios existan. Usa --resolver para especificar el servidor DNS directamente:

gobuster dns \
  -d target.htb \
  -w wordlist.txt \
  --resolver 10.10.10.100:53

Tiempo real del proceso: Un scan estándar con directory-list-2.3-medium.txt (220k palabras) a 50 threads contra un servidor con latencia normal tarda entre 3 y 8 minutos. Con extensiones adicionales (cada extensión multiplica las peticiones), puede subir a 20-30 minutos. Planifica en consecuencia cuando tienes una ventana de tiempo limitada para la auditoría.

Próximos pasos

Si Gobuster ya forma parte de tu flujo de reconocimiento, el siguiente nivel es integrarlo en una metodología más completa:

  1. Enumeración web completa con ffuf — Aprende a usar ffuf para fuzzing de parámetros y APIs REST donde Gobuster se queda corto. Cubre el modo de calibración automática y filtrado por regex. [Ver guía de ffuf en hackchest.net]
  1. Reconocimiento pasivo con Amass y Subfinder — Antes de lanzar Gobuster en modo DNS, la enumeración pasiva de subdominios con Amass puede darte un mapa inicial sin generar tráfico hacia el objetivo. Combinados, cubren ángulos que ninguno de los dos alcanza solo. [Ver guía de reconocimiento pasivo en hackchest.net]
  1. Automatización del reconocimiento web — Cómo integrar Gobuster, Nikto, whatweb y nuclei en un script de reconocimiento automatizado que puedes lanzar al inicio de cada engagement y recibir los resultados organizados. [Ver guía de automatización de recon en hackchest.net]

FAQ

¿Gobuster puede escanear a través de Tor o con rotación de IPs?

Sí, pero con limitaciones. Puedes routear Gobuster a través de un proxy SOCKS5 de Tor usando --proxy socks5://127.0.0.1:9050. El problema es que Tor es lento y Gobuster con muchos threads va a saturar el circuito, resultando en timeouts masivos. Si necesitas anonimato real, baja los threads a 5-10 y acepta que el scan va a tardar mucho más. Para rotación de IPs, la solución más práctica es combinar Gobuster con proxychains y una lista de proxies, aunque en auditorías legítimas esto raramente es necesario.

¿Por qué Gobuster no encuentra nada aunque sé que hay directorios?

Hay tres causas principales: (1) La wordlist no contiene el nombre del directorio — prueba con wordlists más grandes o específicas para la tecnología. (2) El servidor requiere autenticación o una cookie de sesión válida — usa -c con una sesión activa. (3) El servidor tiene protección WAF que está bloqueando tus peticiones — revisa si recibes 403 o 429 consistentemente y considera bajar los threads o agregar delays.

¿Cuál es la diferencia entre el modo dns y el modo vhost?

El modo dns hace consultas DNS reales para verificar si un subdominio existe como registro A o CNAME. El modo vhost manda peticiones HTTP cambiando el header Host de la petición. Usa dns cuando el objetivo tiene subdominios públicos en DNS. Usa vhost cuando los subdominios están configurados en el servidor web pero no necesariamente en DNS público — esto es común en aplicaciones internas, CTFs con entradas en /etc/hosts y entornos de staging. En la práctica, en HTB y THM casi siempre necesitas vhost porque los subdominios solo existen en el servidor, no en DNS público.