Pruebas de penetración en la nube: nuestra metodología para AWS, Azure y GCP

Entréguenos un rol IAM de solo lectura que alguien haya sobreaprovisionado y hay bastantes probabilidades de que lo escalemos hasta el control total de la cuenta antes de que termine su daily. El proveedor de nube no está roto cuando eso ocurre. Alguien adjuntó una policy con una acción comodín, dejó un rol asumible por medio Internet y dejó de leer CloudTrail en algún momento del último trimestre. Toda la metodología de pruebas de penetración en la nube de este artículo vive en esa brecha, la que separa “la plataforma es segura” de “nuestra configuración es segura.”

Lo que sigue es la secuencia que realmente ejecutamos en los trabajos de AWS, Azure y GCP. No es una lista de comprobación de cumplimiento reformateada como prosa, sino el orden en que probamos, las herramientas a las que recurrimos y las configuraciones erróneas que siguen dando frutos proyecto tras proyecto.

Una nota de encuadre. Las pruebas en la nube son un problema de modelo de permisos antes que un problema de red. En on-premise se lucha contra firewalls y segmentación. Aquí se lucha contra policies IAM, relaciones de confianza y endpoints de metadatos. Si lo abordas como una prueba de red externa clásica, pasarás de largo justo por delante de lo que de verdad hace que se tomen las cuentas.

Puntos clave

• Una metodología de pruebas de penetración en la nube es identity-first: las policies IAM y las relaciones de confianza son la principal superficie de ataque, muy por delante de cualquier cosa en la capa de red.
• Cuatro hallazgos dominan nuestros informes: policies IAM demasiado permisivas, almacenamiento expuesto públicamente (S3, Blob, GCS), SSRF que alcanza el servicio de metadatos de instancia y escalada de privilegios por una policy o un rol mal configurado.
• El alcance y la autorización por escrito importan aquí más que en cualquier otra prueba. Trabajas dentro de una frontera de responsabilidad compartida, así que necesitas tanto las reglas del proveedor como el visto bueno del propietario de la cuenta antes de tocar nada.
• IMDSv2, policies de mínimo privilegio, el bloqueo del acceso público al almacenamiento y un logging supervisado (CloudTrail, Azure Monitor, Cloud Logging) cierran la mayor parte de lo que encontramos.
• Los escáneres CSPM señalan las configuraciones erróneas de una en una. No encadenan tres de ellas hasta una toma de control de la cuenta. Ese encadenamiento es todo el sentido de una prueba manual.

¿Qué es una prueba de penetración en la nube y en qué se diferencia?

Una prueba de penetración en la nube es una simulación de ataque autorizada contra el entorno de nube que te pertenece: las cuentas, identidades, servicios y configuraciones que residen dentro de AWS, Azure o GCP. El proveedor asegura el hardware, el hipervisor y la capa física. Tú eres responsable de todo lo que configuras encima: IAM, permisos de almacenamiento, grupos de seguridad de red, gestión de claves, logging. Ese reparto es el modelo de responsabilidad compartida, y traza la línea de lo que se nos permite probar.

La diferencia práctica frente a un pentest tradicional es que el perímetro es blando y el plano de identidad es enorme. Una sola clave de acceso filtrada, una confianza OIDC chapucera para un pipeline de CI o una Lambda que lleva adjunto un rol de admin pueden importar mucho más que cualquier puerto abierto. Por eso la metodología se construye en torno a la identidad, la confianza y la configuración, y no en torno al escaneo de un rango CIDR.

Paso 1: alcance, autorización y reglas de compromiso

Antes de que se ejecute un solo comando, fijamos tres cosas. Qué cuentas y subscriptions están dentro del alcance. De qué tipo de prueba se trata: externa sin credenciales, o autenticada de tipo “assumed breach” partiendo de una identidad de bajo privilegio. Y qué permite realmente el proveedor. AWS, Azure y GCP publican, cada uno, condiciones de uso aceptable para las pruebas de seguridad. La mayoría de los servicios comunes ya no requieren aprobación previa, pero las pruebas de denegación de servicio, la carga intensa y sostenida y ciertos servicios gestionados siguen teniendo límites. Nos mantenemos dentro de ellos.

Las pruebas de nube más útiles que realizamos son autenticadas. Pedimos una identidad deliberadamente débil: un usuario IAM de solo lectura, una cuenta básica de Entra ID, una cuenta de servicio de GCP con roles mínimos. Luego vemos hasta dónde llega. Eso modela la amenaza realista, que es un empleado víctima de phishing, una clave filtrada en un repositorio público o una integración de terceros comprometida, no un atacante sin rostro que parte de cero. El trabajo externo no autenticado tiene su sitio para mapear la superficie de ataque. La escalada interesante casi siempre vive después de ese primer punto de apoyo.

Paso 2: enumerar la identidad, porque ahí está la verdadera superficie de ataque

Con un punto de apoyo en la mano, la primera tarea es responder a dos preguntas: ¿quiénes somos y en qué podemos convertirnos? En AWS empieza de forma sencilla.

