Pentesting cloud (AWS, Azure y GCP): guía técnica para empresas

Un pentesting cloud es una auditoría ofensiva sobre la infraestructura, identidades y servicios gestionados que una empresa tiene desplegados en AWS, Azure o Google Cloud. No es lo mismo que un pentesting tradicional de servidores: aquí el objetivo no son IPs públicas y puertos abiertos, son las políticas IAM mal configuradas, los buckets accesibles desde Internet, las funciones serverless con permisos excesivos, las claves embebidas en pipelines de CI/CD y los pivots entre cuentas que un atacante exterior puede encadenar para terminar leyendo tu base de datos de producción sin entrar nunca a una máquina.

Esta guía cubre qué es un pentesting cloud, qué se audita en cada hyperscaler, los errores que aparecen en el 80% de los entornos auditados y cómo encaja con los marcos NIS2, DORA, ENS, ISO 27001 y los benchmarks CIS.

Qué es un pentesting cloud

Un pentesting cloud es un ejercicio ofensivo autorizado y acotado que evalúa la postura de seguridad de un tenant cloud (AWS Account, Azure Subscription, GCP Project u Organization) desde la perspectiva de tres tipos de atacante:

• Externo no autenticado. Lo que ve cualquiera desde Internet: dominios expuestos, buckets públicos, endpoints de API sin autenticar, credenciales filtradas en GitHub.
• Externo con credenciales filtradas. El escenario más realista hoy: alguien comprometió un usuario IAM o una clave en un repositorio público y empieza desde ahí.
• Interno (asumir compromiso). Partiendo de una identidad legítima de bajo privilegio, el equipo intenta escalar hasta administrador y pivotar entre cuentas o suscripciones.

El alcance se define por configuración, no por IPs. Auditar AWS no significa escanear el rango de Amazon: significa revisar políticas IAM, configuraciones de S3, logs de CloudTrail, despliegues de Lambda, redes VPC, claves KMS, secretos en Secrets Manager y, si aplica, los servicios gestionados que el cliente use (RDS, EKS, ECS, API Gateway, Step Functions). Cada hyperscaler tiene su catálogo y sus pitfalls.

A diferencia de un pentesting de aplicación web, donde el atacante explota código que tú mantienes, en cloud el atacante explota el contrato del modelo de responsabilidad compartida: AWS, Azure o GCP aseguran la plataforma, pero la configuración de identidades, redes y servicios la haces tú. El 90% de los incidentes cloud documentados públicamente vienen de configuraciones del cliente, no de fallos del proveedor.

Por qué hacer pentesting cloud: el valor real

Tres razones que un CISO o CTO ya conoce y que los marcos normativos están convirtiendo en obligación:

1. El perímetro tradicional ya no existe. La superficie de ataque vive en políticas IAM y permisos de servicios, no en firewalls perimetrales. Un escáner de red moderno no detecta un rol de Lambda con iam:PassRole *, pero un atacante sí lo va a usar para escalar a administrador.
2. Los incidentes cloud son rápidos y devastadores. El tiempo medio entre el primer comando ejecutado por un atacante con credenciales válidas y la exfiltración de datos sensibles en cloud es inferior a 6 horas según los informes anuales de respuesta a incidentes de los principales fabricantes EDR/MDR. No hay margen para detectar después.
3. NIS2, DORA, ENS y la propia auditoría ISO 27001 ya piden evidencia. El control A.5.23 (uso de servicios cloud) de ISO 27001:2022 no se cumple con un PDF de buenas intenciones, se cumple con auditorías técnicas regulares.

Bien ejecutado, un pentesting cloud entrega:

• Inventario real de identidades, recursos y permisos efectivos. La mayoría de equipos descubren entidades, claves o roles olvidados que llevan años activos.
• Cadenas de ataque reproducibles desde un punto de partida realista hasta el activo crítico, con los comandos exactos.
• Recomendaciones priorizadas por impacto, no listas de "buenas prácticas" genéricas que nadie aplica.
• Evidencia auditable para el órgano de cumplimiento.

Tipos de pentesting cloud

No todos los proyectos son iguales. Tres formatos cubren el 95% de los encargos:

1. Pentesting de configuración (Cloud Security Posture)

Revisión de toda la cuenta o suscripción contra benchmarks CIS y guías oficiales del fabricante. Combina herramientas (Prowler para AWS, ScoutSuite y Cloudsplaining multi-cloud, PowerZure para Azure, GCP Scanner) con revisión manual de hallazgos no triviales. Es la base de cualquier pentesting cloud: detecta el 60-70% de los problemas explotables antes de empezar a atacar.

2. Pentesting "asume compromiso"

