Qubole: una clave robada expuso datos de clientes en AWS

Qubole: el ataque que entró por la puerta que nadie cerró

Un atacante tardó unos 3 minutos en entrar en todas las cuentas de AWS que confiaban en Qubole, más de una docena, y en 7 minutos leyó cerca de 100 contraseñas y claves desde tres lugares distintos donde un solo cliente las tenía guardadas. No hubo una sola acción de escritura: nada se modificó ni se borró, solo se copió. Ese detalle es lo que hizo el incidente casi invisible.

La investigación la llevó Sentra, que detectó la campaña y la reportó a Wiz; Wiz la analizó junto a Sentra y Mandiant y publicó el informe técnico Trusted by Default: Qubole Cross-Account Access Abused in the Wild. Según The Hacker News, el atacante comprometió cuentas de AWS de varios clientes de Qubole entre el 14 y el 26 de octubre, y utilizó credenciales de una cuenta de AWS que la plataforma de Qubole usa para llegar a esos clientes.

Para un founder, la lectura no es «hubo un hackeo». Es que el rol de un proveedor que ya no usas sigue siendo una puerta abierta con permisos reales, y que el control que creías suficiente no lo era.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué pasó exactamente en el ataque a clientes de Qubole?

Qubole es una plataforma de data lake propiedad de Idera que opera dentro de las cuentas de AWS de sus clientes. Para entrar, el cliente crea un rol de IAM cuya política de confianza autoriza a la cuenta de Qubole a asumirlo (AssumeRole), presentando un código llamado ExternalId.

El atacante consiguió credenciales de la cuenta de Qubole. No está claro cómo las obtuvo: ni Wiz ni el informe de Sentra lo explican. Con ellas, la secuencia fue:

Probó las credenciales en un rol de bajo valor, miró alrededor y extrajo un primer lote de miles de archivos de perfil de cliente.
Después aceleró: asumió todos los roles que confiaban en Qubole y lanzó descargas masivas que corrieron en segundo plano durante los días siguientes.
Una última pasada, desde otra dirección de VPN, se llevó backups de bases de datos de producción.

El detalle más incómodo: los roles del cliente que investigó Sentra pertenecían a una plataforma que había dejado de usarse tiempo atrás. Seguían ahí, seguían confiando en Qubole y podían leer casi todos los buckets de origen. Según The Hacker News, la mayoría de los roles que el atacante asumió estaban sin uso.

¿Por qué el ExternalId no detuvo al atacante?

Las organizaciones afectadas no fueron negligentes. Configuraron sus integraciones con Qubole como recomienda AWS, incluido el ExternalId: un código que el proveedor debe presentar antes de entrar. Todos los roles lo tenían. El atacante presentó el código correcto todas las veces.

Y hay una razón estructural: el ExternalId no es un secreto. AWS documenta que cualquier persona con acceso al rol puede verlo, y según The Hacker News queda registrado en texto plano en CloudTrail y suele estar guardado en el proveedor y en los archivos de infraestructura como código. Sirve para evitar que un tercero te confunda con otro cliente, no para resistir a un atacante que ya tiene las llaves del proveedor.

Por eso, desde la perspectiva de AWS, el atacante era Qubole. El acceso era válido en todos los logs. Lo que no era válido era el comportamiento.

Las cuatro bóvedas de credenciales que el atacante vació

El objetivo no fue solo el dato: fueron las llaves para llegar al siguiente dato. En el caso documentado por Sentra, el atacante saqueó cuatro almacenes:

Secrets Manager: casi todos los secretos, incluidos credenciales de control de código, proveedor de identidad, CI y base de datos, más tokens del propio proveedor y sus ExternalIds.
SSM Parameter Store: todos los parámetros bajo una ruta, descifrados, incluidos los de monitoreo y agentes de escaneo.
Lambda: variables de entorno, extraídas por una segunda vía incluso donde la primera estaba bloqueada.
EC2 user data: scripts de arranque de muchas instancias, un escondite clásico de tokens y contraseñas.

Según The Hacker News, el atacante pasó las credenciales encontradas por TruffleHog para comprobar cuáles funcionaban: claves de AWS de las propias víctimas, secretos de cliente de Entra ID y credenciales de Okta.

¿Tu cuenta de AWS está afectada? La lista de verificación

Wiz publicó indicadores concretos. Si tu equipo alguna vez conectó Qubole a AWS, esto se revisa en CloudTrail desde el 1 de octubre:

