Metodología de pentesting: de la enumeración al informe final

Un buen pentester no lo es por saber muchos payloads: lo es por trabajar con método. Las dos personas con el mismo arsenal técnico pueden entregar informes radicalmente distintos según cómo organicen la fase de recogida de información, cómo estructuren las pruebas, cómo tomen notas y cómo escriban el informe final. La diferencia entre un informe que el cliente ignora y uno que le salva un presupuesto suele estar en el método, no en el truco técnico más brillante que descubriste.

Esta lección es la pieza que une las trece anteriores de /aprende. Aprenderás las fases canónicas de un pentest según OSSTMM, PTES y OWASP, cómo organizar las notas durante la ejecución (porque vas a olvidar qué probaste a las dos horas), cómo clasificar los hallazgos por riesgo y, sobre todo, cómo redactar un informe que el cliente lea entero y entienda. Esta parte final, la del reporting, es donde se juega la reputación de un consultor.

Todo lo que aprendas aquí aplícalo contra sistemas autorizados: tus propios laboratorios y los de whoami-labs. La metodología es la misma en engagements legales reales.

Las fases canónicas#

Las referencias principales coinciden en un flujo con pequeñas variaciones.

Fase 0: pre-engagement#

Antes de tocar nada:

• Alcance firmado: qué IPs, qué dominios, qué aplicaciones. Fuera de alcance explícito.
• Ventanas de tiempo: cuándo se puede atacar, cuándo no.
• Contactos: a quién llamar si algo se cae.
• Autorización explícita por escrito: sin ella, no se arranca.
• Reglas de engagement: ¿fuerza bruta de credenciales permitida? ¿DoS prohibido? ¿Social engineering fuera o dentro?

Saltarse esto es la causa número uno de problemas legales en pentests. Nada empieza antes del documento firmado.

Fase 1: reconocimiento (OSINT)#

Información pública sobre el objetivo sin tocar sus sistemas:

• Dominios y subdominios (Sublist3r, amass, crt.sh, DNSDumpster).
• Empleados y perfiles LinkedIn.
• Correos filtrados (HaveIBeenPwned, dehashed).
• Tecnologías publicadas (BuiltWith, Wappalyzer).
• Google dorking sobre documentos y páginas expuestas.
• GitHub y GitLab por repos públicos con secretos.

Esta fase parece poco técnica pero da los mejores hallazgos: una clave API en un commit, un panel admin indexado, un empleado al que llamar.

Fase 2: enumeración activa#

Ya tocas el objetivo:

• Escaneo de puertos (nmap, masscan).
• Fingerprinting de servicios y versiones.
• Enumeración de usuarios y rutas (gobuster, ffuf, kerbrute).
• Enumeración de APIs (OpenAPI, GraphQL introspection).
• Mapeo de aplicaciones web (BurpSuite crawler).

El objetivo: catalogar la superficie de ataque completa antes de atacar. Prisa aquí lleva a pasar por alto el vector que luego habría ahorrado horas.

Fase 3: análisis de vulnerabilidades#

Cruzar lo enumerado con vulnerabilidades conocidas y custom:

• Scanner automático (Nessus, OpenVAS, Nuclei) como base.
• Revisión manual de cada hallazgo (los scanners reportan muchos falsos positivos).
• Análisis específico por tecnología (WPScan para WordPress, SQLmap en candidatos a SQLi).
• Logic flaws que ningún scanner encuentra.

Fase 4: explotación#

De vulnerabilidad a prueba de concepto funcional:

• Exploit público adaptado o exploit custom.
• Encadenamiento: una vulnerabilidad lleva a otra.
• Movimiento lateral y escalada de privilegios.
• Captura de evidencias (screenshots, respuestas, comandos).

Fase 5: post-explotación#

Qué consigues con el acceso ganado:

• Qué datos hay accesibles.
• Qué más se pivota desde ahí.
• Persistencia (solo si el engagement lo autoriza).
• Impacto real cuantificado.

Fase 6: reporting#

Aquí se juega todo. Un hallazgo sin informe comprensible es como si no existiera. Volveremos a esto al final.

Estándares de referencia#

Los más usados:

En la práctica, los pentesters combinan: PTES para el flujo general, OWASP WSTG o ASVS para la parte web, MITRE para describir técnicas en el informe.

Tomar notas durante la ejecución#

El error más común: ir probando cosas sin anotar. A las tres horas no recuerdas qué payload usaste en qué endpoint. Soluciones:

