Pentesting en AWS: qué se revisa, qué permite la política de AWS y qué te toca a ti

Por Kike Gandia · Co-Fundador y CEO, OSCP

Un pentest de AWS no consiste en escanear las IP públicas de tus instancias. En la nube el perímetro son las identidades y la configuración: quién puede llamar a qué API, con qué permisos y desde dónde. Antes de empezar conviene tener claras tres cosas: qué parte de la seguridad es responsabilidad de AWS y cuál tuya, qué se puede probar sin pedir permiso y qué prohíbe la política de AWS, y qué áreas revisa un pentest bien planteado. Esta guía las recorre, con la política vigente de AWS, su comparación con Azure y Google Cloud, las rutas de escalada de privilegios en IAM que más se explotan y cómo preparar la cuenta.

Qué es un pentest de AWS y en qué se diferencia de uno tradicional

En un pentest de infraestructura clásica, el objetivo son máquinas y servicios de red. En AWS hay un plano más, y suele ser el decisivo: el plano de control, la API de AWS con la que se crean, modifican y leen todos los recursos. Quien obtiene credenciales con permisos suficientes no necesita explotar ningún servidor: le basta con pedirle a la API que le entregue los datos, que cree un usuario o que modifique una política.

Por eso un pentest de AWS se plantea en tres capas:

Lo expuesto a internet: instancias EC2, balanceadores, API Gateway, CloudFront, buckets de S3, URLs de funciones Lambda, bases de datos con acceso público y subdominios que apuntan a recursos de la cuenta.
La cuenta y sus identidades: usuarios, roles, políticas, relaciones de confianza entre cuentas, federación con proveedores de identidad y pipelines de CI/CD, y la configuración de cada servicio.
Las cargas de trabajo: las aplicaciones, funciones y contenedores que corren en la cuenta, que a menudo son la puerta de entrada a todo lo anterior.

Las tres se conectan. El patrón más habitual de incidente grave en AWS empieza en una aplicación vulnerable, sigue con las credenciales del rol que tiene asignado y termina en datos o en el control de la cuenta. Un pentest que mire solo una capa no ve esa cadena.

El modelo de responsabilidad compartida: qué hace AWS y qué te toca a ti

AWS lo resume en una fórmula: AWS es responsable de la seguridad «de» la nube y el cliente, de la seguridad «en» la nube. AWS protege la infraestructura que ejecuta todos sus servicios: centros de datos, hardware, red y la capa de virtualización. Lo que configuras encima es tuyo, y cuánto te toca depende del tipo de servicio:

Tipo de servicio	Ejemplos	Se encarga AWS	Te toca a ti
Infraestructura	EC2, VPC, volúmenes EBS	Hardware, red física, hipervisor	Sistema operativo, parches, grupos de seguridad, aplicaciones, datos e identidades
Servicios abstractos	S3, DynamoDB, Lambda	Infraestructura, sistema operativo y plataforma	Datos, cifrado, políticas de acceso, permisos de IAM y configuración del servicio

En la práctica, en todos los servicios hay cuatro cosas que siempre son tuyas: quién tiene acceso y con qué permisos, qué datos guardas y cómo los cifras, qué expones a internet y qué registras para poder detectar un ataque. Son exactamente las áreas que revisa un pentest de AWS.

Un malentendido frecuente es asumir que, al ser un servicio gestionado, la configuración segura viene dada. AWS ha endurecido algunos valores por defecto —desde abril de 2023, los buckets de S3 nuevos se crean con el bloqueo de acceso público activado y las ACL desactivadas—, pero no cambia la configuración de lo que ya existe ni impide que alguien la relaje después. Si un bucket se vuelve público por una política mal escrita, la responsabilidad es del cliente.

La política de pentesting de AWS: qué se puede probar y qué no

AWS permite a sus clientes hacer pruebas de penetración sobre su propia infraestructura sin aprobación previa para una lista de servicios. A octubre de 2026 son: EC2 (incluidos WAF, NAT Gateway y Elastic Load Balancing), RDS, Aurora, CloudFront, API Gateway, AppSync, Lambda y Lambda@Edge, Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch Service, FSx, Transit Gateway, Bedrock AgentCore y Global Accelerator. La lista cambia con el tiempo, así que se revisa en cada proyecto.

