Clave AWS comprometida: guía de respuesta 2026

Si estás leyendo esto, probablemente algo ya te hizo ruido: un alerta en la consola, un pico de facturación, una llamada del equipo de seguridad o ese presentimiento que te dice que una clave AWS comprometida anda dando vueltas. Tranquilo, no es el fin del mundo, pero necesitás actuar con precisión y sin perder un minuto. En esta guía te cuento paso a paso cómo responder ante una clave aws comprometida en 2026, con el foco puesto en identificar el alcance, cazar recursos maliciosos, rotar la clave y dejar todo blindado mediante auditorías de IAM y CloudTrail. Todo explicado en argentino y con el voseo que nos sale natural.

1. ¿Qué significa realmente una clave AWS comprometida?

Cuando hablamos de una clave aws comprometida nos referimos a un Access Key ID y su Secret Access Key que cayeron en manos no autorizadas. Puede haber pasado porque las subiste sin querer a un repo público de GitHub, las dejaste hardcodeadas en una imagen Docker, te cayó un phishing, un empleado ex filtró las credenciales o simplemente porque un script interno quedó expuesto. En 2026 los atacantes son más rápidos que nunca: en cuestión de segundos automatizan la enumeración de recursos, despliegan instancias de crypto mining, extraen datos de S3 o escalan privilegios usando roles asumidos. Por eso, la respuesta tiene que ser inmediata y metódica.

La buena noticia es que AWS te da todas las herramientas para frenar el sangrado y reconstruir lo ocurrido. Pero necesitás entender que el impacto no termina con revocar la clave; tenés que asegurarte de que no queden puertas traseras, usuarios nuevos o recursos minando cripto en alguna región exótica.

2. Identificá el alcance: ¿hasta dónde llegó el compromiso?

Antes de rotar nada, primero tenés que saber qué se vio afectado. Averiguá qué usuario o rol usa esa clave. Si estás usando IAM, podés ir a la consola, buscar el Access Key ID y ver a quién pertenece. Desde la CLI usá aws iam get-access-key-info --access-key-id AKIA... para obtener el nombre de usuario. Con eso en mano, revisá todas las políticas asociadas —tanto las inline como las administradas— y chequeá cuán amplios son los permisos. Si la clave pertenece a un rol de IAM (algo típico en entornos serverless), identificá quién puede asumirlo y desde qué principales.

Una vez que sabés quién es el dueño de la clave aws comprometida, fijate cuándo fue la última vez que se usó legítimamente. Esto es clave: compará actividad normal contra movimientos sospechosos. Andá a CloudTrail y filtrá por userIdentity.accessKeyId con el ID comprometido. Mirá las acciones, las IPs origen, los User-Agents y los servicios invocados. Prestá atención a llamadas como CreateUser, CreateAccessKey, AssumeRole, RunInstances, PutBucketPolicy o cualquier cosa que no cuadre con el comportamiento esperado de esa credencial.

Si la clave tenía permisos de administrador, asumí el peor escenario: posible creación de cuentas de IAM nuevas, claves adicionales y roles de confianza cruzada que podrían dar acceso a otras cuentas. Revisá IAM Credential Report y la consola de Access Advisor para ver qué servicios se utilizaron efectivamente. Así delimitás el perímetro del incidente.

3. Buscá recursos maliciosos como un cazador

Los atacantes no pierden tiempo. En 2026 los scripts automáticos despliegan recursos en regiones que muchas empresas ni siquiera tienen habilitadas. Por eso, tenés que hacer un barrido exhaustivo. Recorré cada región con la CLI usando aws ec2 describe-regions y preguntá por instancias EC2, volúmenes, snapshots, Lambdas, clústers de ECS, bases de datos RDS, funciones de SageMaker y notebooks, y especialmente servicios de cómputo que consumen muchos créditos.

Un tip: usá AWS Resource Explorer (ya maduro en 2026) para buscar recursos por etiqueta, tipo o región de forma centralizada. También podés ejecutar un script simple con la CLI que itere sobre todas las regiones enlistando instancias y otros recursos comunes. Prestá atención a tipos de instancia caros como las p4d o g5 que se usan para minería. No te olvides de revisar servicios serverless: un atacante podría haber creado una función Lambda que extraiga datos de S3 o que invoque endpoints externos.

Si encontrás algo que no debería estar ahí, no lo termines de inmediato sin antes tomar evidencia. Sacale capturas, guardá los metadatos, anotá IDs y volcá la configuración con comandos describe. Después sí, dale de baja (terminate/delete). Si la carga de trabajo es productiva y no podés apagar todo, aislá los recursos mediante grupos de seguridad bien restrictivos mientras analizás.

4. Rotá la clave comprometida y todo lo que tocó

