Un atacante ha estado entrando en las cuentas de Amazon Web Services (AWS) de varios clientes de Qubole usando las propias credenciales de la plataforma. Lo ha hecho sin explotar ninguna vulnerabilidad: simplemente ha usado la confianza que esas empresas ya habían depositado en su proveedor. Es uno de esos incidentes que debería hacer revisar a cualquier equipo de seguridad todas las integraciones de terceros que tiene conectadas a su nube.
La investigación la ha publicado hoy, 9 de noviembre de 2026, la empresa de seguridad cloud Wiz, que trabajó junto a Sentra —que detectó la actividad sospechosa en varios de sus clientes— y Mandiant. La actividad maliciosa se desarrolló entre el 14 y el 26 de octubre de 2026.
Qué es Qubole y por qué tenía la llave de tantas cuentas
Qubole es una plataforma de data lake, propiedad de Idera, que opera dentro de las cuentas de AWS de sus clientes. Para poder trabajar ahí, el cliente crea un rol de IAM en su propia cuenta cuya política de confianza permite que la cuenta de AWS de Qubole lo asuma. Cada petición de asunción de rol, llamada AssumeRole, debe incluir además un código de Qubole conocido como External ID.
El problema es estructural: ese rol es una puerta que el cliente abre de forma permanente al proveedor. Y en este caso, alguien se hizo con las credenciales de la cuenta de AWS que usa Qubole —la cuenta 805246085872— y empezó a llamar a esas puertas una por una. Cómo consiguió el atacante esas credenciales no se ha revelado.
Lo más inquietante es que la mayoría de los roles que asumió el atacante ni siquiera estaban en uso. Eran integraciones antiguas o abandonadas cuyas políticas de confianza seguían activas. El atacante no necesitó forzar nada: las peticiones llegaban desde la cuenta de confianza y con el External ID correcto, así que AWS las aceptaba todas.
Así se movió el atacante dentro de las cuentas
La primera actividad observada fue el 14 de octubre, cuando una dirección IP de la VPN Mullvad (45.83.220.211) llamó a AssumeRole contra roles de integración en entornos de clientes. A partir del 15 de octubre, la mayor parte de la actividad llegó desde un servidor VPS de OVH (57.129.54.120). El 18 de octubre el atacante empezó a usar un segundo usuario IAM de la misma cuenta, y ese mismo día una segunda dirección de Mullvad (185.209.199.73) asumió roles en varias víctimas en rápida sucesión. También se observó actividad desde 89.37.63.175 y desde la dirección IPv6 2001:41d0:70d:7800::.
Una vez dentro, el atacante se comportaba como un inventario con patas. Las sesiones de rol seguían un patrón de nombres consistente con el prefijo quiam-, como quiam-enum o quiam-scope-full, y enumeraba de forma amplia: buckets y objetos de S3, bases de datos, clústeres, instancias, grupos de seguridad, VPC, snapshots, roles y claves.
Después iba a por las credenciales. Leyó las variables de entorno de las funciones Lambda, sacó secretos de AWS Secrets Manager y valores del Parameter Store de SSM. Y no se limitó a robarlas: usó la herramienta TruffleHog para comprobar si funcionaban, validando claves de acceso de AWS, secretos de clientes de Entra ID y credenciales de cliente de Okta. Esas credenciales pertenecían a las víctimas, no al proveedor, lo que multiplica el alcance del incidente: con una clave de Okta o de Entra ID válida, el atacante puede moverse más allá de AWS.
La exfiltración de datos de S3 fue oportunista: el atacante leía de cualquier bucket al que el rol tuviera acceso, sin buscar datos concretos, y en algunos casos descargó buckets enteros en una sola sesión.
Hay además una segunda línea de actividad que Wiz no ha podido vincular con la anterior: entre el 8 y el 11 de octubre, otro actor —o el mismo, no se sabe— usó claves de acceso de AWS propiedad de los clientes que se cree que se habían creado para las integraciones de Qubole. El 8 de octubre probó todas esas claves en una sola hora y en un pequeño número de casos llegó a comprometer el entorno cloud de la víctima.
Un detalle que apunta a algo más grande
Wiz encontró también una imagen ISO, llamada sso_agent.iso, alojada en la misma IP de OVH durante el periodo del ataque. Es una imagen Linux arrancable que, al iniciarse, pone en marcha un temporizador de 90 minutos, recopila información del sistema y la sube a esa IP, y después sondea el puerto TCP 23458 esperando órdenes que ejecuta como scripts de shell. El hecho de que cargue el driver ntfs3 sugiere que está diseñada para atacar sistemas Windows. Wiz no ha identificado ningún despliegue de esta imagen ni puede confirmar si se llegó a usar, pero su existencia indica que el actor tenía preparada una fase posterior al robo de credenciales.
Wiz no ha vinculado esta campaña con ninguna otra actividad reportada públicamente y señala que el objetivo —robo de datos oportunista— no encaja con las prioridades habituales de los grupos respaldados por estados. La motivación concreta y el uso que se dará a los datos robados siguen sin conocerse.
El fallo de diseño que lo hizo posible
El External ID no es un secreto. AWS lo registra en texto plano en CloudTrail y los proveedores y los archivos de infraestructura como código lo almacenan en muchos sitios. Cualquiera con acceso al rol puede verlo. Tratarlo como si fuera una contraseña es el error de fondo: la única defensa real era limitar desde dónde y desde qué identidad se podía asumir el rol, y casi nadie lo había hecho.
A fecha de hoy, ni Qubole ni Idera han publicado ningún comunicado sobre el ataque, y Wiz no ha confirmado si las credenciales comprometidas han sido revocadas o si la actividad ha cesado. Eso deja abierta la ventana: cualquier organización que haya conectado Qubole a AWS —incluso si ya no lo usa— debe asumir que puede estar afectada.
Qué hacer ahora
Si tu organización ha usado Qubole, revisa los logs de CloudTrail desde el 1 de octubre de 2026 en todas las cuentas que tengan un rol de integración. Busca peticiones AssumeRole donde la cuenta de origen sea 805246085872 y la IP de origen no sea una dirección de AWS. Los identificadores de los usuarios IAM usados son AIDA3W7DIFLYOLTK63SFS —que en los entornos observados solo usó el atacante— y AIDAJYRRH5Y3A7AAJM2HW, que también lleva tráfico legítimo, por lo que en este segundo caso hay que filtrar por la IP de origen. Las direcciones a buscar son 57.129.54.120, 2001:41d0:70d:7800::, 45.83.220.211, 185.209.199.73 y 89.37.63.175, y las sesiones de rol con nombres que empiecen por quiam-.
Si encuentras una sesión sospechosa, revisa todo lo que hizo después, especialmente en Secrets Manager, SSM Parameter Store, Lambda y S3, y rota todos los secretos, parámetros y variables de entorno a los que ese rol tenía acceso. Recuerda que rotar una credencial no cierra las sesiones temporales que ya se emitieron: hay que revocar las sesiones activas del rol.
Y para cerrar la puerta de forma estructural: elimina los roles de integración que ya no uses, sustituye el principal :root de la cuenta en la política de confianza por el principal IAM concreto que usa el proveedor, añade una condición aws:SourceIp o aws:SourceVpce que limite la asunción del rol a las redes documentadas del proveedor —según Wiz, solo con esa condición se habría bloqueado cada asunción observada en este ataque— y aplica el principio de mínimo privilegio a lo que cada rol de proveedor puede alcanzar.
Mirada de analista Blue Team: qué vigilaría un SOC
Este incidente es un caso de manual de abuso de confianza de terceros, y deja varias lecciones de detección. La primera: una alerta de AssumeRole desde una cuenta de proveedor que llega por una VPN comercial o un hosting que ese proveedor nunca ha usado es una señal de altísima fidelidad. El tráfico legítimo de Qubole venía siempre desde infraestructura de AWS; todo lo demás era el atacante.
La segunda: los roles de integración olvidados son una superficie de ataque silenciosa. Un SOC debería inventariar periódicamente todos los roles cuya política de confianza permite cuentas externas, y sobre todo detectar aquellos sin actividad legítima reciente. En este ataque, la mayoría de las víctimas no tenían tráfico legítimo del proveedor en todo octubre: el rol existía solo para el atacante.
La tercera es de visibilidad: los eventos de gestión de CloudTrail registran la asunción del rol y el listado de buckets, pero no qué objetos de S3 se leyeron. Sin eventos de datos de S3 o logs de acceso al servidor, varias víctimas no pudieron determinar qué se había exfiltrado. Si un bucket guarda datos sensibles, sus eventos de datos deben estar activados antes del incidente, no después.
Y la lección estratégica: el External ID no protege nada por sí solo. Cualquier control que dependa de un valor que aparece en texto plano en tus propios logs no es un control. La defensa real es la condición de red y la identidad concreta del principal.
Fuentes
- Wiz — «Trusted by Default: Qubole Cross-Account Access Abused in the Wild»: https://www.wiz.io/blog/qubole-cross-account-access-abused-in-the-wild
- The Hacker News — «Hackers Exploit Qubole’s Trusted AWS Access to Breach Customer Accounts and Steal Data»: https://thehackernews.com/2026/11/hackers-exploit-quboles-trusted-aws.html
- The Daily Tech Feed — «Massive AWS Breach via Qubole IAM Role Compromise Exposes Customer Data»: https://thedailytechfeed.com/massive-aws-breach-via-qubole-iam-role-compromise-exposes-customer-data/