AWS CloudTrail y GuardDuty: detección cloud-native de amenazas

Cada acción que alguien ejecuta en una cuenta de AWS —lanzar una instancia EC2, modificar una política de S3, crear un usuario IAM o simplemente iniciar sesión en la consola— genera una llamada a la API que queda registrada. AWS CloudTrail es el servicio que captura esos registros, y Amazon GuardDuty es el motor de detección que analiza esa telemetría (y más) buscando comportamientos maliciosos, anómalos o no autorizados. Juntos forman el núcleo de la detección cloud-native en AWS: sin ellos, un atacante opera a ciegas para el defensor.

Esta lección explica cómo funcionan CloudTrail y GuardDuty, qué tipos de eventos y findings generan, cómo consultar los logs con Athena para investigar un incidente, y cómo conectar todo con EventBridge y SNS para respuesta automática. Es la tercera lección de la Tanda 9, centrada en seguridad cloud nativa e infraestructura como código.

Practica solo en cuentas AWS propias o de laboratorio con autorización explícita. Acceder a logs o servicios de cuentas ajenas sin permiso es acceso no autorizado.

Qué es CloudTrail#

AWS CloudTrail es un servicio de auditoría que registra las llamadas a la API de AWS realizadas en tu cuenta. Está habilitado por defecto en todas las cuentas desde 2014, pero sin configuración adicional solo retiene 90 días de management events en la consola. Para retención completa necesitas un trail que envíe los logs a un bucket S3.

CloudTrail registra tres categorías de eventos:

Los management events están habilitados por defecto en todo trail. Los data events hay que activarlos explícitamente porque generan mucho volumen (cada GetObject de S3 es un evento). Los insights events detectan desviaciones estadísticas del patrón habitual de uso.

Estructura de un registro CloudTrail#

Cada evento es un JSON con campos estandarizados. Los más relevantes para investigación:

{
  "eventTime": "2026-11-05T14:23:17Z",
  "eventName": "RunInstances",
  "eventSource": "ec2.amazonaws.com",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "198.51.100.42",
  "userAgent": "aws-cli/2.15.0",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/dev-juan",
    "accessKeyId": "AKIA..."
  },
  "requestParameters": {
    "instanceType": "p3.2xlarge",
    "imageId": "ami-0abcdef1234567890"
  },
  "responseElements": {
    "instancesSet": { "instanceId": "i-0a1b2c3d4e5f6" }
  },
  "errorCode": null
}

Este evento dice: el usuario dev-juan, desde la IP 198.51.100.42 usando la CLI, lanzó una instancia p3.2xlarge (GPU, cara) en us-east-1. Si nadie autorizó GPU en esa cuenta, esto es sospechoso.

Trail multi-región y organization trail#

Un trail puede capturar eventos de todas las regiones de la cuenta (recomendado) o solo de una. En AWS Organizations puedes crear un organization trail que centraliza logs de todas las cuentas miembro en un bucket del account de gestión, simplificando la auditoría.

# Crear un trail multi-región con data events de S3
aws cloudtrail create-trail \
  --name security-trail \
  --s3-bucket-name mi-bucket-cloudtrail \
  --is-multi-region-trail \
  --enable-log-file-validation

aws cloudtrail put-event-selectors \
  --trail-name security-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3"]
    }]
  }]'

aws cloudtrail start-logging --name security-trail

El flag --enable-log-file-validation activa la validación de integridad: CloudTrail genera digest files firmados cada hora para detectar si alguien modificó o eliminó logs del bucket.

Qué es GuardDuty#

Amazon GuardDuty es un servicio de detección de amenazas que analiza múltiples fuentes de datos buscando actividad maliciosa. No requiere agentes ni infraestructura: se habilita con un clic y empieza a generar findings.

Las fuentes de datos que consume GuardDuty:

GuardDuty correlaciona eventos de estas fuentes con listas de IPs maliciosas, feeds de amenazas de AWS y modelos de machine learning entrenados con el comportamiento normal de la cuenta.

Tipos de findings en GuardDuty#

GuardDuty clasifica sus detecciones (findings) en categorías que se mapean directamente a fases del ciclo de ataque:

Cada finding tiene una severidad (Low, Medium, High) y un campo resource que identifica el recurso afectado (instancia, usuario IAM, bucket).

Por qué ocurre: la causa raíz#

Los atacantes llegan a cuentas AWS por varias rutas, todas detectables con CloudTrail y GuardDuty:

• Credenciales filtradas: access keys en repos públicos, variables de entorno expuestas, logs con secrets. El atacante hace sts:GetCallerIdentity para validar y luego enumera.
• Console login sin MFA: cuentas IAM con password pero sin MFA habilitado. Un atacante con la contraseña entra directamente.
• Roles excesivamente permisivos: un rol de EC2 con AdministratorAccess permite a cualquier atacante que comprometa la instancia operar con privilegios totales.
• S3 buckets públicos: políticas que permiten s3:GetObject a *. GuardDuty detecta accesos anómalos.

