Qué es un pentesting real y qué no lo es
La semana pasada un cliente nos dijo: «ya tenemos pentest, lo hizo un proveedor el año pasado». Cuando nos pasó el reporte, era un escaneo de Nessus con membrete. 14 páginas de falsos positivos y cero hallazgos explotados manualmente. No era un pentest. Era un PDF caro.
El problema: cualquiera puede decir que hace pentesting
No hay una certificación obligatoria. No hay un estándar que regule quién puede llamarle "pentest" a lo que vende. El resultado: el mercado está inundado de escaneos automáticos disfrazados de prueba de penetración. Y la diferencia no es semántica — es la diferencia entre saber que tenés una puerta abierta y ver a alguien entrar por ella.
Un escaneo te dice: «puerto 3389 abierto». Un pentest te dice: «entré por RDP usando la contraseña 'Admin2024' que encontré en un leak de LinkedIn de tu empleado, escalé a domain admin en 40 minutos y me llevé la base de clientes». El primero es una observación. El segundo es una simulación de lo que haría un atacante real.
Lo que NO es un pentest
- Correr Nessus, OpenVAS o Qualys y exportar el PDF
- Mandar un reporte automático sin validación manual
- Listar CVEs sin explotar ninguno
- No intentar escalar privilegios
- No intentar movimiento lateral
- No probar exfiltración de datos simulada
- Entregar solo capturas de pantalla de la herramienta
Lo que SÍ es un pentest real
- Reconocimiento manual + automatizado
- Explotación controlada de vulnerabilidades encontradas
- Escalación de privilegios local y de dominio
- Movimiento lateral entre segmentos de red
- Simulación de exfiltración (sin llevarse datos, pero demostrando que se podría)
- Reporte ejecutivo + técnico con pasos de remediación priorizados por riesgo real
Qué debería traer un reporte de pentest que sirva
Un reporte decente tiene dos caras. La primera la lee el CTO o el gerente de TI: quiere saber qué encontraron, qué tan grave es, y en qué orden arreglarlo. La segunda la lee el equipo técnico: quiere comandos exactos, evidencia de explotación, y pasos para reproducir y validar la corrección.
Si su reporte actual son 80 páginas con severity "High" en todo y capturas de pantalla de un scanner, está tomando decisiones con datos basura. Hemos visto reportes donde el 60% de los hallazgos eran falsos positivos que nadie se tomó el trabajo de verificar. Eso no es un pentest. Es ruido.
Lo mínimo que debe venir en el reporte:
- Resumen ejecutivo en lenguaje de negocio: qué se comprometió, en cuánto tiempo, con qué impacto
- Hallazgos priorizados por explotabilidad real, no por score CVSS genérico. Un CVE 9.8 que no es accesible desde ningún vector de ataque en su red es menos urgente que un 6.5 explotable con credenciales de invitado
- Evidencia de explotación: capturas, comandos ejecutados, timestamps. Si no hay evidencia de que lo explotaron, asuma que no lo intentaron
- Plan de remediación con pasos concretos. No "aplicar parches de seguridad". Eso no sirve. Queremos: "Actualizar FortiGate a versión 7.4.3, deshabilitar SSL-VPN en modo túnel, habilitar MFA en el portal de administración, y rotar las API keys de los administradores"
Cada cuánto debería hacerse un pentest
Depende del ritmo de cambios de su infraestructura. Regla general: al menos una vez al año. Pero si cada trimestre despliegan servicios nuevos, cambian proveedores cloud o abren sucursales, la frecuencia debería ser mayor. También después de cualquier cambio grande: migración a la nube, fusión, nuevo ERP, o después de un incidente.
Una empresa que solo hace pentest una vez al año y no tiene monitoreo continuo se está revisando el colesterol en enero y comiendo frito los otros 11 meses. No funciona así.
La pregunta que debería hacerle a su proveedor de pentest
"Muéstreme un hallazgo que hayan explotado manualmente en un ejercicio anterior, cómo lo hicieron, y qué impacto tuvo para el cliente." Si la respuesta es vaga o hablan de "escaneos exhaustivos" sin detalles técnicos, probablemente están comprando un PDF generado por una herramienta.
Cómo leer un reporte sin ser técnico
No necesita entender metasploit para evaluar si su pentest valió la pena. Concéntrese en tres cosas:
- ¿Encontraron algo que su scanner automático no vio? Si el reporte solo lista vulnerabilidades que ya aparecían en su Qualys mensual, el pentest no agregó valor
- ¿Encadenaron vulnerabilidades para llegar a un activo crítico? Un atacante real no explota una vulnerabilidad y se va. Busca el camino más débil hasta la base de datos, el directorio activo o el sistema de facturación. Si su reporte no muestra esas cadenas de ataque, es superficial
- ¿El plan de remediación es específico para su stack? Si las recomendaciones aplican igual a un banco que a una fábrica, son genéricas. Su entorno es particular: su Active Directory, su firewall, su ERP. Las soluciones deberían serlo también
Un pentest de verdad es incómodo. Le van a decir que alguien sin autorización podría haber leído los correos del CEO. Lo van a poner nervioso. Eso es bueno. Si su reporte no le quita el sueño al menos un par de noches, probablemente no fue lo suficientemente profundo.
← Volver al blog