Cerramos el Módulo 5 con una idea que ahora se convierte en el eje de todo el Módulo 6: el trabajo técnico ha terminado; empieza el trabajo de convertirlo en valor para TechNova. Durante las fases de reconocimiento, escaneo, explotación y post-explotación capturamos una montaña de materia prima —comandos, salidas, marcas de tiempo, artefactos, la cadena de compromiso y el mapa de la red interna 10.10.10.0/24—. Nada de eso vale para el cliente mientras siga en tu carpeta de notas. El informe es el entregable que da valor al pentest: es lo que TechNova pagó, lo que leerá su dirección y lo que usarán sus técnicos para remediar y reducir riesgo.

Esta primera lección trata de cómo documentar cada hallazgo de forma que sea reproducible, trazable y accionable, y de cómo se estructura un informe de pentest. No entramos todavía en cómo puntuar la severidad con CVSS (eso es 06-02), ni en cómo redactar remediaciones a fondo (06-03), ni en cómo presentar los resultados en la reunión de cierre (06-04). Aquí construimos el ladrillo con el que se levanta el informe: el hallazgo bien documentado. Y una advertencia que recorre toda la lección: el informe contiene vulnerabilidades reales y explotables de TechNova; es un documento altamente confidencial y se trata como tal desde la primera nota de campo.

1. Documentar durante el test, no después
2. Anatomía de un hallazgo
3. Evidencia reproducible y prueba de concepto (PoC)
4. Trazabilidad: del hallazgo a la evidencia cruda
5. Notas de campo y bitácora
6. Gestión de evidencia sensible y confidencialidad
7. Estructura de un informe de pentest
8. Plantilla de hallazgo: la SQLi de TechNova de principio a fin
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

El error más caro de un pentester novato es dejar la documentación para el final. Cuando llevas dos semanas de test, comprometiste cinco máquinas y pivotaste por media red, es imposible reconstruir de memoria qué payload exacto funcionó en producto.php?id= un martes por la tarde. La documentación se hace en caliente, mientras la evidencia está fresca y el terminal aún muestra la salida.

La regla práctica: cada vez que consigues algo relevante —un servicio enumerado, una vulnerabilidad confirmada, un acceso obtenido— capturas la evidencia en ese mismo momento y anotas lo mínimo para reconstruirlo después (activo, hora, comando, resultado). El informe final se redacta al terminar, pero se alimenta durante todo el engagement.

Un hallazgo (finding) es la unidad básica del informe: describe una debilidad concreta en un activo concreto. Un buen hallazgo responde, sin que el lector tenga que preguntar, a: qué es, dónde está, cómo lo demostraste, qué daño causa y qué hacer al respecto. Estos son sus campos:

Cada uno de estos campos tiene una función. Faltando cualquiera, el hallazgo pierde utilidad: sin activo, no se sabe dónde arreglar; sin pasos de reproducción, el cliente no puede validar; sin impacto de negocio, la dirección no entiende por qué priorizarlo.

La evidencia es lo que convierte una afirmación en un hecho. "El sitio es vulnerable a SQLi" es una opinión; una captura de la respuesta del servidor devolviendo la versión de MySQL ante tu payload es una prueba. Buenas prácticas para capturar evidencia:

• Reproducible: incluye el comando/petición completo y la salida literal. Quien lea el informe debe poder repetir el paso y obtener el mismo resultado.
• Mínima pero suficiente: muestra lo justo para probar el punto. No vuelques 4.000 filas de una tabla; una fila que demuestre acceso a datos sensibles basta.
• Con contexto: anota fecha, hora, host de origen y activo destino en cada pieza. Una captura sin contexto no vale como prueba.
• Sin causar daño real: la PoC demuestra el problema, no lo explota destructivamente. Extraes un registro de muestra para probar el acceso, no vuelcas ni exfiltras la base de datos entera del cliente.
• Datos sensibles enmascarados: si la evidencia contiene datos personales reales de clientes de TechNova, redáctalos (anonimiza) en el informe: juan.****@***.com. Demuestras el acceso sin propagar el dato.

La prueba de concepto (PoC) es la secuencia concreta y controlada que demuestra la explotabilidad. En un informe profesional la PoC es suficiente para convencer, insuficiente para causar daño: enseña la ruta, no entrega un arma lista para abusar.