Parte de una identidad real de bajo privilegio (un usuario interno, una clave de pipeline) y mide hasta dónde llega un atacante que ya tiene un pie dentro. Es el formato que mejor refleja el escenario real porque la mayoría de los incidentes empiezan así, no con un 0day desde fuera.

3. Pentesting de aplicación cloud-native

Auditoría de aplicaciones que se apoyan en servicios cloud: APIs detrás de API Gateway con Lambda, contenedores en ECS/AKS/GKE, funciones Cloud Run, integraciones con Cognito o Entra ID. Cubre tanto la lógica de la aplicación como la infraestructura cloud que la sostiene. Solapa con pentesting web pero entra al detalle de la capa cloud.

Qué se audita en AWS

AWS es el hyperscaler con mayor superficie y donde aparecen más fallos por la sencilla razón de que es el más usado. Los puntos críticos:

• IAM. Políticas inline, políticas administradas, roles asumibles entre cuentas, trust policies mal restringidas, uso de wildcards * en Resource o Action, condition keys ausentes, claves de acceso sin rotar.
• S3. Buckets públicos por Block Public Access deshabilitado, ACLs heredadas, bucket policies con Principal: "*", copia entre cuentas sin restricción, pre-signed URLs generadas con credenciales privilegiadas.
• EC2 y VPC. Security Groups con 0.0.0.0/0 en SSH/RDP, instance profiles con permisos amplios accesibles vía Instance Metadata Service v1, AMIs compartidas entre cuentas con datos sensibles, snapshots de EBS públicos.
• Lambda y Step Functions. Roles de ejecución con iam:PassRole *, secretos en variables de entorno, código fuente accesible vía API si la función es invocable sin autenticar.
• RDS y Aurora. Bases públicas, snapshots públicos, cifrado opcional, parameter groups permisivos.
• CloudTrail y GuardDuty. ¿Está activo en todas las regiones? ¿Está integrado con SIEM? ¿Detecta los IoC típicos de ataque a AWS (acceso desde IPs Tor, uso de GetCallerIdentity en bucle, creación de usuarios IAM por entidades inesperadas)?
• Secrets Manager y SSM Parameter Store. Quién puede leer cada secreto, rotación, presencia de credenciales en User Data de EC2 o en plantillas CloudFormation.
• EKS y ECS. RBAC mal configurado, contenedores que montan el socket de Docker, service accounts con permisos excesivos vía IRSA, políticas de red abiertas.

Las cadenas de ataque clásicas en AWS combinan dos o tres de estas piezas. Por ejemplo: bucket S3 con un script .sh que usa una clave hardcodeada, esa clave pertenece a un usuario IAM con permisos de iam:PassRole, y mediante iam:CreateRole + AssumeRole el atacante salta a un rol con AdministratorAccess. Cada eslabón individual parece "menor"; encadenados, son una toma de cuenta completa.

Qué se audita en Azure

Azure tiene un modelo distinto a AWS y eso cambia el repertorio de fallos. Los puntos críticos:

