Cloud Pentesting

El crecimiento exponencial de los entornos en la nube ha transformado la forma en que las organizaciones almacenan, gestionan y protegen sus datos. Sin embargo, esta transición también ha abierto una nueva superficie de ataque: las configuraciones inseguras, la exposición de secretos y los errores de gestión de identidades se han convertido en vectores recurrentes para los atacantes. En este contexto, el pentesting en la nube —o pruebas de penetración en entornos cloud— es una disciplina fundamental para evaluar la seguridad de las infraestructuras modernas.

El pentesting en la nube combina técnicas tradicionales de auditoría con un profundo conocimiento de los servicios específicos de cada proveedor: Microsoft Azure, Amazon Web Services (AWS) y Google Cloud Platform (GCP). A continuación, exploraremos las principales fases, herramientas y comandos que un profesional de ciberseguridad utiliza para evaluar cada uno de estos ecosistemas.

1. Azure y Office 365: El poder de la automatización y la identidad

Azure es, sin duda, uno de los entornos más ricos y complejos para el pentester. Su integración con Active Directory, su modelo de permisos basado en roles (RBAC) y su ecosistema de servicios (como SQL, App Services y Runbooks) hacen que el enfoque de pruebas deba centrarse en identidades, roles y credenciales.

Un auditor inicia el proceso autenticándose en el entorno, ya sea con PowerShell (Connect-AzAccount) o con Azure CLI (az login). Una vez dentro, puede listar los recursos, suscripciones y roles asignados a los usuarios. Comandos como Get-AzRoleAssignment o Get-AzSubscription permiten mapear la jerarquía de permisos dentro del tenant.

Uno de los puntos más críticos en Azure es la gestión de servicios automatizados. Los Runbooks y las Service Principals representan objetivos atractivos: mediante Get-AzAutomationRunbook o New-AzAdServicePrincipal, un atacante puede identificar scripts automatizados o crear “puertas traseras” persistentes. Esta última técnica es particularmente peligrosa, ya que un atacante con permisos elevados puede crear un principal con privilegios de Owner y autenticarse posteriormente sin depender de credenciales humanas.

Además, el uso indebido de los Key Vaults (bóvedas de secretos) es otra debilidad recurrente. Si un usuario con permisos de Contributor puede modificar las políticas del vault (az keyvault set-policy), puede otorgarse acceso completo a contraseñas, claves y certificados. Los pentesters suelen intentar enumerar estos secretos con az keyvault secret list y az keyvault secret show, lo que puede revelar información sensible de bases de datos o tokens de autenticación.

El entorno de Azure también permite evaluar la infraestructura subyacente, desde máquinas virtuales (Get-AzVM) hasta redes (Get-AzVirtualNetwork) y conexiones VPN (Get-AzVpnConnection). Este nivel de visibilidad es esencial para detectar configuraciones erróneas que podrían permitir un movimiento lateral dentro de la nube.

2. Amazon Web Services: S3, IAM y los metadatos como puerta de entrada

En AWS, la superficie de ataque suele centrarse en tres pilares: Identity and Access Management (IAM), almacenamiento en S3 y metadatos de instancias EC2.

Una auditoría básica comienza con aws sts get-caller-identity, que revela el contexto de autenticación actual, seguido de aws iam list-users y aws iam list-roles para identificar usuarios y roles existentes. La mala gestión de políticas IAM —por ejemplo, usuarios con permisos amplios o sin MFA— sigue siendo una de las causas más comunes de brechas de seguridad.

El almacenamiento S3 es otro punto crítico. Los buckets mal configurados son un clásico en las filtraciones de datos. Con comandos como aws s3 ls s3://nombre-bucket/ o aws s3 sync, los pentesters pueden detectar si existen objetos accesibles públicamente o si se han expuesto datos internos. En muchos casos, la explotación de estos errores no requiere técnicas avanzadas, sino simplemente la enumeración de recursos mal protegidos.

Una técnica especialmente interesante en AWS es el abuso del servicio de metadatos (http://169.254.169.254/latest/meta-data). Este endpoint, accesible desde instancias EC2, puede devolver credenciales temporales de IAM o información sensible del entorno. Si una aplicación web hospedada en una instancia EC2 actúa como proxy inseguro, un atacante podría aprovecharla para consultar ese endpoint y obtener tokens de acceso. Aunque Amazon introdujo la versión IMDSv2 con protecciones adicionales, muchos entornos aún no la implementan correctamente.

Entre las herramientas más destacadas para la evaluación de AWS se encuentran Pacu, un framework de explotación que permite escanear permisos, detectar escaladas de privilegios y realizar pruebas controladas, y WeirdAAL, diseñado para enumerar servicios disponibles mediante claves de acceso.

3. Google Cloud Platform: Permisos, metadatos y almacenamiento

En GCP, la autenticación se maneja principalmente a través de gcloud auth login o el uso de cuentas de servicio (gcloud auth activate-service-account). Una vez autenticado, el pentester puede listar proyectos (gcloud projects list), políticas IAM (gcloud projects get-iam-policy) y servicios habilitados (gcloud services list).

Las cuentas de servicio representan un punto de ataque frecuente, especialmente si las claves privadas (JSON) se almacenan en repositorios o servidores sin cifrado. Si un atacante accede a estos archivos, puede autenticarse directamente en GCP con los mismos permisos que la cuenta comprometida.

Otro aspecto crucial es el acceso a la API de metadatos de GCP (http://metadata.google.internal). Similar al caso de AWS, este endpoint puede exponer tokens de servicio si no se filtra adecuadamente. Los pentesters suelen revisar permisos de instancias, redes y túneles VPN (gcloud compute vpn-tunnels list) para detectar posibles movimientos laterales o conexiones inseguras.

En términos de almacenamiento, el uso de gsutil ls permite listar buckets y detectar si existen configuraciones públicas. Un mal ACL (Access Control List) puede permitir a cualquiera copiar información sensible (gsutil cp gs://bucket-id/item ./), un error que, lamentablemente, sigue siendo común en entornos corporativos.

4. Herramientas transversales y técnicas complementarias

Más allá de los comandos nativos, existen herramientas diseñadas para facilitar el reconocimiento y la explotación en entornos multicloud. Entre ellas destacan:

• ScoutSuite, un auditor automático que evalúa configuraciones de seguridad en AWS, Azure y GCP.

• Cloud_Enum, útil para descubrir recursos públicos asociados a un nombre de organización.

• GitLeaks, TruffleHog o Shhgit, que permiten buscar credenciales filtradas en repositorios de código.

• FireProx, que automatiza ataques de password spraying rotando IPs para evitar bloqueos.

• ip2Provider, una utilidad que permite identificar a qué proveedor pertenece una dirección IP determinada.

Estas herramientas, combinadas con técnicas de revisión de historiales de comandos (.bash_history, ConsoleHost_history.txt) y extracción de certificados o hashes, completan el arsenal de un pentester cloud moderno.

El pentesting en la nube no se trata solo de encontrar vulnerabilidades, sino de entender cómo interactúan los servicios, roles y políticas dentro de entornos distribuidos. La seguridad en la nube no depende de un solo componente, sino de una cadena de confianza que puede romperse en cualquier punto.

Para las organizaciones, la lección es clara: las configuraciones por defecto rara vez son seguras, los permisos deben ser mínimos y los secretos nunca deben almacenarse en texto plano. Adoptar una mentalidad de Zero Trust, monitorear continuamente los accesos y realizar pruebas de intrusión periódicas son pasos esenciales para proteger los entornos en la nube.