Resumen
Cuando alguien consigue credenciales IAM de AWS ajenas, lo primero que suele hacer es tantearlas: lanza llamadas a la API y mira cuáles funcionan y cuáles devuelven "acceso denegado". Existen incluso herramientas que automatizan ese reconocimiento. Para los equipos de defensa es una oportunidad de oro, porque ese tanteo genera un montón de intentos fallidos que quedan registrados en CloudTrail y son fáciles de detectar.
El investigador encontró cuatro endpoints no productivos del servicio CloudWatch que rompían esa red de seguridad. Aceptaban credenciales IAM estándar de una cuenta comercial normal, aplicaban la autorización de IAM con normalidad y, sin embargo, no generaban ningún evento en CloudTrail al ejecutar la operación probada (list-dashboards). No daban acceso a datos de clientes, pero bastaban para enumerar permisos de forma invisible.
Es una variante ya conocida de evasión de CloudTrail, que el propio investigador ha documentado y presentado en conferencias, y que AWS considera un problema de seguridad que debe reportarse cuando el endpoint aislado se comporta como uno normal en cuanto a credenciales y permisos. El mismo equipo había reportado antes hallazgos parecidos en muchos otros servicios de AWS (Bedrock, Glue, Route 53, Security Hub, SSM y otros), incluido un caso anterior en CloudWatch.
Pasos de reproducción
La validación se hizo de forma automatizada con dos identidades:
admin: un rol con privilegios, para ver la respuesta cuando la llamada está autorizada.noperm: un rol sin ningún permiso, para comprobar que el endpoint aplica realmente la autorización de IAM.
- Con la identidad privilegiada, lanzar la operación contra uno de los endpoints afectados (las direcciones están ocultas en el reporte público):
aws cloudwatch list-dashboards --region us-east-1 --cli-connect-timeout 10 --cli-read-timeout 10 --endpoint-url [REDACTADO] --no-verify-ssl- Esperar entre 10 y 15 minutos y buscar el evento en CloudTrail: no aparece ninguno.
- Repetir exactamente la misma llamada con la identidad que no tiene permiso para
cloudwatch:ListDashboards:
aws cloudwatch list-dashboards --region us-east-1 --cli-connect-timeout 10 --cli-read-timeout 10 --endpoint-url [REDACTADO] --no-verify-ssl- Comprobar de nuevo CloudTrail: tampoco hay ningún evento.
- Comparar las respuestas. Son distintas según los permisos, y eso es lo que delata si la identidad puede o no ejecutar la acción.
Respuesta con el rol admin:
{
"DashboardEntries": []
}Respuesta con el rol noperm:
An error occurred (AccessDenied) when calling the ListDashboards operation: User: arn:aws:sts::[REDACTADO]:assumed-role/noperm/vm-noperm-20260601T181312Z is not authorized to perform: cloudwatch:ListDashboards on resource: arn:aws:cloudwatch::[REDACTADO]:dashboard/* because no identity-based policy allows the cloudwatch:ListDashboards actionLa búsqueda en CloudTrail (región us-east-1) dio el mismo resultado para las dos llamadas:
matched_any=False, matched_marker=False, events=0, sources=noneLos cuatro endpoints afectados, todos en us-east-1 y con la operación list-dashboards, se comportaron igual: respuesta normal para admin, denegación de IAM para noperm y ningún evento en CloudTrail para ninguno de los dos.
Impacto
Con unas credenciales comprometidas, un atacante podía averiguar si tenían permiso para operar sobre CloudWatch sin que quedara constancia en CloudTrail. Así se salta justo la fase de reconocimiento que más ruido suele hacer y que los equipos de seguridad usan para detectar el robo de credenciales antes de que se haga daño.
El investigador lo valoró con un CVSS 3.1 de 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N/CR:H/IR:H/AR:H) y lo clasificó como CWE-778 (registro insuficiente). Para reproducirlo basta una cuenta normal de la partición comercial de AWS.
El reporte consta como resuelto por AWS, pero no detalla cómo se corrigió.