Categoría	Qué incluye	Qué hacer
Permitido sin aprobación	Pruebas sobre tus recursos de los servicios de la lista, dentro de tu cuenta	Documentar el alcance y las fechas internamente
Siempre con aprobación previa	Cualquier prueba que incluya infraestructura de mando y control (C2)	Solicitarlo a AWS antes de empezar
Eventos simulados	Ejercicios de red team, blue team o purple team, phishing simulado, pruebas de malware y de rendimiento de red	Formulario de eventos simulados en la consola de soporte, con al menos dos semanas de antelación
Pruebas de DDoS	Simulaciones de denegación de servicio distribuida	Solo a través de un partner de AWS preaprobado y sobre recursos protegidos con AWS Shield Advanced
Prohibido	Recorrer zonas DNS de Route 53 (zone walking), secuestro de DNS o pharming a través de Route 53, DoS y DDoS (también simulados fuera de su política), inundación de puertos, protocolos o peticiones, toma de control de buckets de S3 y de subdominios	No se hace, ni siquiera dentro del alcance acordado

Tampoco se puede evaluar la propia infraestructura de AWS ni sus servicios en sí: el objeto de la prueba son tus recursos. Si durante el pentest aparece una vulnerabilidad en un servicio de AWS, se reporta a su equipo de seguridad.

Dos prohibiciones tienen consecuencias prácticas para el alcance. Que no se pueda tomar el control de un bucket o de un subdominio significa que, si el pentester encuentra un registro DNS que apunta a un bucket que ya no existe, lo documenta como hallazgo con su evidencia, pero no lo reclama para demostrarlo. Y la prohibición de inundar peticiones obliga a acordar cómo se prueban los límites de uso de una API sin superar lo que AWS considera un ataque.

¿Y en Azure y Google Cloud?

Los otros dos grandes proveedores tienen políticas parecidas en lo esencial —no hace falta avisar para probar tus propios recursos— y distintas en los detalles:

Proveedor	¿Hay que avisar antes?	Restricciones principales
AWS	No, para los servicios de la lista; sí para pruebas con C2 y eventos simulados	Sin DoS, sin inundación, sin zone walking en Route 53, sin toma de buckets ni subdominios
Microsoft Azure	No desde el 15 de junio de 2017, pero hay que cumplir sus reglas de compromiso	Sin pruebas de denegación de servicio, sin usar credenciales que no son tuyas aunque estén filtradas, sin fuzzing que genere tráfico excesivo, sin phishing a empleados de Microsoft y sin acciones posteriores a la explotación más allá de la prueba de concepto
Google Cloud	No: Google indica que no es necesario contactarle	Cumplir la política de uso aceptable y las condiciones del servicio, y que las pruebas afecten solo a tus proyectos

En entornos multicloud, el alcance del pentest debe recoger las reglas de cada proveedor por separado. Y en los tres casos las políticas cambian: lo prudente es revisarlas al definir el alcance y dejar constancia de la versión consultada.

Qué se revisa en un pentest de AWS

El alcance concreto depende del supuesto de partida, pero un pentest completo de una cuenta de AWS recorre estas áreas:

Área	Qué se busca
IAM	Usuarios con claves de acceso de larga duración, cuenta raíz en uso o sin MFA, políticas con comodines, rutas de escalada de privilegios, roles asumibles desde otras cuentas sin condiciones, federación con GitHub Actions u otros proveedores con condiciones demasiado amplias
S3	Buckets o objetos accesibles públicamente, políticas que conceden acceso a cualquier cuenta de AWS, URLs prefirmadas de larga duración, datos sensibles en buckets de pruebas
EC2 y servicio de metadatos	Instancias que aceptan IMDSv1, secretos en los datos de usuario, grupos de seguridad abiertos a internet, AMI o snapshots compartidos públicamente
Lambda y serverless	Secretos en variables de entorno, roles de ejecución con permisos excesivos, URLs de función sin autenticación, inyección a través de los eventos que procesa la función
API Gateway	Endpoints sin autorizador, políticas de recurso permisivas, ausencia de límites de uso
Red	Grupos de seguridad con 0.0.0.0/0 en puertos de administración o bases de datos, peering y conexiones entre VPC más amplios de lo necesario
Bases de datos	Instancias RDS accesibles públicamente, snapshots compartidos, cifrado desactivado
Secretos	Quién puede leer Secrets Manager y Parameter Store, secretos en el código o en el pipeline
Registro y detección	CloudTrail en todas las regiones y protegido frente a borrado, GuardDuty activo y, sobre todo, si alguien reacciona a sus alertas
Organización	Políticas de control de servicios (SCP), uso de la cuenta de administración para cargas de trabajo, cuentas fuera de la organización

