Mi metodología de reconocimiento (y cómo terminé automatizándola en una sola herramienta)

Hay una frase que se repite hasta el cansancio en el mundo del bug bounty: «la clave está en el reconocimiento». Y es verdad. Lo que casi nadie te cuenta es que el recon, hecho a mano y bien hecho, es lento, repetitivo y muy fácil de hacer a medias cuando ya llevás tres horas y estás cansado.

Con el tiempo (a prueba y error) fui armando un orden que a mí me funciona. No es una lista de herramientas sueltas, sino que es una secuencia donde cada fase alimenta a la siguiente. Los subdominios te dan hosts, los hosts vivos te dan URLs, las URLs te dan JavaScript, el JavaScript te da endpoints y secretos, y así. Este post es sobre esa metodología y sobre cómo terminé integrándola dentro de una sola herramienta.

La idea no es enseñarte recon desde cero, sino mostrarte lo que me es útil a mi y por qué cada paso está donde está.

Nota: Acá uso "recon" en sentido amplio: incluyo tanto lo pasivo como la enumeración activa. En la práctica las dos fases se relacionan todo el tiempo, así que las trato como parte de la misma metodología en vez de separarlas.

El primer paso: descubrir los subdominios

La superficie de ataque no la elegís vos: la descubrís. Y el primer paso siempre es entender qué tan grande es realmente el objetivo. Ninguna herramienta cubre el 100% de los subdominios por sí sola, así que las corro todas y después unifico los resultados. Utilizo: subfinder, assetfinder, amass en modo pasivo, findomain, github-subdomains y chaos, más una pasada por crt.sh para los certificados.

Con toda esa lista deduplicada, el siguiente paso es identificar cuáles están realmente activos. Resuelvo con dnsx y después paso todo por httpx para quedarme solo con los hosts que tienen un servicio HTTP/HTTPS vivo, guardando de paso el status, el título y el server.

Dato: si el dominio tiene wildcard DNS, cualquier subdominio inexistente puede resolver a una misma IP. Si además esa IP responde a cualquier nombre de host, esos falsos positivos no solo aparecen en la resolución DNS: httpx también puede marcarlos como hosts vivos. Por eso conviene detectar el wildcard antes de confiar en esos resultados.

Crawling e histórico de URLs

Una vez identificados los hosts vivos, la prioridad pasa a ser enumerar todos sus endpoints y recursos. Para eso combino: el crawling activo y las URLs históricas.

Para el activo uso katana, siempre limitado en profundidad, tiempo y rate, más adelante te explico por qué. En paralelo consulto las fuentes históricas con waybackurls y gau, que devuelven URLs que quizás ya ni existen en la web actual. Y sumo hakrawler como crawler alternativo.

Todo eso termina en un archivo que después normalizo con uro, que colapsa URLs estructuralmente iguales (misma ruta con distinto ?id=1,2,3...) para evitar que un sitio con paginación genere miles de variantes de la misma URL.

Descubrir secretos en el JavaScript

Si tuviera que priorizar una sola fase del recon, sería esta. El JavaScript esconde: rutas, endpoints internos, llamadas a APIs que ni aparecen en la web, y, cada tanto, secretos hardcodeados que nunca debieron llegar a producción.

Junto todos los .js que aparecieron en el crawling y los paso por dos herramientas: LinkFinder, para extraer endpoints y rutas escondidas dentro del código, y SecretFinder, que busca claves y tokens embebidos. Después analizo todo el contenido descargado con trufflehog y gitleaks, y lo complemento con búsquedas mediante expresiones regulares para detectar patrones de alto valor: claves de AWS, Google, tokens de GitHub, secretos de Stripe, JWTs.

Ojo con esto último: siempre son candidatos, no hallazgos confirmados. Vas a tener muuuchos falsos positivos y hay que verificar cada uno manualmente antes de darlo por válido.

Fingerprinting: identificar las tecnologías del objetivo

Antes de empezar a probar vulnerabilidades conviene entender qué tecnologías usa la aplicación. No es lo mismo analizar un WordPress que una aplicación en Rails, ni un sitio expuesto directamente que otro protegido por un WAF filtrando todo.

Para esto uso whatweb y webanalyze (basado en las firmas de Wappalyzer) para identificar el stack (servidor, framework, CMS, librerías) y wafw00f para detectar si hay un WAF o CDN adelante. Ese último dato te ahorra horas de frustración después, cuando entendés por qué ciertos payloads se bloquean o determinadas peticiones nunca llegan a la aplicación.

Priorizar URLs con parámetros

No todas las URLs tienen el mismo valor. Las que tienen parámetros suelen ser de las más interesantes, porque es ahí donde la aplicación procesa entrada del usuario.

