Brecha en Qubole: confianza en AWS convertida en llave maestra

Alguien entró en decenas de cuentas AWS de clientes entre el 14 y el 26 de octubre usando las claves propias de Qubole. No eran contraseñas robadas de las cuentas de los clientes, sino las credenciales del proveedor, las que su plataforma de datos en la nube usa legítimamente para asumir roles de IAM que los clientes habían creado para ella. Una vez dentro, el atacante enumeró recursos, vació almacenes de secretos, probó las credenciales obtenidas con TruffleHog y, en algunos casos, descargó buckets S3 completos, según las investigaciones de The Hacker News y CSO Online.

La campaña fue detectada por Sentra, una empresa de seguridad de datos con IA, e investigada por Wiz de Google, cuyos analistas del CIRT Zack Morrow, Sean Johnstone y Benjamin Read publicaron el análisis técnico, con respondedores de incidentes de Mandiant involucrados, según The Register. No se ha atribuido a ningún grupo, el objetivo parece oportunista y no del tipo espionaje, y hay un detalle que debería incomodar a cualquier arquitecto de seguridad que lea esto: muchos de los roles comprometidos pertenecían a organizaciones que habían dejado de usar Qubole. La confianza sobrevivió al contrato.

El mecanismo: una política de confianza que sobrevivió al proveedor

Mecánica rápida, porque todo el ataque se reduce a una sola llamada a la API con una identidad prestada. Qubole, una plataforma de data lake propiedad de Idera, opera dentro de las cuentas AWS de los clientes para gestionar cómputo y acceder al almacenamiento sin que los clientes entreguen claves de acceso de larga duración. El patrón estándar: el cliente crea un rol de IAM, y la política de confianza del rol permite que la cuenta AWS de Qubole (805246085872) invoque sts:AssumeRole sobre él. Se supone que el External ID actúa como una verificación de conocimiento compartido contra abusos de tipo confused deputy.

Aquí está el detalle que convierte esto en una historia de compromiso de proveedor y no de error de configuración del cliente: el External ID no se trata como un secreto. Según la propia guía de AWS sobre external ID, cualquiera que pueda ver el rol puede verlo. El atacante tenía credenciales de la cuenta AWS de Qubole, aunque no se ha revelado cómo las obtuvo, y cada solicitud maliciosa de AssumeRole que Wiz observó llevaba el External ID correcto y tuvo éxito. La cerradura funcionó exactamente como fue diseñada. El atacante tenía la llave.

Es la mecánica clásica de escalada de cualquier juego de sigilo: el uniforme del guardia te deja pasar todos los controles hasta que alguien revoca el uniforme. Nadie lo revocó. Wiz descubrió que muchos de los roles atacados no registraron actividad legítima de Qubole durante octubre, porque la relación con la plataforma ya estaba muerta, pero la política de confianza seguía activa, y eso es lo único que AssumeRole comprueba.

8–11 de octubre: el acto previo que nadie logra conectar del todo

Durante su investigación, Wiz detectó una campaña separada entre el 8 y el 11 de octubre que abusaba de otro método de integración: Qubole también permite que los clientes se conecten con sus propias claves de acceso de AWS en lugar de roles, y un atacante usó claves propiedad de clientes, presumiblemente configuradas para Qubole, para comprometer lo que The Register describe como un pequeño número de entornos víctima. Wiz afirma que no puede vincular esto de forma definitiva con el evento principal. Tómelo como una pregunta abierta, pero sugiere que quien estuvo detrás llevaba al menos una semana examinando la superficie de integración de Qubole antes de que comenzara la campaña de AssumeRole.

14–15 de octubre: la primera sangre a través de Mullvad

La primera actividad maliciosa confirmada ocurrió el 14 de octubre. Una dirección IP asociada a Mullvad VPN intentó asumir roles de integración de clientes desde la cuenta de Qubole usando un usuario de IAM identificado como AIDA3W7DIFLYOLTK63SFS. El equipo CIRT de Wiz hizo una observación contundente sobre este principal, citada en la cobertura de The Register:

