Automatización del reconocimiento web

El reconocimiento manual deja de escalar cuando cientos de nombres deben resolverse, probarse por HTTP y recorrerse sin perder su procedencia. La automatización resuelve ese volumen, pero introduce otro riesgo técnico: cada herramienta tiende a emitir solo los éxitos que entiende. Si una etapa reemplaza su entrada por esos resultados, los timeouts, rechazos y candidatos todavía no comprobados desaparecen del modelo.

Un pipeline fiable trata cada etapa como un contrato. La entrada conserva lo que se sabía antes. La salida añade una observación y sus errores. Un comando integrado puede ampliar cobertura, pero no debe mezclar fuentes pasivas, resolución, peticiones HTTP, escaneo de puertos y crawling hasta volver indistinguibles sus supuestos.

Un recorrido reproducible puede usar estos artefactos:

01-candidates.txt
        ↓
02-http.jsonl
        ↓
03-base-urls.txt
        ↓
04-crawl.jsonl
        ↓
05-review.md

01-candidates.txt contiene nombres todavía no validados. 02-http.jsonl conserva una observación HTTP por resultado. 03-base-urls.txt es la entrada deduplicada del crawler. 04-crawl.jsonl reúne recursos enlazados. 05-review.md documenta discrepancias, validaciones manuales y nuevas ramas.

No sustituyas el archivo anterior con la salida del siguiente. La ausencia de un nombre en HTTP no borra que apareció en CT o en otra fuente.

El descubrimiento de contenido se ejecuta después sobre orígenes y rutas base ya revisados. Mantén sus wordlists, filtros y resultados en un artefacto propio. Mezclar rutas enlazadas y rutas adivinadas impide saber qué técnica produjo cada candidato.

El flujo de información de dominios explica subfinder y sus fuentes. La primera etapa produce una línea por nombre:

subfinder -d DOMAIN -silent -o 01-candidates.txt

Añade a ese conjunto los SAN, nombres extraídos de Certificate Transparency, HTML, JavaScript y archivos históricos. Conserva además un registro con la fuente de cada nombre. El archivo plano sirve como interfaz entre herramientas, no como modelo de procedencia.

HTTPX recibe una lista mediante -l. Las opciones -sc, -title, -server y -td añaden código, título, cabecera del servidor y tecnologías detectadas. -ip y -cname conservan resolución. -location muestra la redirección. -j selecciona JSONL y -o guarda el resultado:

httpx -l 01-candidates.txt \
  -sc \
  -title \
  -server \
  -td \
  -ip \
  -cname \
  -location \
  -j \
  -o 02-http.jsonl

Por defecto, HTTPX prueba HTTPS y recurre a HTTP cuando HTTPS no responde. Esto puede ocultar que ambos esquemas entregan aplicaciones distintas. -nf desactiva ese fallback y muestra los dos resultados cuando esa comparación sea necesaria.

La detección de tecnologías utiliza firmas y mantiene las mismas limitaciones que cualquier fingerprinting. El resultado confirma una respuesta desde este origen y momento. No demuestra propiedad ni aplicabilidad de una vulnerabilidad.

HTTPX 1.10.0 separa concurrencia y frecuencia. -threads limita las tareas concurrentes. -rate-limit fija peticiones por segundo. -timeout limita cada petición y -retries añade nuevos intentos. El número de intentos y la cadena de fallback entre HTTPS y HTTP aumentan el tráfico por entrada, así que se registran junto al resultado.

-store-response conserva las respuestas y -store-response-dir fija el directorio. -include-chain añade la cadena de redirecciones al JSONL. Las respuestas completas pueden incluir cuerpos y secretos de sesión:

httpx -l 01-candidates.txt \
  -threads 20 \
  -rate-limit 25 \
  -timeout 10 \
  -retries 1 \
  -sc -title -server -td -ip -cname -location \
  -include-chain \
  -store-response \
  -store-response-dir evidence/httpx-responses \
  -json \
  -o 02-http.jsonl

El perfil admite veinte operaciones concurrentes, pero no envía más de veinticinco peticiones por segundo. Una entrada puede generar más de una petición por fallback, redirección o reintento. Si necesitas observar el camino mediante un proxy, -proxy http://127.0.0.1:8080 cambia el origen y la ruta. Registra esa ejecución como una posición distinta.

HTTPX 1.10.0 inicializa su clasificador de páginas cuando produce JSON o CSV. Si el modelo no existe en la caché del usuario, la primera ejecución puede descargarlo antes de procesar la lista. Este efecto se reprodujo con -json aunque no se solicitara -td. Prepara y verifica la caché en una estación con acceso controlado, o ejecuta una prueba previa para evitar una descarga inesperada durante una actividad sin salida a Internet. El modelo y su directorio no forman parte de la evidencia del objetivo.

-debug-req imprime las peticiones y permite detectar una cabecera, esquema o normalización inesperados. Se usa sobre una lista mínima porque el output crece por petición y puede contener credenciales:

httpx -u BASE_URL \
  -timeout 10 \
  -retries 0 \
  -debug-req