Peticiones AssumeRole desde la cuenta 805246085872 con un sourceIPAddress que no sea una dirección de AWS. El tráfico real de Qubole venía solo desde AWS.
El principal de IAM AIDA3W7DIFLYOLTK63SFS. En las cuentas examinadas solo lo usó el atacante.
El principal AIDAJYRRH5Y3A7AAJM2HW cuando la dirección de origen está fuera de AWS.
Nombres de sesión de rol que empiezan por quiam-, como quiam-enum.
Direcciones de OVH como 57.129.54[.]120 y las de Mullvad VPN (estas son compartidas por otros usuarios: una coincidencia sola no prueba nada).

There’s un límite importante que mucha gente descubre tarde: CloudTrail registra las llamadas de gestión y el listado de buckets, pero no qué objetos de S3 se leyeron. Para eso hacen falta S3 data events o los server access logs. Varias víctimas no los tenían activados, así que los equipos de respuesta no pudieron determinar qué archivos se habían llevado.

El patrón se repite: LiteLLM, ConnectWise y la confianza delegada

Qubole no es un caso aislado y tampoco el más grande del año. En agosto, Help Net Security reportó que un archivo de 153 GB con credenciales robadas en el ataque a la cadena de suministro de LiteLLM contenía 433.909 archivos y datos vinculados a 2.488 dominios corporativos, tras la publicación de versiones maliciosas el 24 de marzo. La cifra la difundió Hudson Rock tras analizar el archivo, y CloudSEK estimó cerca de 2.500 organizaciones expuestas.

Antes, BleepingComputer documentó un abuso de la misma naturaleza en ConnectWise Cloud Backup: los atacantes accedieron a identidades de aplicación y comprometieron tenants de Microsoft 365, y Huntress identificó al menos 162 tenants comprometidos en su entorno. Como señala el análisis, las autenticaciones no involucraban a un usuario, así que el MFA no aplicaba: la aplicación ya tenía permisos amplios concedidos de antemano.

El patrón común es idéntico al de Qubole: nadie rompe la puerta de la víctima, entran con la identidad del proveedor que la víctima autorizó.

¿Qué significa esto para tu startup?

Si tu producto corre en AWS, GCP o Azure, es casi seguro que tienes identidades no humanas con acceso permanente a datos sensibles: integraciones de vendors, automatizaciones y agentes de IA. La mayoría hacen lo mismo todos los días, desde el mismo lugar, con el mismo horario. El riesgo aparece el día que una hace algo distinto y nadie está mirando.

Cinco acciones que puedes ejecutar esta semana, todas salidas de las recomendaciones de Wiz y del informe de Sentra:

Haz el inventario de identidades externas. Lista qué cuentas de terceros pueden asumir roles en tu nube y cuánto dato sensible alcanzan. Sentra advierte que el rol de Qubole figuraba en su lista de riesgos por llevar meses sin usarse y aun así poder llegar a datos críticos. Si un rol externo está sin uso, se elimina, no se vigila.
Recorta el permiso al mínimo real. The Hacker News señala que la guía de configuración de Qubole incluye una política de S3 de ejemplo que permite leer todos los buckets de la cuenta. Revisa qué puede tocar cada rol y qué documenta el proveedor como necesario. Todos los secretos que se filtraron en este caso venían de permisos que Qubole nunca necesitó.
Añade restricción de red. Una condición aws:SourceIp o aws:SourceVpce limitando AssumeRole a los rangos documentados del proveedor. Según Wiz, una condición de IP de origen sola habría bloqueado todas las asunciones de rol que observaron.
Activa logs que te dejen responder. Traza de organización en todas las cuentas y regiones, más S3 data events o server access logs en los buckets con datos sensibles. Sin eso, ante un incidente no sabrás qué se llevaron. Y recuerda que los plazos de notificación de brecha pueden ser de apenas 72 horas.
Prepara la contención antes del incidente. Si un rol fue asumido: rota todos los secretos a los que tenía acceso y revoca las sesiones activas. Rotar una credencial no termina las sesiones ya emitidas, algo que el informe de ConnectWise también subrayó.

Conclusión

El ataque a los clientes de Qubole deja una lección que aplica a cualquier startup con infraestructura en la nube: la seguridad de tu perímetro ya no depende solo de tus contraseñas, sino de cuánto confían tus sistemas en los de otros. El ExternalId, el MFA y las buenas prácticas de configuración funcionaron. El atacante entró igual, porque estaba usando una llave legítima en un horario y un rol que nadie monitoreaba.

La defensa realista es doble: reducir la superficie (menos permisos, menos roles, menos direcciones de origen posibles) y vigilar el comportamiento (qué hace cada identidad hoy comparado con lo que hacía antes). En este caso, el rol de Qubole llevaba meses dormido y volvió a la vida desde servidores alquilados de OVH y una VPN. Esa señal era visible. La pregunta incómoda para cualquier equipo es si tú la verías.