El reconocimiento es la primera fase de cualquier evaluación de seguridad web y, en muchos sentidos, la más determinante. Antes de explotar una vulnerabilidad hay que encontrarla; antes de encontrarla hay que entender cómo está construida la aplicación, qué tecnologías usa, qué rutas expone y qué superficie de ataque ofrece. Un pentester que se salta esta fase suele pasar por alto vectores críticos que sí detectaría un atacante paciente.
Este módulo cubre la metodología completa de reconocimiento aplicada a aplicaciones web, con herramientas reales y práctica sobre laboratorios legales. Todo lo que aquí se describe está orientado a entornos propios o con autorización expresa por escrito. Ejecutar estas técnicas contra sistemas de terceros sin permiso constituye un delito en España tipificado en los artículos 197 bis y siguientes del Código Penal.
1. Reconocimiento pasivo frente a reconocimiento activo
La distinción entre reconocimiento pasivo y activo no es solo académica: determina el riesgo de detección, la huella que dejas y las implicaciones legales de cada acción.
Reconocimiento pasivo
En el reconocimiento pasivo no envías ningún paquete directamente al objetivo. Consultas fuentes públicas: motores de búsqueda, bases de datos WHOIS, certificados TLS, registros DNS públicos, repositorios de código, LinkedIn, foros, Wayback Machine… La aplicación nunca ve tu tráfico. Esto te permite recopilar información de inteligencia (OSINT) sin alertar sistemas de detección (IDS/IPS/WAF) ni dejar rastro en los logs del servidor.
Ejemplos de fuentes pasivas: Google Dorks, Shodan, Censys, BuiltWith, SecurityTrails, crt.sh para enumeración de certificados y Wayback Machine para versiones históricas de la aplicación. Las técnicas OSINT son la base del reconocimiento pasivo y se desarrollan en profundidad en la guía Hacking Web: guía completa.
Reconocimiento activo
En el reconocimiento activo interactúas directamente con el objetivo: envías peticiones HTTP, lanzas escáneres de puertos, fuzeas directorios o rastreas la aplicación con un spider. Toda esta actividad queda registrada en los logs del servidor y puede activar alertas. Por eso, en un pentest real, el reconocimiento activo solo se realiza cuando el cliente ha firmado el alcance y autoriza expresamente dicho tráfico.
En laboratorios como OWASP Juice Shop o DVWA en local, esas restricciones no aplican porque el objetivo eres tú mismo. Es el entorno ideal para practicar sin consecuencias.
Recordatorio legal: En España, acceder sin autorización a sistemas informáticos ajenos, interceptar comunicaciones o introducirse en redes privadas está penado por el artículo 197 bis del Código Penal con hasta dos años de prisión (y hasta cinco si se accede a datos protegidos). Antes de cualquier prueba activa, obtén siempre autorización por escrito que especifique el alcance, las fechas y las técnicas permitidas.
2. Fingerprinting de tecnología
Identificar el stack tecnológico de la aplicación —servidor web, lenguaje de backend, CMS, frameworks, librerías JavaScript— es el primer paso del reconocimiento activo. Cada tecnología tiene vulnerabilidades conocidas; conocer la versión exacta reduce el espacio de búsqueda enormemente.
WhatWeb
WhatWeb es una herramienta de línea de comandos que identifica tecnologías web analizando cabeceras HTTP, cookies, meta-tags, scripts y patrones en el HTML. Viene preinstalada en Kali Linux.
# Escaneo básico (nivel de agresión 1, solo una petición)
whatweb http://localhost:3000
# Salida detallada con nivel de agresión 3 (más peticiones, más datos)
whatweb -a 3 -v http://localhost:3000
# Exportar a JSON para procesado posterior
whatweb -a 1 --log-json=resultado.json http://localhost:3000
WhatWeb define tres niveles de agresión: 1 (sigiloso, una sola petición por objetivo y seguir redirecciones), 3 (agresivo: si un plugin de nivel 1 hace match, lanza peticiones adicionales) y 4 (pesado: muchas peticiones por objetivo). No existe un nivel 2. En producción ajena, si tuvieras permiso, usarías nivel 1. En el lab usa el que quieras.
Cabeceras HTTP de respuesta
Las cabeceras de respuesta HTTP revelan con frecuencia más información de la que debería: versión de Apache/Nginx, lenguaje de servidor (X-Powered-By: PHP/8.1), frameworks, librerías y configuraciones de seguridad ausentes.
# Con curl: ver solo las cabeceras de respuesta
curl -sI http://localhost:3000
# Con curl: seguir redirecciones y ver cabeceras de cada salto
curl -sIL http://localhost:3000
Presta atención a cabeceras como Server, X-Powered-By, X-Generator, X-AspNet-Version o X-Runtime. Su presencia indica que no se han aplicado las medidas de bastionado básicas del servidor.
Wappalyzer y alternativas open source
Wappalyzer fue durante años la extensión de navegador de referencia para detectar tecnologías web (CMS, frameworks JavaScript, plataformas de e-commerce, servicios de terceros) de forma visual mientras navegas. Sin embargo, en mayo de 2023 el proyecto dejó de ser open source: su base de datos de huellas (fingerprints) pasó a código cerrado y la API se convirtió en un producto SaaS de pago. La extensión gratuita sigue existiendo pero su detección quedó congelada y el grueso de funciones útiles (consultas masivas, API, listados de tecnologías) hoy requieren una suscripción comercial.
Por eso, en 2026 no conviene depender de Wappalyzer como herramienta gratuita. Las alternativas open source vigentes son:
- WhatWeb (ya cubierto arriba): la opción CLI gratuita y mantenida más directa, preinstalada en Kali.
- webanalyze (github.com/rverton/webanalyze): port de Wappalyzer en Go, pensado para escaneo masivo de hosts, con salida a stdout, CSV o JSON.
- wappalyzergo (github.com/projectdiscovery/wappalyzergo): librería de detección en Go de ProjectDiscovery, usada internamente por herramientas como httpx.
- Forks comunitarios del ruleset previo al cierre (p. ej.
enthec/webappanalyzer) que siguen recibiendo aportaciones de fingerprints.
Ninguna sustituye por completo a WhatWeb, pero cualquiera de ellas cumple la misma función sin depender de un producto de pago.
Favicon hash
El favicon de una aplicación web (normalmente /favicon.ico) tiene un hash MD5 o MurmurHash característico. Motores como Shodan y Censys permiten buscar por ese hash, lo que puede revelar otros servidores del mismo software, paneles de administración expuestos o instancias de la misma aplicación en otros puertos/IPs. Es una técnica de reconocimiento pasivo avanzada que se estudia en profundidad en cursos como el eJPT y otras certificaciones de hacking ético.
3. Mapeo de la aplicación con Burp Suite
Burp Suite (en su edición Community o Professional) es el proxy de intercepción estándar en pentesting web. Todo el tráfico del navegador pasa a través de él, lo que permite capturar, analizar y modificar cada petición.
Configuración del proxy y el scope
- Arranca Burp Suite y ve a Proxy > Options. El listener por defecto escucha en
127.0.0.1:8080. - Configura tu navegador (o usa el navegador integrado de Burp en la pestaña Proxy > Intercept > Open Browser) para enrutar el tráfico por ese proxy.
- Ve a Target > Scope y añade la URL del laboratorio (
http://localhost:3000) como objetivo. Activa la opción «Use advanced scope control» si necesitas filtrar por rutas específicas. - En Proxy > Options, activa «Intercept responses based on the following rules» para capturar también las respuestas del servidor.
El Site Map de Burp
La pestaña Target > Site map es el corazón del mapeo con Burp. Muestra en árbol todos los hosts, rutas, parámetros y respuestas que Burp ha observado. Se puebla de forma pasiva mientras navegas: cada URL que visitas, cada petición AJAX, cada recurso estático queda registrado.
Para mapear una aplicación con Burp:
- Navega manualmente por toda la aplicación: páginas de login, registro, catálogos, búsquedas, formularios, páginas de perfil, paneles de administración accesibles, APIs. Cuanto más exhaustiva sea la navegación, más completo quedará el Site Map.
- Observa el árbol que se va formando en Target > Site map. Burp agrupa por host y muestra los códigos de respuesta de cada recurso.
- Haz clic derecho en el nodo raíz de la aplicación y selecciona «Add to scope» para limitar el análisis posterior a ese target.
- Usa el filtro del Site Map para mostrar solo respuestas con ciertos códigos de estado, tipos MIME o parámetros.
Identificación de endpoints y parámetros
Durante la navegación manual presta atención a:
- Parámetros en la URL:
?id=1,?user=admin,?redirect=— candidatos a inyección SQL, IDOR y open redirect. - Parámetros POST: formularios de login, búsqueda, registro, comentarios. Visibles en la pestaña Params de cada petición en Burp.
- Headers personalizados:
X-Forwarded-For,X-Real-IP, tokens de sesión, JWT en el header Authorization. - Endpoints de API: rutas tipo
/api/v1/users,/api/products, respuestas JSON. El Site Map los identifica por el tipo MIMEapplication/json. - Archivos JavaScript: los ficheros
.jsdel frontend suelen contener rutas de API hardcodeadas, tokens de desarrollo, URLs de entornos de staging y lógica de negocio sensible.
4. Descubrimiento de contenido y directorios
La navegación manual y el spidering de Burp solo descubren lo que está enlazado. Numerosos recursos críticos —paneles de administración, archivos de configuración, backups, endpoints de debug— no están enlazados desde ningún sitio. Para encontrarlos se usa fuerza bruta de directorios con wordlists.
ÉTICA OBLIGATORIA: El descubrimiento de contenido mediante fuerza bruta genera un volumen significativo de peticiones HTTP. Ejecutarlo contra un sistema sin autorización es fácilmente detectable, puede provocar una denegación de servicio involuntaria y constituye un acceso no autorizado. Practica exclusivamente contra tu propio laboratorio local (Juice Shop en
localhost:3000, DVWA enlocalhost:80) o contra plataformas de bug bounty que lo permitan expresamente en su scope.
SecLists: el repositorio de wordlists de referencia
SecLists (github.com/danielmiessler/SecLists) es la colección de wordlists más usada en pentesting. En Kali Linux se instala en /usr/share/seclists/. Las listas más relevantes para descubrimiento web están en Discovery/Web-Content/:
common.txt— ~4600 rutas comunes, buena relación velocidad/coberturabig.txt— varios miles de rutas, más exhaustiva quecommon.txtdirectory-list-2.3-medium.txt— ~220 000 entradas, para análisis profundosraft-medium-directories.txt— directorios curados de múltiples fuentes
ffuf — Fast Web Fuzzer
ffuf (github.com/ffuf/ffuf) es el fuzzer web más popular actualmente. Requiere colocar la palabra clave FUZZ en cualquier parte de la petición (URL, cabeceras, body, parámetros).
# Descubrimiento básico de directorios contra Juice Shop
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
# Con filtrado de códigos de estado (mostrar solo 200, 301, 302, 403)
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
-mc 200,301,302,403
# Filtrar por tamaño de respuesta (excluir respuestas de 3748 bytes = 404 custom)
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
-fs 3748
# Con extensiones de archivo (buscar .js, .json, .bak, .sql)
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
-e .js,.json,.bak,.sql,.conf
-mc 200,301,302
# Múltiples threads y con color en la salida
ffuf -w /usr/share/seclists/Discovery/Web-Content/big.txt
-u http://localhost:3000/FUZZ
-t 50
-c
-mc 200,301,302,403
# Exportar resultados a JSON
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
-mc 200,301,302,403
-of json
-o resultados-ffuf.json
gobuster — Busting en Go
gobuster (github.com/OJ/gobuster) es otra herramienta Go muy popular para fuerza bruta de directorios, DNS y virtual hosts. Su modo dir es el equivalente más directo a ffuf para descubrimiento de rutas.
En los ejemplos siguientes se usa http://localhost:80 asumiendo la imagen histórica de DVWA. Si arrancas DVWA con la imagen oficial actual (digininja/DVWA vía docker compose), ajusta el puerto a http://localhost:4280.
# Descubrimiento básico de directorios contra DVWA
gobuster dir
-u http://localhost:80
-w /usr/share/seclists/Discovery/Web-Content/common.txt
# Con extensiones de archivo y más threads
gobuster dir
-u http://localhost:80
-w /usr/share/seclists/Discovery/Web-Content/big.txt
-x php,html,txt,bak
-t 50
# Saltando verificación TLS (para labs con certificado autofirmado)
gobuster dir
-u https://localhost:443
-w /usr/share/seclists/Discovery/Web-Content/common.txt
-k
# Filtrar por código de estado (solo mostrar 200 y 301)
# IMPORTANTE: gobuster trae una blacklist por defecto (-b "404") y NO permite
# usar -s y -b a la vez. Para usar whitelist con -s hay que vaciar la blacklist
# con -b "" o la herramienta abortará con un error.
gobuster dir
-u http://localhost:80
-w /usr/share/seclists/Discovery/Web-Content/common.txt
-s 200,301
-b ""
-o resultados-gobuster.txt
Por defecto gobuster incluye todos los códigos salvo los de la blacklist (-b), cuyo valor por defecto es 404. Es el comportamiento recomendado en la mayoría de casos. Si prefieres una lista blanca explícita con -s, recuerda añadir -b "" para vaciar la blacklist; de lo contrario gobuster aborta porque no admite ambos filtros simultáneamente.
Interpretación de códigos de estado y tamaños de respuesta
| Código | Significado en content discovery | Acción |
|---|---|---|
| 200 OK | Recurso existe y es accesible | Prioridad alta: analizar contenido |
| 301/302 | Redirección permanente/temporal | Seguir la redirección; puede llevar a contenido real |
| 403 Forbidden | Recurso existe pero acceso denegado | Interesante: probar bypass de autorización |
| 401 Unauthorized | Requiere autenticación | Existe un recurso protegido; candidato a fuerza bruta de credenciales |
| 404 Not Found | No existe (en condiciones normales) | Descartar, salvo que el tamaño de respuesta sea inusual |
| 500 Internal Server Error | Error en el servidor al procesar la ruta | Puede indicar comportamiento no esperado; investigar |
El tamaño de respuesta (en bytes) es tan importante como el código de estado. Muchas aplicaciones devuelven un 200 OK para rutas inexistentes (con una página de error personalizada). Si todas las respuestas 200 tienen el mismo tamaño, ese es el tamaño de tu «falso positivo» y debes filtrarlo con -fs en ffuf o con --exclude-length (abreviado --xl) en gobuster.
5. Fuentes de información pasiva en la propia aplicación
Antes de lanzar herramientas de fuerza bruta, revisa siempre las fuentes de información que la propia aplicación expone públicamente. Son los primeros lugares que un atacante (o pentester) consulta.
robots.txt
El fichero /robots.txt le indica a los crawlers de los motores de búsqueda qué rutas no deben indexar. Pero al ser público, hace exactamente lo contrario desde el punto de vista del atacante: lista las rutas que el propietario quiere mantener ocultas. Es habitual encontrar rutas como /admin, /backup, /staging o /internal.
curl http://localhost:3000/robots.txtsitemap.xml
El sitemap XML lista todas las URLs de la aplicación para facilitar la indexación. Proporciona un inventario completo de la superficie pública de la app sin necesidad de crawling.
curl http://localhost:3000/sitemap.xmlComentarios en HTML y JavaScript
Los comentarios en el código fuente HTML y en archivos JavaScript son una fuente frecuente de información sensible: credenciales hardcodeadas, URLs de APIs internas, nombres de desarrolladores, TODOs que revelan vulnerabilidades conocidas y rutas de entornos de desarrollo.
En Burp, mientras navegas, haz clic derecho en cualquier respuesta HTML y selecciona «Send to Repeater» para examinarla. En el navegador, Ctrl+U (ver fuente) o las DevTools (F12) sirven para el mismo fin. Para buscar comentarios en JavaScript de forma sistemática, herramientas como grep o extensiones como LinkFinder automatizan la tarea.
Archivos expuestos
Es sorprendentemente común encontrar en aplicaciones web archivos que nunca deberían estar accesibles públicamente: ficheros .git expuestos (que permiten reconstruir el código fuente), .env con credenciales, backups (.bak, .old, .zip), ficheros de configuración (config.php.bak, web.config), logs (error.log, access.log) y dumps de base de datos (db.sql).
Las wordlists de SecLists como Discovery/Web-Content/web-extensions.txt y Fuzzing/extensions-most-common.fuzz.txt incluyen extensiones orientadas a encontrar estos archivos.
6. Enumeración de subdominios (introducción)
Una aplicación web no vive solo en www.ejemplo.com. Los subdominios amplían enormemente la superficie de ataque: admin.ejemplo.com, api.ejemplo.com, staging.ejemplo.com, dev.ejemplo.com, test.ejemplo.com… Estos entornos secundarios suelen tener menos medidas de seguridad que el dominio principal.
La enumeración de subdominios combina técnicas pasivas y activas, y conviene distinguir qué hace cada herramienta:
- subfinder (projectdiscovery/subfinder): enumeración pasiva, consultando fuentes públicas (logs de Certificate Transparency, APIs de terceros). No hace fuerza bruta. Suele ser el primer paso por ser rápido y sigiloso.
- amass (proyecto de OWASP): mapeo de superficie más profundo; combina recopilación pasiva con técnicas activas (resolución DNS, fuerza bruta opcional). Más lento pero más exhaustivo.
- dnsx (projectdiscovery/dnsx): toolkit DNS rápido para validar los candidatos obtenidos (resolución masiva, filtrado de wildcards) y, con un diccionario, hacer fuerza bruta de nombres.
La parte pasiva (consultas a crt.sh, CT logs, subfinder) no toca los servidores del objetivo. La parte activa —resolución masiva y fuerza bruta DNS con amass o dnsx— genera muchas consultas y puede considerarse intrusiva; en programas de bug bounty, verifica siempre que el scope incluye subdominios antes de lanzarla.
En el módulo de OSINT del curso se profundiza en la metodología completa de enumeración de subdominios con estas herramientas. Para el OWASP Top 10, la enumeración de subdominios es especialmente relevante para encontrar instancias vulnerables a A02:2025 – Security Misconfiguration (que en la edición 2025 ascendió al puesto 2).
7. Práctica guiada: mapeo completo de OWASP Juice Shop
Esta práctica combina Burp Suite y ffuf para mapear OWASP Juice Shop en local. Es el flujo de trabajo estándar en la fase de reconocimiento de un pentest web real.
Paso 1: Levantar Juice Shop con Docker
# Descargar y arrancar Juice Shop (accesible en http://localhost:3000)
docker pull bkimminich/juice-shop
docker run --rm -p 3000:3000 bkimminich/juice-shop
Paso 2: Fingerprinting con WhatWeb y curl
# Identificar tecnologías
whatweb -a 1 http://localhost:3000
# Inspeccionar cabeceras de respuesta
curl -sI http://localhost:3000
Anota qué servidor web responde, qué framework usa el backend y si hay cabeceras de seguridad ausentes (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options).
Paso 3: Navegación manual con Burp Suite
- Configura Burp como proxy en
127.0.0.1:8080y abre el navegador integrado. - Navega por Juice Shop: página principal, registro de usuario, login, catálogo de productos, página de un producto, carrito, proceso de checkout, sección «About Us».
- En Target > Site map, observa cómo se puebla el árbol. Fíjate en las rutas
/api/y los endpoints REST que aparecen. - Añade
localhost:3000al scope con clic derecho «Add to scope». - Revisa los archivos JavaScript en el Site Map (busca entradas con extensión
.js). Haz clic enmain.jso similares y en la pestaña Response busca rutas de API conCtrl+F.
Paso 4: Revisión de fuentes públicas
# robots.txt
curl http://localhost:3000/robots.txt
# sitemap.xml
curl http://localhost:3000/sitemap.xml
Juice Shop expone información deliberadamente en estas rutas como parte de sus desafíos. ¿Qué encuentras?
Paso 5: Content discovery con ffuf
# Primera pasada: wordlist común, mostrar 200/301/302/403
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
-mc 200,301,302,403
-c
# Si aparecen muchos falsos positivos con el mismo tamaño, filtra por tamaño
# (reemplaza 3748 por el tamaño real que observes en las respuestas 404)
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
-mc 200,301,302,403
-fs 3748
-c
# Segunda pasada: buscar archivos JavaScript adicionales
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt
-u http://localhost:3000/FUZZ
-e .js,.json,.map
-mc 200
-c
Paso 6: Análisis de resultados
Con los resultados de ffuf y el Site Map de Burp, construye un inventario de la aplicación:
- Lista de endpoints de la API (
/api/Users,/api/Products,/api/Challenges…) - Rutas con respuestas 403 (existen pero están protegidas)
- Archivos estáticos interesantes (JavaScript con lógica de negocio)
- Rutas administrativas (
/administrationen Juice Shop está ahí…)
Este inventario es la base sobre la que trabajarás en los módulos posteriores de explotación.
8. Ejercicio propuesto
Realiza el proceso completo de reconocimiento sobre DVWA (Damn Vulnerable Web Application) en lugar de Juice Shop. DVWA tiene un stack diferente (PHP/Apache/MySQL) y una estructura de directorios distinta.
- Instala DVWA con Docker. La imagen histórica
vulnerables/web-dvwasigue funcionando pero está desactualizada (no se reconstruye desde el código actual). En 2026 se recomienda la imagen oficial del repositorio digininja/DVWA, que se publica en GitHub Container Registry y se levanta condocker compose up -d(queda accesible enhttp://localhost:4280). Tras arrancarla, accede a/setup.phpy pulsa «Create / Reset Database» para inicializarla. - Ejecuta WhatWeb e identifica las tecnologías. Compara con Juice Shop.
- Configura Burp y navega por DVWA con todos los niveles de seguridad (Low, Medium, High). Documenta los endpoints y parámetros que encuentras.
- Lanza ffuf con
directory-list-2.3-medium.txty las extensiones.php,.txt,.bak,.old. ¿Qué encuentras que no estaba enlazado? - Consulta
/robots.txty el código fuente de cada página. ¿Hay comentarios reveladores?
Errores comunes en la fase de reconocimiento
Lanzar content discovery sin filtrar falsos positivos
Si no filtras por tamaño de respuesta o código de estado, te ahogarás en miles de resultados irrelevantes. Antes de lanzar ffuf o gobuster, haz una petición a una ruta que sabes que no existe (curl -v http://localhost:3000/rutafalsa123) y anota el código y tamaño de respuesta. Ese es tu falso positivo de referencia; filtralo con -fs o -fc.
Ignorar los archivos JavaScript
El mayor error en reconocimiento web moderno es centrarse solo en rutas del servidor y olvidar los ficheros JavaScript del frontend. Las aplicaciones SPA (Single Page Application) como Juice Shop tienen prácticamente toda su lógica de rutas y llamadas a la API en el JavaScript. Revisar el bundle principal (main.js, chunk.js) con un minifier inverso o buscando patrones como api/, endpoint o fetch( puede revelar decenas de rutas que ninguna wordlist incluye.
No anotar ni organizar los hallazgos
El reconocimiento genera un volumen enorme de información. Sin una metodología de toma de notas (Obsidian, CherryTree, la propia herramienta de notas de Burp Pro o simplemente un fichero Markdown estructurado), perderás hallazgos importantes. Usa el exportador de Burp (Target > Site map > Save selected items) y los flags de output de ffuf (-of json -o output.json) desde el principio.
Saltarse el reconocimiento pasivo
La información pública disponible antes de tocar el objetivo con una sola petición puede ser decisiva: versiones antiguas de la app en Wayback Machine, credenciales filtradas en paste sites, código fuente en GitHub, registros DNS históricos. En un pentest real, el reconocimiento pasivo puede llevar más tiempo que el activo y a menudo es más fructífero.
Preguntas frecuentes
¿Puedo usar gobuster o ffuf en plataformas de bug bounty?
Depende completamente del programa. Muchos programas de bug bounty en plataformas como HackerOne o Bugcrowd permiten el escaneo activo, pero algunos lo prohíben expresamente o requieren que se realice desde un rango de IPs específico o con un User-Agent identificador. Lee siempre el policy del programa antes de lanzar cualquier herramienta de escaneo. Hacerlo sin autorización te puede descalificar del programa e incluso resultar en acción legal.
¿Qué wordlist uso primero?
Para una primera pasada rápida, common.txt (~4700 entradas) de SecLists ofrece la mejor relación tiempo/cobertura. Si tienes más tiempo o la aplicación parece grande, pasa a raft-medium-directories.txt o directory-list-2.3-medium.txt. Para extensiones de archivo, web-extensions.txt de SecLists es un buen punto de partida. En aplicaciones PHP, añade siempre -e .php; en ASP.NET, -e .asp,.aspx.
¿Cuántos threads es seguro usar sin romper la aplicación?
En un laboratorio local en tu máquina, puedes usar 100-200 threads sin problema. En un entorno de producción (con permiso), empieza siempre con un valor bajo (10-20) y aumenta progresivamente mientras monitorizas la disponibilidad de la aplicación. Un escaneo agresivo puede provocar una denegación de servicio involuntaria, lo que puede estar fuera del scope del pentest y te puede generar problemas. Para ser más sigiloso, usa --delay en gobuster o, en ffuf, -p (segundos de retardo entre peticiones, admite un rango aleatorio como -p 0.1-2.0) o -rate (límite de peticiones por segundo).
¿Qué diferencia hay entre Burp Spider y el content discovery?
Burp Spider (o el Crawler de Burp Pro) rastrea la aplicación siguiendo enlaces, formularios y referencias en el código fuente: solo encuentra lo que está enlazado. El content discovery con ffuf/gobuster busca rutas por fuerza bruta: encuentra lo que existe aunque no esté enlazado. Son técnicas complementarias, no excluyentes. En la práctica siempre se usan las dos: primero spidear para mapear lo visible, luego fuerza bruta para descubrir lo oculto.
Recordatorio ético final
Todo lo practicado en este módulo —fingerprinting, spidering, descubrimiento de directorios, análisis de JavaScript— son técnicas de doble filo. En manos de un profesional de seguridad con autorización, permiten encontrar vulnerabilidades antes de que lo hagan los atacantes. Sin autorización, las mismas técnicas constituyen un acceso no autorizado a sistemas informáticos.
Practica en laboratorios controlados como OWASP Juice Shop, DVWA, las máquinas de PortSwigger Web Security Academy o las plataformas de entrenamiento de OWASP. Cuando estés listo para el mundo real, busca programas de bug bounty en HackerOne o Bugcrowd con scope bien definido. Las certificaciones como el eJPT te preparan para realizar esta metodología de forma estructurada y profesional: más información en nuestra sección de cursos y certificaciones.