En los entornos afectados, el equipo CIRT de Wiz no ha observado este usuario de IAM en ninguna actividad distinta de la asociada a este actor de amenazas.

Eso convierte a AIDA3W7DIFLYOLTK63SFS en un IOC de referencia: cualquier aparición en su CloudTrail es maliciosa por definición. La actividad continuó el 15 de octubre, y el 18 de octubre el atacante empezó a usar un segundo usuario de IAM de la misma cuenta de Qubole, AIDAJYRRH5Y3A7AAJM2HW, junto con otra dirección de Mullvad. Este requiere cuidado: el tráfico legítimo de Qubole también usa esa identidad, así que solo es un IOC cuando la dirección de origen está fuera de AWS. Wiz afirma que el tráfico real de Qubole procede solo de la infraestructura de AWS, lo que da a los defensores un discriminador claro.

La mayor parte de la actividad posterior se originó en un VPS alojado en OVH, 57.129.54[.]120 (con su equivalente IPv6 2001:41d0:70d[:]7800::). Las direcciones de Mullvad, 45.83.220[.]211, 185.209.199[.]73 y 89.37.63[.]175, son salida compartida de VPN, así que una coincidencia por sí sola no es prueba. El atacante también ejecutó sesiones de rol que empezaban por quiam-, como quiam-enum, lo cual es un gancho de caza muy útil.

Dentro de las cuentas: una carrera contrarreloj por los almacenes de secretos

Tras la asunción del rol, la táctica fue pura enumeración y cosecha, y sinceramente parece una lista de verificación de escalada de privilegios de un CTF ejecutada a escala de producción. El atacante mapeó buckets S3, bases de datos, instancias EC2, grupos de seguridad e identidades de IAM, y luego fue directo a los lugares donde los clientes de AWS guardan sus joyas de la corona: Secrets Manager, Parameter Store de Systems Manager y las variables de entorno de Lambda. Sentra informó de más de 100 contraseñas y claves leídas en minutos, además de miles de registros de credenciales adicionales dentro de archivos descargados.

Luego vino el movimiento interesante: el atacante pasó las credenciales obtenidas por TruffleHog, el escáner de secretos de código abierto, para validar qué funcionaba. El botín confirmado y activo incluía las propias claves de acceso AWS de las víctimas, credenciales de entidades de servicio de Microsoft Entra ID y credenciales OAuth de clientes de Okta. La guía de Wiz indica explícitamente a los defensores que revisen los registros de inicio de sesión del proveedor de identidad en busca del user agent de TruffleHog en llamadas a GetCallerIdentity. Ahí está la preocupación sobre el radio de impacto: esto no fue solo una brecha de AWS, fue un intermediario de credenciales para todo lo demás que esos entornos tocaban. Ya hemos visto lo que la exposición de tokens activos hace al alcance de un incidente: la brecha de Chainalysis que expuso tokens activos de todos los usuarios convirtió un compromiso único en una maratón de rotación cliente por cliente, y la misma lógica aplica aquí.

En S3, el comportamiento fue de arrasar con todo: enumerar buckets y objetos accesibles, extraer el contenido y, a veces, un bucket entero en una sola sesión. Ese oportunismo es la razón por la que Wiz afirma que el objetivo no encaja con los manuales de actores respaldados por Estados: sin selección, sin preparación, solo recolección masiva. Sentra señaló que el atacante no realizó operaciones de escritura en los entornos observados, algo coherente con una operación de robo y no con una posición previa para destrucción o ransomware.

El ISO que (probablemente) nunca se ejecutó

Un hallazgo merece precisión sobre qué está confirmado y qué es teórico. En la infraestructura OVH del atacante, Wiz descubrió una ISO de Linux arrancable llamada sso_agent.iso. Recopila información del sistema, se comunica con el servidor por el puerto TCP 23458 y ejecuta comandos de shell suministrados remotamente; su configuración sugiere que los sistemas Windows podrían haber sido el objetivo previsto. Pero Wiz no encontró despliegues de la imagen y no puede confirmar que se usara contra víctimas. Así que: capacidad observada, explotación no observada. Archívelo como «lo que estaban preparando», no como «lo que pasó».

