Qué es el pentesting: alcance, fases, entregable y retest

Qué es un pentest, y qué no es

Un pentest es un encargo con tres cosas que lo definen: permiso por escrito, un alcance cerrado y un objetivo. Sin las tres, no es un pentest.

El trabajo consiste en hacer lo que haría un atacante: buscar qué tienes expuesto, encontrar fallos, encadenarlos y demostrar hasta dónde se llega. La palabra importante es demostrar. Un pentest no dice "esto podría ser explotable": lo explota, en un entorno controlado, y te enseña la prueba.

Lo que no es:

• No es una pasada de escáner. Un escáner encuentra versiones viejas y configuraciones por defecto. No encuentra que el identificador de la factura del cliente A funcione en la sesión del cliente B, porque para eso hay que entender qué hace tu negocio.
• No es una auditoría de cumplimiento. Una auditoría comprueba que tienes un control; un pentest comprueba si ese control aguanta.
• No es una garantía. Dice lo que se encontró en ese alcance y en esa fecha. Un pentest limpio significa que quien lo hizo no entró con ese tiempo y ese alcance, no que no se pueda entrar.
• No es un red team. Un pentest busca cobertura, encontrar todo lo que pueda en el alcance. Un red team busca un objetivo concreto sin avisar a los defensores, y lo que mide es si alguien se entera.

Pentest o análisis de vulnerabilidades: la confusión que más caro sale

Es la duda de quien compra por primera vez, y la que hace que se pague un pentest y se reciba otra cosa.

Un análisis de vulnerabilidades es automático, amplio y recurrente. Pasa una herramienta sobre muchos activos, compara versiones y configuraciones con una base de fallos conocidos, y devuelve una lista. Es barato, se puede lanzar todos los meses y sirve para lo que sirve: saber qué tienes desactualizado.

Un pentest es manual, estrecho y puntual. Una persona intenta entrar. Cuesta más, cubre menos superficie y encuentra lo que ninguna herramienta ve: fallos de lógica de negocio, permisos que no separan a un cliente de otro, cadenas de tres cosas inofensivas que juntas dan acceso.

No compiten, se ordenan. El análisis recurrente es higiene y va primero, porque encontrar con un pentest algo que un escáner habría cantado gratis es tirar el dinero. El pentest va después y responde a otra pregunta.

Cómo distinguir qué te están vendiendo, con una sola pregunta: pide el informe de ejemplo. Si tiene cientos de hallazgos, todos con el mismo formato y ninguno con una petición reproducible, es una exportación de escáner con portada.

Lo que se decide antes de empezar

Esta fase no se factura y decide el resultado entero. Todo esto se cierra por escrito y en conjunto se llama rules of engagement.

• El alcance, enumerado. Dominios, IPs, aplicaciones, APIs, cuentas cloud, redes, apps móviles. Y lo que queda fuera, con la misma claridad. Antes de cerrarlo conviene saber qué tienes de verdad expuesto, que casi nunca coincide con el inventario: eso es la superficie de ataque.
• El punto de partida. Sin información y sin credenciales, con documentación, o con usuario y contraseña de cada perfil. Cuanto más se da, más se cubre en el mismo tiempo, porque no se gastan días en averiguar lo que ya sabes. Empezar a ciegas prueba el reconocimiento; empezar con credenciales prueba la aplicación.
• El entorno. Producción o una copia, y si es una copia, en qué se diferencia. Una preproducción con otros datos y otra configuración no prueba lo mismo.
• Ventana y avisos. Cuándo se puede lanzar tráfico, quién lo sabe y quién no, y a quién se llama si algo se cae.
• Los límites. Denegación de servicio, ingeniería social sobre personas concretas, exfiltración real de datos de clientes.
• La vía rápida. Qué pasa si aparece algo crítico el primer día. La respuesta correcta es que se avisa en el momento y no se espera al informe.

Las fases, en el orden en que ocurren de verdad

1. Reconocimiento. Qué existe, qué responde, qué versiones, qué subdominios olvidados, qué credenciales de tu dominio ya circulan por ahí. Aquí sale casi siempre alguna sorpresa que no estaba en el inventario.
2. Análisis y mapeo. Cómo funciona la aplicación, qué roles hay, dónde están los puntos donde se decide si alguien puede hacer algo. Es la fase que separa el trabajo manual del automático.
3. Explotación. Confirmar que un fallo es real explotándolo, con cuidado y sin romper nada.
4. Post-explotación y encadenado. Qué se alcanza desde ahí. Es donde un fallo "medio" se convierte en un problema grave, porque tres cosas pequeñas seguidas llegan más lejos que una grande sola.
5. Informe. Escribirlo bien lleva tiempo real y forma parte del proyecto, no es un extra.
6. Retest. Después de que tu equipo arregle.

El detalle de cómo lo hacemos nosotros está en nuestra metodología, y hay dos ejemplos completos escritos fase a fase: un pentest de aplicación web y uno de red interna.

Qué tipo de pentest te toca

