Entre el 14 y el 26 de octubre, un actor malintencionado logró entrar en varias cuentas de Amazon Web Services (AWS) que pertenecían a clientes de la plataforma de lagos de datos Qubole. La intrusión fue detectada por la empresa de seguridad en la nube Wiz, que describió cómo el invasor utilizó credenciales vinculadas a la cuenta de Qubole para ejecutar peticiones AssumeRole y acceder a recursos críticos.
¿Cómo se produjeron las suplantaciones?
Qubole, propiedad del grupo Idera, opera dentro de la infraestructura del cliente mediante un rol IAM creado por cada empresa. El trust policy del rol autoriza a la cuenta de Qubole (ID 805246085872) a asumir el rol siempre que la petición incluya el External ID asociado. Este identificador no se trata como secreto; cualquiera con permiso sobre el rol puede verlo, tal como indica la guía de AWS. Los investigadores de Wiz observaron que todas las solicitudes del atacante contenían el External ID correcto y fueron aceptadas sin objeciones.
En varios entornos, la mayoría de los roles suplantados estaban inactivos, pero aun así mantenían la confianza hacia la cuenta de Qubole, lo que permitió al atacante ejecutar los AssumeRole necesarios. El Sentra detectó la actividad irregular y alertó a los investigadores, quienes posteriormente rastrearon la cadena de acciones del intruso.
Acciones realizadas dentro de las cuentas comprometidas
Una vez dentro, el atacante buscó credenciales almacenadas: extrajo variables de entorno de funciones Lambda, obtuvo claves de Secrets Manager y leyó valores del SSM Parameter Store. Cada credencial encontrada se sometió a la herramienta TruffleHog para comprobar su validez. Entre los datos expuestos estaban claves de acceso de AWS, secretos de clientes de Entra ID y credenciales de Okta.
Además, el actor descargó información de S3 sin filtrar: accedió a cualquier bucket que el rol pudiera ver y, en ocasiones, descargó un bucket entero en una sola sesión. Los registros de CloudTrail mostraron las peticiones de AssumeRole a partir del 1 de octubre, con direcciones IP externas como 57.129.54.120, 2001:41d0:70d:7800:: y otras pertenecientes a servicios VPN como Mullvad (45.83.220.211, 185.209.199.73, 89.37.63.175).
Indicadores de compromiso y recomendaciones técnicas
Wiz propone buscar en los logs de CloudTrail los siguientes patrones:
– userIdentity.accountId igual a 805246085872 y sourceIPAddress fuera de los rangos de AWS.
– Identificadores de IAM AIDA3W7DIFLYOLTK63SFS o AIDAJYRRH5Y3A7AAJM2HW usados desde IPs externas.
– Nombres de sesión que comienzan con quiam-.
– Agentes de usuario que indiquen el uso de TruffleHog en llamadas a GetCallerIdentity.
Para remediar la brecha, los expertos aconsejan rotar todas las llaves y secretos a los que el rol comprometido tenía acceso, revocar sesiones activas, eliminar roles de Qubole que ya no se utilicen y, sobre todo, añadir una condición aws:SourceIp o aws:SourceVpce que limite las peticiones a rangos de red documentados por el proveedor. Como citó el informe de Wiz, “a source IP condition alone would have blocked every role assumption we observed”. Además, se sugiere sustituir el uso del root principal en la política de confianza por el identificador IAM específico del servicio Qubole y generar External IDs únicos por rol.
Finalmente, activar logs de eventos de datos en S3 o habilitar los registros de acceso al servidor permitirá identificar qué objetos fueron leídos, algo que faltó en varios casos y dificultó la evaluación del alcance del robo.
