Cómo investigar una fuga de datos en AWS - Guía forense para empresas

El director de tecnología de una empresa de comercio electrónico recibe una llamada a las 3 de la madrugada: han aparecido datos de 50.000 clientes en un foro de la dark web. Su infraestructura está 100% en AWS. Tiene 72 horas para notificar a la AEPD y necesita saber qué pasó, cuándo y cómo.

Este escenario se repite cada vez con más frecuencia. Como perito informático forense certificado en AWS Security Specialty y con experiencia como CTO gestionando infraestructuras cloud de producción, he desarrollado una metodología específica para investigar fugas de datos en entornos AWS que preserva la evidencia con validez judicial.

Por qué las fugas en AWS requieren un enfoque diferente

El problema de la evidencia efímera

En un servidor tradicional, la evidencia está en un disco duro que puedes clonar. En AWS, la situación es radicalmente diferente:

• Auto-scaling puede haber destruido la instancia comprometida hace horas
• S3 lifecycle policies pueden haber eliminado versiones anteriores de archivos
• CloudWatch logs tienen retención limitada por defecto (nunca indefinida)
• Lambda functions no dejan rastro en disco después de ejecutarse

Lo que otros peritos no saben buscar

La mayoría de peritos informáticos no han operado infraestructuras AWS de producción. No saben que:

• Los VPC Flow Logs capturan tráfico de red pero no el contenido
• CloudTrail solo registra llamadas a API, no acceso a datos dentro de S3
• S3 Access Logs son diferentes de CloudTrail y se almacenan en otro bucket
• Las instancias spot pueden desaparecer sin previo aviso
• Los roles IAM pueden asumir identidades de forma temporal sin dejar rastro obvio

Mi experiencia como CTO diseñando estas arquitecturas me permite saber exactamente dónde buscar la evidencia que otros no encuentran.

Fase 1: Preservación de emergencia (0-4 horas)

Paso 1: Suspender procesos automáticos

Lo primero es detener la destrucción de evidencia:

# Suspender auto-scaling de grupos críticos
aws autoscaling suspend-processes \
  --auto-scaling-group-name production-asg \
  --scaling-processes Launch Terminate

# Desactivar lifecycle policies de S3 temporalmente
aws s3api put-bucket-lifecycle-configuration \
  --bucket datos-clientes \
  --lifecycle-configuration '{"Rules":[]}'

Documentación forense: Captura timestamp, usuario que ejecuta, y estado anterior de cada configuración modificada.

Paso 2: Crear snapshots de instancias en ejecución

Antes de cualquier análisis, preservamos el estado actual:

# Identificar instancias en el grupo comprometido
INSTANCE_IDS=$(aws ec2 describe-instances \
  --filters "Name=tag:Environment,Values=production" \
  --query 'Reservations[].Instances[].InstanceId' \
  --output text)

# Crear snapshots de todos los volúmenes
for INSTANCE_ID in $INSTANCE_IDS; do
  VOLUME_IDS=$(aws ec2 describe-volumes \
    --filters "Name=attachment.instance-id,Values=$INSTANCE_ID" \
    --query 'Volumes[].VolumeId' --output text)

  for VOLUME_ID in $VOLUME_IDS; do
    aws ec2 create-snapshot \
      --volume-id $VOLUME_ID \
      --description "FORENSE-$(date +%Y%m%d-%H%M%S)-$INSTANCE_ID" \
      --tag-specifications "ResourceType=snapshot,Tags=[{Key=forensic,Value=true}]"
  done
done

Paso 3: Capturar memoria RAM

La memoria RAM contiene evidencia que no existe en disco: claves de sesión, conexiones activas, procesos en ejecución.

# Usando LiME (Linux Memory Extractor) en instancias Linux
sudo insmod lime.ko "path=/tmp/memory-$(hostname)-$(date +%Y%m%d).lime format=lime"

# Calcular hash para cadena de custodia
sha256sum /tmp/memory-*.lime > /tmp/memory-hashes.txt

Paso 4: Preservar logs antes de que expiren

# Exportar CloudTrail de los últimos 90 días
aws cloudtrail lookup-events \
  --start-time $(date -d '90 days ago' --iso-8601) \
  --end-time $(date --iso-8601) \
  --output json > cloudtrail-export-$(date +%Y%m%d).json

