Una investigación sobre credenciales de Amazon Web Services expuestas públicamente encontró 768 claves empresariales todavía activas con control total sobre sus cuentas. La cifra reúne 526 credenciales root y 242 usuarios IAM con la política AdministratorAccess. El problema central no es solo que el secreto apareciera en internet, sino que siguiera siendo válido.

Truffle Security volvió a verificar el 10 de agosto de 2026 una muestra de 10.616 pares de claves que habían aparecido en fuentes públicas entre 2022 y 2026. El 88 % —9.308 credenciales— aún podía autenticarse. El hallazgo muestra cómo un secreto olvidado en el historial de Git, una imagen de contenedor, un conjunto de datos o un registro de integración continua puede conservar acceso durante años.

Para organizaciones que operan en España y Colombia, la lección es directa: encontrar y borrar una cadena de caracteres no equivale a contener un incidente. La respuesta debe revocar la capacidad, comprender sus permisos, revisar el uso histórico y reemplazar el diseño que permitió una credencial permanente y excesiva.

Qué encontró la investigación

Truffle Security consolidó 431.875 hallazgos públicos en 64.024 pares únicos de claves AWS asociados con 50.654 cuentas. Las fuentes incluían historiales de repositorios, conjuntos de datos de Hugging Face, imágenes Docker, registros de paquetes y logs de CI. Para evitar duplicados y medir vigencia, los investigadores tomaron 10.616 pares completos y realizaron llamadas de metadatos de solo lectura.

Entre las 9.308 claves aún activas identificaron 817 vinculadas con empresas. De estas, 768 permitían control total: las credenciales root no pueden limitarse mediante políticas IAM, mientras que AdministratorAccess concede una amplitud equivalente sobre recursos y servicios de la cuenta. La investigación también encontró 130 claves root activas en cuentas de administración de AWS Organizations, desde las que podría alcanzarse una estructura completa de cuentas miembro.

La antigüedad agrava el escenario. Para las 2.903 claves cuya fecha pudo enumerarse, la mediana era de 1.831 días, aproximadamente cinco años. Solo el 13,7 % tenía una clave más nueva asociada al mismo usuario. Estas cifras describen la muestra analizada, no todas las cuentas AWS del mundo, y las tasas de privilegio pueden estar condicionadas por qué permisos permitían consultar metadatos.

Por qué borrar el archivo no basta

Un secreto publicado se replica. Puede permanecer en commits anteriores, forks, cachés, artefactos de compilación, capas de contenedor, paquetes, datasets o copias descargadas. Reescribir el archivo visible reduce una exposición futura, pero no invalida las copias que ya existen.

La contención real ocurre en el proveedor: desactivar o eliminar la clave y revocar las sesiones relacionadas. Después hay que determinar qué identidad representaba, qué políticas tenía, qué roles podía asumir y qué recursos pudo consultar o modificar. Una credencial de bajo privilegio sobre un entorno de pruebas no tiene la misma prioridad que una clave root de producción, pero ambas requieren una decisión documentada.

AWS recomienda no crear claves de acceso para el usuario root y utilizar credenciales temporales mediante roles cuando sea posible. Su documentación de seguridad de claves también advierte que las credenciales de larga duración permanecen válidas hasta su revocación manual.

Cómo priorizar una clave expuesta

La prioridad debe combinar vigencia, privilegio, alcance y evidencia de uso. Un proceso práctico puede ordenar cada hallazgo con estas preguntas:

  • ¿La clave sigue activa? No se debe probar una credencial ajena. En cuentas propias, la verificación debe realizarse mediante inventarios y servicios autorizados.
  • ¿Pertenece a root, un usuario IAM o una automatización? Root y administradores requieren la respuesta más urgente.
  • ¿Qué políticas y rutas de confianza existen? Una clave aparentemente limitada puede asumir un rol más privilegiado o leer secretos que abren otra ruta.
  • ¿Dónde apareció? Repositorio público, historial privado, imagen de contenedor, paquete, log, ticket, wiki o dataset determinan el posible alcance de replicación.
  • ¿Qué actividad registra CloudTrail? Inicios de sesión, creación de recursos, cambios IAM, acceso a datos, nuevas claves y desactivación de controles ayudan a estimar impacto.