• Microsoft Entra ID (antes Azure AD). Privileged Identity Management mal configurado, conditional access policies incompletas, consent grants abusivos en aplicaciones empresariales, service principals con secretos expuestos en Azure DevOps o GitHub Actions, MFA opcional para roles privilegiados.
• RBAC y management groups. Asignaciones de Owner heredadas, scope /, roles personalizados con Microsoft.Authorization/*/write.
• Storage Accounts. Contenedores con acceso anónimo, Shared Access Signatures generadas con privilegios excesivos y caducidad infinita, claves de cuenta sin rotar.
• Azure Key Vault. Políticas de acceso vs RBAC, secretos con permisos de listado abiertos, soft delete desactivado, ausencia de purge protection.
• Virtual Networks y NSG. Reglas con Internet en origen, peering entre suscripciones sin segmentación, ausencia de Azure Firewall en suscripciones críticas.
• AKS. RBAC del clúster, managed identities asignadas con permisos amplios, integración con Entra ID, pod security standards desactivados.
• Logic Apps y Functions. Triggers expuestos sin auth, claves embebidas, managed identities con roles de Owner.

El movimiento lateral típico en Azure pasa casi siempre por Entra ID y los service principals: un atacante que controla una cuenta con permisos sobre Azure DevOps, GitHub Actions o cualquier pipeline puede leer los secretos guardados en Key Vault con la managed identity correspondiente.

Qué se audita en Google Cloud (GCP)

GCP tiene menos cuota de mercado en España pero está creciendo en ML, big data y arquitecturas serverless. Los puntos críticos:

• IAM y Service Accounts. Bindings al allUsers o allAuthenticatedUsers (públicos), service accounts default con Editor (lo que pasa si no se configura nada), ausencia de organization policies que restrinjan los servicios habilitables.
• Cloud Storage. Buckets públicos, ausencia de uniform bucket-level access, ACLs legacy heredadas.
• Compute Engine. Imágenes y discos compartidos entre proyectos, service accounts asociados con Editor, scopes de OAuth permisivos.
• GKE. Workload Identity, node pools con cuentas privilegiadas, RBAC del clúster, integración con Binary Authorization.
• Cloud Functions y Cloud Run. Funciones invocables sin auth (allUsers en roles/run.invoker), service accounts default.
• VPC Service Controls. ¿Hay perímetros para datos sensibles (BigQuery, Cloud Storage) o todo confía en IAM?
• Cloud Logging y SCC. Cobertura de Audit Logs (Admin Activity, Data Access), conexión a un SIEM externo.

GCP penaliza menos los wildcards en IAM porque las roles bindings son más granulares por defecto, pero compensa con un blast radius mayor cuando algo falla en un proyecto host de Shared VPC.

Metodología: cómo se ejecuta un pentesting cloud serio

El proceso que seguimos en cualquier auditoría cloud sigue siempre los mismos seis bloques:

1. Alcance y autorizaciones. Acuerdo escrito con la lista de cuentas/suscripciones/proyectos en scope, ventanas horarias, criterios de parada y, en AWS, la Customer Support Policy for Penetration Testing (autopruebas permitidas sin aviso previo desde 2019, con excepciones para DDoS y ataques a recursos compartidos).
2. Reconocimiento. Identificación de identidades, recursos, dominios públicos, repositorios filtrados, secretos en GitHub/Pastebin con búsquedas dirigidas (gitleaks, trufflehog, dorks específicos del cliente).
3. Configuración. Ejecución de auditoría automatizada (Prowler, ScoutSuite, Cloudsplaining, PowerZure) y revisión manual de los hallazgos no triviales. Mapeo de la postura contra CIS Benchmarks y CCM (Cloud Controls Matrix) de la Cloud Security Alliance.
4. Explotación con criterio. Encadenamiento de los fallos relevantes hasta demostrar el impacto real (acceso a datos, escalada a admin, pivote entre cuentas). Sin destrucción de datos ni interrupción de servicio.
5. Reporte. Cadenas de ataque reproducibles con comandos, severidad CVSS justificada por impacto en negocio (no por categoría genérica), recomendaciones priorizadas por esfuerzo/beneficio.
6. Acompañamiento. Sesión de revisión con los equipos técnicos, soporte durante la remediación y, en clientes con auditoría recurrente, retest tras los cambios.

Errores recurrentes que aparecen en el 80% de los entornos auditados

Tres fallos sistémicos que vemos en casi cualquier organización, independientemente del tamaño:

• IAM con wildcards históricos. Roles creados hace años con * en Action o Resource que nadie se atreve a tocar porque "rompemos algo". El punto medio es revisar los logs de uso (CloudTrail Lake o Access Analyzer en AWS, Activity Logs en Azure) y ajustar permisos a lo que se está usando realmente.
• Cuentas y suscripciones sin segmentación clara. Producción, staging y entornos de innovación viven en la misma cuenta, con el mismo trust boundary. Un compromiso en cualquier sandbox compromete producción.
• Logs activos pero nadie los mira. CloudTrail, Azure Monitor o Cloud Logging activos pero sin SIEM, sin alertas y sin equipo que los atienda. La capacidad forense existe; la capacidad de detección, no.

Pentesting cloud y compliance: NIS2, DORA, ENS, ISO 27001

El pentesting cloud es la pieza técnica que evidencia varios controles obligatorios:

• NIS2 (artículo 21). Las medidas de gestión de riesgos exigen pruebas regulares de eficacia de medidas técnicas. Para entornos cloud, eso es una auditoría ofensiva específica.
• DORA (artículo 25). El régimen TIBER-EU/TLPT presupone pruebas amenaza-céntricas en cualquier infraestructura crítica para la operación, incluida cloud.
• ENS (Real Decreto 311/2022). La medida op.cont.4 (medios alternativos) y mp.s.2 (protección de servicios cloud) presuponen evaluación regular de la postura.
• ISO 27001:2022 (control A.5.23 Information security for use of cloud services). El certificador exige evidencia técnica de control sobre el proveedor cloud.
• PCI DSS v4.0. Exige segmentation testing anual cuando se usa cloud para procesar tarjeta.

Cómo elegir un proveedor de pentesting cloud

Cinco criterios que hacen la diferencia entre un PDF lleno de capturas de Prowler y un pentesting útil:

1. Especialización por hyperscaler. AWS, Azure y GCP no son intercambiables. El equipo que firma el informe debe demostrar experiencia explotando entornos reales en cada uno, no sólo hacer checklist.
2. Capacidad de encadenar fallos. Un buen informe no lista "57 hallazgos críticos sueltos", lista "3 cadenas de ataque que llevan de un usuario sin privilegios a tomar la cuenta". Es donde se ve si hay pentesters reales detrás o sólo herramientas.
3. Reporte que sirve a desarrollo. Comandos exactos, capturas, scripts mínimos viables. Sin eso, los desarrolladores no pueden remediar y el informe acaba archivado.
4. Disposición a hacer retest tras la remediación. La auditoría sin verificación de cierre tiene la mitad del valor.
5. Discreción operativa. Los hallazgos cloud incluyen secretos, claves y, a veces, datos personales. El proveedor debe operar con cifrado de extremo a extremo, repositorio interno y borrado contractual al cierre.

Preguntas frecuentes sobre pentesting cloud

¿Hace falta pedir permiso a AWS, Azure o GCP para hacer pentesting?

Hoy ya no en la mayoría de casos. AWS publicó en 2019 la Customer Support Policy for Penetration Testing que permite autotest sobre tu propia cuenta sin aviso previo en una lista amplia de servicios. Azure tiene una política equivalente desde 2017 y GCP no exige notificación si el alcance es propio. Las excepciones son DDoS, ataques a recursos compartidos del proveedor y técnicas que puedan afectar a otros tenants. Cualquier pentesting cloud serio empieza por revisar la política vigente del hyperscaler antes de tocar nada.

¿Cuánto dura un pentesting cloud?

Depende del tamaño del estate. Una cuenta única con 30-50 servicios habilitados se cubre en 5-7 días laborables. Una organización multi-cuenta con landing zone, varios entornos y cientos de recursos requiere típicamente 10-20 días, distribuidos en pentesting de configuración + asume-compromiso + revisión de aplicaciones críticas.

¿Qué diferencia hay entre pentesting cloud y CSPM?

Un CSPM (Cloud Security Posture Management) como Wiz, Prisma Cloud o Microsoft Defender for Cloud es una herramienta continua que detecta desviaciones de configuración. Un pentesting cloud es un ejercicio puntual con criterio humano que encadena los fallos para demostrar impacto real. Son complementarios: el CSPM da cobertura amplia y permanente; el pentesting da profundidad y prioriza lo que de verdad explotaría un atacante.

¿El pentesting cloud sustituye al pentesting de aplicaciones?

No. Si tu aplicación corre en cloud (Lambda + API Gateway, contenedores en EKS, Cloud Run) necesitas las dos cosas: el pentesting cloud audita la infraestructura y la identidad; el pentesting web audita el código y la lógica de la aplicación. La superposición es real pero parcial.

¿Y qué pasa con los entornos híbridos y multicloud?

Es el escenario más común en empresa española mediana y grande: parte en AWS, parte en Azure por Microsoft 365, GCP para data analytics. El pentesting tiene que cubrir cada uno con la metodología propia y, sobre todo, los puntos de conexión: federación de identidades, peering de redes, sincronización de claves. Los pivots multicloud son el vector más infraexaminado y el que más sorprende cuando se evalúa.

¿Qué pasa con Kubernetes en cloud?

EKS, AKS y GKE merecen su propio bloque de pentesting porque combinan las particularidades del cluster (RBAC, pod security, service accounts, admission controllers) con la integración cloud (IRSA en AWS, Workload Identity en GCP, managed identities en Azure). Una auditoría cloud completa incluye Kubernetes; una auditoría que ignora el clúster deja fuera el activo donde corre la aplicación crítica de la mayoría de los clientes modernos.

Recursos relacionados

• Qué es un pentesting: la guía pillar para entender la disciplina completa.
• Pentesting web: cómo se audita la capa de aplicación que corre encima de cloud.
• Errores típicos de configuración cloud en AWS y Azure: el catálogo de patrones que aparecen en el 80% de las auditorías.
• Auditoría NIS2 paso a paso: cómo se evidencia el control técnico cloud en NIS2.
• Servicio de auditoría cloud: el servicio donde aplicamos esta metodología.

El pentesting cloud en Secra

En Secra ejecutamos pentesting cloud sobre AWS, Azure y GCP combinando auditoría de configuración (Prowler, ScoutSuite, herramientas internas), pentesting asume compromiso y revisión de aplicaciones cloud-native. Cada hallazgo va con cadena de ataque reproducible, severidad justificada por impacto en negocio y plan de remediación priorizado. Si quieres una propuesta concreta para tu landing zone o tus suscripciones, escríbenos a través de contacto y te respondemos con una primera valoración.