# Exportar VPC Flow Logs
aws logs filter-log-events \
  --log-group-name /aws/vpc/flow-logs \
  --start-time $(date -d '30 days ago' +%s)000 \
  --output json > vpc-flow-logs-$(date +%Y%m%d).json

# Exportar S3 Access Logs (si están habilitados)
aws s3 sync s3://bucket-access-logs/ ./s3-access-logs/ --exclude "*" --include "*.log"

Fase 2: Identificación del alcance (4-24 horas)

Análisis de CloudTrail para identificar el vector de ataque

CloudTrail es el “registro de actividad” de AWS. Cada llamada a API queda registrada:

-- Consulta en Athena para identificar actividad sospechosa en S3
SELECT
    eventTime,
    userIdentity.userName,
    userIdentity.arn,
    eventName,
    requestParameters.bucketName,
    requestParameters.key,
    sourceIPAddress,
    userAgent
FROM cloudtrail_logs
WHERE eventTime BETWEEN '2025-01-10T00:00:00Z' AND '2025-01-18T00:00:00Z'
  AND eventSource = 's3.amazonaws.com'
  AND eventName IN ('GetObject', 'ListObjects', 'ListObjectsV2')
  AND requestParameters.bucketName = 'datos-clientes'
ORDER BY eventTime DESC;

Patrones de exfiltración que busco

Mi experiencia analizando fugas de datos me ha enseñado a identificar patrones específicos:

1. Descarga masiva desde IP inusual

SELECT
    sourceIPAddress,
    COUNT(*) as descargas,
    SUM(CAST(additionalEventData.bytesTransferredOut AS BIGINT)) as bytes_total
FROM cloudtrail_logs
WHERE eventName = 'GetObject'
GROUP BY sourceIPAddress
HAVING COUNT(*) > 1000
ORDER BY descargas DESC;

2. Uso de credenciales comprometidas

-- Identificar uso de AccessKey desde múltiples IPs (indicador de robo)
SELECT
    userIdentity.accessKeyId,
    COUNT(DISTINCT sourceIPAddress) as ips_diferentes
FROM cloudtrail_logs
WHERE userIdentity.accessKeyId IS NOT NULL
GROUP BY userIdentity.accessKeyId
HAVING COUNT(DISTINCT sourceIPAddress) > 5;

3. Escalada de privilegios

-- Cambios en IAM que podrían indicar escalada
SELECT *
FROM cloudtrail_logs
WHERE eventSource = 'iam.amazonaws.com'
  AND eventName IN ('CreateAccessKey', 'AttachUserPolicy', 'PutUserPolicy', 'AssumeRole')
ORDER BY eventTime;

Correlación con VPC Flow Logs

Los VPC Flow Logs muestran conexiones de red que CloudTrail no captura:

-- Tráfico saliente inusual desde instancias de base de datos
SELECT
    srcaddr,
    dstaddr,
    dstport,
    SUM(bytes) as total_bytes
FROM vpc_flow_logs
WHERE srcaddr IN (SELECT private_ip FROM rds_instances)
  AND action = 'ACCEPT'
  AND dstport NOT IN (443, 5432, 3306)  -- puertos legítimos
GROUP BY srcaddr, dstaddr, dstport
HAVING SUM(bytes) > 1000000000  -- más de 1GB
ORDER BY total_bytes DESC;

Fase 3: Reconstrucción del timeline (1-3 días)

Correlación de eventos entre servicios

La clave del análisis forense cloud es correlacionar eventos de múltiples fuentes. He desarrollado herramientas propias para esto:

