Perfecto. Aquí tienes una nota técnica completa sobre el informe de pentest, basada en el documento “Auditoría Técnica de Seguridad.pdf” y enriquecida con buenas prácticas reales, recomendaciones profesionales y ejemplos actualizados:


El Informe de Pentest

Relacionado: SSRF. owasp. Alcance. Controles. IDOR.

El informe de pentest (penetration testing report) es el resultado formal de una auditoría técnica que recoge las pruebas realizadas, los hallazgos encontrados, su gravedad, y las recomendaciones para mitigar los riesgos. Es el entregable más importante del proceso, ya que representa la única evidencia tangible del trabajo realizado.

Un buen informe debe ser claro, preciso, estructurado y comprensible tanto para públicos técnicos como para responsables de negocio.


️ Estructura típica de un informe de pentest

La mayoría de los informes profesionales siguen una estructura similar a la siguiente:

1. Tratamiento del documento

  • Clasificación: Confidencial / Uso interno / Sensible

  • Control de versiones

  • Identificación de las personas responsables (auditores, cliente, revisores)

  • Fecha del informe


2. Resumen ejecutivo

Una visión no técnica para directivos:

  • Qué se auditó

  • Qué se encontró (resumen de riesgos por nivel)

  • Riesgos críticos identificados

  • Conclusión general

  • Recomendación principal

Debe poder leerse en 2-3 minutos y permitir a la dirección tomar decisiones de forma informada.


3. Alcance y objetivos

  • Aplicaciones, IPs, APIs o entornos evaluados

  • Límites definidos (qué no se testea)

  • Tipo de caja (blanca, gris, negra)

  • Duración del pentest

  • Usuarios/roles proporcionados (si aplica)

  • Herramientas permitidas y condiciones (por ejemplo: sin DoS)


4. Metodología

  • Marco seguido: OWASP WSTG, OSSTMM, PTES, NIST 800-115…

  • Descripción de fases:

    • Recolección de información

    • Reconocimiento

    • Enumeración

    • Análisis de vulnerabilidades

    • Explotación

    • Post-explotación

  • Técnicas aplicadas (manuales, automáticas, semi-dirigidas)

  • Limitaciones encontradas durante la ejecución


5. Hallazgos de seguridad

Cada vulnerabilidad debe tener una ficha que incluya:

  • Título claro: SQL Injection en login – /login.php

  • Descripción del fallo

  • Riesgo (por ejemplo, CVSS 4.0)

  • Evidencia (capturas, comandos, respuesta del servidor)

  • Impacto posible (filtración, acceso, control del sistema)

  • Recomendación técnica y priorización

  • Referencias (CWE, OWASP, MITRE, parches, links útiles)

Se puede añadir un cuadro resumen con todos los hallazgos ordenados por criticidad (alto, medio, bajo, info).


6. Detalles técnicos adicionales

  • Resultados del escaneo automático (Nmap, Nessus, Nikto, etc.)

  • Scripts o payloads utilizados (por ejemplo, XSS, LFI, SSRF, etc.)

  • Hashes, tokens, sesiones capturadas

  • Análisis de tráfico (pcaps si aplica)

  • Evidencia de escaladas de privilegios o persistencia


7. Mitigaciones y recomendaciones

Por cada hallazgo, se puede proponer:

  • Parche o configuración específica

  • Cambio de arquitectura (si aplica)

  • Implementación de controles compensatorios

  • Mejora en detección (SIEM, alertas, WAF, etc.)


8. Conclusiones generales

  • Grado de exposición de los activos

  • Riesgos acumulados

  • Evaluación del posture de seguridad

  • Grado de madurez observado

  • Roadmap recomendado


9. Anexos

  • Documentación complementaria

  • Logs o dumps extensos

  • Scripts utilizados

  • Declaración de conformidad con la metodología


Buenas prácticas profesionales

  • Clara separación entre hechos y opiniones

  • Uso del lenguaje adecuado al público objetivo

  • Evidencia reproducible (respuestas completas, no solo capturas)

  • Evitar juicios destructivos o sarcasmo

  • Priorizar los hallazgos según impacto real (no cantidad)


️ Clasificación de vulnerabilidades (CVSS)

Se recomienda usar el sistema CVSS (Common Vulnerability Scoring System), versión 3.1 o 4.0, para asignar una puntuación objetiva a cada fallo:

NivelRango CVSSDescripción breve
Crítico9.0 – 10Explotación directa y completa
Alto7.0 – 8.9Acceso o daño significativo
Medio4.0 – 6.9Impacto controlado
Bajo0.1 – 3.9Poco aprovechable
Informativo0No es un fallo, pero aporta contexto

Recursos y ejemplos de informes reales


Plantillas útiles

¿Te interesa que te prepare una plantilla en Word o Markdown para tus propios informes de pentest? También puedo ayudarte a adaptar una para un caso específico (por ejemplo: entorno web, API REST, red interna, etc.).


¿Quieres que hagamos un informe simulado con algún entorno como HackTheBox, TryHackMe o VulnHub para practicar?