Amazon Web Services (AWS) es capaz de pasar de la detección a la contención en cuestión de segundos cuando una clave de acceso de Identity and Access Management (IAM) se publica en un repositorio público de GitHub. En una prueba de exposición controlada realizada por Unit 42, AWS aplicó su política gestionada AWSCompromisedKeyQuarantineV3 al usuario afectado tan solo 10 segundos después de que los investigadores publicaran la credencial, reduciendo drásticamente la ventana de riesgo.

Amazon Web Services puede pasar de la detección a la contención en cuestión de segundos cuando una clave de acceso de Identity and Access Management (IAM) aparece en un repositorio público de GitHub.

En una prueba de exposición controlada de Unit 42, AWS adjuntó su política gestionada AWSCompromisedKeyQuarantineV3 al usuario de IAM afectado solo 10 segundos después de que los investigadores publicaran la credencial, reduciendo drásticamente la ventana disponible para el abuso.

Las claves de acceso IAM a largo plazo siguen siendo vectores de acceso inicial atractivos porque pueden proporcionar acceso programático sin autenticación interactiva. Es posible que los desarrolladores las incluyan accidentalmente en el código fuente, archivos de configuración o archivos de entorno accesibles públicamente.

• https://unit42.paloaltonetworks.com/detecting-exposed-aws-iam-credentials/

El escaneo de secretos de GitHub busca patrones de credenciales reconocidos en repositorios públicos y otras superficies abiertas; a través de su integración de socios, informa de los secretos de AWS detectados directamente a AWS para que el proveedor pueda responder.

AWS pone automáticamente en cuarentena las claves IAM expuestas

Según la investigación publicada por Unit 42, la prueba del 19 de diciembre de 2025 ofrece una visión precisa de esa automatización. Los investigadores subieron una clave de acceso y un secreto a un repositorio público a las 18:50:05 UTC, después de que la protección de subida de GitHub advirtiera sobre ambos valores.

A las 18:50:15, CloudTrail registró un evento AttachUserPolicy que mostraba que AWSCompromisedKeyQuarantineV3 fue adjuntada a TestUser.

GitHub envió una alerta por correo electrónico un segundo después, AWS Health mostró un aviso de “Cuarentena de riesgo de IAM” a las 18:50:17, AWS envió un correo electrónico a las 18:50:26 y un caso de Soporte apareció a las 18:50:59.

Un detalle del registro podría complicar el triaje del incidente. El campo userIdentity de CloudTrail nombró a TestUser como el actor detrás de la adjunción de la política, a pesar de que el usuario no la realizó, y el registro no identificó claramente la automatización de AWS.

La alerta de Salud y la creación del caso de Soporte tampoco produjeron ningún evento de CloudTrail en la prueba, convirtiendo el registro AttachUserPolicy en la señal legible por máquina más fiable.

AWS introdujo la política original AWSCompromisedKeyQuarantine en agosto de 2020, seguida de la V2 en abril de 2021 y la V3 en agosto de 2024. La primera versión denegaba explícitamente 28 acciones en IAM, EC2, Organizations, Lambda y Lightsail.

La V2 amplió las restricciones a S3 y acabó acumulando 61 permisos denegados adicionales en 17 servicios, mientras que las revisiones posteriores abordaron abusos relacionados con ECS, ECR, Bedrock, SageMaker, STS y otros servicios.

Esta evolución refleja los cambios en los ataques a la nube. Las restricciones sobre la creación de roles y Lambda dificultan la persistencia de minería de criptomonedas, los controles de eliminación de S3 pueden interrumpir los intentos de extorsión de datos, y las denegaciones relacionadas con Bedrock abordan el consumo no autorizado de IA generativa.

Debido a que un "Denegar" explícito anula un "Permitir" durante la evaluación de la política IAM, la cuarentena puede bloquear acciones de alto riesgo enumeradas sin necesidad de reescribir los permisos existentes del usuario.

Sin embargo, la cuarentena no es una revocación. AWS bloquea deliberadamente operaciones seleccionadas en lugar de desactivar la clave o aplicar AWSDenyAll, reduciendo la posible interrupción de las cargas de trabajo legítimas.

En consecuencia, un atacante aún podría ejecutar acciones que no figuren en la lista de denegación. Debes tratar la adjunción como un incidente de exposición de credenciales confirmado, seguir el caso de Soporte de AWS, rotar o desactivar la clave y revisar la actividad relacionada con la filtración.

Tus equipos de seguridad deberían configurar alertas para los eventos IAM AttachUserPolicy donde requestParameters.policyArn contenga AWSCompromisedKeyQuarantine, AWSCompromisedKeyQuarantineV2 o AWSCompromisedKeyQuarantineV3.

Deberían correlacionar el nombre de usuario afectado con la actividad de CloudTrail precedente y posterior, incluyendo las solicitudes GetCallerIdentity que lleven el agente de usuario de validación automatizada de GitHub, y centralizar los casos de Soporte a través de AWS Systems Manager Explorer para evitar que las notificaciones queden aisladas en el área de ingeniería de la nube.

Palo Alto Networks afirma que Cortex Cloud puede añadir contexto conductual a las amenazas de la nube basadas en la identidad, mientras que Idira PAM soporta la gestión centralizada de secretos, el acceso justo a tiempo y la ausencia de privilegios permanentes.

Tú y tu organización también podéis utilizar una Evaluación de Seguridad en la Nube de Unit 42 para identificar errores de configuración y brechas de seguridad; debéis escalar cualquier sospecha de compromiso inmediatamente al equipo de Respuesta a Incidentes de Unit 42 en entornos complejos de nube con múltiples cuentas.