Un pentest cloud no es un escaneo de postura con un PDF más bonito. Esta es la secuencia que recorremos de verdad, qué necesitas tener listo antes del primer día, cuánto dura y qué cosas deja fuera a propósito.
Un pentest cloud responde a una sola pregunta: cuál de las exposiciones de tu estructura en AWS, Azure o Google Cloud alcanza de verdad tus datos o tu plano de control. No cuántas configuraciones incorrectas tienes. Cuáles de ellas se conectan entre sí.
Esa distinción es todo el trabajo. Una herramienta de gestión de la postura de seguridad cloud (CSPM) devuelve cientos de hallazgos contra un estándar y no puede decirte qué tres de ellos se encadenan. Un pentest es una persona siguiendo la cadena a mano: este bucket es público, guarda esta clave, esa clave asume este rol, ese rol lee esta base de datos.
Los datos de amenazas apuntan a lo mismo. El informe Top Threats to Cloud Computing 2024 de la Cloud Security Alliance sitúa en primer lugar la configuración incorrecta y el control de cambios insuficiente, en segundo la gestión de identidades y accesos, y en tercero las interfaces y API inseguras. Las tres son cosas que configuras tú, no cosas que opera tu proveedor.
No se enumera nada hasta que el papeleo está hecho. Casi toda discusión que aparece más adelante en un proyecto se remonta a algo que no se escribió aquí.
Las rules of engagement registran qué se puede tocar y qué no: qué cuentas, si se pueden listar o leer datos de producción, si se pueden crear recursos y a quién se llama si algo se rompe. Primero enumeración de solo lectura, y explotación controlada únicamente dentro de esas reglas.
La política de tu proveedor se suma a la tuya, y las tres no coinciden.
Las pruebas empiezan donde empieza un atacante de verdad: desde internet, sin cuenta y sin clave.
Todavía no se actúa sobre nada. Esto es recogida de inteligencia en términos de PTES, y la primera mitad del descubrimiento en términos de la NIST SP 800-115.
En un test de web el objeto interesante es una petición. En un test cloud es una identidad. Esta fase no tiene equivalente en los demás tipos de pentest, y es la que más tiempo se lleva.
Con el rol de solo lectura enumeramos la estructura tal como está, no como la describe el diagrama: roles y sus políticas de confianza, fronteras de permisos y políticas de control de servicio, políticas de claves y de almacenamiento, y cada identidad de máquina asociada a una carga de trabajo. Esa lista se recorta después a lo que es alcanzable desde donde estamos.
Nada de esto se arregla rápido. El Data Breach Investigations Report 2026 de Verizon, que se apoya en más de 22.000 brechas confirmadas, mira aparte cómo se remedia la exposición cloud de terceros: solo el 23% de esas organizaciones remedió por completo la autenticación multifactor ausente o mal protegida en sus cuentas cloud, y para las contraseñas débiles y las configuraciones de permisos incorrectas tardaron casi ocho meses en resolver la mitad de los hallazgos.
Todo lo anterior es una hipótesis. Esta fase convierte cada una en una prueba, o la descarta.
Intentamos la escalada: un rol limitado convertido en uno mayor a través de una política que puede asociarse o de una tubería que puede disparar. Después el salto a la cuenta siguiente, y el alcance hasta los datos: almacenamiento de objetos, copias de bases de datos, las claves que las descifran. Cada intento corre dentro de las reglas acordadas el primer día, y de cada uno que sale bien se guarda la petición exacta, la política que lo permitió, la respuesta y la hora.
La escalada de privilegios hay que demostrarla, no deducirla: que este rol podría escalar en teoría es un hallazgo que tus desarrolladores van a discutir; que este rol escaló a las 14:12 y aquí está la llamada es uno que van a corregir. Y una cadena se recorre hasta donde hace falta para establecer qué alcanza, ni un paso más.
Las vulnerabilidades que se parchean pertenecen a esta fase, pero pocas veces son el titular. El mismo informe de Verizon pone la explotación de vulnerabilidades en el 31% de los vectores de acceso inicial conocidos, por delante del abuso de credenciales con un 13%, y encuentra que solo el 26% de las vulnerabilidades críticas, entendiendo por críticas las del catálogo de vulnerabilidades explotadas conocidas de CISA, se remediaron por completo durante 2025, frente al 38% del año anterior. Ese catálogo tenía 1.655 entradas el 27 de julio de 2026; lo que aparece en él se prueba primero.
Una cadena de este tipo, contada de punta a punta, se lee así: una falsificación de peticiones en una aplicación pública alcanza el servicio de metadatos, las credenciales del rol de la instancia permiten asumir un segundo rol, y una política de bucket demasiado permisiva convierte ese segundo rol en lectura de datos de otro inquilino. Tres configuraciones que por separado no eran nada.
El informe es la única parte del proyecto que va a leer la mayoría de tu organización, así que se dirige a dos públicos.
La NIST SP 800-115 describe una metodología de cuatro etapas, planificación, descubrimiento, ataque e informe, con un bucle de realimentación que vuelve del ataque al descubrimiento cada vez que un exploit revela algo nuevo. Eso es exactamente lo que se ve al seguir una cadena cloud. PTES establece siete apartados: interacciones previas al encargo, recogida de inteligencia, modelado de amenazas, análisis de vulnerabilidades, explotación, postexplotación e informe.
Los hallazgos se cruzan con MITRE ATT&CK, cuya matriz cloud cubre IaaS, SaaS, proveedor de identidad y suite de oficina, y con el CIS Benchmark que corresponda. CIS publica Foundations Benchmarks para AWS, Azure y Google Cloud, además de estándares para Kubernetes gestionado, incluidos EKS y GKE.
Una sola cuenta o suscripción en un proveedor son normalmente una o dos semanas de pruebas activas. Una estructura con varias cuentas, varias regiones o varios proveedores, o con Kubernetes de peso, son normalmente de dos a cuatro semanas. El alcance se acuerda antes de esa ventana y el retest va después de tus correcciones.
El rango se fija en la propuesta, no se alarga a mitad del proyecto porque haya aparecido algo interesante.
Este es el apartado que la mayoría de los proveedores se salta, y el que evita una discusión al tercer mes.
Un hallazgo no está cerrado porque un ticket haya cambiado de columna. Está cerrado cuando la prueba original deja de funcionar.
El retest vuelve a ejecutar cada cadena demostrada contra el entorno corregido, con los pasos que quedaron registrados en el informe. Falla en el paso que cambiaste, y se cierra con evidencia fechada. O sigue funcionando, y recibes la petición nueva que lo demuestra. O falla en un paso distinto, que normalmente significa que se parcheó el síntoma y no la causa. Ese último resultado es la razón de que un retest parta de la prueba original y no de la recomendación.
Para una carpeta de ISO 27001, ENS, PCI DSS o SOC 2, la evidencia del retest es lo que quiere el auditor: no que tuvieras hallazgos, sino que los cerraste y que puedes mostrar el antes y el después, con sus horas.
Las mismas siete fases aplicadas a todos los tipos de proyecto están en nuestra metodología de pentesting, de principio a fin. El alcance y los entregables de este están en la página de pentesting cloud.
Todas las cifras y las referencias a marcos de este artículo salen de aquí.
Qué es el ciclo de vida de desarrollo seguro, qué se hace en cada fase, qué aportan SAST, DAST y SCA, y por dónde empezar si hoy no tenéis nada montado.
Qué riesgos trae la IA generativa en empresa, por qué la inyección de prompts no es el problema real y qué se prueba en un pentest de IA.
Qué es un pentest, qué fases tiene, qué recibes al final, cuánto dura y en qué se diferencia de un análisis de vulnerabilidades.
Si algo de aquí se parece a un problema que llevas encima, media hora de llamada para acotarlo con un pentester senior vale más que leer otro artículo.
Hablar con un pentester seniorElige la hora que mejor te venga. Nos cuentas qué necesitas y en qué punto estás, y te explicamos cómo trabajamos y de qué forma podemos ayudarte.