Trazabilidad significa que cada afirmación del informe se puede seguir hasta la evidencia cruda que la sustenta. Es lo que hace tu trabajo auditable y defendible: si TechNova (o un tercero) cuestiona un hallazgo, tú puedes enseñar la captura original, el log de la herramienta y la hora exacta.

Un esquema de trazabilidad simple pero eficaz:

En la práctica se materializa nombrando los ficheros de evidencia de forma consistente (TN-001_sqli_producto_respuesta.png), guardándolos en una carpeta por hallazgo y referenciándolos desde el informe. Así, el ID del hallazgo es el hilo que une la nota de campo, la evidencia y la recomendación.

Las notas de campo son tu registro en bruto durante el test. Ya insistimos en la bitácora en el Módulo 5 desde la ética (dejar rastro auditable); aquí la vemos desde la utilidad para el informe. Una entrada de bitácora útil recoge, por cada acción relevante:

Con marcas de tiempo, origen, destino, acción y referencia a la evidencia, cualquier entrada se convierte después en parte de un hallazgo o de la cronología del ataque. La bitácora también protege al pentester: demuestra que se mantuvo dentro del alcance autorizado.

El informe y su evidencia son material sensible: documentan cómo comprometer sistemas reales de TechNova y pueden contener datos de sus clientes. Tratar esto con ligereza es una falta profesional grave. Principios:

• Confidencialidad por defecto: el informe se clasifica como confidencial y solo se comparte con los interlocutores autorizados en el contrato.
• Cifrado en reposo y en tránsito: las notas, capturas y el informe se guardan cifrados y se entregan por un canal seguro (nunca por correo sin cifrar). La entrega segura se detalla en 06-04.
• Minimización: no captures más datos sensibles de los necesarios para probar el hallazgo; enmascara los que sí capturas.
• Retención y destrucción: acuerda con el cliente cuánto tiempo conservas la evidencia y destrúyela de forma segura al vencer ese plazo.
• Control de acceso: solo el equipo del engagement accede a la evidencia; nada de copias en dispositivos personales sin cifrar ni en servicios en la nube no autorizados.

Recuerda: filtrar un informe de pentest es entregar a un atacante un mapa exacto de por dónde entrar. La confidencialidad no es burocracia, es parte del servicio.

Un informe profesional sirve a dos públicos a la vez y por eso se organiza en dos grandes bloques (la comunicación a cada público se trabaja en 06-04). Estructura típica:

La regla de oro: el resumen ejecutivo se lee sin conocimientos técnicos; el detalle técnico se lee con ellos. Un director debe entender el riesgo sin saber qué es una inyección SQL; un administrador debe poder reproducir y corregir el problema con el detalle técnico.

Reunimos todo lo anterior en una plantilla reutilizable, documentando el hallazgo estrella del engagement: la inyección SQL en producto.php?id= que explotamos en el Módulo 4.

Esta plantilla es autoexplicativa: quien la lea sabe qué pasa, dónde, cómo probarlo, qué se juega TechNova y por dónde empezar a arreglarlo. Nota que la PoC demuestra el acceso (una fila de muestra) sin volcar datos masivos ni causar daño: evidencia suficiente, impacto controlado.

• Documentar de memoria al final. Se pierden detalles críticos y la evidencia deja de ser reproducible. Captura en caliente, siempre.
• Evidencia sin contexto. Una captura sin fecha, host y activo no prueba nada. Anota el contexto en cada pieza.
• Volcar datos reales del cliente en el informe. Enmascara los datos sensibles: demuestra el acceso, no propagues el dato. Un informe filtrado no debe ser una fuga de datos añadida.
• Un hallazgo que mezcla dos problemas. Un hallazgo = una debilidad = un activo. Si hay SQLi y XSS, son dos hallazgos con dos IDs.
• Títulos vagos. "Problema de seguridad en la web" no ayuda a nadie. Sé específico: "Inyección SQL en producto.php".
• [Ético] Tratar el informe como un documento cualquiera. Contiene vulnerabilidades reales y explotables; cífralo, contrólalo y entrégalo por canal seguro.
• Consejo: escribe el impacto pensando en quién decide el presupuesto. "Extrae la base de datos" es técnico; "expone los datos de todos los clientes" es negocio. Ambos importan, en su sección.

