Respuesta a incidentes en AWS: de clave filtrada a minería

Escenario ficticio. Todo lo que aparece en este artículo (la empresa, las personas, la cuenta 111122223333, las claves, el bucket) es inventado. Las direcciones IP proceden de los rangos reservados para documentación del RFC 5737. Son los datos que hay detrás del botón Probar con un ejemplo del analizador, así que puede reproducir cada paso.

En resumen. El 14 de septiembre de 2026 (ficticio), la clave de acceso del desarrollador dev-marco se utiliza desde un VPS con Kali Linux. En 48 minutos, el atacante valida la clave, enumera la cuenta, crea un usuario administrador backup-admin con su propia clave y contraseña de consola, elimina GuardDuty en dos regiones, descarga 320 objetos de acme-customer-exports y lanza ocho instancias GPU en ap-southeast-1 que minan para un pool. Los registros lo muestran todo. El veredicto es Indicios de compromiso, y la lista de remediación debe cubrir dos claves, un usuario, una política, dos detectores, ocho instancias y una evaluación de las obligaciones de notificación.

Las evidencias

El ZIP de ejemplo reproduce exportaciones reales:

Cuatro días tranquilos (del 10 al 13 de septiembre) sirven de línea base: ops-julia inicia sesión en la consola con MFA desde la dirección de la oficina 198.51.100.24; dev-marco usa la CLI con su clave de larga duración desde esa misma dirección; un rol de tarea de ECS se asume a diario.

Cronología (UTC, 14 de septiembre de 2026)

El informe de credenciales añade un hallazgo de configuración: backup-admin tiene contraseña de consola y no tiene MFA.

Cómo avanza la investigación

1. El veredicto. Veintitrés hallazgos, varios de ellos de gravedad alta y con señales propias de un atacante (anomalía de acceso, evasión de defensas, exfiltración, impacto): el veredicto es Indicios de compromiso. Los motivos principales que se enumeran son el agente de usuario ofensivo, la clave usada desde una IP nueva, la política de administrador, la clave creada para otro usuario y las dos eliminaciones de GuardDuty.

2. El punto de entrada. Pivote sobre AKIA3EXAMPLEMARCO123 en la pestaña Entidades: cuatro días desde 198.51.100.24 con una CLI de macOS y, a partir de las 09:02, 203.0.113.77 con una cadena de compilación de Kali. La primera llamada desde la nueva dirección es GetCallerIdentity: la apertura de manual de una clave de acceso filtrada. Cómo se filtró la clave (el escenario habla de un repositorio público) queda fuera de los registros de AWS.

3. La segunda clave. Pivote sobre 203.0.113.77: además de la clave de dev-marco, esa dirección utilizó AKIA3EXAMPLEBKUP4567, la clave generada a las 09:09:05 para backup-admin. A partir de las 09:12, el atacante no vuelve a usar la clave filtrada. Desactivar solo la clave de dev-marco no habría cambiado nada. Es el patrón de persistencia en IAM en su forma más simple.

4. Evasión de defensas. Ambos detectores se eliminan en menos de un minuto, tres minutos después de que exista la puerta trasera. CloudTrail sigue funcionando (no hay StopLogging), y por eso el resto de la historia es visible. Los hallazgos de GuardDuty solo sobreviven porque se habían exportado; consulte el artículo sobre evasión de defensas.

5. Los datos. 320 GetObject en 21 minutos por un único principal sobre un único bucket, vistos dos veces: en los eventos de datos de CloudTrail y en los registros de acceso al servidor. Las claves de los objetos (de exports/2026/customers/customers-0001.csv.gz a -0320) constituyen el inventario de divulgación. Observe que los VPC Flow Logs no muestran nada aquí: la descarga fue de S3 al host del atacante a través de internet, sin pasar nunca por la VPC, exactamente el límite que se describe en evidencias de exfiltración de datos en S3.

6. El coste. Una región sin actividad durante la línea base, un aumento de cuota, un par de claves, SSH abierto a todo el mundo y ocho instancias GPU; desde las 09:52, sus interfaces se comunican cada minuto con una misma dirección en puertos de pools. El artículo sobre minería de criptomonedas cubre esta fase.

7. La sesión de consola. A las 09:50, el atacante inicia sesión como backup-admin sin MFA. Todo lo que hiciera en la consola a partir de ese momento aparecería con sessionCredentialFromConsole; en este conjunto de datos, la sesión cierra la historia.

La lista de remediación resultante

Primero la contención, con los valores extraídos de los registros:

1. Desactive AKIA3EXAMPLEMARCO123 y AKIA3EXAMPLEBKUP4567; sustituya la clave de dev-marco y elimínela del repositorio.
2. Guarde y después elimine backup-admin (política, clave, perfil de inicio de sesión).
3. Desasocie AdministratorAccess de backup-admin y revise quién más la tiene.
4. Deniegue las llamadas a la API desde 203.0.113.77 mientras investiga.
5. Cree una instantánea de una instancia, termine las ocho de ap-southeast-1 y revise todas las demás regiones; elimine el par de claves ops-maint y el grupo de seguridad abierto; retire la solicitud de cuota L-417A185B.
6. Vuelva a activar GuardDuty en us-east-1 y eu-west-1 (idealmente, en todas las regiones).
7. Trate acme-customer-exports como exfiltrado: enumere los 320 objetos y evalúe las obligaciones de notificación.
8. Abra un caso en AWS Support sobre el uso no autorizado.

Lo que este ejemplo no muestra

Los incidentes reales son más desordenados: roles de CI ruidosos, varias IP del atacante, encadenamiento de roles, actividad repartida a lo largo de semanas, registros que faltan justo donde los necesita. El ejemplo es deliberadamente limpio para que el método se vea con claridad. Lea los límites de una investigación basada solo en registros antes de aplicar la misma confianza a datos reales, y siga la guía paso a paso de análisis de logs de CloudTrail para el flujo de trabajo.