A lo largo de este curso has aprendido a enumerar servicios, explotar vulnerabilidades web, encadenar fallos para escalar privilegios y rastrear la superficie de ataque de una aplicación real. Sin embargo, todo ese conocimiento técnico solo convierte en valor profesional cuando se plasma en un documento que el cliente puede leer, entender y actuar sobre él: el informe de pentest. El informe no es un trámite burocrático; es el entregable principal del trabajo y, en la mayoría de los contratos, el único producto tangible que el cliente recibe a cambio de su inversión.
Antes de continuar, una nota de ética fundamental: un pentest profesional siempre se realiza con autorización escrita y un alcance claramente definido. Las técnicas de este curso solo son legales y éticas cuando existe un contrato de servicios que delimita los sistemas objetivo, el periodo de pruebas y las acciones permitidas. Este módulo no cubre ninguna explotación nueva; se centra exclusivamente en cómo documentar, comunicar y entregar los resultados de pruebas ya realizadas dentro de ese marco legal.
Qué aprenderás en este módulo
- Por qué el informe es el verdadero entregable de un pentest y cómo diferencia a un profesional de un amateur.
- La estructura estándar de un informe profesional: portada, resumen ejecutivo, alcance, metodología, hallazgos y anexos.
- Cómo redactar cada sección de un hallazgo de forma clara, reproducible y orientada al riesgo de negocio.
- Cómo calcular y justificar una puntuación CVSS v4.0 (y v3.1, aún muy presente en 2026) y traducirla a severidad.
- Buenas prácticas de comunicación con el cliente y proceso de retest.
- Herramientas y plantillas usadas en la industria para agilizar la redacción.
- Próximos pasos para seguir creciendo: plataformas de práctica, certificaciones y bug bounty.
Por qué el informe importa más de lo que parece
Un pentest sin informe es como una auditoría contable sin dictamen: el trabajo se hizo, pero nadie puede actuar sobre él. El informe cumple varias funciones críticas a la vez:
- Prueba contractual: acredita que el trabajo se realizó según el alcance acordado y protege legalmente tanto al cliente como al consultor.
- Hoja de ruta de remediación: la dirección de seguridad y el equipo de desarrollo necesitan saber exactamente qué corregir, en qué orden y cómo verificar que la corrección es efectiva.
- Comunicación ejecutiva: un CISO debe presentar los hallazgos al consejo de administración sin tecnicismos; el resumen ejecutivo hace eso posible.
- Base para el retest: sin un registro detallado de los pasos de reproducción, el equipo de desarrollo no puede confirmar si la corrección funciona, y el pentester no puede verificar el fix en una segunda ronda.
Si quieres profundizar en los fundamentos técnicos que se documentan aquí, puedes revisitar la guía completa de hacking web que acompaña a este curso.
Estructura de un informe profesional
1. Portada y cláusula de confidencialidad
La portada identifica el documento de forma inequívoca. Debe incluir: nombre del cliente, nombre del proyecto o sistema auditado, fecha de entrega, versión del documento, nombre y firma del consultor o empresa, y clasificación de confidencialidad (CONFIDENCIAL — USO RESTRINGIDO es la etiqueta habitual). Inmediatamente después, o al pie de la portada, se incluye la cláusula de confidencialidad que prohíbe la distribución no autorizada del documento.
Muchos contratos exigen que cada página lleve un pie de página con la clasificación del documento. Este detalle, aparentemente menor, tiene implicaciones legales si el informe se filtra.
2. Resumen ejecutivo
El resumen ejecutivo está escrito para la dirección y el CISO, no para el equipo técnico. Debe ser comprensible por alguien sin formación en ciberseguridad y no debe superar una o dos páginas. Su contenido habitual es:
- Objetivo del encargo en una o dos frases.
- Conclusión global de la postura de seguridad (sin listar todos los hallazgos).
- Los dos o tres riesgos más críticos, explicados en términos de impacto de negocio (pérdida económica, reputacional, regulatoria).
- Una recomendación de priorización de alto nivel.
Evita usar acrónimos técnicos sin definir, referencias a CVE o términos como Remote Code Execution sin explicar qué significa en términos de negocio. Un CISO no necesita saber que la vulnerabilidad es un SQLi; necesita saber que un atacante podría acceder a todos los datos de clientes en menos de diez minutos.
3. Alcance y reglas de enganche (Rules of Engagement)
Esta sección documenta exactamente qué estaba autorizado a probar y qué no. Incluye:
- Listado de sistemas en alcance (IPs, dominios, aplicaciones).
- Sistemas explícitamente fuera de alcance.
- Periodo de pruebas (fechas y horarios).
- Tipos de pruebas autorizadas (black-box, grey-box, white-box; destructivas o no).
- Contacto de emergencia del cliente en caso de incidente durante las pruebas.
- Restricciones específicas (p. ej., no realizar denegación de servicio en producción).
Esta sección protege al consultor ante cualquier disputa posterior sobre qué se testó o qué se causó.
4. Metodología y estándares utilizados
Referenciar estándares reconocidos aporta credibilidad y transparencia. Los más habituales en un pentest web son:
- PTES (Penetration Testing Execution Standard): marco de siete fases (pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting) que define el ciclo completo de un pentest. Aunque su contenido lleva años sin recibir una revisión mayor, sigue siendo una referencia ampliamente citada para estructurar el trabajo y comunicar la metodología al cliente.
- OWASP WSTG (Web Security Testing Guide): guía exhaustiva con más de 90 casos de prueba para aplicaciones web, organizados por categoría (autenticación, autorización, gestión de sesiones, validación de entrada, etc.). Proporciona identificadores únicos (WSTG-INPV-01, etc.) que se pueden citar en los hallazgos para referenciar el caso de prueba exacto. La versión estable en 2026 sigue siendo la v4.2; la v5.0 está en desarrollo en el repositorio del proyecto pero aún no se ha publicado como estable.
- NIST SP 800-115: guía técnica del NIST para la planificación y ejecución de pruebas de seguridad. Sigue siendo en 2026 la referencia vigente (publicada en 2008 y sin revisión posterior); pese a su antigüedad, su metodología se mantiene válida y es muy valorada en entornos corporativos y administraciones públicas por su rigor documental.
- CVSS v4.0 (y la aún muy usada v3.1) de FIRST: sistema de puntuación de vulnerabilidades para cuantificar la severidad de cada hallazgo de forma objetiva y comparable. v4.0 es la versión vigente desde noviembre de 2023, pero en 2026 la transición sigue en curso y v3.1 continúa muy presente en escáneres, bases de datos (NVD) y plantillas, por lo que es habitual reportar el vector indicando explícitamente la versión usada.
5. Hallazgos detallados
Esta es la sección más extensa y la que más valor técnico aporta. Cada vulnerabilidad se documenta en una ficha de hallazgo estructurada (ver sección siguiente). Los hallazgos se ordenan habitualmente de mayor a menor severidad. Es recomendable comenzar con una tabla resumen de todos los hallazgos que permita al lector tener visión global antes de entrar en el detalle.
6. Conclusiones y recomendaciones generales
Más allá de cada hallazgo individual, esta sección ofrece una valoración global de la madurez de seguridad de la aplicación. Incluye patrones observados (p. ej., ausencia sistemática de validación de entrada en todos los formularios), recomendaciones transversales (adoptar un SDLC seguro, implementar WAF, revisar la política de gestión de dependencias) y métricas globales (número de hallazgos por severidad).
7. Anexos
Los anexos contienen material de soporte que enriquece el informe sin interrumpir el flujo de lectura:
- Capturas de pantalla adicionales y salidas de herramientas.
- Definición de metodología de puntuación CVSS usada.
- Listado completo de herramientas utilizadas (Burp Suite, OWASP ZAP, nikto, sqlmap, etc.).
- Glosario de términos técnicos.
- Referencias normativas (OWASP Top 10:2025, CWE, CVE).
Cómo redactar un hallazgo
Cada hallazgo es una unidad de información autónoma. Debe poder leerse de forma independiente y responder a cuatro preguntas: ¿qué se encontró?, ¿qué impacto tiene para el negocio?, ¿cómo se reproduce?, ¿cómo se soluciona? Los campos estándar son:
Campos de un hallazgo
- Título: claro, específico y descriptivo. No «SQL Injection» sino «Inyección SQL en el parámetro
iddel endpoint/api/productos«. - Identificador: número de referencia interno (p. ej., HW-007) para cruzar con la tabla de hallazgos.
- Descripción técnica: qué es la vulnerabilidad, dónde se encontró, qué la causa a nivel de código o configuración.
- Impacto de negocio: qué puede hacer un atacante que explote este fallo y qué consecuencias tiene en términos de confidencialidad, integridad, disponibilidad, cumplimiento normativo o reputación.
- Valoración de riesgo (CVSS): vector de puntuación y severidad resultante (ver más abajo).
- Evidencia / PoC: captura de pantalla, fragmento de petición/respuesta HTTP, salida de herramienta, que demuestre inequívocamente la existencia de la vulnerabilidad.
- Pasos de reproducción: secuencia numerada y reproducible que permita al equipo de desarrollo replicar el hallazgo por sí mismo para verificar la corrección.
- Recomendación de remediación: qué hacer para corregirlo. Debe ser concreta y aplicable, no genérica («usa consultas parametrizadas en el ORM» es mejor que «valida las entradas del usuario»).
- Referencias: OWASP Top 10 (categoría pertinente), CWE, WSTG, CVE si aplica.
Tabla de ejemplo de hallazgo
| Campo | Contenido |
|---|---|
| ID | HW-003 |
| Título | Cross-Site Scripting (XSS) reflejado en el parámetro search de /buscar |
| Severidad | Alta |
| CVSS v3.1 | 7.4 — AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N |
| CVSS v4.0 | 7.1 (High) — evaluado con el calculador oficial de FIRST |
| Descripción | El parámetro search se refleja sin codificación en la respuesta HTML, permitiendo inyectar código JavaScript arbitrario que se ejecuta en el navegador de la víctima. |
| Impacto de negocio | Un atacante puede robar cookies de sesión de cualquier usuario que haga clic en un enlace manipulado, impersonar su identidad y acceder a su cuenta. En un contexto de tienda online, esto incluye datos de pago y dirección guardados. |
| Evidencia | Petición: GET /buscar?q=<script>alert(document.cookie)</script> — respuesta refleja el payload sin escapar. Captura adjunta en Anexo B, figura 3. |
| Pasos de reproducción | 1. Abrir la URL https://ejemplo.com/buscar?q=<script>alert(1)</script> en Firefox sin extensiones. 2. Observar que el diálogo de alerta se ejecuta. 3. Sustituir el payload por document.cookie para confirmar la exfiltración de sesión. |
| Remediación | Codificar toda salida HTML con la función de escape del framework usado (p. ej., htmlspecialchars() en PHP con ENT_QUOTES). Implementar Content Security Policy (CSP) como control adicional en profundidad. |
| Referencias | OWASP Top 10 A05:2025 — Injection (XSS está incluido en esta categoría); CWE-79; WSTG-CLNT-01 |
Cálculo de CVSS: claves prácticas
El CVSS v3.1 utiliza seis métricas base: Vector de Ataque (AV), Complejidad de Ataque (AC), Privilegios Requeridos (PR), Interacción del Usuario (UI), Alcance (S) e Impacto (C/I/A). El resultado es un número entre 0 y 10 que se mapea a una severidad según la escala de FIRST:
| Puntuación | Severidad |
|---|---|
| 0.0 | None (Ninguna) |
| 0.1 – 3.9 | Low (Baja) |
| 4.0 – 6.9 | Medium (Media) |
| 7.0 – 8.9 | High (Alta) |
| 9.0 – 10.0 | Critical (Crítica) |
El CVSS v4.0, publicado por FIRST en noviembre de 2023, mantiene exactamente las mismas bandas de severidad (None / Low / Medium / High / Critical) pero cambia la estructura de métricas. El cambio más relevante es que elimina la métrica de Alcance (Scope) —la más confusa de v3.1— y la sustituye por dos conjuntos de impacto: sistema vulnerable (VC/VI/VA) y sistema(s) posterior(es) (SC/SI/SA). Añade además métricas suplementarias (Automatable, Recovery, Value Density, etc.) e introduce una nomenclatura de puntuación según los grupos usados: CVSS-B (solo Base), CVSS-BT (Base+Threat), CVSS-BE (Base+Environmental) y CVSS-BTE (los tres). En 2026 la adopción de v4.0 avanza pero la transición no está cerrada: muchos escáneres y la propia NVD siguen apoyándose en v3.1, por lo que es frecuente reportar ambas puntuaciones por compatibilidad con bases de datos históricas, indicando siempre la versión del vector.
Consejo importante: el CVSS mide la severidad técnica intrínseca de la vulnerabilidad, no el riesgo real en el contexto del cliente. Un hallazgo de severidad Media puede convertirse en riesgo Crítico si afecta a un sistema que procesa datos de tarjetas de crédito. Siempre complementa el CVSS con una valoración del riesgo contextual (probabilidad × impacto de negocio).
Priorización por riesgo y matriz de hallazgos
La tabla resumen de hallazgos al inicio de la sección de findings es lo primero que lee el equipo técnico del cliente. Su formato habitual es:
| ID | Título (abreviado) | Severidad | CVSS | Estado |
|---|---|---|---|---|
| HW-001 | SQLi en login | Crítica | 9.8 | Abierto |
| HW-002 | IDOR en API de pedidos | Alta | 8.1 | Abierto |
| HW-003 | XSS reflejado en búsqueda | Alta | 7.4 | Abierto |
| HW-004 | Cabeceras de seguridad ausentes | Baja | 3.1 | Abierto |
La priorización debe guiar al cliente en la asignación de recursos. La recomendación estándar es corregir los hallazgos Críticos y Altos antes de la siguiente ventana de despliegue, los Medios en el siguiente ciclo de desarrollo y los Bajos según capacidad. Sin embargo, siempre se debe contextualizar: un hallazgo Bajo en un sistema de autenticación puede merecer prioridad sobre un Medio en un servicio interno sin datos sensibles.
Buenas prácticas de redacción y comunicación con el cliente
Un informe técnico excelente puede arruinarse por una mala comunicación. Estas son las prácticas más importantes:
- Lenguaje neutral y constructivo: describe vulnerabilidades, no errores de personas. «El endpoint carece de validación de entrada» es mejor que «el desarrollador olvidó sanitizar». El objetivo es que el equipo de desarrollo quiera colaborar, no que se sienta atacado.
- Separación de públicos: el resumen ejecutivo para dirección, la sección técnica para desarrolladores y administradores de sistemas. Nunca mezcles niveles de abstracción en la misma sección.
- Evidencia reproducible: cada hallazgo debe poderse reproducir por alguien ajeno al pentest. Si no se puede reproducir, no existe.
- Revisión por pares: antes de entregar, otro técnico del equipo debe revisar el informe buscando inconsistencias, errores en los vectores CVSS y claridad de las recomendaciones.
- Reunión de entrega (debriefing): en contratos de tamaño medio o grande, es habitual realizar una reunión con el cliente para presentar los hallazgos verbalmente, responder dudas y acordar el plan de remediación. Esta reunión suele separarse en dos sesiones: una ejecutiva y una técnica.
- Versión y control de cambios: el informe debe tener número de versión. Si el cliente solicita aclaraciones o el pentester detecta un error, se emite una v1.1 con el registro de cambios documentado.
Retest y verificación de remediaciones
El informe no es el final del trabajo: el retest cierra el ciclo. Una vez que el cliente ha corregido los hallazgos, el consultor verifica que las correcciones son efectivas y completas. El retest genera un addendum al informe (o una sección nueva) con el estado actualizado de cada hallazgo:
- Resuelto: la vulnerabilidad ya no es reproducible.
- Parcialmente resuelto: la corrección mitiga el riesgo pero no lo elimina completamente (p. ej., se sanitizó un endpoint pero no el resto de la misma API).
- No resuelto: el cliente aceptó el riesgo de forma explícita o la corrección no fue efectiva.
El retest también puede revelar que la corrección introdujo una nueva vulnerabilidad, lo cual se documenta como un hallazgo nuevo. Es frecuente acordar una o dos rondas de retest dentro del alcance del contrato original.
Herramientas y plantillas para la redacción del informe
Redactar un informe desde cero para cada proyecto es ineficiente. La industria usa plataformas especializadas de gestión de pentest y reporting:
- SysReptor: plataforma open-source de reporting pensada para pentesters individuales y equipos pequeños. Permite escribir hallazgos en Markdown y exporta directamente a PDF con plantillas personalizables. Muy utilizada para reportes de certificaciones como OSCP, PNPT y CPTS. Dispone de opción cloud y autohospedada.
- Dradis: plataforma autohospedada enfocada en equipos y consultorías. Importa resultados de más de 40 herramientas de seguridad (Nessus, Burp Suite, Nmap, etc.), normaliza los hallazgos y genera informes en plantillas Word o HTML. Especialmente potente para proyectos con múltiples testers.
- Plantillas de Word/LibreOffice: muchos consultores independientes mantienen su propia plantilla corporativa. Herramientas como el repositorio de informes públicos de pentest en GitHub ofrecen ejemplos reales anonimizados que sirven de referencia.
- Gestión de evidencias: durante el pentest, herramientas como KeepNote, CherryTree o Obsidian permiten tomar notas estructuradas que luego se convierten en la base del informe. La disciplina de tomar capturas y notas durante el test, no después, es fundamental.
Cierre del curso: próximos pasos
Has llegado al final del curso de Hacking Web. Ahora tienes los fundamentos teóricos y prácticos para entender, identificar y documentar vulnerabilidades web. El siguiente paso es la práctica constante y la validación de tus habilidades con certificaciones reconocidas por la industria.
Plataformas de práctica
- HackTheBox: máquinas y labs de dificultad progresiva. Ideal para aplicar técnicas de enumeración, explotación web y escalada de privilegios en entornos realistas. La sección Web Challenges es especialmente relevante para lo aprendido en este curso.
- TryHackMe: plataforma con rutas de aprendizaje guiadas, muy adecuada para consolidar conocimientos de forma estructurada. Las rutas Web Fundamentals y Jr Penetration Tester son un buen punto de partida.
- PortSwigger Web Security Academy: los creadores de Burp Suite ofrecen de forma gratuita uno de los mejores recursos de aprendizaje de hacking web, con labs interactivos para cada categoría de vulnerabilidad del OWASP Top 10.
Certificaciones recomendadas
- eJPT (eLearnSecurity Junior Penetration Tester): certificación de nivel entrada ofrecida por INE Security. Sin prerrequisitos formales, con un examen práctico en laboratorio (48 horas, basado en resolver tareas reales y responder preguntas a partir de los resultados obtenidos). La versión actual amplía la cobertura de reconocimiento y pentesting de aplicaciones web e incorpora nociones de IA ofensiva. Ideal como primera certificación que valida habilidades básicas de pentest.
- PNPT (Practical Network Penetration Tester): certificación de TCM Security con un examen de cinco días de lab más dos días para redactar y entregar el informe. Destaca por ser 100 % práctica y por incluir explícitamente la evaluación del informe como parte de la puntuación, lo que la hace especialmente relevante para lo aprendido en este módulo.
- OSCP+ (Offensive Security Certified Professional): el estándar de oro del sector, asociado al curso PEN-200. Desde la revisión de finales de 2024, OffSec entrega la designación OSCP+ (la versión clásica OSCP carece del «+» y de caducidad). El examen práctico dura 23 horas y 45 minutos —con tres máquinas independientes y un dominio de Active Directory en escenario de compromiso asumido— y otorga después 24 horas adicionales para redactar y entregar el informe completo, que es obligatorio para aprobar. Ya no existen puntos de bonificación por los ejercicios del curso. Reconocido internacionalmente por empleadores y clientes; requiere experiencia previa sólida, por lo que se recomienda completar eJPT o PNPT antes de afrontarlo.
Bug bounty
Los programas de bug bounty de plataformas como HackerOne o Bugcrowd permiten practicar hacking web en entornos reales con autorización explícita y recompensas económicas. Son un excelente complemento a los labs: aportan variedad de objetivos, feedback real y, eventualmente, ingresos. Empieza por programas públicos con alcances bien definidos y lee las reglas de cada programa con atención antes de comenzar cualquier prueba.
Si quieres explorar qué certificaciones y rutas de aprendizaje se adaptan mejor a tu perfil, puedes consultar nuestra sección de cursos y certificaciones.
Ejercicio propuesto
Elige uno de los hallazgos que identificaste en los módulos anteriores del curso (M4 a M9: SQLi, XSS, IDOR, SSRF, CSRF, deserialización insegura, etc.) y redacta una ficha de hallazgo completa siguiendo la estructura de este módulo. Incluye:
- Título específico con el endpoint afectado.
- Descripción técnica de la causa raíz.
- Impacto de negocio en dos o tres frases sin jerga técnica.
- Vector CVSS calculado con el calculador oficial de FIRST y su puntuación resultante. Usa preferentemente la versión vigente v4.0; opcionalmente añade también el vector v3.1, todavía habitual en muchos informes y bases de datos.
- Pasos de reproducción numerados.
- Recomendación de remediación concreta.
- Al menos dos referencias (OWASP Top 10, CWE o WSTG).
Este ejercicio simula exactamente lo que tendrás que hacer en un pentest real. Si repites este proceso para cada vulnerabilidad que encuentres en tus prácticas en HackTheBox, TryHackMe o PortSwigger, cuando llegues a tu primer encargo profesional el informe ya no será el mayor reto: será el resultado natural de un proceso bien ejecutado.
Preguntas frecuentes
¿Cuánto tiempo lleva redactar un informe de pentest profesional?
Depende de la extensión del proyecto y el número de hallazgos, pero como referencia general, para un pentest web de una semana con entre cinco y quince hallazgos, la redacción del informe consume entre un 20 % y un 30 % del tiempo total del proyecto, es decir, uno o dos días de trabajo. Por eso es fundamental tomar notas detalladas y capturas durante el propio test: redactar con notas completas tarda la mitad que intentar reconstruir los hallazgos de memoria al final. Las plataformas como SysReptor o Dradis pueden reducir significativamente este tiempo gracias a las plantillas y la importación de resultados de herramientas.
¿Qué diferencia hay entre un informe de pentest y un informe de escaneo de vulnerabilidades?
Un escaneo de vulnerabilidades (como el que genera Nessus, OpenVAS o un escáner web automatizado) produce un listado de posibles vulnerabilidades detectadas por firmas o heurísticas, con muchos falsos positivos y sin confirmación de explotabilidad. Un informe de pentest incluye únicamente vulnerabilidades verificadas manualmente, con evidencia de explotación real, análisis de impacto contextual y cadenas de ataque (cómo se puede combinar una vulnerabilidad con otra para maximizar el daño). El informe de pentest tiene mucho mayor valor porque el consultor filtra, confirma y contextualiza; el informe de escáner es un punto de partida, no un entregable final.
¿Puedo publicar un informe de pentest como parte de mi portfolio profesional?
Nunca debes publicar un informe real de un cliente sin su consentimiento explícito y por escrito, incluso si los datos identificativos están anonimizados: el contrato de confidencialidad generalmente lo prohíbe. Lo que sí puedes incluir en tu portfolio son: informes de labs de plataformas como HackTheBox o TryHackMe (que son entornos ficticios sin datos reales), informes de programas de bug bounty en los que la plataforma lo permita explícitamente, y write-ups de CTF (Capture The Flag). Para la certificación PNPT, el informe del examen es tuyo y es una excelente pieza de portfolio. Algunos profesionales crean también informes de ejemplo sobre aplicaciones vulnerables de práctica como DVWA o WebGoat.