class AWSForensicsTimeline:
    """
    Correlaciona eventos de CloudTrail, VPC Flow Logs y S3 Access Logs
    en un timeline unificado.
    """

    def __init__(self):
        self.events = []

    def add_cloudtrail_events(self, cloudtrail_json):
        for event in cloudtrail_json['Events']:
            self.events.append({
                'timestamp': event['EventTime'],
                'source': 'CloudTrail',
                'event_type': event['EventName'],
                'user': event.get('Username', 'unknown'),
                'ip': event.get('SourceIPAddress', 'unknown'),
                'details': event
            })

    def add_vpc_flow_logs(self, flow_logs):
        for log in flow_logs:
            self.events.append({
                'timestamp': datetime.fromtimestamp(log['start']),
                'source': 'VPCFlowLogs',
                'event_type': 'network_flow',
                'ip': log['srcaddr'],
                'details': log
            })

    def generate_timeline(self, start_time, end_time):
        filtered = [e for e in self.events
                   if start_time <= e['timestamp'] <= end_time]
        return sorted(filtered, key=lambda x: x['timestamp'])

    def find_correlations(self):
        """
        Identifica eventos relacionados por IP o timestamp cercano
        """
        correlations = []
        for i, event in enumerate(self.events):
            for j, other in enumerate(self.events[i+1:], i+1):
                if self._are_related(event, other):
                    correlations.append((event, other))
        return correlations

Ejemplo de timeline reconstruido

En una investigación reciente, el timeline reveló:

Este timeline permitió determinar que el atacante usó credenciales de un empleado (comprometidas por phishing) para acceder a datos y exfiltrarlos en menos de 30 minutos.

Fase 4: Documentación para procedimiento judicial

Estructura del informe pericial cloud

Mi informe pericial para fugas de datos en AWS incluye:

1. Resumen ejecutivo

• Qué datos fueron comprometidos
• Cuándo ocurrió la exfiltración
• Cómo accedió el atacante
• Alcance del compromiso

2. Metodología aplicada

• Herramientas utilizadas (todas certificadas)
• Proceso de preservación de evidencia
• Cadena de custodia documentada

3. Análisis técnico detallado

• Timeline de eventos con evidencia
• Correlación entre fuentes de logs
• Identificación del vector de ataque

4. Conclusiones fundamentadas

• Hechos probados con evidencia
• Nivel de certeza de cada conclusión
• Limitaciones del análisis

5. Anexos técnicos

• Hashes de toda la evidencia
• Capturas de pantalla con timestamps
• Queries utilizados y resultados

Consideraciones legales específicas

Para que la evidencia cloud sea admisible en España:

• Jurisdicción: Documentar en qué región de AWS estaban los datos
• GDPR: El análisis debe cumplir con minimización de datos
• Notificación AEPD: El informe debe servir para la notificación obligatoria en 72h
• Preservación: Demostrar que la evidencia no ha sido alterada desde su captura

Errores comunes que veo en otras investigaciones

1. No preservar antes de investigar

He visto casos donde el equipo de IT “investiga” reiniciando servidores, modificando configuraciones y eliminando logs “sospechosos”. Esto destruye evidencia y puede invalidar cualquier procedimiento judicial posterior.

2. Confiar solo en CloudTrail

CloudTrail registra llamadas a API, pero no el contenido de los datos. Si alguien descarga un archivo de S3, CloudTrail registra que hubo un GetObject, pero no qué había en ese archivo. Necesitas correlacionar con otras fuentes.

3. Ignorar la responsabilidad compartida

AWS es responsable de la seguridad de la nube. Tú eres responsable de la seguridad en la nube. Esto afecta a qué evidencia puedes obtener y cómo documentarla.

4. No considerar la jurisdicción

Si tus datos estaban en eu-west-1 (Irlanda) y el atacante operaba desde fuera de la UE, las implicaciones legales son diferentes que si todo ocurrió en España.

Cuándo necesitas un perito especializado en cloud

• Datos de clientes comprometidos: Obligación de notificar a AEPD en 72h
• Sospecha de empleado desleal: Necesitas evidencia que se sostenga en juicio laboral
• Disputa con proveedor cloud: Demostrar responsabilidades en un incidente
• Due diligence tecnológica: Verificar seguridad antes de una adquisición
• Ransomware en infraestructura cloud: Investigar cómo entraron y qué alcanzaron

Sobre el autor: Jonathan Izquierdo es perito informático forense con certificación AWS Security Specialty y más de 15 años de experiencia como CTO gestionando infraestructuras cloud de producción. Esta combinación única de conocimiento operativo y metodología forense permite investigaciones más profundas y evidencia más sólida.

> ¿Quieres profundizar? Ver servicios de peritaje cloud.