Acesso cross-account da Qubole é abusado em ataques reais, aponta Wiz

A Wiz, em conjunto com a Sentra e a Mandiant, observou entre 14 e 26 de outubro de 2026 um agente de ameaça usando credenciais IAM de uma conta AWS associada à Qubole (805246085872) para assumir roles que clientes criaram para confiar no fornecedor. O modelo é comum em plataformas SaaS: o cliente cria uma role com trust policy que permite à conta do fornecedor chamar sts:AssumeRole, normalmente protegida por um External ID. Todas as chamadas atribuídas ao atacante incluíram o External ID e todas tiveram sucesso. Em boa parte dos ambientes, as roles nem estavam em uso, mas a confiança continuava ativa.

Dentro dos ambientes, o ator enumerou serviços, leu variáveis de ambiente de Lambda (GetFunctionConfiguration), segredos do Secrets Manager e parâmetros do SSM. Usou o TruffleHog para validar chaves da AWS, client secrets do Entra ID e credenciais OAuth do Okta. Também baixou objetos do S3, às vezes buckets inteiros numa única sessão. A Wiz descreve o comportamento como oportunista e não encontrou ligação com outras campanhas públicas. Os eventos de gerenciamento do CloudTrail registram a assunção da role e a listagem de buckets, mas não a leitura dos objetos, que exige eventos de dados do S3 ou logs de acesso do servidor.

A Wiz achou ainda um ISO bootável (sso_agent.iso) hospedado no IP 57.129.54[.]120, que busca comandos via TCP 23458 e força reboot após 90 minutos. Não há deployments identificados nem confirmação de uso. Separadamente, de 8 a 11 de outubro, outro ator usou chaves AWS de clientes ligadas a integrações com a Qubole, sem vínculo comprovado com a campanha principal. Em poucos casos, houve comprometimento do ambiente da vítima.

Em 10 de novembro de 2026, o CEVIU noticiou "Acesso cross-account da Qubole foi abusado em ataques reais contra clientes na AWS", com a mesma janela de 14 a 26 de outubro e a mesma conta de origem. A cobertura de hoje acrescenta o segundo ator, que usou chaves de clientes entre 8 e 11 de outubro, e o ângulo da Wiz sobre o que fazer a partir daí.

Para quem opera AWS com integrações de terceiros, o caso mostra que a trust policy esquecida é superfície de ataque. Roles sem uso continuaram aceitando requisições. Na leitura da própria Wiz, uma condição de IP de origem sozinha teria barrado todas as assunções observadas. Vale inventariar roles que confiam em contas externas, remover as inativas e não tratar o External ID como segredo.