aws sts get-caller-identity
aws iam get-account-authorization-details   # if permitted
aws iam list-attached-user-policies --user-name svc-ci

Después mapeamos el grafo de identidades. Pacu y ScoutSuite nos dan una amplia cobertura de AWS, y PMapper convierte un montón de policies en JSON en una respuesta directa sobre qué principal puede alcanzar admin. En Azure nos apoyamos en AzureHound y en el ecosistema más amplio de BloodHound para grafiar roles de directorio, anidamiento de grupos y asignaciones PIM elegibles. En GCP recorremos la jerarquía de recursos a mano y leemos los role bindings a nivel de organización, carpeta, proyecto y recurso, porque una vinculación heredada de un padre es tremendamente fácil de pasar por alto a simple vista.

Lo que cazamos en esta fase: acciones comodín como "Action": "*" o un iam:* a nivel de servicio, roles con policies de confianza sts:AssumeRole permisivas y cualquier camino que permita a una identidad débil concederse más. Una policy que permite iam:PassRole junto a un permiso de creación de compute no es una preocupación teórica. Es una primitiva de escalada que funciona.

Paso 3: escalada de privilegios en IAM

Aquí es donde se ganan o se pierden los proyectos de nube. Las rutas de escalada de AWS que Rhino Security Labs documentó hace años siguen funcionando en cuentas en producción, porque los equipos continúan concediendo los permisos ingrediente sin darse cuenta de lo que suman. Unos cuantos que comprobamos siempre, sin excepción:

• iam:PassRole más creación de compute. Si podemos pasar un rol de admin a una instancia EC2 nueva, una función Lambda o un job de Glue, ejecutamos nuestro propio código bajo ese rol y leemos sus credenciales. Escalada instantánea.
• iam:CreatePolicyVersion o AttachUserPolicy. Si nuestro usuario puede editar o adjuntar policies, puede adjuntarse AdministratorAccess a sí mismo. Fin del juego.
• Roles asumibles con confianza laxa. Un rol que confía en "Principal": {"AWS": "*"}, o en una raíz de cuenta demasiado amplia, es una puerta que se ha dejado abierta de par en par.

Los equivalentes en Azure y GCP son igual de productivos. En Azure buscamos roles personalizados que lleven Microsoft.Authorization/roleAssignments/write, service principals con permisos de Graph excesivos y runbooks de Automation Account o identidades administradas que podamos secuestrar. En GCP las primitivas fiables son iam.serviceAccounts.getAccessToken (acuñar un token para una cuenta de servicio más potente), iam.serviceAccountKeys.create y setIamPolicy a nivel de proyecto. Cualquiera de ellas convierte un modesto punto de apoyo en la propiedad del proyecto.

Paso 4: SSRF hacia el servicio de metadatos de instancia

La cadena de mayor valor en las pruebas de nube es un fallo de server-side request forgery en una aplicación capaz de alcanzar el endpoint de metadatos. Apunta esa SSRF a la dirección de metadatos link-local e intenta leer las credenciales temporales del rol adjunto.

http://169.254.169.254/latest/meta-data/iam/security-credentials/
# then, with the role name that comes back:
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

En un host heredado con IMDSv1 que devuelve un AccessKeyId, un SecretAccessKey y un token de sesión, los exportamos y los usamos directamente. Este es el patrón que hay detrás de una de las brechas de nube más estudiadas de la historia, y el motivo por el que insistimos tanto en IMDSv2. Los endpoints equivalentes existen en otros sitios: Azure en 169.254.169.254/metadata/identity/oauth2/token con una cabecera Metadata: true, y GCP en metadata.google.internal con Metadata-Flavor: Google. Después mapeamos hasta dónde alcanza esa identidad. Esta técnica se corresponde limpiamente con MITRE ATT&CK T1552.005, credenciales no protegidas de la API de metadatos de instancia en la nube.

Paso 5: almacenamiento expuesto y datos públicos

El almacenamiento de objetos legible públicamente sigue siendo uno de los hallazgos graves más frecuentes que documentamos. Enumeramos buckets de S3, contenedores de Azure Blob y buckets de GCS ligados al objetivo, leemos sus ACL y bucket policies, y probamos el acceso público de listado y lectura. Luego probamos la escritura pública, que es la que la gente olvida. La escritura pública en un bucket que sirve assets de un sitio o actualizaciones de software no es un problema de exposición de datos. Es un problema de cadena de suministro.

El almacenamiento es solo la mitad. También rastreamos secretos expuestos: claves de acceso subidas a repositorios públicos, claves incrustadas en bundles de apps móviles, tokens que descansan en el JavaScript de front-end y entradas de Secrets Manager o Key Vault demasiado legibles. Una sola clave válida y de larga vida puede cambiar la forma de todo el proyecto.

Paso 6: red, servicios y movimiento lateral

