Web Content Discovery (Directory Fuzzing)

Un servidor web solo enseña lo que alguien decidió enlazar. El panel de administración, el backup.zip que quedó olvidado, el .git/ desplegado por error o el db.php de pruebas siguen ahí y siguen respondiendo, pero no hay ningún enlace que lleve a ellos. No estar enlazado no es no existir, y por eso, después de mirar la portada, el paso obligado es preguntar por rutas a ciegas: se lanzan miles de peticiones con nombres de un diccionario y se observa cuáles responden distinto de las que no existen.

# gobuster: rápido, con extensiones acordes a la tecnología detectada
gobuster dir -u http://10.10.10.10 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
  -x php,txt,bak,zip -t 50

# dirsearch: parecido, filtrando los códigos que no aportan
dirsearch -u http://10.10.10.10 -e php,html -x 403,404

# ffuf / wfuzz: la palabra FUZZ marca dónde va el diccionario, así que sirven
# para rutas, parámetros, cabeceras o campos de un POST
ffuf -u http://10.10.10.10/FUZZ -w raft-medium-directories.txt -fs 4242
wfuzz -u 'http://10.10.10.10/index.php?FUZZ=id' -w burp-parameter-names.txt --hh=275

Qué hace cada flag (y por qué).

• -w (el diccionario) es, con diferencia, lo que más condiciona el resultado. Ninguna herramienta "descubre" nada: solo prueba las palabras que le das. common.txt es rápido para una primera pasada; directory-list-2.3-medium.txt o los raft-* de SecLists son el estándar cuando la primera pasada no saca nada. Si el objetivo es un producto concreto (WordPress, Jenkins), un diccionario específico de ese producto rinde mucho más que uno genérico.
• -x php,txt,bak (-e en dirsearch) prueba cada palabra también con esas extensiones. Es necesario porque el servidor ejecuta el fichero: pedir /admin puede dar 404 mientras /admin.php devuelve 200. Las extensiones no se eligen al azar, salen de la tecnología que ya identificó el escaneo de versiones o whatweb (escaneo de puertos): PHP → php, IIS/.NET → asp,aspx, y siempre conviene añadir las de descuido (bak, old, zip, txt, ~).
• -t (hilos) sube las peticiones en paralelo. Más hilos es más rápido, pero también más ruido y más posibilidades de tumbar una aplicación frágil o de que un WAF corte; 40-50 es un punto razonable.
• Filtrar la respuesta base es la clave del fuzzing. Lo intuitivo es descartar los 404 (-b 404, --hc=404), pero muchas aplicaciones responden 200 con una página de "no encontrado", y entonces todo parece existir. La solución es pedir primero algo que seguro no existe (/asdfasdf123), anotar el tamaño de esa respuesta y filtrarlo: --hh=<bytes> en wfuzz (--hl por líneas, --hw por palabras) o -fs <bytes> en ffuf (-fl, -fw). Lo que sobreviva al filtro es lo que de verdad responde distinto, es decir, lo que existe.
• Recursión (-r en feroxbuster, --recursion en gobuster) vuelve a fuzzear dentro de cada directorio encontrado. Sirve cuando el contenido cuelga varios niveles (/dev/api/v1/...), a costa de multiplicar las peticiones.
• -k acepta certificados autofirmados (habitual en HTTPS de laboratorio) y -H añade cabeceras, necesario para fuzzear ya autenticado (una Cookie: de sesión) o para variar el Host:, que es el caso particular del fuzzing de virtual hosts.

Leer la salida. El código de estado dice más que "encontrado o no": un 200 es contenido servido; un 301/302 suele ser un directorio que redirige a su versión con / final, o un recurso protegido que te manda al login; un 401/403 es un hallazgo igual de valioso, porque significa existe pero no me dejan, y eso marca dónde merece la pena insistir (credenciales por defecto, bypass de la restricción, otra ruta que llegue al mismo sitio).

Por qué importa. Casi toda cadena que empieza en web pasa por aquí: el panel de login que da las credenciales, el directorio de subidas donde luego cae la webshell, el .git/ que filtra el código fuente o el fichero de configuración con la contraseña de la base de datos aparecen en este paso y no en otro. Cuando un objetivo web "no tiene vector", lo habitual no es que no lo tenga, sino que el diccionario o las extensiones no eran los adecuados.

Cómo detectarlo. El fuzzing es de lo más visible en el log de acceso: cientos o miles de peticiones desde una misma IP en pocos segundos, la mayoría 404 (o del tamaño de la página de "no encontrado"), recorriendo nombres de diccionario que ningún usuario teclearía. El User-Agent de gobuster/ffuf/dirsearch y las peticiones a rutas sensibles (/.git/, .bak, /admin) lo confirman; un WAF o un rate-limit por origen lo alerta y frena. Un pico de 403/401 también delata que se están probando rutas protegidas.

Defensa. Desactivar el listado de directorios, devolver un 404 consistente (mismo código y mismo tamaño para todo lo que no existe, para que no haya nada que filtrar), no dejar copias de seguridad ni repositorios dentro del docroot, y proteger los paneles con autenticación y no con una ruta poco adivinable.