Patrón típico de un ataque a AWS:

1. Obtener credenciales (filtradas, robadas, phishing)
2. sts:GetCallerIdentity → validar quién soy
3. iam:ListUsers, iam:ListRoles → enumerar
4. ec2:DescribeInstances → mapear infra
5. s3:ListBuckets → buscar datos
6. s3:GetObject → exfiltrar
7. ec2:RunInstances (p3.2xlarge) → minería
8. iam:CreateAccessKey → persistencia

CloudTrail registra cada uno de esos pasos. GuardDuty alerta en los pasos 1 (si la IP es conocida), 3-4 (reconnaissance), 6 (exfiltration), 7 (cryptomining), 8 (persistence).

Cómo se detecta#

Consultas con Amazon Athena#

CloudTrail envía logs a S3 en formato JSON comprimido. Para consultar esos logs a escala usas Amazon Athena, un servicio serverless de queries SQL sobre S3.

Primero creas la tabla:

CREATE EXTERNAL TABLE cloudtrail_logs (
  eventTime STRING,
  eventName STRING,
  eventSource STRING,
  sourceIPAddress STRING,
  userIdentity STRUCT<
    type: STRING,
    arn: STRING,
    accessKeyId: STRING
  >,
  awsRegion STRING,
  requestParameters STRING,
  responseElements STRING,
  errorCode STRING
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://mi-bucket-cloudtrail/AWSLogs/123456789012/CloudTrail/'

Luego puedes hacer queries de investigación:

-- Llamadas API desde IPs de Tor o desconocidas en las últimas 24h
SELECT eventTime, eventName, sourceIPAddress, userIdentity.arn
FROM cloudtrail_logs
WHERE eventTime > date_add('hour', -24, now())
  AND sourceIPAddress NOT LIKE '10.%'
  AND sourceIPAddress NOT LIKE '172.%'
ORDER BY eventTime DESC
LIMIT 100;

-- Creación de access keys (persistencia)
SELECT eventTime, userIdentity.arn, sourceIPAddress,
       requestParameters
FROM cloudtrail_logs
WHERE eventName = 'CreateAccessKey'
ORDER BY eventTime DESC;

-- Instancias GPU lanzadas (posible cryptomining)
SELECT eventTime, userIdentity.arn, sourceIPAddress,
       requestParameters
FROM cloudtrail_logs
WHERE eventName = 'RunInstances'
  AND requestParameters LIKE '%p3.%'
ORDER BY eventTime DESC;

Detección manual vs GuardDuty#

La práctica recomendada es usar GuardDuty para detección continua automática y Athena para investigación ad-hoc cuando un finding requiere contexto adicional.

Explotación paso a paso en un laboratorio#

En los laboratorios de whoami-labs que practican estos conceptos, la cadena típica involucra credenciales en entornos cloud:

Paso 1: Reconocimiento#

# Escanear el objetivo
nmap -sV -sC IP_DEL_LAB

Identificas los servicios expuestos. En un entorno cloud real, el equivalente sería un atacante haciendo DescribeInstances o ListBuckets tras obtener credenciales.

Paso 2: Buscar credenciales expuestas#

# En el laboratorio: buscar variables de entorno
env | grep -i aws
cat /proc/self/environ | tr '\0' '\n' | grep AWS

# Buscar archivos de credenciales
find / -name "credentials" -o -name ".aws" 2>/dev/null
cat ~/.aws/credentials

Paso 3: Validar y enumerar#

# Verificar identidad
aws sts get-caller-identity

# Enumerar recursos
aws s3 ls
aws ec2 describe-instances --region us-east-1
aws iam list-users

Paso 4: Exfiltrar o escalar#

# Descargar datos de S3
aws s3 cp s3://bucket-sensible/datos.tar.gz ./

# Crear nueva access key para persistencia
aws iam create-access-key --user-name dev-juan

Cada uno de estos comandos genera eventos en CloudTrail. En una cuenta bien monitoreada, GuardDuty generaría findings de tipo Recon y Exfiltration.

Qué puede lograr un atacante#

Un compromiso de credenciales AWS sin detección puede costar desde cientos hasta cientos de miles de dólares en cuestión de horas, especialmente si el atacante lanza instancias de minería en múltiples regiones simultáneamente.

Cómo se corrige#

Habilitar GuardDuty en todas las regiones#

# Habilitar GuardDuty en la región actual
aws guardduty create-detector --enable

# Script para habilitar en todas las regiones
for region in $(aws ec2 describe-regions \
  --query 'Regions[].RegionName' --output text); do
  aws guardduty create-detector --enable --region "$region"
done

Configurar alertas con EventBridge#

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }]
  }
}

Esta regla de EventBridge captura findings de severidad High (7+) y los envia a un target: SNS (email/SMS), Lambda (respuesta automática), o Step Functions (workflow completo).

Respuesta automática con Lambda#

import boto3
import json