• CherryTree, Obsidian, Joplin, OneNote: notebook por engagement.
• Burp Suite project files: guardan todo el histórico de requests.
• Script de bash + tmux: script -f engagement.log graba terminal entera.
• Markdown por host: un .md por cada IP con todo lo que fuiste descubriendo.
• Screenshots etiquetados durante toda la ejecución.

Plantilla mínima por host:

# host: 10.10.11.42
## puertos
22, 80, 443
## servicios
- 80: Apache 2.4.18
- 443: Apache 2.4.18
## hallazgos
- SQLi en /login (POST, parámetro user)
- LFI en /index.php?page=
## credenciales
maria:Verano2024
## shells
www-data vía LFI → log poisoning
root vía kernel exploit CVE-XXXX

Si lo tienes todo así, redactar el informe a posteriori es ensamblar lo que ya está.

Clasificación de riesgo#

Los hallazgos se clasifican típicamente con CVSS (Common Vulnerability Scoring System):

• Crítico (9.0 – 10.0): RCE sin autenticación en sistemas expuestos.
• Alto (7.0 – 8.9): RCE autenticado, SQLi masivo, BOLA sobre PII.
• Medio (4.0 – 6.9): XSS reflected, información sensible filtrada.
• Bajo (0.1 – 3.9): headers de seguridad faltantes, SSL débil.

Un buen informe no se limita al CVSS: añade contexto del cliente. Un XSS en un portal interno de 10 usuarios y uno en el e-commerce con 100.000 usuarios al día no tienen el mismo impacto real aunque CVSS dé igual.

Estructura del informe final#

Un buen informe de pentest incluye:

Resumen ejecutivo#

Una página para la dirección. Sin jerga.

• Qué se auditó, cuándo, con qué alcance.
• Cuántos hallazgos de cada nivel.
• Riesgo global del entorno.
• Recomendaciones de alto nivel (3-5 bullet points).

Si la dirección solo lee esto, debe entender qué está pasando y qué se recomienda.

Alcance y metodología#

• Objetivos y exclusiones.
• Fechas y horas.
• Herramientas usadas.
• Referencia a estándares aplicados.

Hallazgos técnicos#

Un capítulo por hallazgo, con estructura constante:

• Título y nivel de severidad.
• Descripción: qué es la vulnerabilidad.
• Impacto: qué consigue un atacante al explotarla.
• Pasos de reproducción: paso a paso, con screenshots.
• Evidencia: respuesta HTTP, comandos, screenshots.
• Remediación: cómo arreglarlo, con ejemplo de código cuando sea útil.
• Referencias: CVE, CWE, OWASP, MITRE ATT&CK.

Conclusiones#

• Resumen de los hallazgos más graves.
• Comparación con auditorías anteriores si hay.
• Roadmap sugerido.

Anexos#

• Listado de puertos, servicios, versiones.
• Payloads usados.
• Transcripciones de sesión si procede.
• Cualquier dato técnico que ayude al equipo blue team.

El resumen ejecutivo: cómo escribirlo#

Es la parte más leída y la más difícil de escribir bien. Reglas:

• No usar jerga técnica sin explicar. «SQL injection» aparece una vez con una línea de explicación.
• Hablar de riesgo, no de técnica. «Un atacante podría acceder a la base de datos completa» vale más que «UNION SELECT en el campo user».
• Cuantificar. «3 hallazgos críticos, 7 altos, 12 medios. Dos de los críticos permiten acceso completo a datos de clientes.»
• Recomendaciones accionables. «Actualizar X a versión Y antes del día Z. Implementar WAF corporativo en el perímetro. Formación en autorización para el equipo backend.»
• Una página. Máximo dos. Si no cabe, la ejecutiva no lo leerá.

Errores comunes en reporting#

• Copiar la salida de herramientas sin interpretar: Nessus escupe cientos de bajos; el informe no es Nessus.
• Falta de screenshots: una imagen vale una semana de discusión.
• Severidad inflada: todo crítico pierde valor rápidamente.
• No explicar el impacto en lenguaje de negocio: el cliente se queda con «no entiendo qué significa».
• Remediaciones genéricas: «actualice su software» no sirve de nada.
• No distinguir vulnerabilidad de riesgo: una vulnerabilidad sin exposición real al negocio tiene menos prioridad.

Ejemplo de ficha de hallazgo#

Para ilustrar la forma de redacción, un hallazgo típico queda así en el informe:

### SQL Injection crítica en /login (user)

Severidad: Crítica · CVSS v3.1: 9.8 · CWE-89 · MITRE T1190

Descripción
-----------
El parámetro `user` del endpoint POST /login no sanitiza entradas,
lo que permite inyectar SQL arbitrario y extraer cualquier dato de
la base `app_db`.

