Recon activo y mapeo de superficie

01Objetivo

Pasar de "qué existe" a "cómo se comporta": mapear endpoints, parámetros y flujos de la aplicación una vez la policy confirma que el recon activo está permitido.

02Teoría

La diferencia entre mapear y atacar

Recon activo no es lanzar un escáner de vulnerabilidades contra el objetivo. Es construir el mapa completo de superficie — todas las rutas, todos los parámetros, todos los roles — antes de decidir qué categoría de vulnerabilidad probar en cada punto. Atacar sin mapear produce cobertura parcial: se encuentra lo obvio y se pasa por alto lo que solo aparece en flujos menos usados (recuperación de contraseña, exportación de datos, invitación a equipo, cambios de plan de suscripción).

Técnicas de mapeo, en orden de prioridad

1. Navegación manual completa de la app, con proxy interceptando todo. Cada clic, cada formulario, cada rol disponible (crear cuenta free y, si existe, de pago/admin, para comparar). Esto genera el mapa base de endpoints "oficiales".
2. Spidering/crawling automatizado sobre lo navegado manualmente, para capturar enlaces y recursos que la navegación humana no toca (sitemap.xml, robots.txt, rutas enlazadas solo desde JS).
3. Análisis estático del JavaScript del cliente. Las SPA modernas filtran rutas de API enteras en el bundle JS que nunca se llaman desde la UI visible — rutas de features en desarrollo, paneles internos, endpoints de administración condicionados por un flag de rol que el frontend no muestra pero que el backend puede seguir aceptando.
4. Descubrimiento de contenido dirigido (wordlists específicas de la tecnología detectada en el módulo 3, no wordlists genéricas) para encontrar rutas no enlazadas desde ningún sitio.
5. Diferenciación de versiones de API — si existe /api/v1 y /api/v2, mapear ambas: la antigua suele tener menos validaciones porque "ya nadie la usa", pero sigue aceptando tráfico.

Qué anotar de cada endpoint encontrado

No basta con la lista de URLs. Por cada endpoint relevante:

• Método HTTP y si acepta otros métodos no documentados (a veces PATCH o DELETE funcionan donde solo se documentó GET/POST).
• Parámetros esperados y su tipo (ID numérico secuencial vs UUID — predictor directo de IDOR, ver módulo 7).
• Rol mínimo requerido observado vs. qué pasa si se llama con un rol inferior o sin autenticar.
• Si la respuesta cambia de forma observable entre "recurso no existe" y "recurso existe pero no autorizado" (fuga de información que facilita enumeración).

03Caso real (anonimizado) — plataforma de carpooling europea

En el programa de una plataforma europea de carpooling, el recon activo sobre la API móvil (distinta de la API de la web, con endpoints y niveles de validación distintos) permitió construir un mapa de endpoints bastante más amplio que el que exponía la aplicación web. La decisión en ese punto, antes de lanzarse a probar explotación, fue invertir en configurar correctamente el proxy de intercepción (Burp) para ese tráfico específico — certificados, scope del proxy, reglas de Match & Replace para cabeceras obligatorias de la app móvil — en vez de empezar a probar manualmente endpoint por endpoint con herramientas sueltas. La inversión de tiempo en tener el entorno bien montado antes de atacar activamente se pagó varias veces durante el resto de la campaña, porque cada endpoint nuevo descubierto se podía probar de inmediato sin fricción de configuración repetida.

Lección: mapear la superficie incluye mapear qué infraestructura de pruebas (proxy, certificados, headers) necesitas para poder atacar esa superficie eficientemente. No es trabajo previo, es parte del recon.

04Resumen operativo

1. Mapea toda la app con rol más alto disponible antes de decidir dónde atacar.
2. El JS del cliente filtra rutas que la UI no muestra. Analízalo siempre.
3. Compara API v1 vs v2: la versión "vieja" suele tener menos controles.
4. Configurar bien el entorno de intercepción es parte del recon, no un paso aparte.