Recon pasivo

01Objetivo

Mapear la superficie de un objetivo sin enviar una sola petición que el objetivo pueda distinguir de tráfico normal de internet, y decidir con esa información dónde merece la pena mirar activamente.

02Teoría

Por qué pasivo primero

El recon activo (fuzzing de subdominios, escaneo de puertos, peticiones dirigidas) deja huella y, en programas sensibles (gobierno, infraestructura crítica, sector financiero), puede estar restringido o directamente prohibido por la policy. El recon pasivo no toca el objetivo: consulta fuentes de terceros que ya han indexado la información. Es gratis en términos de riesgo y casi siempre se puede hacer antes de que la policy diga qué está permitido activamente.

Fuentes de recon pasivo, por qué cada una importa

• Certificate Transparency logs (crt.sh y equivalentes) — revela subdominios que nunca se mencionan en la web pública, porque cualquier certificado TLS emitido queda registrado públicamente. Es la fuente más subestimada por hunters nuevos.
• Motores de búsqueda de infraestructura (Shodan, Censys, FOFA) — qué puertos/servicios/banners son visibles desde fuera, sin escanear tú mismo.
• Archive.org / Wayback Machine — versiones antiguas de la app que pueden revelar endpoints, parámetros o funcionalidades retiradas de la UI actual pero que el backend puede seguir aceptando.
• Repositorios públicos de código (GitHub, GitLab, npm/PyPI) — búsqueda por el nombre de dominio/empresa; configuraciones, claves olvidadas, nombres internos de servicios. Hay que ser especialmente cuidadoso aquí: encontrar una clave filtrada en un repo público de un tercero no autoriza a usarla contra el objetivo sin que la policy lo contemple.
• Registros DNS históricos y WHOIS — relaciones entre dominios, proveedores de infraestructura, adquisiciones corporativas que amplían el scope real de una empresa.
• APIs públicas documentadas de la propia organización — a veces la mejor fuente de recon es la documentación oficial que la empresa publica para desarrolladores externos.

Qué buscar, no solo cómo buscarlo

Recon pasivo sin un objetivo de qué hacer con la información es solo acumular listas. Las preguntas que debe responder esta fase:

1. ¿Qué tecnologías usa el stack (versiones de frameworks, CMS, librerías con CVEs conocidos)?
2. ¿Qué subdominios existen que no están enlazados desde la navegación normal (staging, admin, API interna expuesta por error)?
3. ¿Hay indicios de una API versionada distinta de la que usa la app web (/api/v1 vs /api/v2 donde la v1 nadie revisa ya)?
4. ¿Qué terceros/proveedores están integrados (y por tanto, probablemente fuera de scope aunque aparezcan en las peticiones)?

03Caso real — VDP de la NASA (Bugcrowd)

El VDP de la NASA se gestiona en Bugcrowd con safe harbor y reglas estrictas (sin DoS, sin ingeniería social, confirmar con el mínimo imprescindible, parar ante cualquier PII real, 90 días de confidencialidad). El alcance publicado cubría tres dominios: el dominio principal de la agencia, un dominio secundario de ciencia ciudadana, y un tercer dominio casi sin superficie. *(Los detalles exactos de endpoint, parámetro y dominio de este caso siguen bajo el embargo de confidencialidad del programa en el momento de escribir esto — lo que sigue es la metodología y el criterio, no una receta reproducible.)*

Recon pasivo con Certificate Transparency: una consulta a crt.sh por cada dominio en alcance devolvió el inventario de subdominios jamás indexados por un certificado TLS: 2.887 en el dominio principal, 80 en el secundario, 2 en el terciario. El instinto de novato es lanzarse al dominio con casi 3.000 subdominios. El instinto correcto es el contrario: ese es precisamente el que más gente ya ha mirado. El terreno fértil suele ser el objetivo mediano y poco vistoso — el que tiene cuentas de usuario y datos aportados por personas —, no el más grande.

Un obstáculo real de infraestructura propia: el resolver DNS del entorno de trabajo no resolvía la mayoría de los nombres encontrados, aunque fueran públicos. La solución fue rodear el problema con DNS-over-HTTPS: pedir la IP a un resolver público por HTTPS (al que sí se llegaba) y fijar esa IP manualmente en la petición de comprobación de vida (curl --resolve). Un barrido de una sola petición por host, sobre esa base, separó en minutos lo muerto/interno de lo vivo y relevante — entre ello, una aplicación de ciencia ciudadana con cuentas de usuario, entrada de datos y una API pública documentada (Swagger).

El primer callejón sin salida, documentado con honestidad: esa API pública parecía el candidato ideal — aceptaba parámetros que sonaban a nombres de campo de consulta. Probada con método (sin fuzzing a ciegas, peticiones acotadas), se cerró limpia: los nombres de campo estaban validados contra listas blancas definidas en el propio backend (no se podían inyectar campos arbitrarios), los valores fuera de rango solo rompían la consulta sin filtrar nada, y un WAF cortaba cualquier payload de inyección clásico con 403. No se fabricó un informe con esos errores de servidor — habría sido ruido, no una vulnerabilidad, y habría quemado credibilidad para el siguiente hallazgo (ver módulo 15).

El pivote correcto, tras cerrar ese vector, fue el que predice el módulo 5: moverse de una API pública de solo lectura a las aplicaciones con sesión, donde cada usuario tiene objetos propios que proteger. Ese pivote es el punto de partida del caso real del módulo 7.

Lección: recon pasivo no termina con "qué existe", termina con "qué de lo que existe concentra impacto si falla" — y descartar un vector grande con método, sin forzar un informe de él, es tan parte del trabajo como encontrar el que sí funciona.

04Resumen operativo

1. Recon pasivo primero siempre: cero riesgo, a menudo revela más que el escaneo activo.
2. Certificate Transparency y Wayback Machine son las fuentes más infravaloradas.
3. El objetivo no es la lista más larga, es identificar dónde vive el impacto real.
4. Superficie grande ≠ superficie valiosa. Prioriza por lógica de negocio y datos de usuario, no por número de endpoints.