def handler(event, context):
    finding = event['detail']
    finding_type = finding['type']

    # Si detecta access key comprometida
    if 'UnauthorizedAccess:IAMUser' in finding_type:
        iam = boto3.client('iam')
        access_key = finding['resource']['accessKeyDetails']
        user = access_key['userName']
        key_id = access_key['accessKeyId']

        # Desactivar la access key comprometida
        iam.update_access_key(
            UserName=user,
            AccessKeyId=key_id,
            Status='Inactive'
        )

        # Adjuntar política de denegación total
        iam.attach_user_policy(
            UserName=user,
            PolicyArn='arn:aws:iam::aws:policy/AWSDenyAll'
        )

        return {
            'action': 'key_disabled_and_user_denied',
            'user': user,
            'keyId': key_id
        }

Protección del trail#

# Habilitar validación de integridad del log
aws cloudtrail update-trail \
  --name security-trail \
  --enable-log-file-validation

# Proteger el bucket con Object Lock (WORM)
aws s3api put-object-lock-configuration \
  --bucket mi-bucket-cloudtrail \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 365
      }
    }
  }'

Con Object Lock en modo COMPLIANCE, ni siquiera el root account puede eliminar los logs durante el período de retención.

Errores comunes al defenderse#

• Habilitar CloudTrail solo en una región: el atacante opera desde otra región sin dejar rastro en tu trail.
• No activar data events de S3: ves que alguien cambió la política del bucket pero no quién descargó los archivos.
• GuardDuty habilitado pero sin alertas configuradas: los findings se acumulan sin que nadie los vea.
• Trail sin protección de integridad: el atacante con permisos suficientes borra los logs de S3.
• No habilitar MFA en cuentas IAM: la defensa más básica contra compromiso de credenciales.
• Ignorar findings de severidad Low: un Recon:EC2/PortProbeUnprotectedPort puede ser el primer paso de un ataque mayor.
• No tener organization trail: cada cuenta gestiona sus propios logs y la visibilidad centralizada es inexistente.

Preguntas frecuentes#

CloudTrail ya viene habilitado, entonces no tengo que hacer nada#

Sí tienes. El trail por defecto solo retiene 90 días en la consola y no captura data events. Necesitas crear un trail que envíe a S3, habilitar data events para S3 y Lambda, activar insights, y proteger el bucket con Object Lock.

GuardDuty tiene coste, merece la pena#

GuardDuty cobra por volumen de eventos analizados. Para la mayoría de cuentas el coste es de unos pocos dólares al mes. Comparado con el coste de un incidente no detectado (miles en minería, daño reputacional, multas regulatorias), el ROI es inmediato.

Puedo usar solo CloudTrail sin GuardDuty#

Puedes, pero tendrás que escribir todas las reglas de detección tú mismo (queries en Athena, reglas en EventBridge, o exportar a un SIEM). GuardDuty viene con cientos de reglas mantenidas por AWS, feeds de amenazas actualizados y modelos de ML. Reinventar eso es posible pero costoso.

Cómo investigo un finding de GuardDuty#

El finding incluye el recurso afectado, la acción detectada, y el actor (IP, usuario, access key). Desde ahí vas a Athena y consultas CloudTrail filtrando por ese accessKeyId o sourceIPAddress en el rango de tiempo para reconstruir toda la sesión del atacante.

GuardDuty detecta amenazas en tiempo real#

Casi. GuardDuty procesa CloudTrail management events con una latencia típica de 5-15 minutos. VPC Flow Logs y DNS pueden tardar un poco más. No es estrictamente real-time, pero es suficiente para la mayoría de escenarios.

Qué hago si GuardDuty detecta cryptomining#

Primero, aísla: desactiva la access key comprometida y cambia el security group de la instancia para cortar tráfico. Segundo, investiga: usa CloudTrail para identificar todas las acciones del atacante. Tercero, remedia: termina instancias no autorizadas, rota todas las credenciales que pudieron estar expuestas, revisa IAM policies.

Resumen#

• CloudTrail registra cada llamada a la API de AWS: management events por defecto, data events e insights bajo configuración explícita.
• GuardDuty analiza CloudTrail, VPC Flow Logs, DNS y más para detectar amenazas automáticamente con ML y feeds de amenazas.
• Los findings de GuardDuty cubren reconocimiento, acceso no autorizado, cryptomining, exfiltración y persistencia, mapeados a MITRE ATT&CK.
• Athena permite consultar logs de CloudTrail con SQL para investigación ad-hoc durante un incidente.
• EventBridge + SNS/Lambda conectan los findings con alertas y respuesta automatizada.
• Proteger el trail con Object Lock y validación de integridad evita que el atacante borre sus propias huellas.

Fuentes y lecturas recomendadas#

• AWS CloudTrail User Guide
• Amazon GuardDuty User Guide
• GuardDuty Finding Types
• Querying CloudTrail Logs with Athena
• MITRE ATT&CK Cloud Matrix
• AWS Security Incident Response Guide