Checklist de reconocimiento web

Esta checklist controla cobertura. No reemplaza las páginas que explican cada técnica. Registra cada comprobación como complete, partial, blocked, not-applicable o not-tested. Blocked conserva la señal que impidió avanzar. Not-tested necesita una razón y una tarea pendiente.

Trabaja por origen y por vista. https://portal.DOMAIN:443 con una sesión anónima no es la misma superficie que ese origen con otro rol, desde otra ruta de red o detrás de otro hostname.

• Cada dominio, hostname, IP y URL conserva la fuente que lo produjo.
• El inventario distingue observación actual, dato histórico e inferencia.
• Registro de dominio, RDAP o WHOIS, DNS, Certificate Transparency y alojamiento están enlazados a su evidencia.
• Los proveedores externos y activos compartidos no se han atribuido únicamente por proximidad técnica.
• Las URLs mantienen esquema, hostname, puerto, ruta y query.
• Los resultados incluyen timestamp y posición de origen.
• Los candidatos descartados conservan la razón del descarte.

La información de dominios es la referencia canónica de RDAP, WHOIS, DNS y Certificate Transparency. El reconocimiento web consume esos nombres y los valida como orígenes o relaciones HTTP.

• A, AAAA y CNAME se han consultado con un resolutor identificado.
• Se han registrado CDN, proxy inverso, balanceador o proveedor cuando existe evidencia.
• La IP contactada y la interfaz de salida están anotadas.
• Los puertos HTTP o HTTPS no estándar descubiertos por Nmap están incorporados.
• HTTP, HTTPS y cualquier redirección entre ellos se han observado por separado.
• SNI y autoridad HTTP utilizados en cada petición están registrados.
• TLS conserva versión, ALPN, certificado, cadena enviada y resultado de validación.
• Las diferencias por IPv4, IPv6, IP, región o ruta se mantienen separadas.

Una URL que responde no demuestra que todas sus direcciones entreguen el mismo backend. Un fallo TLS tampoco equivale a puerto cerrado.

• Una petición manual confirma método, destino, autoridad y versión HTTP.
• La primera respuesta se conserva antes de seguir redirecciones.
• Cada salto registra código, Location, cookies y cambio de origen.
• Cabeceras y cuerpo se guardan por separado cuando facilita el análisis.
• Se han observado una ruta conocida y varias rutas aleatorias inexistentes.
• Los soft 404, las redirecciones al login y los errores dinámicos tienen una respuesta de referencia propia.
• 401, 403, 404, 429 y 5xx se interpretan dentro de su cadena.
• Las diferencias entre curl, navegador, proxy y herramienta automática se han reducido a una petición.

Consulta la interacción manual con HTTP y TLS antes de automatizar una respuesta que todavía no puedes reproducir.

• DNS, SNI y Host o :authority se tratan como variables distintas.
• La respuesta del virtual host por defecto está registrada.
• Los candidatos se prueban manteniendo fija la IP cuando esa es la pregunta.
• La comparación utiliza código, redirección, título, longitud y contenido.
• Los wildcard y plantillas por defecto están identificados.
• Cada hostname confirmado vuelve al inventario.
• Las vistas anónima, autenticada y por rol están separadas.
• Cookies, locale, user agent y cabeceras que cambian contenido están anotados.

• Certificado, cabeceras, cookies, HTML, scripts, assets y errores se analizan como señales separadas.
• Producto anunciado y componente inferido no se presentan como la misma certeza.
• Proxy, CDN y backend no se confunden.
• Una versión aparente se contrasta con comportamiento o recurso propio del producto.
• WhatWeb, Wappalyzer, Nmap, Nikto u otras firmas se han usado para responder preguntas concretas.
• Las discrepancias entre firmas conservan sus outputs.
• Un fingerprint no se ha convertido directamente en vulnerabilidad.
• Las tecnologías nuevas generan hipótesis de contenido, rutas y pruebas posteriores.

• /robots.txt se interpreta por user-agent y grupo.
• Las rutas Allow y Disallow se validan como candidatos, no como controles de acceso.
• Los sitemaps e índices de sitemaps se recorren y normalizan.
• Las fechas de sitemap se tratan como metadatos declarados.
• Los endpoints /.well-known/ consultados responden a una tecnología observada.
• security.txt, OpenID Connect Discovery u otros documentos conservan su semántica.
• Las rutas, hostnames, contactos y endpoints nuevos vuelven al inventario.
• El contenido recuperado se atribuye al origen exacto que lo sirvió.