Se nombran por lo que se prueba, y lo normal es necesitar dos o tres, no los nueve. Empieza por donde está tu negocio y por lo que da a internet.

• Aplicación web. Si tu producto o tu operación viven en una web, es este.
• API. Cada vez más, el fallo grave está aquí y no en la interfaz.
• Red externa. Todo lo que se ve desde internet.
• Red interna. Desde un puesto normal: hasta dónde se llega. Es el camino del ransomware.
• Cloud. Permisos, configuración y confianza entre cuentas, que es donde está el problema y no en las máquinas.
• Aplicación móvil y wifi.
• IoT, cuando hay hardware y firmware de por medio.
• IA. Para asistentes y agentes conectados a datos y herramientas propias.

Si lo que quieres medir no son las vulnerabilidades sino la capacidad de detectar y responder, el formato es un red team, o un ejercicio de assumed breach que arranca dando por hecho que el atacante ya está dentro. Y si no sabes por cuál empezar, la puerta de entrada habitual es hacking ético.

El entregable, que es lo único que te queda

Cuando el proyecto termina, lo que te queda es un documento. Lo que tiene que llevar:

• Un hallazgo reproducible. Petición exacta, pasos, capturas o traza. Si tu equipo no lo puede repetir, no lo puede arreglar ni comprobar.
• Impacto de negocio, no solo severidad técnica. El CVSS es una escala útil y no es una prioridad: un fallo medio en el sistema de pagos va antes que uno alto en una intranet interna. Eso lo tiene que decir el informe, con tus sistemas delante.
• Una recomendación concreta. "Sanitizar la entrada" es una categoría, no una recomendación.
• Resumen para dirección que se sostenga solo, porque quien aprueba el presupuesto de corrección va a leer esa página y no las otras cuarenta.
• Qué se probó y salió limpio. Sin eso no se distingue lo que está bien de lo que no se miró.
• Metodología y cobertura, para que dentro de un año se sepa qué cubría aquel informe.

Un PDF es un documento; los hallazgos en el flujo de trabajo de tu equipo son trabajo empezado. En nuestro caso viven en la plataforma desde que se encuentran, con su estado, en lugar de aparecer todos juntos al final.

El retest, que es donde el informe se convierte en una mejora

Un pentest sin retest es una foto: alguien dice qué está mal, tu equipo lo arregla y nadie comprueba que esté arreglado. Pasa mucho que la corrección tape el camino que se probó y deje abierto el de al lado.

Lo que hay que cerrar en el contrato, antes y no después: si el retest está incluido o se factura aparte, cuánto tiempo tienes para pedirlo, si cubre solo lo corregido o también lo que haya cambiado alrededor, y qué documento produce. Lo normal es una versión del informe con cada hallazgo marcado como corregido, mitigado o abierto, que es lo que luego se enseña a un cliente o a un auditor.

Y algo que no cuesta dinero y evita casi todos los atascos: acordar antes quién arregla, en qué plazo por severidad, y quién puede decidir que un riesgo se acepta en vez de corregirse.

Cuánto dura, cómo se presupuesta y qué pide la norma

Aquí no vas a encontrar un precio, y es a propósito: un número sin tu alcance delante no es información, es un anzuelo. Lo que sí se puede explicar es qué lo mueve, que es lo que necesitas para pedir presupuesto sin que te den una cifra de plantilla.

Un pentest se presupuesta por días de trabajo, y los días salen de:

• El tamaño real del alcance. No cuántas aplicaciones, sino cuántas funciones distintas y cuántos roles hay. Una aplicación con cinco perfiles de usuario es mucho más trabajo que cinco aplicaciones de un solo perfil.
• El punto de partida. Empezar a ciegas consume días en averiguar lo que tú ya sabes.
• El tipo. Un pentest de IoT lleva hardware y tiempos que uno web no tiene.
• Si hay retest incluido y cuántas rondas.
• Requisitos formales. Un informe para un auditor o para un cliente que lo exige por contrato tiene más trabajo de redacción.

En duración, lo que se puede decir sin inventar: la parte de pruebas suele ser bastante más corta que el proyecto entero, porque el alcance, la coordinación de accesos, el informe y el retest también ocupan calendario. Si alguien te ofrece "toda la infraestructura" en dos días, lo que cabe en dos días es una pasada de herramienta.

Y la parte de cumplimiento, que es el motivo real de muchos proyectos: el ENS exige auditoría periódica y llega por contrato a quien vende a la administración; ISO 27001 no se certifica con un pentest, pero el pentest es la evidencia que sostiene varios controles; NIS2 alcanza a la cadena de suministro, así que puede llegarte como cláusula de tu cliente; y DORA exige a determinadas entidades financieras pruebas dirigidas por inteligencia de amenazas, el TLPT, que no es un pentest normal. Para protección de datos personales, el marco es el RGPD y va por aquí.

El catálogo completo está en servicios, cómo elegir proveedor en esta guía, y para un alcance concreto, contacto.