Atacante usó credenciales de Qubole AWS para asumir roles en cuentas de clientes y robar secretos

Entre el 14 y el 26 de octubre, un atacante explotó credenciales asociadas a la cuenta de AWS que utiliza la plataforma de Qubole para acceder a los entornos de varios clientes y extrajo secretos y datos, según el análisis de los investigadores de Wiz. El método empleado fue asumir roles (AssumeRole) que los clientes habían creado para permitir que Qubole actuara dentro de sus cuentas; esos roles confiaban en la cuenta de Qubole (ID 805246085872) y requerían un External ID, que en este caso el atacante pudo incluir correctamente. Los investigadores también documentan actividad anterior, entre el 8 y el 11 de octubre, en la que otro actor —o posiblemente el mismo con una técnica distinta— usó claves de acceso AWS de clientes configuradas para Qubole; esa etapa preliminar fue vinculada a compromisos en algunos entornos, pero no ha sido correlacionada públicamente con el abuso de AssumeRole que siguió.

Hechos confirmados: Wiz publicó un informe técnico que detalla la campaña, y la investigación fue iniciada tras alertas de la empresa Sentra. El atacante leyó variables de entorno de funciones Lambda, extrajo secretos de AWS Secrets Manager, obtuvo parámetros del SSM Parameter Store y descargó objetos de S3 —a veces descargando un bucket entero si el rol lo permitía—. Para validar credenciales extraídas, el atacante empleó herramientas automatizadas como TruffleHog. Además, los investigadores identificaron firmas operativas reproducibles: la cuenta de Qubole 805246085872, dos IAM principal IDs relevantes (AIDA3W7DIFLYOLTK63SFS, asociada al atacante en los casos examinados, y AIDAJYRRH5Y3A7AAJM2HW, usada por Qubole y también por el atacante desde el 18 de octubre), direcciones IP públicas vinculadas a OVH y a servidores de VPN (por ejemplo 57.129.54.120 y 45.83.220.211), sesiones con nombres que comienzan por “quiam-” y registros GetCallerIdentity cuyo user-agent mostraba TruffleHog.

Qué permitió el acceso y por qué funcionó: técnicamente, Qubole funciona dentro de la cuenta del cliente mediante un rol IAM cuya política de confianza permite que la cuenta de Qubole asuma el rol. AWS valida que la solicitud AssumeRole provenga de la cuenta confiable y que el External ID coincida. El problema clave en este incidente no fue una vulnerabilidad en AWS sino que las credenciales que el atacante tenía del lado del proveedor (la cuenta de Qubole) pudieron ser usadas para emitir solicitudes válidas a roles aún configurados para confiar en esa cuenta. Además, el External ID no es secreto según la propia guía de AWS: se registra en CloudTrail y es visible en ficheros de infraestructura y plantillas, por lo que su conocimiento por parte del atacante no es sorprendente. Más detalles técnicos y recomendaciones generales sobre vendor roles se encuentran en la página de investigación de Wiz y la documentación de AWS sobre External ID (Wiz Research, AWS External ID guidance).

A quién afecta y alcance práctico: cualquier organización que haya concedido un rol IAM a Qubole, incluso si ya no usa activamente la plataforma, está potencialmente afectada. En los entornos examinados, el atacante buscó y aprovechó secretos que podían desbloquear otros recursos y servicios: claves de acceso AWS (que permiten operar directamente la API), secretos de proveedores de identidad (por ejemplo Entra/Okta) y credenciales de aplicaciones. Donde faltaban logs detallados de S3 (S3 data events o server access logs), los equipos de respuesta no pudieron determinar con precisión qué objetos fueron leídos o copiados, lo que agrava el riesgo de exposición de información sensible.

Qué partes del relato siguen sin confirmarse públicamente: Wiz y los investigadores no han declarado públicamente cómo se obtuvieron inicialmente las credenciales que permitieron al atacante operar desde la cuenta de Qubole ni si esas credenciales ya han sido revocadas; tampoco Qubole o su matriz Idera habían emitido una declaración pública en el momento en que se verificó la información. Tampoco hay vinculación pública y confirmada entre esta campaña y otros incidentes mayores ni indicios concluyentes de que se trate de una operación patrocinada por un estado actor; Wiz señala que los objetivos no se ajustan al patrón habitual de grupos estatales.

Consecuencias reales y potenciales: la exposición de secretos y claves de acceso puede permitir al atacante escalado lateral dentro de cuentas, persistencia mediante nuevas credenciales o integraciones, robo de datos, y en entornos integrados con otras nubes o SaaS, comprometimiento de identidades federadas. La falta de registros detallados impide determinar el alcance exacto de la exfiltración en todos los afectados, lo que complica la respuesta y remediación.

Medidas concretas e inmediatas que debe tomar cualquier equipo afectado o que haya usado Qubole con AWS: primero, rastree los eventos en CloudTrail desde el 1 de octubre en adelante buscando AssumeRole donde userIdentity.accountId = 805246085872 y sourceIPAddress no sea una dirección de AWS; investigue sesiones cuya sessionName empiece por “quiam-”, llamadas GetCallerIdentity con user-agent TruffleHog y actividad desde las IPs señaladas por los investigadores. Active una revisión exhaustiva de Secrets Manager, SSM Parameter Store, variables de entorno de Lambda y permisos de lectura de S3 que el rol podía alcanzar; rote de inmediato todas las credenciales (claves de acceso, secretos de aplicaciones, client secrets) a las que el rol tenía visibilidad y cambie contraseñas o tokens externos que puedan haber sido expuestos. Tenga en cuenta que rotar un secreto no invalida sesiones temporales ya emitidas; para bloquear sesiones activas, elimine o modifique la política de confianza del rol (por ejemplo eliminando la cuenta de Qubole de la trust policy o sustituyendo el principal de cuenta por el IAM principal específico que el proveedor documenta) y, si procede, borre roles que no se utilicen. Añada condiciones al trust policy, como aws:SourceIp o aws:SourceVpce, para limitar desde dónde se pueden asumir los roles —los investigadores indican que en este caso una condición de IP habría bloqueado las asunciones observadas. Implemente un trail de organización y habilite S3 data events o server access logs en buckets sensibles para poder auditar lecturas de objetos en el futuro (ver guía de CloudTrail: AWS CloudTrail).

Por último, revise y reduzca el alcance de permisos concedidos a roles de terceros: es frecuente ver roles de proveedores con permiso de lectura amplio sobre S3, acceso a Secrets Manager y parámetros SSM “por conveniencia”; limite esos permisos al mínimo necesario y configure alertas para AssumeRole que provengan de VPS, redes de hosting o IPs de VPN no documentadas por el proveedor. Estas acciones no garantizan que un compromiso pasado deje de tener consecuencias, pero reducen drásticamente la ventana de abuso futuro y facilitan contención y auditoría.

Este incidente subraya que la confianza cruzada entre cuentas y la gestión de credenciales en integraciones de proveedores requieren políticas y registros específicos: no basta con delegar acceso, es necesario instrumentarlo y restringirlo de manera proactiva. Manténgase atento a comunicaciones oficiales de Qubole o Idera y a los informes técnicos de Wiz para actualizaciones y detecciones adicionales.