Llegó el momento de cortar el acceso. Desactivá la clave aws comprometida de inmediato desde IAM. En la consola, seleccioná el usuario, andá a la pestaña “Security credentials” y hacé clic en “Make inactive” sobre la clave afectada. Por CLI, ejecutá aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name nombre-usuario. Después, si estás seguro de que no se necesita más, podés eliminarla directamente.

Pero rotar no es solo desactivar. Implica generar una nueva clave (si todavía necesitás claves estáticas, aunque en 2026 deberías estar migrando a roles y proveedores de identidad) y distribuirla de forma segura. Si la credencial estaba asociada a una aplicación, actualizá las variables de entorno y los secretos en tu gestor (AWS Secrets Manager, Parameter Store). Rotá también cualquier otra credencial que compartiera el mismo nivel de acceso, por ejemplo, claves de usuarios que tuvieran políticas similares o roles que el atacante pudo haber asumido.

Aprovechá el incidente para eliminar claves estáticas de larga duración en favor de soluciones temporales. Integrá AWS IAM Identity Center (heredero de SSO) o usá roles asumibles mediante OIDC para CI/CD. Si la clave estaba en un repositorio, limpiá el historial de git con BFG o git filter-repo, e invalidá todas las sesiones abiertas.

5. Auditoría de IAM: cerrá las puertas que dejó el ataque

Una clave aws comprometida es síntoma de que algo falló en la gestión de accesos. Después de la contención, tenés que hacer una auditoría profunda de IAM. Revisá usuario por usuario, especialmente aquellos creados recientemente. Buscá políticas con iam:CreateUser, iam:CreateAccessKey, iam:PutUserPolicy que no estén justificadas. Eliminá todo lo que el atacante haya creado: usuarios extra, claves nuevas, roles de confianza maliciosos.

Fijate si se modificaron políticas de bucket S3 o de KMS para volver públicos los datos. Verificá roles que tengan sts:AssumeRole con principales externos o cuentas desconocidas. Usá IAM Access Analyzer para identificar recursos compartidos externamente y archivá los hallazgos.

Implementá de una vez el principio de mínimo privilegio. Ajustá las políticas usando los datos de Access Advisor: si un usuario no ha usado un servicio en los últimos 90 días, quitale el permiso. Aplicá políticas condicionales (Condition) que limiten rangos de IP, tags obligatorios o MFA. Si todavía no lo hiciste, exigí MFA para todos los usuarios IAM, sin excepciones.

6. Análisis forense con CloudTrail y más allá

CloudTrail es tu mejor aliado para entender qué pasó. Activá el logging en todas las regiones y asegurate de que los logs se manden a un bucket S3 separado, idealmente en una cuenta de archivado, con control de acceso estricto y sin posibilidad de modificación (habilitá S3 Object Lock y versionado). Filtra eventos por el accessKeyId comprometido durante el período sospechoso. Herramientas como Athena sobre los logs de CloudTrail te permiten consultarlos con SQL, lo que es un golazo para detectar patrones.

Buscá eventos de ConsoleLogin que indiquen que el atacante pudo haber creado un usuario con acceso a la consola, o CreateVirtualMFADevice para atar su propio MFA. Prestá atención a llamadas GetCallerIdentity tempranas; suelen ser las primeras que ejecuta un script para validar la clave. Si ves mucho DescribeRegions, DescribeInstances o GetServiceQuota en rápida sucesión, es enumeración automatizada.

Completá el análisis con VPC Flow Logs y registros de DNS (Route53 Resolver Query Logs) si tenés la sospecha de exfiltración de datos. Si usás GuardDuty, ya debería haberte alertado: revisá los hallazgos de tipo UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration o CryptoCurrency:EC2/BitcoinTool.B. Guardá toda la evidencia para post-mortem y posibles acciones legales.

7. Blindaje de cara a 2026: prevención proactiva

Después de apagar el incendio es cuando realmente tenés que fortalecer el castillo. Mové tus cargas de trabajo a un modelo donde las claves estáticas sean la excepción y no la regla. Adoptá roles de IAM con tokens de sesión temporales vía STS, integraciones con proveedores OIDC para GitHub Actions, GitLab CI/CD y demás. Automatizá la rotación con AWS Secrets Manager, que puede rotar claves cada N días sin que muevas un dedo.

Configurá alertas en tiempo real: métricas de CloudWatch basadas en eventos de CloudTrail, reglas de EventBridge que detecten creación de usuarios o cambios en políticas, y notificaciones a Slack o PagerDuty. Mantené habilitado AWS Config para registrar cambios en la configuración de IAM y poder volver atrás. Usá Service Control Policies (SCPs) en organizaciones para prohibir acciones peligrosas a nivel raíz, como desactivar CloudTrail o modificar presupuestos.

No subestimes la capacitación: todo el equipo tiene que saber que una clave aws comprometida puede salir de un descuido mínimo. Incorporá hooks de pre-commit como git-secrets o trufflehog en los repos y revisá periódicamente los escaneos de credenciales expuestas.