La carencia de registros que más duele

Aquí está la parte que debería escocer. Los eventos de gestión de CloudTrail registran cada llamada AssumeRole y cada listado de buckets, así que sabemos que el atacante estuvo en la despensa de S3. Pero no registran qué objetos se leyeron. Eso requiere eventos de datos de S3 o registros de acceso al servidor, y varias víctimas no los tenían, lo que dejó a los equipos de respuesta sin poder determinar qué se llevaron realmente. No se puede delimitar una brecha que no se puede observar, y «no sabemos qué se robó» es la peor respuesta que puede dar a su equipo legal. Si este incidente le enseña una sola cosa, que sea una auditoría de eventos de datos.

Qué buscar y qué corregir

La guía de caza de Wiz apunta a CloudTrail desde el 1 de octubre en cada cuenta AWS que tenga un rol de Qubole. La lógica de la consulta principal:

eventName = "AssumeRole"
AND userIdentity.accountId = "805246085872"
AND sourceIPAddress NOT AWS-owned   -- Qubole's legit traffic is AWS-internal
-- High-fidelity indicators:
-- userIdentity.principalId = "AIDA3W7DIFLYOLTK63SFS"   (always malicious)
-- principalId = "AIDAJYRRH5Y3A7AAJM2HW" from non-AWS IP (malicious only off-AWS)
-- roleSessionName starts with "quiam-"
-- sourceIPAddress in 57.129.54.120, 2001:41d0:70d:7800::/64 (OVH)
-- userAgent contains "TruffleHog" on GetCallerIdentity

Para cada sesión sospechosa, rastree todo lo que hizo después: Secrets Manager, Parameter Store, Lambda, S3. Y tenga cuidado con la trampa que señaló The Register: rotar una credencial no termina las sesiones temporales ya emitidas. Si se asumió un rol, debe rotar por completo cada secreto alcanzable, no solo la credencial de la integración. Eso incluye los secretos de Entra ID y las credenciales de cliente de Okta, porque el atacante también validó esas.

En el plano estructural, las recomendaciones de Wiz parecen una plantilla de auditoría para cada concesión a un proveedor SaaS que tenga, no solo para Qubole:

• Elimine la confianza obsoleta. Si dejó de usar un proveedor, borre el rol. Una política de confianza sin tráfico legítimo es una puerta cargada que nadie vigila.
• Limite el principal. Confíe en principales IAM específicos del proveedor, no en una cuenta AWS externa completa. La confianza a nivel de cuenta fue lo que convirtió el compromiso de Qubole automáticamente en su compromiso.
• Fije la ruta de red. Añada condiciones aws:SourceIp o de endpoint VPC que coincidan con los rangos documentados del proveedor. Este atacante operó desde Mullvad y OVH; una condición de IP de origen habría detenido en seco cada solicitud observada.
• Deje de tratar los External ID como secretos. Cualquiera con acceso al rol puede verlos. Son una verificación contra confused deputy, no autenticación.
• Active los eventos de datos de S3. Varias víctimas no pueden decir qué se llevaron. No sea una de esas víctimas.

Ni Qubole ni Idera habían publicado una declaración cuando The Hacker News lo comprobó, y Qubole no respondió a las consultas de The Register. También se desconoce si las credenciales comprometidas han sido desactivadas o si la actividad se ha detenido. Así que la cuestión de la confianza en el proveedor se sostiene por sí sola: el modelo de integración no está roto, porque los roles con mínimo privilegio superan siempre a las claves de larga duración, pero traslada el riesgo a la higiene de credenciales del proveedor, y este mes ese riesgo se materializó en decenas de entornos cuyos dueños, en muchos casos, habían olvidado que la puerta existía.