Solución — M16: CloudTrail y respuesta en la nube

1-2. Los tres eventos

$ jq '.Records[] | {eventTime, eventName, user: .userIdentity.userName, type: .userIdentity.type}' cloudtrail_export.json
{"eventTime":"2026-03-14T02:22:01Z","eventName":"GetObject","user":"backup-svc","type":"IAMUser"}
{"eventTime":"2026-03-14T02:24:37Z","eventName":"PutBucketPolicy","user":"backup-svc","type":"IAMUser"}
{"eventTime":"2026-03-14T02:26:48Z","eventName":"CreateAccessKey","user":"backup-svc","type":"IAMUser"}

Los tres eventos usan la misma identidad IAM, backup-svc — exactamente el mismo usuario que ya apareció comprometido en el caso Linux (módulo 7, auth.log/bash_history). El atacante reutilizó las credenciales de ese servicio para moverse a AWS.

3. El cambio de política del bucket

La nueva bucketPolicy añade un Statement con "Principal": "*" y "Action": "s3:GetObject" sobre todo el bucket (finanzas-internas/*) — convierte el bucket privado en público de lectura para cualquiera en Internet, no solo para el atacante. Es grave porque expone todo el contenido del bucket, no solo el fichero que ya había leído en el primer evento.

4. CreateAccessKey

Una CreateAccessKey genera un par de credenciales (accessKeyId + secreto, no visible en el log) nuevo y válido para la misma cuenta backup-svc. Esto le da al atacante acceso persistente independiente del método de entrada original — el equivalente exacto, en AWS, a la tarea programada del módulo 6 o la clave SSH del módulo 7: una puerta trasera que sobrevive aunque se cierre la vía de entrada inicial.

5. Misma IP, cuarta fuente independiente

203.0.113.44 en los tres eventos — la misma IP de Event Logs (módulo 6), memoria (módulo 9), tráfico de red (módulos 11-12) y, de forma indirecta, del cómplice interno (módulo 15). Cinco fuentes completamente distintas, todas apuntando a la misma infraestructura: la corroboración cruzada más sólida de todo el caso.

6. Contención inmediata

Según el módulo 17: desactivar inmediatamente la accessKeyId creada (AKIAEXAMPLE000000PERSIST), revertir la política del bucket a su estado anterior, y rotar las credenciales del propio usuario backup-svc — no basta con bloquear la IP de origen, porque la clave de acceso ya es válida desde cualquier IP del mundo.