El ataque a Qubole entró por los roles IAM en AWS que los propios clientes crearon para la plataforma: entre el 14 y el 26 de octubre, un intruso con credenciales de la cuenta de Qubole asumió esos roles de integración y salió con secretos, configuraciones y archivos de Amazon S3 de decenas de empresas.

Nadie forzó una cerradura. Wiz, que investigó el caso con Sentra y Mandiant, reveló que cada solicitud de asunción de rol llevaba el External ID correcto, el código que acompaña a estos accesos entre cuentas, y que cada una tuvo éxito. La mayoría de esos roles no registraba uso del proveedor en todo octubre: la confianza seguía activa aunque el trabajo ya no existiera.

Qubole es una plataforma de procesamiento y análisis de datos en la nube. Para operar dentro de la cuenta de AWS de cada cliente, el cliente crea un rol con una política de confianza que autoriza a la cuenta del proveedor a asumirlo y recibir credenciales temporales. Es el estándar para estas integraciones, y fue la puerta que el intruso encontró abierta.

La primera actividad observada llegó el 14 de octubre desde una dirección de Mullvad VPN, con el usuario IAM AIDA3W7DIFLYOLTK63SFS de la cuenta 805246085872, la cuenta de operaciones de Qubole. Ese usuario no apareció en ninguna otra actividad: solo actuó en manos del intruso. Desde el 15 de octubre, casi todo el tráfico salió de un servidor alquilado en OVH, y el 18 entró en juego un segundo usuario IAM de la misma cuenta, que también mueve tráfico legítimo de la plataforma.

Sentra contó 100 contraseñas y claves en siete minutos



La empresa de seguridad de datos que detectó la actividad en varios de sus clientes y avisó a Wiz confirmó decenas de víctimas y millones de archivos robados de un solo cliente. Su medición de velocidad retrata la campaña: unas 100 contraseñas y claves leídas en siete minutos, desde tres lugares distintos donde estaban guardadas, y miles de registros de credenciales más dentro de los archivos descargados.

Ya dentro, el recorrido se repetía con orden de fábrica. El intruso enumeraba cómputo, redes y bases de datos, abría las variables de entorno de las funciones Lambda, listaba los secretos de Secrets Manager y los leía con GetSecretValue, y revisaba los parámetros de Systems Manager. Las sesiones de rol llevaban nombres con el prefijo quiam-, como quiam-enum y quiam-scope-full, una firma publicada para quien busque en sus registros.

Las credenciales halladas en los entornos de las víctimas, no las del proveedor, pasaron por TruffleHog, herramienta abierta que busca secretos y comprueba si una clave sigue viva. Con ella el intruso validó claves de AWS, secretos de cliente de Microsoft Entra ID y credenciales OAuth de Okta en ráfagas de segundos. El patrón recuerda al de AntiFox, la plataforma de pruebas con IA que llegó a los secretos de producción en AWS con credenciales válidas: otra vez, el fallo no estaba en un programa, sino en lo que unas credenciales legítimas podían alcanzar.

La descarga siguió la misma secuencia en cada cuenta: asumir el rol, listar los depósitos de S3 al alcance, revisar su contenido y bajarlo con GetObject. BleepingComputer reportó que el intruso no hizo operaciones de escritura en los entornos observados por Sentra, un detalle que explica el silencio de la campaña durante casi dos semanas: nada se rompió, nada se borró, solo se copió. En algunos casos, depósitos completos bajaron en una sesión.

Wiz encontró además una imagen de disco de arranque, sso_agent.iso, alojada en el servidor del intruso: arranca un reloj de 90 minutos, recoge información del equipo y espera órdenes por un puerto TCP. La firma no halló instalaciones de esa imagen en víctimas ni pudo confirmar su uso.

El arreglo no es un parche: es borrar la confianza que sobra



Este ataque a Qubole no tiene CVE ni actualización que lo cierre, porque no explotó ningún fallo de software. AWS lo dijo con todas las letras en la respuesta que recogió BleepingComputer: sus servicios no fueron comprometidos y operaron tal como fueron diseñados; la actividad usó credenciales de un proveedor externo contra roles que los clientes configuraron para confiar en ese proveedor. Qubole no había publicado ningún anuncio del incidente, y cómo se obtuvieron sus dos usuarios IAM sigue sin explicación pública.

La caza que propone Wiz empieza en CloudTrail, el registro de actividad de AWS, desde el 1 de octubre, en cada cuenta con un rol de integración: asunciones de los roles IAM en AWS desde la cuenta 805246085872 con direcciones de origen que no sean de AWS, cualquier actividad del usuario AIDA3W7DIFLYOLTK63SFS y sesiones con nombres quiam-. Si un rol quedó asumido, toca rotar cada secreto que ese rol podía leer y revocar las sesiones ya emitidas, porque rotar una credencial no cierra las sesiones temporales abiertas.

El dato que mejor resume la lección quedó en el informe de Wiz: una sola condición de dirección IP de origen en la política de confianza, limitada a las redes documentadas del proveedor, habría bloqueado cada asunción de rol observada en octubre. El External ID no salva a nadie: viaja en texto claro en los registros y funciona como identificador, no como secreto. Las integraciones que una empresa ya no usa, con su rol borrado, son la única puerta de este tipo que no se puede abrir.

Fuente: Wiz