Cada línea JSON de HTTPX incluye la URL observada. jq -r extrae el campo .url, select descarta entradas que no lo tengan y sort -u deduplica:

jq -r 'select(.url != null) | .url' 02-http.jsonl |
  sort -u > 03-base-urls.txt

Revisa el archivo antes del rastreo. Separa proveedores externos, paneles con sesiones diferentes y endpoints que necesiten límites propios. Una lista técnicamente válida puede mezclar superficies que no deben rastrearse con la misma configuración.

Katana acepta un archivo de URL iniciales mediante -list. -d 3 limita la profundidad. -jc analiza endpoints en JavaScript. -kf all incorpora los ficheros conocidos que soporta la herramienta, incluidos robots.txt y sitemaps. -j guarda JSONL:

katana -list 03-base-urls.txt \
  -d 3 \
  -jc \
  -kf all \
  -j \
  -o 04-crawl.jsonl

La referencia de crawling desarrolla scope, sesiones, JavaScript y modos headless. No actives el navegador, el relleno de formularios o una profundidad mayor como opciones rutinarias. Cada una cambia el comportamiento y el volumen del recorrido.

Antes de ampliar el rastreo, fija scope y ejecución. -crawl-scope acepta una expresión regular que decide qué URL puede seguir el crawler. -concurrency limita fetchers por entrada y -parallelism limita cuántas entradas se procesan en paralelo. -rate-limit aplica un máximo global por segundo. -host-rate-limit añade un máximo por host. -timeout limita cada petición y -retry fija reintentos:

katana -list 03-base-urls.txt \
  -crawl-scope '^https?://([A-Za-z0-9-]+\.)*DOMAIN(?::[0-9]+)?(?:/|$)' \
  -d 3 \
  -concurrency 5 \
  -parallelism 2 \
  -rate-limit 20 \
  -host-rate-limit 5 \
  -timeout 10 \
  -retry 1 \
  -jc \
  -kf all \
  -jsonl \
  -o 04-crawl.jsonl

La expresión de scope debe probarse con nombres que deban entrar y salir. Si no coincide con el formato de URL que evalúa la versión instalada, el crawler puede abandonar rutas válidas o seguir dominios con sufijos parecidos. -display-out-scope permite conservar endpoints externos descubiertos sin seguirlos.

-store-response guarda peticiones y respuestas. -store-response-dir fija su ubicación. Es útil para explicar por qué un enlace entró en el grafo, pero multiplica almacenamiento y puede conservar datos autenticados. -resume recibe un resume.cfg generado por una ejecución interrumpida:

katana -u BASE_URL \
  -crawl-scope '^https?://([A-Za-z0-9-]+\.)*DOMAIN(?::[0-9]+)?(?:/|$)' \
  -d 2 \
  -concurrency 4 \
  -rate-limit 8 \
  -timeout 10 \
  -store-response \
  -store-response-dir evidence/katana-responses \
  -jsonl \
  -o evidence/katana.jsonl

Antes de continuar con katana -resume resume.cfg, repite una URL conocida y confirma que la sesión, el scope y la respuesta de referencia siguen siendo válidos. La reanudación conserva progreso del crawler. No congela el estado de la aplicación.

Registra junto a cada ejecución:

• versión de herramienta y comando completo
• fecha, origen, resolutores e interfaz de salida
• ficheros de entrada y su hash
• rate, concurrencia, timeout y reintentos
• errores de fuente, DNS, TLS y HTTP
• reglas de filtrado y deduplicación

Los fallos no son equivalentes. Un NXDOMAIN, un timeout DNS, un rechazo TLS, un 403 y una conexión cerrada describen etapas diferentes. Si el pipeline solo conserva URLs exitosas, pierde precisamente la información necesaria para diagnosticar una discrepancia.

Compara ejecuciones antes de unirlas. Una nueva fuente de Subfinder cambia la cobertura. Una actualización de firmas cambia el fingerprint. Una ruta de red diferente puede cambiar CDN, idioma o bloqueos. La repetibilidad consiste en poder explicar la diferencia, no en exigir que Internet produzca siempre el mismo resultado.

FinalRecon, Recon-ng, SpiderFoot y otros frameworks coordinan varias tareas desde una interfaz. Son útiles para contrastar cobertura y para prototipos. Antes de aceptar su resultado, identifica:

• qué fuentes consulta y cuáles necesitan API key
• si contacta directamente con el objetivo
• qué esquemas, puertos y redirecciones prueba
• cómo limita concurrencia y profundidad
• qué formato permite conservar evidencia
• cuándo se actualizaron sus firmas y dependencias

Una herramienta integrada puede formar parte del pipeline, pero no debe borrar los contratos entre descubrimiento, validación y análisis. Los resultados que cambian el mapa se reproducen con una petición o consulta explícita.

• ProjectDiscovery: Subfinder
• ProjectDiscovery: HTTPX Usage
• HTTPX 1.10.0 release
• ProjectDiscovery: Katana Usage
• Katana 1.6.1 release
• Recon-ng
• SpiderFoot