Una campaña de ciberataques aprovechó las conexiones de confianza entre Qubole y las cuentas de Amazon Web Services de varios clientes para acceder a secretos, credenciales y archivos almacenados en la nube. Los investigadores advierten de que incluso las integraciones abandonadas pueden seguir abiertas a los atacantes.
La confianza concedida a un proveedor tecnológico se ha convertido en una puerta de entrada para los ciberdelincuentes. Varios entornos empresariales de Amazon Web Services (AWS) fueron comprometidos después de que un atacante utilizara credenciales asociadas a la cuenta de Qubole, una plataforma de procesamiento de datos en la nube propiedad de Idera.
La actividad maliciosa se produjo entre el 14 y el 26 de octubre de 2026, según la investigación de la empresa de ciberseguridad Wiz, que trabajó junto a Sentra y Mandiant para analizar el incidente. Los atacantes consiguieron asumir roles de acceso que los clientes habían configurado para permitir que Qubole trabajara dentro de sus cuentas.
Una vez dentro, buscaron contraseñas, claves y otros secretos almacenados en los servicios de AWS. También accedieron a información de los sistemas de almacenamiento S3 y, en algunos casos, descargaron depósitos completos de datos.
Wiz no ha revelado cuántas organizaciones resultaron afectadas ni ha explicado cómo consiguieron los atacantes las credenciales de la cuenta de Qubole. Tampoco ha atribuido la operación a un grupo concreto. El incidente constituye una advertencia para las empresas que conceden permisos amplios a proveedores externos y después no revisan si esas conexiones siguen siendo necesarias.
Cómo consiguieron entrar en las cuentas de AWS de los clientes
Para comprender el alcance del ataque hay que conocer cómo funciona la integración entre Qubole y Amazon Web Services.
Qubole es una plataforma de procesamiento y análisis de datos que puede operar dentro de la infraestructura cloud de sus clientes. Para hacerlo, la organización que contrata el servicio crea un rol de IAM (Identity and Access Management) en su propia cuenta de AWS.
Ese rol es una identidad con permisos específicos. Su política de confianza permite que una cuenta de AWS asociada al proveedor pueda asumirlo y utilizar las capacidades autorizadas por el cliente.
El procedimiento se realiza mediante una operación denominada AssumeRole, que permite obtener credenciales temporales para actuar con los permisos del rol. Como medida adicional, la integración utiliza un código conocido como External ID.
En condiciones normales, esta arquitectura permite que un proveedor acceda a los recursos necesarios sin que el cliente tenga que entregarle directamente sus claves de acceso permanentes.
El problema apareció cuando los atacantes consiguieron utilizar credenciales vinculadas a la cuenta de AWS que Qubole emplea para conectarse con sus clientes. Desde esa identidad solicitaron asumir los roles de integración que seguían confiando en la cuenta del proveedor.
Las solicitudes fueron aceptadas porque incluían el External ID correcto y procedían de una cuenta autorizada por las políticas de confianza. De esta manera, los atacantes pudieron obtener credenciales temporales y entrar en los entornos de las organizaciones afectadas.
La investigación de Wiz destaca un detalle especialmente preocupante: muchos de los roles utilizados no estaban en uso habitual. Sin embargo, las políticas de confianza seguían activas y permitieron que las solicitudes maliciosas prosperasen.
El ataque aprovechó conexiones que algunas empresas ya no utilizaban
Uno de los aspectos más relevantes del incidente es que no todas las integraciones comprometidas estaban siendo utilizadas de forma activa por sus propietarios.
Según Wiz, en la mayoría de los entornos analizados, las solicitudes maliciosas eran las únicas operaciones de acceso procedentes de la cuenta del proveedor durante octubre. Pese a esa ausencia de actividad legítima, los permisos continuaban vigentes.
Esto significa que una empresa podía haber dejado de utilizar Qubole y, aun así, mantener abierta una vía de acceso a su infraestructura.
La situación refleja un problema habitual en la gestión de servicios en la nube: las organizaciones incorporan herramientas externas, crean permisos para facilitar su funcionamiento y, cuando abandonan el servicio, no siempre eliminan las autorizaciones asociadas.
Una integración que ya no se utiliza no es necesariamente una integración desactivada. Si el rol continúa confiando en la cuenta externa, puede seguir siendo aprovechado por quien consiga controlar esa identidad.
Wiz recomienda revisar todas las relaciones de confianza con proveedores externos, no solo las que mantienen actividad reciente. El incidente demuestra que los permisos olvidados pueden representar un riesgo real para la seguridad de los datos empresariales.
Robo de contraseñas, secretos y credenciales de Microsoft y Okta
Una vez dentro de las cuentas de AWS, los atacantes no se limitaron a consultar información general sobre la infraestructura. La investigación de Wiz describe una operación de búsqueda sistemática de credenciales y secretos almacenados en distintos servicios.
Entre los recursos examinados se encontraban:
- AWS Lambda: los atacantes consultaron la configuración de funciones para obtener variables de entorno, que pueden contener claves y credenciales.
- AWS Secrets Manager: accedieron al servicio utilizado para almacenar contraseñas, claves de acceso y otros secretos.
- AWS Systems Manager Parameter Store: consultaron parámetros que podían contener información sensible.
- Amazon S3: identificaron los depósitos de almacenamiento accesibles y descargaron información.
Los atacantes también utilizaron TruffleHog, una herramienta que permite localizar y comprobar secretos y credenciales. En este caso, la emplearon para verificar si las claves encontradas en los entornos de las víctimas seguían siendo válidas.
Los investigadores identificaron intentos de validación de distintos tipos de credenciales:
- Claves de acceso de cuentas de Amazon Web Services.
- Secretos de cliente de Microsoft Entra ID, la plataforma de identidad de Microsoft.
- Credenciales de cliente de Okta, utilizadas para autenticación y acceso a servicios.
La importancia de este procedimiento reside en que el robo de un secreto puede abrir nuevas puertas. Una contraseña o clave almacenada en una función de AWS puede permitir acceder a otros servicios, aplicaciones o sistemas de identidad de la misma organización.
Por tanto, el incidente no se limitó al acceso inicial a los roles de Qubole: también pudo proporcionar a los atacantes credenciales adicionales para ampliar su capacidad de intrusión.
Los ciberdelincuentes descargaron datos de Amazon S3
Otro de los objetivos de la campaña fue Amazon S3, el servicio de almacenamiento de objetos de AWS utilizado por empresas para guardar archivos, copias de seguridad, documentos y grandes volúmenes de información.
Wiz observó que los atacantes seguían una secuencia de operaciones para localizar y extraer datos:
- Primero asumían el rol de integración del proveedor.
- Después enumeraban los depósitos S3 a los que tenían acceso.
- A continuación consultaban los objetos disponibles y sus características.
- Finalmente descargaban los archivos mediante las operaciones de lectura autorizadas por el rol.
Los investigadores describen un comportamiento oportunista: en lugar de seleccionar únicamente determinados documentos, los atacantes accedían a los datos que podían leer con los permisos disponibles.
En algunos casos, llegaron a descargar depósitos completos durante una sola sesión.
La investigación no permite establecer qué información concreta contenían todos los archivos sustraídos ni si los datos han sido publicados, vendidos o utilizados posteriormente. Tampoco se ha comunicado una cifra global sobre el volumen de información extraída.
Esta falta de visibilidad está relacionada con otro problema técnico. Los registros habituales de administración de CloudTrail permiten conocer cuándo se solicita asumir un rol y cuándo se enumeran depósitos, pero no registran necesariamente qué objetos concretos de S3 se han leído.
Para identificar esos accesos es necesario disponer de eventos de datos de S3 en CloudTrail o registros de acceso del servidor S3. Algunas de las organizaciones afectadas no tenían habilitados esos mecanismos, lo que impidió determinar exactamente qué archivos había consultado el atacante.
Wiz identifica direcciones IP y cuentas utilizadas en el ataque
La investigación también ha permitido identificar varios indicadores técnicos que pueden ayudar a las empresas a comprobar si sus cuentas estuvieron expuestas.
El acceso inicial detectado el 14 de octubre procedía de una dirección asociada a la red VPN Mullvad. Posteriormente, la mayor parte de la actividad se originó desde una infraestructura alojada en OVH.
Los investigadores identificaron las siguientes direcciones:
| Dirección | Infraestructura asociada |
|---|---|
| 57.129.54[.]120 | OVH |
| 2001:41d0:70d[:]7800:: | OVH |
| 45.83.220[.]211 | Mullvad |
| 185.209.199[.]73 | Mullvad |
| 89.37.63[.]175 | Infraestructura asociada a Mullvad |
También identificaron la cuenta de AWS 805246085872, utilizada por Qubole para acceder a los entornos de sus clientes.
Dos identificadores de usuarios IAM aparecen en el análisis:
- AIDA3W7DIFLYOLTK63SFS: Wiz indica que solo observó actividad del atacante asociada a este usuario en los entornos afectados que examinó.
- AIDAJYRRH5Y3A7AAJM2HW: fue utilizado por el atacante desde el 18 de octubre, pero también registraba actividad legítima de Qubole desde infraestructura de AWS.
Otro indicador es el nombre de sesión de rol con el prefijo quiam-, con ejemplos como quiam-enum y quiam-scope-full.
Estas señales deben analizarse conjuntamente. Una coincidencia aislada con una dirección VPN, por ejemplo, no demuestra por sí sola que exista una intrusión, porque esas direcciones pueden ser compartidas por numerosos usuarios.
Cómo comprobar si una empresa ha sido afectada
Wiz recomienda que todas las organizaciones que hayan conectado Qubole con AWS revisen sus registros de actividad desde el 1 de octubre de 2026, incluso si dejaron de utilizar la plataforma.
La comprobación debe realizarse en todas las cuentas que tengan o hayan tenido roles de integración asociados al proveedor.
Los administradores deben buscar especialmente:
- Solicitudes
AssumeRoleen las queuserIdentity.accountIdsea805246085872y la dirección de origen no pertenezca a infraestructura de AWS. - Actividad asociada al identificador IAM
AIDA3W7DIFLYOLTK63SFS. - Operaciones del identificador
AIDAJYRRH5Y3A7AAJM2HWcuando procedan de direcciones externas a AWS. - Conexiones desde las direcciones IP identificadas por Wiz.
- Sesiones de rol cuyo nombre comience por
quiam-. - Llamadas a
GetCallerIdentityque utilicen TruffleHog y coincidan con otros indicadores sospechosos.
Si se identifica una sesión sospechosa, la revisión debe continuar sobre todas las operaciones realizadas después de asumir el rol. Es especialmente importante comprobar las consultas a Secrets Manager, Parameter Store, Lambda y S3.
La investigación también debe revisar los registros de acceso de los proveedores de identidad, especialmente cuando aparezcan intentos de validación de credenciales de Microsoft Entra ID u Okta.
No encontrar una solicitud sospechosa en los registros de administración no garantiza que no se hayan leído archivos, especialmente si la empresa no tenía habilitados los eventos de datos de S3.
Ocho medidas para cerrar la puerta a nuevos ataques
Los investigadores de Wiz han publicado una serie de recomendaciones para las empresas que utilizan integraciones externas en AWS. Las medidas más importantes son las siguientes:
- Revocar los accesos que ya no sean necesarios. Eliminar los roles de Qubole que no se utilicen o retirar la cuenta del proveedor de sus políticas de confianza.
- Rotar todas las credenciales expuestas. Si un rol comprometido podía acceder a secretos, parámetros o variables de entorno de Lambda, deben cambiarse todos los valores potencialmente afectados.
- Revocar las sesiones activas. Cambiar una contraseña o una clave no invalida automáticamente las credenciales temporales que ya se hayan emitido. Es necesario cerrar las sesiones comprometidas.
- Restringir las identidades autorizadas. Cuando el proveedor lo permita, conviene sustituir la confianza concedida a toda una cuenta mediante el principal
:rootpor una identidad IAM específica. - Limitar el origen de las conexiones. Las condiciones
aws:SourceIpoaws:SourceVpcepermiten restringir las solicitudes a rangos de red o puntos de conexión autorizados. - No utilizar el External ID como única barrera. Este identificador no debe considerarse un secreto, ya que puede aparecer en registros de CloudTrail y archivos de configuración. Es recomendable emplear valores diferentes para cada integración cuando sea posible.
- Aplicar el principio de mínimo privilegio. Los roles de proveedores externos solo deberían tener acceso a los recursos estrictamente necesarios para prestar el servicio.
- Mejorar la monitorización. Las empresas deben mantener registros centralizados de todas sus cuentas y regiones y habilitar eventos de datos de S3 para los depósitos que contengan información confidencial.
Wiz señala que una restricción de IP de origen habría bloqueado todas las solicitudes de asunción de roles que observó en esta campaña. Es una de las conclusiones técnicas más importantes del análisis.
Una segunda actividad maliciosa también afectó a integraciones de Qubole
La investigación identificó además otra actividad sospechosa relacionada con integraciones de Qubole, aunque Wiz no ha podido vincularla con la campaña principal.
Entre el 8 y el 11 de octubre, otro actor utilizó claves de acceso de AWS pertenecientes a los propios clientes. Los investigadores creen que esas claves habían sido creadas para configurar las conexiones con Qubole.
El 8 de octubre se detectaron pruebas de esas credenciales en un intervalo de aproximadamente una hora. En un número reducido de casos, el atacante consiguió comprometer también los entornos cloud de las víctimas.
La diferencia es importante: en la campaña principal se abusó de las credenciales de una cuenta asociada al proveedor para asumir roles de clientes. En esta segunda actividad se utilizaron claves de acceso propiedad de los clientes.
Aunque ambas operaciones están relacionadas con las integraciones de Qubole, los investigadores mantienen que no hay pruebas suficientes para atribuirlas al mismo actor o a una única campaña.
Un aviso para todas las empresas que dependen de proveedores cloud
Wiz no ha atribuido el ataque a un grupo conocido ni ha encontrado vínculos con otras campañas públicas. Sus investigadores consideran que el comportamiento parece oportunista y no encaja con los objetivos habituales de operaciones respaldadas por Estados, aunque reconocen que no conocen la motivación real de los responsables.
Tampoco se ha publicado una cifra definitiva de organizaciones afectadas ni se ha aclarado qué uso se ha dado a la información sustraída. En el momento de las primeras informaciones, ni Qubole ni su propietaria, Idera, habían publicado una explicación pública sobre el incidente. The Register tampoco obtuvo respuesta de AWS y Qubole a sus consultas.
La lección va mucho más allá de una plataforma concreta. Las empresas externalizan cada vez más procesos, análisis de datos y almacenamiento, pero cada conexión con un proveedor amplía potencialmente la superficie de ataque.
La seguridad de una infraestructura cloud no depende únicamente de proteger las contraseñas propias: también exige controlar las identidades externas a las que se concede acceso. Un permiso olvidado, una política demasiado amplia o una credencial comprometida pueden poner en riesgo información de toda una organización.
El caso Qubole demuestra que la confianza técnica debe revisarse de forma permanente. En la nube, dejar una puerta abierta porque ya nadie recuerda que existe puede ser suficiente para que alguien termine utilizándola.
Toqueteo
Toqueteo
Toqueteo