Informe de pentest de ejemplo: qué recibe su institución al terminar la prueba

El informe tiene dos partes que se leen por separado. El informe ejecutivo dice en palabras de negocio qué se probó, qué quedó fuera y qué exposición encontramos. El informe técnico documenta cada hallazgo para que el equipo de TI lo pueda reproducir y corregir sin llamar a nadie.

Lo firma la persona que acordó el alcance y dirigió la prueba. Cada hallazgo se confirma a mano antes de entrar al informe. Una alerta de una herramienta que nadie pudo confirmar no se reporta como hallazgo. Del contrato firmado al informe pasan de 2 a 4 semanas.

En el ejemplo, el cliente es Cooperativa Ejemplo, una institución ficticia. El alcance es su red externa y su banca en línea. Las partes del documento son estas:

• Portada: institución, alcance autorizado, fechas de la prueba, versión del documento y quién firma.
• Informe ejecutivo: la exposición en dos o tres párrafos, la tabla de hallazgos por criticidad y lo que se recomienda hacer primero.
• Alcance y método: qué sistemas entraron, desde dónde se probó, qué quedó fuera y por qué.
• Informe técnico: una ficha por hallazgo, con evidencia, pasos, impacto y corrección.
• Verificación de correcciones: el estado de cada hallazgo después de volver a probar.

Así se lee el resumen del ejemplo. Todo lo que sigue es ficticio.

"Entre el 3 y el 14 de marzo probamos la red externa de Cooperativa Ejemplo, con 12 direcciones IP públicas, y su banca en línea, con dos roles de usuario. La prueba se hizo con autorización escrita y dentro de las ventanas acordadas. No se afectó la operación."

"El hallazgo más serio permite a un usuario de la banca en línea hacer una transferencia a una cuenta de tercero sin el factor adicional que la cooperativa exige en ese tipo de operación. Un atacante que obtenga la contraseña de un asociado podría mover dinero sin el segundo factor. Recomendamos corregirlo antes que cualquier otro punto."

"En la red externa encontramos un servicio de acceso remoto con una versión que tiene una vulnerabilidad pública conocida. No la explotamos más allá de confirmar la versión, porque el alcance excluía cambios en producción. El resto de hallazgos son de criticidad media, baja o informativa."

La tabla es lo primero que mira el comité y lo que se copia en el plan de remediación. Cada hallazgo tiene un identificador que no cambia entre el informe, el plan y la verificación. El identificador dice dónde está el hallazgo: EXT para la red externa y WEB para la aplicación.

Cada hallazgo ocupa una ficha con los mismos campos. Este es WEB-01 del ejemplo.

Qué encontramos: al enviar la transferencia, la aplicación pide el código del segundo factor. Si se repite la solicitud cambiando un parámetro que el navegador envía, el servidor acepta la operación sin validar el código.

Evidencia: las solicitudes y respuestas completas, con la hora de cada una, y capturas de la pantalla del usuario de prueba. Los datos de asociados y las credenciales aparecen tachados. Se usaron solo las cuentas de prueba que entregó la cooperativa.

Pasos para reproducirlo: la secuencia exacta, numerada, para que TI vea el problema con sus propios ojos en el ambiente de pruebas.

Impacto: quién puede usar el fallo, qué necesita antes y qué puede lograr. Aquí, cualquiera con la contraseña de un asociado puede mover dinero a otra cuenta sin el segundo factor.

Corrección sugerida: validar el factor adicional en el servidor para toda transferencia a terceros, sin depender de lo que envía el navegador, y registrar los intentos fallidos.

Referencia normativa, cuando aplica: en El Salvador, los Arts. 22 y 23 de la NRP-32 piden el factor adicional en transferencias electrónicas a terceros. En otros países la ficha cita la norma que aplique a la institución.

Cuando TI corrige, volvemos a probar lo corregido. La verificación va incluida en el precio y se hace dentro de 90 días desde el informe. Cada hallazgo queda en uno de dos estados: corregido o pendiente. Los hallazgos que se aceptan como riesgo los decide la institución, no el proveedor.

La verificación del ejemplo se ve así:

Con la tabla de hallazgos en la mano, cada herramienta arma en su navegador el documento que su regulador pide antes o después de la prueba. Lo que escribe no sale de su navegador.

• El SalvadorNRP-23: resumen de resultados y plan de remediación
• GuatemalaJM-98-2025: alcance interno y externo para pedir cotizaciones
• HondurasCNBS 025/2022: análisis de periodicidad y alcance del Art. 24
• Costa RicaCONASSIF 5-24: programa anual del Art. 33

El informe es evidencia. Su institución decide cómo lo presenta. Toukan no forma parte de ningún supervisor y no emite opiniones de cumplimiento.

• El Salvador: la NRP-23, Art. 20 i), pide remitir un resumen de resultados a más tardar diez días hábiles después de recibir el informe del proveedor, y un plan de remediación treinta días hábiles después. La NRP-32, Art. 5, pide remediar todas las brechas, no solo las críticas.
• Guatemala: la JM-98-2025, Art. 18, pide pruebas de penetración internas y externas y que el resultado conste en un informe técnico.
• Honduras: la Circular CNBS 025/2022, Art. 24, pide pruebas de intrusión ejecutadas por terceros.
• Costa Rica: el Acuerdo CONASSIF 5-24, Art. 33, pide programas anuales de análisis de vulnerabilidades y pruebas. El Art. 3 deja ese artículo como voluntario para dos grupos de entidades.