Automatización del recon

En bug bounty, el recon es a menudo lo que decide quién encuentra el bug: cuanta más superficie descubras (y antes), más oportunidades tienes sobre activos que otros no ven. Automatizar el recon permite cubrir objetivos grandes y monitorizar cambios de forma continua. (Teoría general en el área recon.)

Objetivo del recon en BB

- descubrir TODA la superficie del scope: subdominios, apps, APIs, parámetros, tecnologías
- encontrar lo OLVIDADO: subdominios viejos, staging, adquisiciones, paneles expuestos
- monitorizar CAMBIOS: nuevos subdominios/endpoints = nuevas oportunidades (menos ojos)

Pipeline típico (encadenado)

# 1. subdominios (pasivo + activo)
subfinder -d target.com | tee subs.txt
amass enum -passive -d target.com >> subs.txt
# 2. ¿cuáles están vivos? (resolver + sondear HTTP)
cat subs.txt | sort -u | httpx -silent -title -tech-detect -status-code > live.txt
# 3. descubrimiento de URLs/endpoints (histórico + crawling)
gau target.com ; waybackurls target.com ; katana -u https://target.com
# 4. escaneo por plantillas (vulns conocidas/exposiciones)
nuclei -l live.txt -severity medium,high,critical   # ver tool-nuclei

Técnicas de descubrimiento

Pasivo    CT logs (crt.sh), DNS, buscadores, archivos (wayback) -> sin tocar el objetivo
Activo    brute force de subdominios/DNS, resolución, sondeo HTTP
JS mining  parsear ficheros JS -> endpoints, claves, rutas ocultas (LinkFinder)
Favicon/hashes  identificar tecnología/activos por favicon hash (Shodan/FOFA)
Content   ffuf/feroxbuster para contenido y parámetros ocultos (ver tool-ffuf)

Monitorización continua

- re-ejecutar el recon periódicamente y DIFF: lo NUEVO es lo interesante
- alertas de nuevos subdominios/endpoints (cron + notificación)
- frameworks: una tubería que orquesta las herramientas y guarda histórico
# el que detecta el cambio PRIMERO suele quedarse el bug

Herramientas

Subdominios   subfinder, amass, assetfinder, findomain
Probing       httpx, dnsx
URLs          gau, waybackurls, katana, hakrawler
Vulns         nuclei (plantillas, ver tool-nuclei), ffuf (ver tool-ffuf)
Orquestación  flujos propios en bash/python; evitar frameworks "caja negra" que no entiendes

Blue Team / nota ética

Mantener el recon dentro del scope (Leer el scope & reglas): resolver/sondear fuera del alcance es problema.
Preferir técnicas pasivas primero (menos ruido y riesgo) y activas con cabeza.
La clave competitiva es la monitorización continua + diff: detectar lo nuevo primero.
Entender tus herramientas; no lanzar frameworks que no controlas contra objetivos reales.

Buenas prácticas y errores comunes

El recon amplio y continuo (subdominios, staging, JS) es donde salen los bugs de mayor impacto.
Monitoriza cambios (nuevos subdominios y endpoints) de forma continua, no en una sola pasada.
Error típico: verificar un subdomain takeover de forma destructiva; demuéstralo al mínimo y sin romper nada.

Checklist de prueba

Enumerar subdominios (pasivo + activo) dentro del scope
Resolver y sondear HTTP (httpx: título, tech, status)
Descubrir URLs/endpoints (gau/wayback/katana + JS mining)
Escaneo por plantillas (nuclei) de exposiciones/vulns
Fuzzing de contenido/parámetros ocultos (ffuf)
Buscar subdomain takeover y activos olvidados
Monitorización continua + diff de lo nuevo