Reports
MEDIA[CONFIGURACIÓN]#3780277

AWS S3 Tables: 23 endpoints de no producción permitían enumerar permisos IAM sin dejar rastro en CloudTrail

Varios endpoints internos de S3 Tables aceptaban credenciales IAM normales y respondían distinto según los permisos, pero no registraban nada en CloudTrail. Un atacante con credenciales robadas podía averiguar a qué tenía acceso sin ser visto.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Cuando alguien roba credenciales de IAM en AWS, lo primero que suele hacer es probarlas: lanza muchas llamadas a la API y mira cuáles funcionan y cuáles devuelven "acceso denegado". Existen incluso herramientas que automatizan ese tanteo. Para quien defiende la cuenta, ese ruido es una de las mejores señales de alerta, porque deja en CloudTrail un rastro de errores de autorización muy fácil de detectar.

El investigador encontró 23 endpoints de no producción del servicio Amazon S3 Tables (s3tables) que:

  • aceptaban credenciales IAM normales de una cuenta comercial estándar,
  • aplicaban la autorización de IAM como lo haría el endpoint real (respuesta distinta si el usuario tiene o no el permiso),
  • y no generaban ningún evento en CloudTrail, ni para la llamada permitida ni para la denegada.

Es decir, servían como oráculo silencioso para saber qué permisos tiene una identidad comprometida. El investigador lo llama "non-production endpoint permission enumeration CloudTrail bypass" y lo ha documentado antes en otros servicios de AWS (bedrock, glue, route53, securityhub, ssm y más de veinte reportes previos). AWS ha declarado públicamente que considera este tipo de omisión del registro un problema de seguridad cuando el endpoint es invocable con credenciales normales y se comporta igual que el de producción en cuanto a IAM.

La operación con la que se comprobó el comportamiento fue list-table-buckets. Los endpoints estaban todos en us-west-2: dos con nombres del tipo s3tables.us-west-2.[REDACTADO].people.aws.dev, uno censurado por completo en el reporte y veinte balanceadores de carga con el patrón:

s3table-nlb-personal-us-west-2{a,b,c}-<identificador>.elb.us-west-2.amazonaws.com

Las pruebas no demostraron acceso a datos de clientes; el problema es que dejaban sin visibilidad a los defensores.

Pasos de reproducción

La validación se automatizó con dos roles: admin (con permisos amplios) y noperm (sin ningún permiso).

  1. Con el rol privilegiado, lanzar la operación contra uno de los endpoints afectados:
aws s3tables list-table-buckets --region us-west-2 --cli-connect-timeout 10 --cli-read-timeout 10 --endpoint-url https://s3tables.us-west-2.[REDACTADO].people.aws.dev --no-verify-ssl
  1. Esperar entre 10 y 15 minutos y buscar el evento en CloudTrail. No aparece ninguno que coincida.
  1. Repetir exactamente la misma orden con el rol sin permisos (noperm).
  1. Volver a consultar CloudTrail: tampoco hay evento para esta llamada.
  1. Comparar las respuestas. Con admin la llamada funciona:
{
    "tableBuckets": []
}

Con noperm devuelve un error de autorización de IAM:

An error occurred (AccessDeniedException) when calling the ListTableBuckets operation: User: arn:aws:sts::[REDACTADO]:assumed-role/noperm/vm-noperm-20260601T181312Z is not authorized to perform: s3tables:ListTableBuckets on resource: arn:aws:s3tables:us-west-2:[REDACTADO]:bucket/* because no identity-based policy allows the s3tables:ListTableBuckets action

La búsqueda en CloudTrail se hizo en us-east-1 y en us-west-2 para ambos roles, con el mismo resultado: events=0, sin ninguna fuente que coincidiera. La diferencia entre las dos respuestas basta para saber si la identidad tiene o no el permiso, y ninguna de las dos llamadas queda registrada.

Impacto

Un atacante que haya conseguido credenciales de IAM podía comprobar si tienen el permiso s3tables:ListTableBuckets sin generar ni un solo evento en CloudTrail. Así esquivaba una de las detecciones más habituales tras un robo de credenciales: la ráfaga de llamadas fallidas que deja el tanteo de permisos. El investigador estimó un CVSS 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). El reporte figura en HackerOne con severidad media y como resuelto; se envió el 3 de junio de 2026 y se divulgó el 2 de julio de 2026.

Qué aprender de este caso

  • Al auditar un servicio cloud, no basta con mirar el endpoint oficial: busca nombres de host internos, de pruebas o "personales" (como balanceadores *-nlb-personal-* o dominios de desarrollo) que respondan a la misma API, y comprueba si sus llamadas aparecen en el registro de auditoría.
  • La prueba clave es doble: que la autorización sea real (respuesta distinta con un rol con permisos y otro sin ellos) y que ninguna de las dos llamadas deje evento. Si se cumplen ambas, el endpoint es un oráculo de permisos invisible.
  • Si mantienes entornos de no producción de un servicio, o los aíslas para que no acepten credenciales de clientes, o haces que registren en la misma auditoría que producción; un entorno a medio camino es justo lo que permite este fallo.
  • En detección, no confíes solo en contar errores AccessDenied en CloudTrail para descubrir credenciales robadas: combínalo con otras señales (uso desde IP o agentes nuevos, llamadas posteriores inusuales), porque el tanteo puede hacerse por canales que no registran.