• Las URL iniciales, el scope y la profundidad están definidos.
• La estrategia distingue contenido anónimo, autenticado y por rol.
• Concurrencia, rate, timeout, duración y tamaño máximo están registrados.
• El output conserva URL de origen, destino, método y procedencia del enlace.
• URLs equivalentes se normalizan sin borrar variantes significativas.
• Fragmentos, parámetros de tracking y sesiones embebidas se tratan con reglas explícitas.
• Scripts estáticos y bundles se han revisado para rutas, endpoints, sourcemaps y hostnames.
• El modo headless se utiliza solo cuando el navegador cambia la cobertura.
• Formularios y acciones con estado no se envían automáticamente sin un caso de prueba separado.
• Las rutas descubiertas alimentan el mapa y el descubrimiento de contenido.

• La ruta base y la posición del marcador están definidas.
• La wordlist tiene procedencia, versión o hash.
• Las extensiones proceden del fingerprint o de evidencia observada.
• Varias rutas inexistentes forman la respuesta de referencia.
• Los matchers y filtros tienen una justificación reproducible.
• Rate, concurrencia, timeout, reintentos y duración máxima están registrados.
• La recursión tiene profundidad y tiempo por rama limitados.
• Los candidatos relevantes se reproducen manualmente.
• 401, 403, redirecciones y diferencias de cuerpo no se descartan por código.
• Los parámetros se prueban en una ejecución separada de las rutas.

La página de descubrimiento de contenido desarrolla respuestas de referencia, ffuf, Gobuster, Feroxbuster y falsos negativos.

• Cada consulta conserva motor, sintaxis, fecha y resultados relevantes.
• Los documentos públicos se registran con URL, hash y procedencia.
• Repositorios y snippets se atribuyen antes de extraer relaciones.
• La Wayback Machine y otras fuentes históricas conservan timestamp de captura.
• Una URL histórica no se presenta como recurso actual hasta validarla.
• Las diferencias entre captura archivada, índice y respuesta actual están anotadas.
• Credenciales, secretos o datos personales encontrados se tratan según la política de evidencia.
• Los nuevos hostnames, rutas, tecnologías y personas vuelven al inventario correspondiente.

• Cada etapa recibe y produce un artefacto documentado.
• Los candidatos no se sobrescriben con la lista de respuestas exitosas.
• Los resultados conservan la fuente y el método de validación.
• Se separan consulta a terceros, DNS e interacción directa con el objetivo.
• Las herramientas y plantillas tienen versión.
• API keys, errores de fuente y límites de cuota están registrados.
• La deduplicación conserva origen, puerto, ruta, query y vista cuando son significativos.
• Las discrepancias importantes se validan con una petición explícita.
• Un comando integrado no ha borrado límites, errores ni pasos intermedios.

• DNS negativo se distingue de timeout y respuesta filtrada.
• TCP, TLS y HTTP tienen errores separados.
• SNI, Host, proxy, cookies, redirecciones y versión HTTP se han comparado.
• Los resultados se han revisado frente a 429, 503, pérdida y bloqueo temporal.
• Una petición conocida se repite antes, durante y después de recorridos extensos.
• Se ha cambiado una sola variable por repetición.
• Los filtros automáticos se han comprobado contra muestras aceptadas y descartadas.
• Las diferencias por CDN, backend o región no se han fusionado prematuramente.
• Un resultado parcial no se resume como «sin superficie».

• Comando, versión, timestamp, origen y archivos de entrada están enlazados.
• Las peticiones enviadas pueden reconstruirse.
• Cabeceras, cuerpos y outputs están saneados sin perder la señal técnica.
• Cookies, tokens y credenciales no aparecen en historial o documentación publicada.
• El volumen esperado puede calcularse a partir de listas, extensiones, hosts y recursión.
• Los componentes que registran la actividad están identificados cuando afectan a la operación.
• Sesiones, ficheros temporales, proxies y procesos locales han terminado.
• Subidas, objetos o cambios remotos se han retirado y verificado.
• El cierre distingue confirmado, histórico, bloqueado, descartado y pendiente.
• Cada hallazgo o nueva rama tiene responsable y siguiente acción.

Área	Pregunta que debe quedar respondida
Orígenes	¿Qué combinación de esquema, nombre y puerto selecciona cada aplicación?
Transporte	¿Qué IP, TLS, SNI y protocolo se observaron desde esta posición?
Enrutamiento	¿Qué proxies, redirecciones y hosts virtuales median la petición?
Aplicación	¿Qué tecnologías están confirmadas y con qué evidencia?
Contenido	¿Qué rutas, archivos, endpoints, parámetros y scripts forman el mapa?
Vistas	¿Qué cambia entre sesión anónima, identidad, rol, idioma o red?
Procedencia	¿Qué se observó directamente, qué vino de terceros y qué es histórico?
Cobertura	¿Qué quedó bloqueado, qué no se probó y por qué?
Siguiente paso	¿Qué hipótesis verificable abre cada señal relevante?

• OWASP Web Security Testing Guide: Information Gathering
• RFC 9110: HTTP Semantics
• NIST SP 800-115