Solo después de la identidad nos importa la red. Revisamos security groups y NSG en busca de ingress abierto, el habitual SSH y RDP expuestos a 0.0.0.0/0, bases de datos colgando de la Internet pública, y luego comprobamos endpoints públicos de RDS o de bases de datos gestionadas y cómo se comporta la segmentación entre VPCs, subredes y peering. Desde una identidad o un host comprometidos, probamos el movimiento. ¿Podemos alcanzar servicios internos? ¿Asumir roles en otras cuentas? ¿Pivotar de una subscription de dev a producción a través de una identidad compartida? Las fronteras de confianza multicuenta y multisubscription suelen ser más blandas de lo que sugiere el diagrama de arquitectura.

Paso 7: ¿nos vio alguien?

Este es un hallazgo que nos importa tanto como cualquier exploit: ¿se dio cuenta el entorno? Confirmamos que CloudTrail está activo en todas las regiones con validación de archivos de log, que Azure Monitor y los Activity Logs están recopilando, y que los GCP Cloud Audit Logs están habilitados, centralizados y alertando sobre las acciones que acabamos de realizar. Un atacante que crea una clave de acceso, desactiva el logging y exfiltra datos debería disparar algo. En muchísimos proyectos no salta absolutamente nada. Lo reportamos como una brecha de detección, y no lo suavizamos, porque la prevención acaba fallando y la detección es la red de seguridad.

¿Cómo se previene lo que encontramos?

El mínimo privilegio es todo el juego. Acota las policies IAM a acciones y recursos concretos, borra los comodines y usa permission boundaries y service control policies para poner un techo a lo que cualquier identidad puede alcanzar. Impón IMDSv2 en cada instancia para que una SSRF perdida no pueda acuñar credenciales. Activa el bloqueo del acceso público a nivel de cuenta para S3, mantén Blob y GCS privados por defecto, y verifícalo en lugar de confiar en el valor por defecto de la consola. Prefiere credenciales federadas de corta vida frente a claves de larga vida, y rota las claves que de verdad no puedas evitar. Y haz que el logging sea real: centralizado, a prueba de manipulaciones y conectado a alertas sobre las que un humano o un SIEM vayan a actuar. Un log que nadie lee es puro teatro.

Cómo ayuda CyberXplore

Nuestro servicio de pruebas de penetración en la nube ejecuta exactamente esta metodología contra tus entornos de AWS, Azure y GCP. Identity-first, manual y centrado en encadenar configuraciones erróneas hasta el impacto que alcanzaría un atacante real, no en imprimir una lista de alertas de CSPM. Obtienes hallazgos ordenados por explotabilidad, pasos de reproducción que puedes entregar a ingeniería y un nuevo test gratuito una vez que remedias. Si quieres una prueba acotada de tu huella en la nube, pide un presupuesto y adaptaremos el proyecto a tus cuentas y a las reglas de compromiso del proveedor.

FAQ

¿AWS, Azure y GCP permiten las pruebas de penetración en la nube?

Sí, dentro de ciertos límites. Los tres proveedores permiten probar tus propios recursos para la mayoría de los servicios comunes sin aprobación previa, y cada uno restringe las pruebas de denegación de servicio y ciertos servicios gestionados. Trabajamos dentro de la política de uso aceptable actualmente publicada por el proveedor para todo lo que esté dentro del alcance, y exigimos una autorización por escrito del propietario de la cuenta antes de empezar.

¿Cuál es la diferencia entre un escaneo CSPM y una prueba de penetración en la nube?

Una herramienta de cloud security posture management señala de forma continua las configuraciones erróneas frente a un conjunto de reglas, lo cual es útil, pero reporta cada problema de forma aislada. Una prueba de penetración encadena esos problemas, de modo que un rol de solo lectura más un permiso PassRole más una SSRF se convierte en una toma de control de la cuenta demostrada. Usamos los escáneres para la cobertura y las pruebas manuales para el impacto.

¿Necesitáis credenciales o podéis probar desde fuera?

Ambas opciones son válidas y responden a cosas distintas. Una prueba externa, no autenticada, mide tu superficie de ataque expuesta. Una prueba autenticada de tipo “assumed breach”, partiendo de una identidad de bajo privilegio, tiende a sacar a la luz las rutas de escalada y de movimiento lateral que más importan. Para el trabajo en la nube solemos recomendar el enfoque autenticado.

¿Cuánto tarda una prueba de penetración en la nube?

Depende del número de cuentas, de la amplitud de servicios y de si es de una sola nube o multinube. Una única cuenta de AWS bien acotada lleva menos tiempo que una organización con varias cuentas y Azure y GCP en la mezcla. El alcance marca el calendario, y por eso dimensionamos cada prueba de forma individual en lugar de dar una cifra fija.

¿Cuáles son los hallazgos de nube más frecuentes que reportáis?

Las policies IAM demasiado permisivas y las rutas de escalada de privilegios van por delante con diferencia, seguidas del almacenamiento expuesto públicamente, la SSRF que alcanza el servicio de metadatos de instancia y un logging insuficiente o no supervisado. Por sí solos van de gravedad media a alta. Encadenados, se convierten habitualmente en críticos.