768 claves AWS filtradas siguen activas: cómo protegerte
En pocas palabras: Truffle Security re-verificó 10.616 claves AWS filtradas en repositorios públicos como Hugging Face: 768 conservan permisos de administrador o root totales, el 88% sigue operativa ante llamadas de la API y solo el 13,7% registra algún intento de rotación.
Una auditoría de Truffle Security confirmó que 768 claves AWS filtradas siguen activas con permisos de administrador o root totales. El equipo re-verificó 10.616 credenciales de un universo de 431.875 expuestas: el 88% respondió a llamadas de la API y apenas el 13,7% registró algún intento de rotación.
Las claves de acceso de AWS son pares de credenciales formados por un access key ID y una secret access key con los que scripts, aplicaciones y pipelines autentican llamadas a la API de Amazon Web Services. Cuando esas credenciales quedan públicas en repositorios, imágenes o datasets, cualquiera puede usarlas: según el relevamiento de Truffle Security, 768 de las claves filtradas conservan control completo sobre sus cuentas corporativas.
En 30 segundos
- 88% de la muestra sigue viva: de 10.616 claves re-verificadas con llamadas de solo lectura a la API, el 88% seguía operativa.
- 768 con poder absoluto: esa cantidad otorga permisos de admin o root sobre cuentas corporativas; 526 son claves root, la categoría más grave.
- Rotación casi nula: solo el 13,7% de las credenciales filtradas pasó por una rotación después de quedar expuesta.
- Cinco años de ventana: la mediana de vida de una clave filtrada antes de ser descubierta ronda los 5 años.
- Hugging Face encabeza las fugas: superó a GitHub como mayor origen de claves expuestas, junto con imágenes Docker y logs de CI/CD.
¿Qué es una clave de acceso de AWS y qué la hace tan peligrosa?
Una clave de acceso de AWS es el par de valores (access key ID y secret access key) con el que cualquier cliente se identifica ante la API del servicio. Lo peligroso depende del dueño: una clave root es la identidad máxima de la cuenta, sin límites de permisos, mientras que una clave de usuario IAM solo alcanza lo que su política autorice.
¿Por qué importa esa diferencia? Porque con una clave root el atacante crea y borra usuarios, cambia métodos de pago, elimina backups y hasta cierra la cuenta completa. Con una clave IAM mal configurada también se hacen estragos, pero al menos hay un techo. Por eso la regla de oro es no usar root en código jamás y mantenerla bajo MFA para emergencias.
Esta tabla ordena los tipos de credencial y su exposición al riesgo:
| Tipo de credencial | Alcance real | Riesgo si se filtra | Recomendación |
|---|---|---|---|
| Clave root | Control total: usuarios, facturación, borrado de recursos y de la cuenta | Máximo | Nunca en código; bajo MFA y sin uso diario |
| Usuario IAM con AdministratorAccess | Todos los servicios de la cuenta | Máximo | Evitarla; repartir permisos mínimos entre roles |
| Usuario IAM acotado | Solo los servicios definidos en su política | Medio | Última opción si no hay rol disponible |
| Rol IAM / credenciales temporales | Permisos limitados con vencimiento automático | Bajo | Opción por defecto para EC2, Lambda y pipelines |
Ahora entendés por qué las 526 claves root del estudio dan escalofríos. Una sola de esas llaves no abre una aplicación: abre todo. Complementá con cómo evitar caídas por mala configuración.
¿Quién descubrió las claves AWS filtradas y qué midió el estudio?
Lo midió Truffle Security, el equipo detrás del escáner open source TruffleHog, en una investigación que acumula cuatro años de trabajo y cuyos resultados se dieron a conocer en agosto de 2026. El universo analizado suma 431.875 credenciales AWS expuestas, recogidas de repositorios de GitHub, imágenes Docker, logs de pipelines de CI/CD y datasets públicos de Hugging Face. De ahí tomaron una muestra de 10.616 claves y las re-verificaron con llamadas de API de solo lectura, un método seguro porque consulta solo la identidad, sin tocar recursos.
Los resultados explican el título. El 88% de la muestra seguía activa, 768 claves otorgan acceso de administrador o root, 526 son claves root y la mediana de vida de una clave filtrada antes de su detección ronda los cinco años. Solo el 13,7% recibió rotación alguna vez. ¿Algún tercero independiente validó estos números? Todavía no, así que tomalos como el mejor termómetro disponible, no como dogma.
¿Cómo llegan las claves de AWS a GitHub, Docker y Hugging Face?
Vía de entrada número uno: el commit accidental. Ponele que un martes a la noche subís un fix urgente y el .env con tus credenciales viaja dentro del commit. Al día siguiente lo borrás, pusheás y respirás aliviado. Spoiler: la clave sigue viva, guardada en la historia del repositorio, a un simple git clone de distancia de cualquiera.
Borrar un archivo del branch actual no destruye nada de los commits anteriores, así que el secreto queda disponible para quien clone el proyecto y recorra el historial. Y la cosa se multiplica: la credencial aparece en un commit, alguien hace fork del repo, otro copia ese script dentro de una imagen Docker, la imagen termina publicada en un registro, un notebook la referencia y el dataset resultante se comparte en Hugging Face, de modo que cuando por fin encontrás el origen, tu clave ya vive en media docena de lugares distintos. Tema relacionado: dónde guardan los secrets los pipelines.
Ojo: eliminar el archivo no revoca nada.
Las imágenes Docker suman su propio problema, porque cada capa conserva lo que las capas previas escribieron y un RUN que imprimió variables de entorno deja huella aunque la capa final esté limpia. Los logs de CI/CD hacen lo suyo cuando un pipeline vuelca el entorno completo en su salida visible. Y en Hugging Face, el volumen explica el primer puesto: los equipos de machine learning comparten datasets, notebooks y salidas de entrenamiento con credenciales incrustadas, y nadie revisa ese mar de archivos antes de publicarlo.
¿Por qué nadie rotó las claves AWS comprometidas?
La respuesta corta: casi ninguna empresa sabía que su clave estaba afuera. Sin visibilidad sobre el historial de Git, las capas de Docker o los datasets públicos, la exposición resulta invisible para el dueño de la credencial. El informe no nombra a las compañías afectadas (nadie quiere ese cartel), pero habla de cuentas corporativas, y el dato de “sigue activa” viene de llamadas reales a la API, no de una suposición.
A eso se le suma el clásico “seguridad por oscuridad”: uno asume que nadie va a encontrar su clave entre millones de repositorios. Mal cálculo, porque los escáners automáticos barren todo en minutos y no necesitan suerte, necesitan volumen. Está también el costo operativo: rotar implica coordinar equipos, tocar producción y aceptar que algo se pueda romper, así que la tarea queda postergada sine die. ¿El resultado? Mediana de cinco años activas, según los datos de Truffle Security.
¿Cómo verificar si tus credenciales AWS están expuestas?
Tres comandos de AWS CLI te dan el diagnóstico inicial: qué claves existen, qué identidad ejecuta la sesión y hasta dónde llegan sus permisos. Son de solo lectura, así que podés correrlos sin miedo en cualquier cuenta. Lo explicamos a fondo en qué herramienta protege mejor tus credenciales.
aws iam list-access-keys: lista las claves activas del usuario IAM consultado.aws sts get-caller-identity: confirma qué identidad está detrás de la sesión actual.aws iam list-attached-user-policies: muestra las políticas adjuntas y, con ellas, el tamaño del desastre potencial.
Después viene la búsqueda activa. Corré TruffleHog, el escáner open source del equipo que firmó el estudio, contra el historial completo de tus repositorios, tus imágenes Docker y los artefactos que hayan compartido tus pipelines. Completá con una pasada por CloudTrail buscando llamadas desde IPs o regiones que no reconozcas, y activá el secret scanning nativo de GitHub o GitLab con protección en el push, que bloquea commits con secretos antes de que salgan. ¿Encontraste una clave ajena en algún lado? Reportala por divulgación responsable al dueño y por los canales de abuso de la plataforma, pero no la uses para probar nada: eso ya es acceso no autorizado.
¿Cómo rotar una clave de AWS comprometida sin romper producción?
El orden correcto es crear primero, migrar después y eliminar al final; invertir ese orden es la receta para dejar apps caídas. AWS permite dos claves activas por usuario IAM para que la nueva conviva con la vieja durante la transición.
- Creá la clave nueva sin eliminar la vieja. Conviven ambas mientras preparás la migración.
- Actualizá todos los consumidores: aplicaciones, scripts, variables de entorno, funciones serverless y pipelines de CI/CD que usaban la credencial anterior.
- Validá con logs. Revisá CloudTrail hasta confirmar que el tráfico corre con la clave nueva y que nadie sigue llamando con la vieja.
- Desactivá la clave antigua y esperá un ciclo completo de deploys; si nada se rompe, procedé a la eliminación definitiva.
Si la clave ya apareció en público, el calendario cambia: esto es respuesta a incidente y se hace ese mismo día. Aprovechá para revisar en CloudTrail qué hizo la credencial mientras estuvo expuesta, porque dimensionar el daño forma parte de la remediación. El informe completo de Xpert4cyber incluye un checklist paso a paso si querés seguir la guía original.
Claves estáticas o roles IAM: ¿qué conviene para no repetir esta historia?
Si podés evitar credenciales de largo plazo, evitalas. Los roles IAM entregan credenciales temporales que vencen solas: EC2 y Lambda asumen roles sin que exista ningún secreto guardado, y los pipelines de CI pueden federarse vía OIDC para recibir permisos puntuales sin almacenar nada sensible. Si persisten menos secretos, tenés menos material para filtrar.
Donde la clave estática sea inevitable, aplicá mínimo privilegio, rotación periódica automatizada y un gestor tipo Secrets Manager en lugar de hardcodear valores. Sumá monitoreo continuo con herramientas como GitGuardian o los escaneos nativos de tu plataforma Git. Ahora, ojo con una cosa: si tu carga es una web corporativa o un e-commerce clásico, quizás no necesites credenciales programáticas para nada, y un hosting administrado como donweb.com te ahorra toda esta superficie de riesgo de arranque.
Los errores más comunes con credenciales AWS
Estos cuatro patrones explican la mayoría de las fugas que uno ve al revisar entornos ajenos:
- Creer que borrar el commit borra la clave. La historia de Git conserva todo; si el repo fue público aunque fuera minutos, tratá la credencial como comprometida y rotála.
- Escanear solo el código vigente. El estudio encontró claves vivas en capas viejas de imágenes y datasets; el escaneo serio cubre historial completo, imágenes y logs, no el último estado del repo.
- Operar a diario con la cuenta root. Cada script con clave root es una amenaza latente; creá usuarios y roles con permisos mínimos y reservá la root para emergencias, bajo MFA.
- Postergar la rotación para después. Con claves promediando cinco años activas, ese después lo define el atacante; fijá plazos automáticos y cumplilos.
Preguntas Frecuentes
¿Qué pasó con las 768 claves AWS filtradas?
Siguen activas con permisos de administrador o root sobre sus cuentas corporativas, según el relevamiento de Truffle Security. De ese grupo, 526 son claves root, el tipo más peligroso de AWS, y solo el 13,7% de las credenciales analizadas recibió alguna rotación. Cubrimos ese tema en detalle en si además gestionás proyectos multilingües.
¿Cómo sé si una de mis claves AWS quedó expuesta?
Arrancá con aws iam list-access-keys, aws sts get-caller-identity y aws iam list-attached-user-policies para mapear claves, identidad y permisos. Después escaneá el historial de tus repositorios con TruffleHog y buscá en CloudTrail accesos desde IPs desconocidas.
¿Por qué Hugging Face fue la mayor fuente de claves AWS filtradas?
Porque los equipos de machine learning comparten un volumen enorme de datasets, notebooks y logs, y ese caudal superó al de GitHub como origen de credenciales expuestas. Esos archivos suelen arrastrar claves incrustadas y casi nadie audita un dataset antes de descargarlo.
¿Cuánto tiempo pueden estar activas las claves AWS comprometidas?
Todo el tiempo que nadie las rote: la mediana del estudio marca unos cinco años de vida antes de su detección. AWS no vence las claves de acceso de forma automática, de modo que la única fuerza que las mata es una rotación manual o programada.
¿Cómo se rota correctamente una clave AWS comprometida?
Creá la clave nueva manteniendo la vieja activa, actualizá aplicaciones y pipelines, validá en CloudTrail que todo usa la credencial nueva y recién entonces desactivá y eliminá la anterior. Si la clave ya circuló en público, ejecutá el proceso el mismo día como respuesta a incidente.
Conclusión
El número que debería doler no es 768 sino 13,7%: la rotación casi no existe incluso después de la exposición. Truffle Security aportó la foto más completa hasta ahora de un problema crónico, con 88% de claves filtradas aún activas y medianas de cinco años de vida. Es un problema de higiene de credenciales que la mayoría de las organizaciones no practica.
Tu plan de acción cabe en una tarde: corré los tres comandos de diagnóstico, pasá TruffleHog por tu historial, rotá todo lo sospechoso y migrá cargas a roles IAM donde puedas. Que Hugging Face haya desbancado a GitHub no me sorprende; cuando sube el volumen de material compartido, viaja más basura con él. La buena noticia es que acá no esperás parche de ningún fabricante: las decisiones que cierran la puerta son todas tuyas.