Ejercicio 1. Durante el test descubres que el panel de administración de la tienda (https://tienda.technova.lab/admin/) es accesible sin autenticación y muestra pedidos de clientes. Redacta un hallazgo completo siguiendo la anatomía de la sección 2 (título, activo, descripción, impacto, pasos de reproducción, evidencia y recomendación resumida). Asígnale un ID.

Ejercicio 2. Un compañero te pasa esta nota: "la web tiene fallos, hay que arreglarla". Explica por qué esta nota es inservible como hallazgo y enumera qué campos le faltan para serlo.

Ejercicio 3. Estás a punto de incluir en el informe una captura que muestra la tabla usuarios completa con 12.000 correos y hashes reales de clientes de TechNova. Explica qué haces antes de incluirla y por qué, relacionándolo con la gestión de evidencia sensible.

Solución 1. Ejemplo de hallazgo:

• ID: TN-2026-014
• Título: Panel de administración accesible sin autenticación
• Activo afectado: https://tienda.technova.lab/admin/
• Descripción: El directorio /admin/ no exige autenticación; cualquier usuario que conozca o adivine la ruta accede al panel y visualiza pedidos de clientes. Es un fallo de control de acceso (autorización rota).
• Impacto: Un atacante no autenticado accede a datos personales y de pedidos de los clientes. Para el negocio: brecha de datos, incumplimiento normativo y daño reputacional.
• Pasos de reproducción: (1) navegar a https://tienda.technova.lab/admin/; (2) observar que el panel carga sin pedir credenciales y lista pedidos.
• Evidencia: captura del panel con los datos de cliente redactados (TN-014_admin_sin_auth.png).
• Recomendación (resumen): exigir autenticación y autorización por rol en todo /admin/; denegar por defecto. Referencia: OWASP A01:2021 (Broken Access Control), CWE-284.

Solución 2. La nota es inservible porque no es reproducible, ni trazable, ni accionable: no dice qué falla, dónde, ni cómo demostrarlo. Le faltan todos los campos de un hallazgo: ID, título específico, activo afectado, descripción del problema, severidad, impacto de negocio, pasos de reproducción, evidencia/PoC y recomendación. Tal como está, TechNova no puede verificar nada ni corregir nada.

Solución 3. Antes de incluirla, enmascaro los datos sensibles (anonimizo correos y no incluyo hashes reales) y reduzco la evidencia a una fila de muestra que baste para probar el acceso, no la tabla entera. Motivo: la evidencia debe ser mínima pero suficiente y no debe convertir el informe en una fuga de datos. Extraer y volcar 12.000 registros reales excede la PoC necesaria, aumenta el riesgo si el informe se filtra y puede vulnerar la protección de datos. Demuestro el acceso sin propagar el dato, y guardo la evidencia cifrada y con acceso restringido.

Hemos convertido la materia prima del Módulo 5 en la unidad fundamental del informe: el hallazgo bien documentado. Vimos su anatomía completa —título, activo, descripción, impacto, pasos de reproducción, evidencia/PoC, severidad y recomendación—, la importancia de capturar evidencia reproducible en caliente, la trazabilidad que une cada afirmación con su evidencia cruda, el papel de las notas de campo y, muy en primer plano, la gestión de la evidencia sensible: el informe contiene vulnerabilidades reales de TechNova y se trata como material confidencial de principio a fin. También encajamos el hallazgo dentro de la estructura del informe, con su resumen ejecutivo para negocio y su detalle técnico, y dejamos una plantilla reutilizable aplicada a la SQLi de TechNova.

Ya sabemos documentar cada hallazgo; el siguiente paso es priorizarlos. En la plantilla escribimos "Severidad: Crítica | CVSS 9.8" y prometimos justificarlo. Eso es exactamente lo que hace la próxima lección, 06-02: Clasificación de Riesgos y CVSS, donde aprenderemos a calcular y leer un vector CVSS, a traducir el score a un rating y, sobre todo, a distinguir la severidad técnica del riesgo de negocio para TechNova. Documentar es tener las piezas; clasificar es saber cuáles atacar primero.