Más de 9.300 claves de AWS activas siguen expuestas en Internet: cientos podrían permitir tomar el control total de las cuentas

Cuatro años de monitorización revelan miles de credenciales válidas

Un análisis de Truffle Security identificó más de 9.300 claves de acceso de AWS publicadas en Internet entre agosto de 2022 y agosto de 2026 que todavía seguían siendo válidas. El hallazgo se dio a conocer el 21 de agosto de 2026, tras cuatro años de monitorización.

El problema no se debe a una vulnerabilidad del software de AWS, sino a la publicación accidental de credenciales utilizables para autenticarse en cuentas cloud. Las claves aparecieron en repositorios de código, historiales de Git, datasets, imágenes de Docker, registros y logs generados por sistemas de integración continua.

En total, los investigadores encontraron 431.875 secretos de AWS. Tras eliminar los duplicados, la muestra quedó compuesta por 64.024 claves únicas asociadas a 50.654 cuentas de AWS.

El subconjunto analizado con credenciales completas, que podían verificarse mediante una nueva autenticación, incluía 10.616 claves. El 88 % seguía autenticándose correctamente a fecha del 10 de agosto. El dato indica que una parte considerable de las credenciales publicadas no había sido revocada ni sustituida.

Root y AdministratorAccess pueden convertir una filtración en una toma de control

Entre las claves que seguían activas, 817 estaban vinculadas a empresas. De ellas, 526 pertenecían a usuarios root de AWS, mientras que 242 estaban asociadas a usuarios de IAM con la política AdministratorAccess.

Ambas categorías concentran los privilegios más peligrosos. La identidad root representa el máximo nivel administrativo de la cuenta y no está limitada por los permisos que normalmente se aplican a los usuarios de IAM. Por su parte, AdministratorAccess permite crear, modificar, eliminar y consultar prácticamente todos los recursos y servicios de la cuenta.

Según los investigadores, 768 claves activas pertenecientes a estos dos grupos privilegiados permitían tomar el control total de la cuenta corporativa de AWS. Esto no significa que todas las claves fueran utilizadas por un atacante, sino que una credencial pública y funcional podía ofrecer un punto de entrada extremadamente amplio.

Con un acceso de este tipo, un intruso puede:

• leer, copiar o borrar datos almacenados en la nube;
• intervenir en servidores, aplicaciones, bases de datos y configuraciones;
• modificar recursos existentes o crear otros nuevos;
• generar cuentas administrativas fraudulentas para mantener el acceso;
• instalar software de minería y aumentar rápidamente los costes;
• alterar servicios y componentes de la infraestructura online.

Por tanto, el riesgo no se limita al robo de la clave. Un atacante puede utilizarla para modificar el entorno de AWS y dificultar la distinción entre una actividad maliciosa y las operaciones administrativas habituales.

Hugging Face es la principal fuente individual de las exposiciones

La plataforma de la que procede el mayor número de exposiciones es Hugging Face, utilizada para compartir modelos de inteligencia artificial, datasets y aplicaciones. Los investigadores asociaron a esta plataforma 8.482 exposiciones de claves únicas.

El 17,9 % correspondía a claves root. La presencia de credenciales de AWS en contenidos publicados en una plataforma dedicada a la inteligencia artificial puede deberse a código de ejemplo, notebooks, datasets, archivos de configuración o material incorporado durante el desarrollo.

Una clave publicada en un proyecto público debe considerarse comprometida incluso si el repositorio se convierte posteriormente en privado o se elimina el archivo que la contiene. Las copias pueden permanecer en el historial de Git, forks, cachés, datasets descargados o sistemas de indexación.

Las organizaciones afectadas pueden sufrir consecuencias distintas en función de los recursos presentes en sus cuentas: exposición de datos, interrupción de aplicaciones, alteración de la infraestructura o costes imprevisibles derivados de servicios creados de forma abusiva.

Las credenciales antiguas y la falta de controles de gasto agravan el riesgo

El análisis de antigüedad, disponible para 2.903 claves, reveló una antigüedad mediana de 1.831 días, aproximadamente cinco años. La clave más antigua llevaba existiendo 17,4 años.

Solo 398 elementos, el 13,7 %, tenían asociada una clave de acceso más reciente para el mismo usuario. Para Truffle Security, esto sugiere que muchas credenciales probablemente nunca se habían rotado.

Una clave activa durante años amplía el periodo en el que puede ser recopilada y reutilizada. Además, la mera existencia de una clave más reciente no demuestra automáticamente que la antigua haya sido revocada: la comprobación debe realizarse directamente en las configuraciones de la cuenta.

La gestión de costes agrava aún más la situación. Solo 262 de las 2.754 cuentas cuyo dato era legible tenían configurada una alerta de presupuesto. Sin avisos, un atacante puede crear recursos cloud o iniciar actividades intensivas sin que el propietario reciba rápidamente una señal anómala.

El contexto operativo sigue siendo difícil incluso cuando la organización dispone de herramientas de defensa. El Blue Report 2026, basado en 338 millones de simulaciones realizadas en entornos de producción de clientes, indica que cuando el atacante utiliza credenciales válidas solo se bloquea el 37 % de las acciones. Por tanto, una clave legítima puede superar numerosos controles diseñados para detectar accesos no autorizados.

Qué deben hacer los propietarios de cuentas de AWS

La prioridad es revocar cualquier clave que haya aparecido en una fuente pública y sustituirla por credenciales nuevas, sin limitarse a eliminar el archivo que la contiene. La rotación debe ir acompañada de una revisión de los logs para detectar autenticaciones o modificaciones sospechosas.

Las principales recomendaciones son:

1. eliminar las claves de acceso root;
2. inventariar las credenciales de IAM según su antigüedad y último uso;
3. revocar o rotar inmediatamente las que hayan quedado expuestas;
4. revisar usuarios, roles, políticas y cuentas administrativas creadas recientemente;
5. configurar alertas de presupuesto y límites de gasto;
6. buscar claves en repositorios, historiales de Git, imágenes de Docker, datasets y logs;
7. considerar comprometida cualquier credencial publicada, aunque no existan indicios de abuso.

Para la monitorización futura, es preferible utilizar roles de IAM y credenciales temporales, reduciendo la dependencia de claves estáticas. Los secretos no deben incluirse en el código ni en los datasets: deben almacenarse en sistemas específicos y someterse a análisis automatizados antes de su publicación.

Truffle Security afirma que limitó las pruebas a la lectura de metadatos y que avisó a todos los propietarios identificables. No se sabe cuántas cuentas fueron comprometidas realmente ni cuántos ataques aprovecharon las claves detectadas. Sin embargo, el dato confirmado basta para considerar no fiable cualquier credencial expuesta.