Impacto
-------
Un atacante no autenticado puede autenticarse como cualquier usuario
y extraer la base de clientes completa (nombre, email, teléfono,
dirección de envío). Riesgo de reputación, legal (GDPR) y financiero.

Reproducción
------------
1. Enviar POST a https://objetivo.com/login
   con body: user=admin' OR '1'='1'--&pass=x
2. La respuesta devuelve 302 y cookie de sesión autenticada.
3. Volcar tabla users con sqlmap:
   `sqlmap -u https://objetivo.com/login --data "user=x&pass=x" --dbs`

Evidencia: screenshot_01.png, screenshot_02.png, sqlmap.log

Remediación
-----------
Reemplazar concatenación por consultas parametrizadas:
`db.query("SELECT * FROM users WHERE user = ?", [user])`
Aplicar también en los demás endpoints mapeados en el anexo B.

Referencias: OWASP A03:2021, PortSwigger SQLi cheatsheet.

Esta estructura constante acelera lectura y comparación entre informes de distintas auditorías.

Herramientas que ayudan#

• Dradis, SysReptor, PlexTrac, Faraday: plataformas de pentest reporting.
• Pandoc: convertir Markdown a PDF con plantilla profesional.
• Typora + plantilla LaTeX: para equipos pequeños con buena presentación.
• CherryTree, Obsidian: recogida de notas estructuradas.
• Burp + Flagger plugin: anotar hallazgos directamente sobre el historial.

Yo recomiendo empezar simple: Markdown en Obsidian durante la auditoría, Pandoc al PDF final, plantillas corporativas revisadas por un diseñador la primera vez.

Preguntas frecuentes#

¿Cuánto tiempo dedico a reporting?#

Rule of thumb: 30-40 por ciento del engagement. Si el pentest dura dos semanas, al menos cuatro días son para escribir. Menos tiempo = informe peor que no refleja el trabajo técnico.

¿Debo entregar el informe como PDF o como repositorio Git?#

Para la mayoría de clientes: PDF firmado digitalmente. Para clientes muy maduros: repositorio Git privado con Markdown versionado + exportación PDF. Depende.

¿Qué hago con hallazgos que el cliente marca como «aceptados»?#

Se documentan igual, con la decisión del cliente registrada. No se eliminan del informe; se marcan como «risk accepted» con la fecha y responsable.

¿Cómo gestiono retest?#

Se incluye en el alcance inicial: 1-2 semanas tras entrega, el cliente arregla, se revalida. Se entrega informe de retest corto confirmando qué se cerró y qué sigue abierto.

¿Dónde practico?#

En todos los laboratorios que has ido usando a lo largo de /aprende: distcc, vsftpd, superhero, tom-jerry, red-hat, snort y los siguientes. El reto esta vez es entregar un informe con el formato descrito, no solo conseguir la flag.

¿Cómo manejo hallazgos sensibles como PII o credenciales de empleados en el informe?#

Se referencian sin reproducir. Si durante la auditoría accediste a datos personales o credenciales reales, el informe lo indica («se accedió a 12.483 registros de clientes con datos de contacto»), pero no los copia. Capturas de pantalla se recortan o se anonimizan. Los archivos originales se entregan por canal seguro (carpeta cifrada con clave fuera de banda) y se destruyen tras aceptación del cliente. Documentar la cadena de custodia es parte del profesionalismo.

¿Qué pasa si descubro algo fuera del alcance?#

Dos escenarios. Si es un hallazgo crítico (RCE, exposición masiva de datos) que afecta al cliente aunque esté fuera del alcance contratado, se comunica al contacto designado inmediatamente por canal seguro, sin reportarlo en el informe principal. Si es un hallazgo menor fuera de alcance, se menciona en el apartado de observaciones generales sin desarrollar. Nunca se explota ni se documenta la ruta de explotación de algo fuera del alcance.

Resumen#

• Un pentest profesional sigue fases canónicas: pre-engagement, recon, enumeración, análisis, explotación, post-explotación, reporting.
• Las referencias: OSSTMM, PTES, OWASP Testing Guide, NIST SP 800-115, MITRE ATT&CK.
• Tomar notas estructuradas desde el minuto uno; sin método, pierdes información.
• Clasificación de riesgo con CVSS más contexto del cliente.
• El informe final incluye resumen ejecutivo, alcance, hallazgos con reproducción, conclusiones y anexos.
• 30-40% del engagement se dedica a escribir el informe.

Fuentes y lecturas recomendadas#

• PTES: Penetration Testing Execution Standard
• OWASP Web Security Testing Guide
• NIST SP 800-115
• OSSTMM
• MITRE ATT&CK