Para priorizarlas utilizo gf, que aplica patrones para agruparlas según el tipo de vulnerabilidad que podrían contener: SSRF, IDOR, open redirects, SQLi, XSS, LFI o RCE. En vez de mirar un archivo con 50.000 líneas, te quedás con un puñado de URLs ordenadas por dónde es más probable que haya algo. Asique este paso sería el puente entre "junté miles de URLs" y "sé cuáles analizar primero".

Automatizar comprobaciones con Nuclei

Con nuclei sigo dos estrategias diferentes, según el objetivo del análisis.

• La primera es pasiva: utilizo templates de bajo riesgo (exposures, misconfigurations, tech-detect) para identificar paneles expuestos, archivos de configuración, filtraciones de tecnologías y otras exposiciones sin realizar pruebas intrusivas contra la aplicación. Es una etapa que suelo ejecutar siempre.

• La segunda es activa y focalizada: utilizo templates de vulnerabilidades (auth, SQLi, XSS, SSRF, IDOR, LFI, RCE, CVEs) únicamente sobre las URLs que ya prioricé en las fases anteriores. Como estas pruebas interactúan directamente con la aplicación, solo las ejecuto cuando el programa las permite. Ejecutar todos los templates sin ningún criterio solo genera tráfico innecesario y una mayor cantidad de falsos positivos.

Escaneo de puertos y fuzzing

Cuando el alcance del programa lo permite, complemento el recon con dos tareas más.

Primero resuelvo los hosts a IPs y elimino las repetidas para no escanear la misma máquina varias veces. Después para descubrir puertos abiertos utilizo naabu y para identificar los servicios expuestos uso nmap -sV. Luego hago fuzzing de directorios con ffuf y wordlists de SecLists para descubrir rutas y archivos que no aparecen durante el crawling.

Al igual que las pruebas activas con Nuclei, estas técnicas generan tráfico directo contra el objetivo, por lo que conviene utilizarlas solo cuando están permitidas y realmente aportan valor al análisis.

Todo esto es automatizable: L1ghtRecon

Si releés todo lo de arriba, hay algo evidente: es siempre lo mismo, en el mismo orden. Y lo que es siempre igual, se automatiza. Así nació L1ghtRecon: un herramienta en Bash que automatiza toda esta metodología en una sola ejecución.

Cubre las siguientes fases:

1. Descubrimiento de subdominios.
2. Verificación de hosts vivos.
3. Crawling y recopilación de URLs históricas.
4. Análisis de JavaScript y búsqueda de secretos.
5. Fingerprinting de tecnologías.
6. Priorización de URLs con gf.
7. Análisis con nuclei (pasivo y activo).
8. Escaneo de puertos y fuzzing (solo en modo --aggressive).

Tiene dos modos de ejecución: --passive, que ejecuta únicamente las fases pasivas, y --aggressive, que añade las fases activas. Además incluye presets de velocidad para controlar la velocidad de las peticiones (slow/normal/fast).

Al terminar genera un report.html autocontenido (un único archivo, sin depender de CDNs ni recursos externos), con tema claro/oscuro, tablas filtrables y exportación a PDF o Markdown. Además crea un resumen de la superficie de ataque pensado para pegarlo directamente en un LLM y decidir por dónde seguir. También escapa automáticamente todo dato proveniente del objetivo (títulos, URLs, subdominios) para evitar que contenido malicioso pueda ejecutar XSS al abrir el reporte en el navegador.

El crawling siempre se ejecuta con límites de tiempo y rate, respetando las restricciones que la mayoría de los programas de bug bounty establecen. Además, cuando un archivo alcanza un tamaño determinado, la recolección se detiene y se informa en el reporte, evitando generar archivos innecesariamente grandes.

Aclaración: la idea nunca fue reemplazar a subfinder, httpx, nuclei ni al resto de las herramientas que ya existen y funcionan muy bien. L1ghtRecon simplemente las integra dentro de un único workflow, con el objetivo de reunir en una sola herramienta la metodología que uso habitualmente, para no tener que ejecutarla manualmente en cada programa.

Podés descargarla desde mi GitHub: github.com/l1ghtn1ng-0nl1n3/L1ghtRecon.

Conclusión

La herramienta se encarga de ordenar la información y reducir el trabajo repetitivo. Después queda lo que realmente marca la diferencia: entender cómo funciona la aplicación, conectar hallazgos y encontrar caminos que no son tan evidentes.

Al final, automatizar el recon no significa dejar de investigar. Significa llegar a la etapa de análisis con la información ya organizada, para dedicar el tiempo a lo que ninguna herramienta puede hacer por vos: pensar como un investigador de seguridad.