Un Security GAP Assessment permite relacionar estas preguntas con propietarios, entornos y procesos de desarrollo. El objetivo no es producir una lista extensa de secretos, sino separar los que requieren contención inmediata de las mejoras estructurales.

Respuesta durante las primeras 24 horas

  1. Preservar contexto antes de revocar. Registrar ID de la clave, identidad, políticas, última utilización, repositorio o artefacto de origen y responsables. Nunca copiar el secreto completo a un ticket.
  2. Desactivar la credencial. La desactivación corta nuevas solicitudes y permite una transición controlada. Si el riesgo es alto o existe uso malicioso, eliminarla y emitir nuevas credenciales desde un entorno confiable.
  3. Revisar actividad y persistencia. Analizar CloudTrail, IAM, recursos de cómputo, funciones, buckets, almacenes de secretos, facturación y cambios en la organización. Buscar usuarios, roles o claves creados por el atacante.
  4. Rotar secretos alcanzables. Si la identidad podía leer otros secretos, bases de datos o tokens de terceros, tratarlos como potencialmente expuestos aunque no aparezcan en el hallazgo original.
  5. Restaurar la carga con menor privilegio. Sustituir claves permanentes por roles, identidad federada u OIDC en CI/CD. La aplicación debe recuperar solo los permisos y recursos que necesita.

En caso de acceso no autorizado, el trabajo puede requerir análisis forense digital de logs, artefactos y cambios en múltiples cuentas. Rotar sin revisar actividad puede cerrar una puerta mientras persiste otra identidad creada durante el acceso.

Del inventario al modelo preventivo

La prevención empieza por reducir la cantidad de secretos permanentes. Las cargas en AWS pueden usar roles; los pipelines modernos pueden federarse mediante OIDC; las personas pueden acceder con IAM Identity Center y autenticación multifactor. Un secreto que no existe no puede filtrarse en un commit.

Para las excepciones es necesario un inventario con propietario, finalidad, permisos, ubicación autorizada, fecha de creación, última utilización y fecha de retiro. El escaneo debe cubrir repositorios y su historial, imágenes antes de publicarlas, paquetes, registros de CI/CD y fuentes de datos utilizadas en proyectos de inteligencia artificial.

La gobernanza debe incluir protección de ramas, revisiones de código, detección previa al commit, bloqueo en el pipeline y una ruta de respuesta automática. Un modelo de CISO as a Service puede coordinar esas obligaciones entre desarrollo, plataforma, seguridad, finanzas y proveedores, evitando que la rotación dependa de una persona que recuerda una clave antigua.

Lectura para España y Colombia

La investigación no publica nombres de empresas ni confirma que las 768 cuentas pertenezcan a organizaciones españolas o colombianas. La relevancia para ambos mercados se deriva del patrón técnico: equipos distribuidos, software tercerizado, pipelines compartidos y adopción de servicios cloud aumentan las rutas por las que una credencial puede terminar fuera del almacén autorizado.

La gestión debe abarcar también proveedores. Un desarrollo externo puede desplegar sobre la cuenta del cliente, conservar claves en su CI o transferir imágenes con capas antiguas. Los contratos y accesos deben definir dónde se almacenan secretos, quién responde ante una filtración, cuánto tiempo se conservan logs y cómo se revoca el acceso al terminar el servicio.

El indicador más útil no es cuántas alertas genera el escáner, sino cuánto tarda la organización desde el hallazgo hasta la revocación, la estimación de impacto y la sustitución por un mecanismo de menor riesgo.

Convierta las claves expuestas en una mejora verificable

Insylux puede ayudar a identificar rutas críticas de acceso cloud, priorizar privilegios, revisar evidencia y construir un plan para sustituir secretos permanentes por identidades controladas.

Solicite una revisión de credenciales, privilegios y accesos cloud.

Fuentes y alcance

Las cifras corresponden al conjunto de datos y al método de Truffle Security. La priorización y la aplicación a empresas de España y Colombia son análisis editorial del Equipo Insylux. No se publican ni reproducen credenciales, cuentas o identidades afectadas.