Un atacante utilizó entre el 14 y el 26 de octubre de 2026 credenciales IAM de una cuenta de AWS asociada a Qubole, una plataforma de procesamiento y análisis de datos en la nube, para entrar en las cuentas de sus clientes a través de los roles de confianza que estos habían creado para la integración. Una vez dentro, enumeró recursos, recogió secretos y descargó datos de S3. Lo han documentado Wiz, Sentra y Mandiant, y según Sentra hay decenas de empresas afectadas, con millones de archivos robados en un solo cliente.
Las claves del ataque a través de Qubole en 20 segundos
- El atacante asumió los roles IAM que los clientes de Qubole confiaban a su cuenta de AWS.
- Robó secretos, variables de Lambda y datos de S3 entre el 14 y el 26 de octubre.
- Wiz recomienda revisar CloudTrail desde el 1 de octubre y rotar secretos.
Es un ataque a la cadena de suministro de manual. Muchas plataformas SaaS que operan dentro de la nube del cliente funcionan con roles IAM entre cuentas: durante el alta, el cliente crea un rol con una política de confianza que permite a la cuenta del proveedor asumirlo, normalmente con un identificador externo (External ID). Si alguien se hace con una identidad del proveedor, esos roles se convierten en puertas abiertas a todos sus clientes a la vez. Según BleepingComputer, Qubole no había publicado ningún aviso sobre el incidente, y no se sabe cómo se comprometieron sus credenciales.
Qué hizo el atacante
Según Wiz, la primera actividad se detectó el 14 de octubre desde una dirección de la VPN Mullvad, que llamó a sts:AssumeRole desde la cuenta de AWS 805246085872, la que usa Qubole para entrar en las cuentas de sus clientes. Desde el 15 de octubre, casi toda la actividad salió de un servidor virtual de OVH. El atacante usó dos usuarios IAM de esa cuenta y todas sus peticiones incluyeron un External ID válido y tuvieron éxito. La mayoría de los roles que asumió ni siquiera estaban en uso: los clientes habían dejado de usar la integración, pero las políticas de confianza seguían activas.
Dentro, enumeró buckets, bases de datos, instancias, roles y claves, y fue a por los sitios donde suelen guardarse credenciales: las variables de entorno de las funciones Lambda, AWS Secrets Manager y SSM Parameter Store. Con la herramienta TruffleHog validó las claves de AWS, los secretos de aplicaciones de Microsoft Entra ID y las credenciales de cliente de Okta que encontró. Sentra calcula que reunió unas 100 contraseñas y claves en siete minutos. Después descargó todo lo que cada rol podía leer en S3, en algunos casos buckets enteros, sin buscar datos concretos.
Wiz encontró además, alojada en el servidor de OVH del atacante, una imagen sso_agent.iso de Linux arrancable que recoge información del sistema y ejecuta órdenes remotas durante 90 minutos antes de reiniciar y borrar el rastro, aunque no ha visto que se haya usado. Tampoco ha podido atribuir la campaña a ningún grupo conocido y la considera oportunista. Por separado, entre el 8 y el 11 de octubre otro actor probó claves de acceso de clientes creadas para integraciones con Qubole, sin que Wiz haya podido vincular ambas actividades.
Cómo comprobar si te ha afectado
Si tu organización ha integrado Qubole, Wiz recomienda revisar CloudTrail desde el 1 de octubre en todas las cuentas con un rol de integración y buscar:
- Eventos AssumeRole de la cuenta
805246085872desde direcciones que no sean de AWS. - Cualquier actividad del usuario
AIDA3W7DIFLYOLTK63SFS, que solo ha usado el atacante, y del usuarioAIDAJYRRH5Y3A7AAJM2HWdesde fuera de AWS. - Sesiones de rol con nombres que empiezan por
quiam-, comoquiam-enum. - Tráfico desde 57.129.54[.]120 y 2001:41d0:70d[:]7800:: (OVH) y desde 45.83.220[.]211, 185.209.199[.]73 y 89.37.63[.]175 (Mullvad, que por ser VPN compartida no es concluyente por sí sola).
- Llamadas a GetCallerIdentity con agente de usuario TruffleHog desde esas direcciones.
Si el atacante asumió algún rol, hay que revisar todo lo que hizo esa sesión, rotar cada secreto, parámetro y variable de Lambda que el rol pudiera leer y revocar las sesiones activas, porque rotar una credencial no invalida las sesiones temporales ya emitidas. Un aviso importante: CloudTrail registra por defecto la asunción del rol y el listado de buckets, pero no las lecturas de objetos. Sin los eventos de datos de S3 o los registros de acceso al servidor activados, no se puede saber qué archivos se llevaron.
Cómo cerrar la puerta a los proveedores
La lección va más allá de Qubole. Wiz recomienda inventariar todos los roles que confían en cuentas externas y borrar los de integraciones que ya no se usan. También aconseja sustituir el principal :root de la cuenta del proveedor por la identidad concreta que este usa y limitar desde dónde se puede asumir el rol con condiciones como aws:SourceIp o aws:SourceVpce. Según la empresa, una condición de IP de origen habría bloqueado todas las asunciones de rol que observó. Por ejemplo:
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::<cuenta-proveedor>:role/<rol-del-proveedor>" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "<external-id>" },
"IpAddress": { "aws:SourceIp": ["<rangos-publicados-por-el-proveedor>"] }
}
}El External ID no debe tratarse como un secreto, porque aparece en claro en CloudTrail y en el código de infraestructura, así que no puede ser el único control. Los roles de integración deberían tener los permisos mínimos, sin acceso de conveniencia a Secrets Manager, Lambda o lectura completa de S3, y conviene alertar de cualquier asunción de rol de un proveedor desde redes nuevas, VPN o proveedores de alojamiento. A los proveedores SaaS, Wiz les pide asumir los roles de sus clientes desde cargas de trabajo con credenciales de corta duración en lugar de claves de usuario IAM de larga vida, y publicar sus rangos de salida para que los clientes puedan fijarlos en sus políticas.
Preguntas frecuentes
¿Qué ha pasado con Qubole?
Un atacante usó credenciales IAM de la cuenta de AWS asociada a Qubole para asumir los roles de confianza de sus clientes y robar secretos y datos de S3 entre el 14 y el 26 de octubre de 2026.
¿Cómo sé si mi cuenta de AWS está afectada?
Revisando CloudTrail desde el 1 de octubre en busca de AssumeRole desde la cuenta 805246085872 fuera de la red de AWS, sesiones quiam-* y las direcciones IP publicadas por Wiz.
¿Basta con el External ID para proteger un rol entre cuentas?
No. Todas las peticiones del atacante llevaban un External ID válido. Hay que limitar además la identidad de confianza y las redes de origen.
Fuentes:
