Ataque a la cadena de suministro de Qubole expone secretos de AWS mediante roles IAM de confianza

Entre el 14 y el 26 de octubre de 2026, un atacante comprometió múltiples cuentas de AWS pertenecientes a clientes de Qubole, una plataforma de lago de datos propiedad de Idera. La firma de seguridad en la nube Wiz informó que el intruso utilizó credenciales robadas de la propia cuenta de AWS de Qubole para eludir los controles de seguridad y acceder a los entornos de los clientes.

Esta brecha destaca una vulnerabilidad crítica en la forma en que se otorga acceso a proveedores externos a la infraestructura en la nube. Al aprovechar roles de Identity and Access Management (IAM) de confianza, el atacante pudo extraer secretos sensibles y copiar grandes volúmenes de datos sin necesidad de descifrar contraseñas individuales ni explotar errores a nivel de aplicación.

Qué ocurrió

Qubole opera dentro de las cuentas de AWS de sus clientes asumiendo roles IAM que los clientes crean específicamente para la plataforma. Estos roles incluyen una política de confianza que permite a la cuenta de AWS de Qubole asumir los permisos del rol. Para validar estas solicitudes, AWS requiere un External ID, un código proporcionado por Qubole. El atacante obtuvo credenciales para la cuenta central de AWS de Qubole y las usó para enviar solicitudes AssumeRole a las cuentas de los clientes.

Los investigadores de Wiz señalaron que muchos de los roles comprometidos no eran utilizados por los clientes, pero permanecían activos en sus configuraciones. Dado que la relación de confianza seguía vigente, las solicitudes del atacante fueron aceptadas siempre que incluyeran el External ID correcto. Esto permitió al intruso moverse lateralmente a través de múltiples entornos de clientes durante la ventana de dos semanas.

Además de la intrusión basada en roles, se produjo una actividad separada pero no relacionada entre el 8 y el 11 de octubre. Durante este período, un atacante utilizó claves de acceso de AWS que se cree estaban configuradas para Qubole para comprometer algunos entornos en la nube. Wiz no ha conectado este evento anterior con la campaña principal que involucra el abuso de AssumeRole.

Cómo funciona

El mecanismo central de este ataque se basó en el patrón estándar de acceso entre cuentas de AWS. Cuando un proveedor como Qubole necesita gestionar recursos en la cuenta de un cliente, el cliente crea un rol IAM con una política de confianza que apunta al ID de la cuenta del proveedor. Luego, el proveedor utiliza la llamada API AssumeRole para obtener temporalmente esos permisos. El External ID está diseñado para prevenir problemas de deputy confuso, pero no es un secreto. Es visible en los registros de CloudTrail y a menudo se almacena en archivos de infraestructura como código.

Una vez dentro, el atacante no necesitó adivinar contraseñas. Inmediatamente comenzó a cosechar credenciales existentes. El intruso leyó variables de entorno de funciones Lambda, extrajo secretos de AWS Secrets Manager y accedió a valores en SSM Parameter Store. Para verificar qué credenciales eran válidas, el atacante utilizó TruffleHog, una herramienta de código abierto para detectar secretos, para probar claves de acceso de AWS, secretos de cliente de Entra ID y credenciales de cliente de Okta.

La exfiltración de datos fue amplia en lugar de dirigida. El atacante copió datos de cualquier bucket de S3 al que pudiera acceder el rol asumido. En algunos casos, se descargaron buckets completos en una sola sesión. Debido a que los roles a menudo tenían permisos de lectura amplios por conveniencia, el atacante pudo acceder a cantidades significativas de información almacenada sin necesitar escalar privilegios adicionales.

Detalles clave

• Cuenta del Atacante: Las solicitudes maliciosas de AssumeRole se originaron desde el ID de cuenta de AWS 805246085872, que pertenece a Qubole.
• Período: El ataque principal basado en roles ocurrió entre el 14 y el 26 de octubre de 2026.
• Indicadores de Compromiso: Busque solicitudes AssumeRole desde la cuenta 805246085872 con direcciones IP de origen fuera de AWS, particularmente desde rangos de VPN de OVH o Mullvad.
• Usuarios IAM Específicos: Investigue la actividad desde los IDs de principal IAM AIDA3W7DIFLYOLTK63SFS y AIDAJYRRH5Y3A7AAJM2HW si provienen de IPs no-AWS.
• Herramientas: El atacante utilizó TruffleHog para validar credenciales robadas, identificable por su user agent en llamadas GetCallerIdentity.
• Lagunas en los Registros: Muchas víctimas carecían de eventos de datos de S3 o registros de acceso de servidor, lo que hizo imposible determinar exactamente qué objetos fueron leídos.

Por qué importa

Para los equipos de ingeniería, este incidente subraya el riesgo del acceso inactivo de proveedores. Incluso si un servicio ya no se usa activamente, los roles IAM y las políticas de confianza a menudo permanecen vigentes. Estas conexiones olvidadas crean una amplia superficie de ataque que los hackers pueden explotar si las credenciales centrales del proveedor son comprometidas. Esto desplaza la carga de seguridad de simplemente proteger su propio perímetro a verificar la higiene de cada integración de terceros.

El ataque también demuestra las limitaciones de los External IDs como control de seguridad. Como no son secretos, no pueden prevenir el acceso no autorizado si las credenciales de la cuenta de confianza son robadas. Los ingenieros deben tratar los roles de proveedores con el mismo escrutinio que los roles administrativos internos, aplicando condiciones de red estrictas y principios de mínimo privilegio. Confiar en guías de configuración predeterminadas, que a menudo otorgan acceso amplio de lectura a S3, puede llevar a una pérdida catastrófica de datos cuando esos roles son abusados.

Qué puede hacer

• Audite los registros de CloudTrail desde el 1 de octubre de 2026 en adelante buscando solicitudes AssumeRole desde la cuenta 805246085872 originadas desde direcciones IP no-AWS.
• Rotee todos los secretos, parámetros y variables de entorno de Lambda accesibles por cualquier rol de Qubole que muestre signos de compromiso, y revoque sesiones activas.
• Elimine cualquier rol IAM de Qubole que ya no sea necesario o actualice la política de confianza para eliminar el ID de cuenta de Qubole si el servicio ha sido discontinuado.
• Agregue condiciones aws:SourceIp o aws:SourceVpce a las políticas de confianza de roles de proveedores para restringir el acceso a los rangos de red documentados del proveedor.
• Habilite eventos de datos de S3 o registros de acceso de servidor para todos los buckets que contengan datos sensibles para asegurar visibilidad futura sobre el acceso a nivel de objeto.
• Reemplace el principal :root de toda la cuenta en las políticas de confianza con principales IAM específicos donde sea compatible, y use External IDs únicos para cada rol.