¿Qué Es Un Pentesting y Cómo Se Hace?
Un pentesting, o test de penetración, es una simulación controlada de un ciberataque real sobre los sistemas de una organización, realizada con autorización expresa y con el objetivo de encontrar las vulnerabilidades antes que un atacante.
La idea de fondo es sencilla: la única forma fiable de saber si unas defensas aguantan es intentar atravesarlas. Todo lo demás son suposiciones.
Pentesting y análisis de vulnerabilidades no son lo mismo
Es la confusión más extendida y conviene resolverla primero, porque hay quien contrata lo segundo creyendo que compra lo primero.
Un análisis de vulnerabilidades es un escaneo automatizado. Una herramienta recorre los sistemas, los compara con bases de datos de fallos conocidos y emite un listado. Es rápido, económico, repetible y conviene hacerlo con frecuencia. Pero es automático: no confirma si los fallos detectados son explotables de verdad, y produce un número considerable de falsos positivos.
Un pentesting implica a una persona intentando explotar realmente esos fallos. Confirma cuáles son aprovechables, encadena varios problemas menores para lograr un impacto mayor —algo que ninguna herramienta hace— y demuestra el alcance concreto de una brecha. También detecta fallos de lógica de negocio que un escáner nunca encuentra, como poder acceder a los datos de otro cliente cambiando un número en la URL.
La diferencia práctica: el análisis dice que una puerta parece mal cerrada; el pentesting la abre, entra y te enseña hasta dónde puede llegar alguien desde dentro. Ambos son útiles y se complementan, pero no se sustituyen.
Los tres enfoques: caja negra, blanca y gris
Caja negra
El auditor no recibe ninguna información previa. Parte de cero, exactamente igual que un atacante externo que solo conoce el nombre de la empresa.
Es el escenario más realista para evaluar la exposición desde internet y la eficacia del perímetro. Su limitación es el tiempo: buena parte del esfuerzo se dedica a labores de reconocimiento, y si el presupuesto de horas se agota ahí quedan zonas sin revisar.
Caja blanca
El auditor recibe información completa: arquitectura, credenciales, documentación y a menudo el código fuente.
Es el enfoque más exhaustivo, porque todo el tiempo se dedica a buscar fallos en lugar de a descubrir qué hay. Permite revisar el código en profundidad y encontrar problemas que desde fuera serían invisibles. Es el más recomendable cuando el objetivo es asegurar a fondo una aplicación concreta.
Caja gris
Un punto intermedio: el auditor tiene conocimiento parcial, normalmente credenciales de usuario estándar y alguna información de la arquitectura.
Simula el escenario que más se parece a la realidad de muchas brechas: un empleado con acceso limitado, un atacante que ya ha conseguido unas credenciales mediante phishing, o un proveedor con acceso al sistema. Suele ofrecer la mejor relación entre realismo y cobertura, y es el más solicitado.
Las fases de un pentesting
- Alcance y autorización. Se define qué sistemas entran, qué técnicas están permitidas, en qué ventana horaria se trabaja y quién es el contacto ante un imprevisto. Se firma la autorización expresa, sin la cual el trabajo sería sencillamente ilegal.
- Reconocimiento. Recopilación de información sobre el objetivo: dominios, direcciones IP, tecnologías empleadas, datos expuestos públicamente y, en algunos alcances, información de los empleados.
- Escaneo y enumeración. Identificación de servicios activos, puertos abiertos, versiones de software y posibles puntos de entrada.
- Análisis de vulnerabilidades. Contraste de lo encontrado con fallos conocidos y detección de configuraciones débiles.
- Explotación. El núcleo del trabajo: intentar aprovechar realmente las vulnerabilidades para obtener acceso.
- Post-explotación. Una vez dentro, evaluar hasta dónde se puede llegar: escalar privilegios, moverse lateralmente, acceder a datos sensibles y comprobar si es posible mantener el acceso.
- Informe. La entrega real del servicio, y la parte que distingue un buen trabajo de uno mediocre.
- Reevaluación. Verificación posterior de que las correcciones aplicadas funcionan.
Tipos según el alcance
- Externo. Todo lo accesible desde internet: web corporativa, VPN, correo, servicios publicados.
- Interno. Simula a alguien ya dentro de la red, sea un empleado o un atacante que ha logrado entrar.
- De aplicación web. Centrado en una aplicación concreta y su lógica de negocio. Es el más demandado.
- De aplicación móvil. Revisa la app, su almacenamiento local y su comunicación con el servidor.
- Inalámbrico. Evalúa la seguridad de las redes wifi y su segmentación.
- Ingeniería social. Campañas de phishing controladas y pruebas sobre el factor humano.
- De infraestructura cloud. Revisa configuraciones, permisos y exposición en los entornos en la nube.
Lo que realmente se entrega: el informe
El valor de un pentesting no está en el acceso conseguido, sino en el documento final. Un informe útil incluye un resumen ejecutivo comprensible para dirección, sin jerga; el detalle técnico de cada hallazgo con los pasos exactos para reproducirlo; una clasificación de severidad basada en criterios objetivos; el impacto concreto en términos de negocio, no genéricos; recomendaciones de corrección específicas y aplicables; y una priorización realista de por dónde empezar.
Un informe que se limita a volcar la salida de una herramienta con cientos de hallazgos sin priorizar no sirve para nada. Es, de hecho, la señal más clara de que lo que se ha hecho es un escaneo automatizado vendido como pentesting.
Cada cuánto conviene hacerlo
La referencia habitual es una vez al año para los sistemas críticos, pero hay circunstancias que justifican adelantarlo: antes de publicar una aplicación nueva, tras un cambio importante en la arquitectura, después de una migración a la nube, cuando lo exige una certificación o un cliente en el marco de un contrato, y siempre después de un incidente de seguridad.
Entre pentestings, lo razonable es mantener análisis de vulnerabilidades automatizados de forma periódica. Cubren la aparición de fallos nuevos en el software instalado, que es lo que más cambia entre una auditoría y la siguiente.
Cada infraestructura tiene su propio punto de partida y sus propias restricciones. Si quieres valorar cómo aplicar esto en tu organización, escríbenos y lo revisamos sobre tu caso concreto.