Los errores concretos de cada área y cómo se corrigen están en la guía de errores de configuración cloud más comunes.

Escalada de privilegios en IAM: el núcleo del pentest

La pregunta que mejor resume un pentest de AWS es: si un atacante compromete esta identidad, ¿puede convertirse en administrador? Muchas veces la respuesta es sí, aunque la identidad no tenga ninguna política de administrador, porque hay combinaciones de permisos que permiten concederse más permisos. Rhino Security Labs documentó en 2018 veintiún métodos de escalada en IAM y amplió la lista después; siguen siendo la base de cualquier revisión. Algunos ejemplos:

Permisos	Qué permite
iam:CreatePolicyVersion	Crear una nueva versión de una política que ya tiene asignada, con permisos de administrador, y marcarla como predeterminada
iam:AttachUserPolicy o iam:PutUserPolicy	Asignarse a sí mismo una política administrada o escribir una política en línea con los permisos que quiera
iam:CreateAccessKey sobre otro usuario	Crear claves de acceso para un usuario con más privilegios y actuar como él
iam:UpdateAssumeRolePolicy y sts:AssumeRole	Modificar la política de confianza de un rol privilegiado para poder asumirlo
iam:PassRole, lambda:CreateFunction y lambda:InvokeFunction	Crear una función con un rol más privilegiado e invocarla para ejecutar código con sus permisos
iam:PassRole y ec2:RunInstances	Lanzar una instancia con un rol privilegiado y obtener sus credenciales desde dentro

Los tres últimos ejemplos explican por qué iam:PassRole es uno de los permisos que más se revisan: no da privilegios por sí mismo, pero permite entregar un rol a un servicio que luego actúa con él.

Las defensas son conocidas, aunque no siempre se aplican: mínimo privilegio en las políticas, límites de permisos (permission boundaries) para los roles que crean otros roles, SCP en la organización que impidan las acciones más peligrosas fuera de los roles de administración y revisión periódica de los permisos no usados con IAM Access Analyzer. El pentest comprueba si, con todo eso aplicado, queda alguna ruta.

Caja negra, caja blanca o assumed breach

El enfoque condiciona lo que se puede encontrar. En AWS es habitual combinar varios:

Enfoque	Punto de partida	Qué responde	Limitación
Caja negra externa	Solo el nombre de la empresa y sus dominios	Qué ve un atacante desde internet: buckets, endpoints, subdominios huérfanos, servicios expuestos	No ve configuración interna ni rutas de escalada
Caja blanca de configuración	Un rol de solo lectura sobre las cuentas	Qué está mal configurado en todos los servicios y regiones	No demuestra qué es explotable
Assumed breach	Una identidad de bajo privilegio o una carga de trabajo comprometida	Hasta dónde llega un atacante que ya ha conseguido un primer acceso	Depende de elegir bien el supuesto de partida

Para la parte de configuración basta un rol de solo lectura; AWS ofrece políticas administradas pensadas para ello, como SecurityAudit o ViewOnlyAccess. Para la parte ofensiva hace falta además una identidad de prueba con permisos deliberadamente limitados, que represente de forma realista lo que un atacante podría robar: las claves de un desarrollador, el rol de una función expuesta o las credenciales del pipeline.

Sobre producción: la mayoría de las pruebas de un pentest de AWS son de lectura y enumeración y no afectan al servicio. Las que modifican recursos —crear una versión de política, lanzar una función— se acuerdan previamente, se hacen con recursos marcados y se deshacen al terminar. Las pruebas destructivas no forman parte de un pentest normal.

Herramientas habituales

Las herramientas aceleran el trabajo, pero ninguna sustituye al análisis de cadenas. Las más usadas, con su estado a octubre de 2026:

Herramienta	Para qué se usa	Estado
Prowler	Revisión de configuración contra buenas prácticas y marcos como CIS, en AWS y otros proveedores	Código abierto, con desarrollo muy activo
ScoutSuite (NCC Group)	Revisión de configuración multicloud	Código abierto, con poca actividad desde 2024
Pacu (Rhino Security Labs)	Marco de explotación para AWS, incluida la detección de rutas de escalada de IAM	Código abierto, activo
CloudFox (Bishop Fox)	Enumeración de caminos de ataque: qué secretos, roles y puntos de entrada existen	Código abierto, activo
PMapper (NCC Group)	Grafo de permisos de IAM para encontrar rutas de escalada	Sin mantenimiento desde 2022
IAM Access Analyzer	Accesos externos, permisos no usados y validación de políticas	Servicio nativo de AWS

La salida de estas herramientas es el punto de partida. El trabajo del pentest es decidir qué hallazgos se combinan, comprobarlo de forma controlada y medir si la detección —CloudTrail, GuardDuty, el SOC— reacciona mientras ocurre.

Cómo preparar la cuenta y qué deberías recibir

Una preparación de una o dos horas evita la mayoría de los problemas durante el pentest:

Definir el alcance por escrito: cuentas, regiones, servicios y entornos incluidos y excluidos, supuestos de partida y fechas.
Revisar la política vigente de AWS y, si el ejercicio incluye phishing, C2 o pruebas de red team, enviar el formulario de eventos simulados con antelación.
Crear las identidades del pentest: el rol de auditoría de solo lectura y la identidad de prueba de bajo privilegio, con caducidad.
Decidir qué se hace con la detección: si el equipo de seguridad está avisado o si el ejercicio sirve también para medir su respuesta, y quién puede pararlo.
Confirmar que CloudTrail está activo en todas las regiones del alcance: sin él no se puede evaluar la detección ni reconstruir qué se hizo.
Designar un contacto técnico disponible durante la ventana de pruebas.

Al terminar, el entregable debería incluir las cadenas de ataque demostradas con sus evidencias, cada hallazgo con su impacto en tu contexto y su corrección concreta, la correspondencia con el CIS AWS Foundations Benchmark o el marco que uses y un re-test tras las correcciones. Si la empresa presta servicios al sector público, conviene además contrastar la configuración con la serie de guías CCN-STIC 887 del Centro Criptológico Nacional para AWS.

FAQ

¿Hay que pedir permiso a AWS para hacer un pentest?

Para los servicios incluidos en su política, no: AWS permite probar tus propios recursos sin aprobación previa. Sí hace falta solicitarlo para cualquier prueba con infraestructura de mando y control (C2) y, mediante el formulario de eventos simulados, para ejercicios de red team, phishing simulado o pruebas de malware. Las pruebas de DDoS solo se pueden hacer con un partner preaprobado.

¿Qué está prohibido en un pentest de AWS?

Recorrer zonas DNS de Route 53, el secuestro de DNS y el pharming a través de Route 53, cualquier denegación de servicio fuera de su política específica, la inundación de puertos, protocolos o peticiones y la toma de control de buckets de S3 o de subdominios. Tampoco se puede atacar la infraestructura ni los servicios de AWS en sí.

Si nos atacan por una mala configuración, ¿es responsabilidad de AWS?

No. Según el modelo de responsabilidad compartida, AWS responde de la seguridad de la infraestructura que ejecuta sus servicios; la configuración, las identidades y los permisos, los datos y su cifrado son responsabilidad del cliente. Un bucket público o un rol con permisos excesivos son fallos del lado del cliente.

¿Se puede hacer el pentest en la cuenta de producción?

Sí, y suele ser lo más útil, porque es donde están los permisos y los datos reales. La mayoría de las pruebas son de lectura. Las que crean o modifican recursos se pactan antes, se hacen con recursos identificados y se revierten al terminar; las destructivas no forman parte de un pentest normal.

¿Un pentest de AWS incluye las aplicaciones que corren en la cuenta?

Depende del alcance, y conviene decidirlo conscientemente. Muchos incidentes empiezan en una aplicación —un SSRF, una inyección— y continúan en la cuenta con las credenciales de su rol. Si la aplicación no entra en el alcance, al menos debería incluirse el supuesto de que esa carga de trabajo está comprometida.

¿Qué guías de configuración segura de AWS aplican al ENS?

El Centro Criptológico Nacional publica la serie CCN-STIC 887 para AWS, con el perfil de cumplimiento específico y guías de configuración segura, entre otras. Para las empresas que prestan servicios al sector público son la referencia natural con la que contrastar la configuración, además de los CIS Benchmarks.