Un pentesting o test de penetración, a diferencia del red team, se centra en identificar el mayor número posible de vulnerabilidades en un sistema, aplicación o red dentro de un alcance y tiempo definidos, sin priorizar necesariamente el sigilo.
Tipos de pentesting
El pentesting recibe su tipología principalmente según el objetivo.
Existe el pentesting de infraestructura, interno o externo, centrado en servidores, redes y servicios expuestos; el de aplicaciones web, orientado a vulnerabilidades como inyecciones SQL, XSS o broken access control; y el de aplicaciones móviles, que analiza tanto el binario como las comunicaciones con el backend.
También es habitual el pentesting de Active Directory o Entra ID, enfocado en configuraciones erróneas y escalada de privilegios en entornos híbridos, así como el de APIs, redes inalámbricas y dispositivos IoT/OT cuando el entorno lo requiere.
Más allá del objetivo técnico, también se distingue el pentesting según el conocimiento previo que tiene el consultor: caja negra cuando no se dispone de información previa, caja gris cuando se cuenta con algo de contexto (como credenciales de bajo privilegio) y caja blanca cuando se tiene acceso completo a código fuente o documentación interna.
Fases del pentesting
La metodología de un pentesting suele mantenerse constante independientemente del tipo de objetivo. Todo comienza con el reconocimiento, donde se recopila información pública y técnica sobre el objetivo mediante OSINT o enumeración de subdominios. Después sigue el escaneo y la enumeración, donde se identifican servicios, puertos abiertos y versiones de software en uso.
Una vez mapeado el entorno, se pasa a la fase de explotación, en la que se aprovechan las vulnerabilidades encontradas para obtener acceso o extraer información. La postexplotación permite escalar privilegios y moverse lateralmente de forma limitada, aunque sin buscar persistencia a largo plazo como ocurriría en un red team. Finalmente, el reporte documenta cada hallazgo con su nivel de riesgo, evidencias técnicas y recomendaciones de remediación, siendo esta la parte que suele consumir más tiempo del engagement.
Elementos técnicos habituales
El trabajo diario de un pentester se apoya en herramientas que varían según el tipo de prueba, aunque algunas son transversales. Los escáneres de vulnerabilidades como Nessus, Nuclei o Nmap se usan para el descubrimiento automatizado, mientras que proxies de interceptación como Burp Suite permiten manipular peticiones HTTP y analizar la lógica de aplicaciones web en detalle.
Para validar vulnerabilidades conocidas de forma rápida se recurre a frameworks de explotación como Metasploit, y en entornos de Active Directory son habituales herramientas de enumeración como BloodHound, PowerView o AzureHound, que ayudan a mapear rutas de escalada de privilegios. A esto se suman scripts personalizados en Python o PowerShell, adaptados a las necesidades específicas de cada engagement.
Marco regulatorio y estándares
A diferencia del red team, el pentesting suele regirse por estándares metodológicos más que por marcos regulatorios estrictos, aunque en ciertos sectores también es obligatorio por normativa. El OWASP Testing Guide es la referencia principal para pentesting de aplicaciones web, mientras que PTES ofrece una metodología general aplicable a cualquier tipo de prueba. OSSTMM, por su parte, se enfoca en la seguridad operativa desde una perspectiva más amplia.
En cuanto a normativa obligatoria, PCI DSS exige pentesting periódico a organizaciones que procesan datos de tarjetas de pago, e ISO 27001 recomienda pruebas de seguridad regulares como parte de la gestión de riesgos. A diferencia de TIBER o DORA, estos estándares no exigen una fase previa de inteligencia de amenazas ni escenarios basados en actores reales, ya que el objetivo del pentesting es la cobertura de vulnerabilidades y no la simulación de un adversario específico.
