Ataque ao Qubole explora papel de confiança da AWS e expõe contas de clientes

O que aconteceu, segundo a Wiz

Entre 14 e 26 de outubro de 2026, um atacante invadiu contas AWS de várias organizações clientes da Qubole, plataforma de data lake controlada pela Idera, e roubou segredos e dados armazenados. A informação é da empresa de segurança em nuvem Wiz, que publicou a análise técnica hoje (9 de novembro). A Sentra identificou a atividade em ambientes de clientes e acionou os pesquisadores da Wiz, que então mapearam o alcance do ataque em outras contas.

O ponto central do incidente: o atacante não comprometeu a infraestrutura da Qubole diretamente, nem explorou uma vulnerabilidade de software. Ele usou credenciais da conta AWS que a Qubole utiliza para operar dentro das contas dos clientes, a 805246085872. Como essas credenciais foram obtidas não foi divulgado.

Como a integração funciona (e por que ela vira porta de entrada)

Para conectar o Qubole a uma conta AWS, o cliente cria uma IAM role com uma trust policy que autoriza a conta da Qubole a assumi-la via AssumeRole. Cada chamada precisa incluir um código chamado External ID, pensado para impedir o chamado "confused deputy problem": sem ele, qualquer cliente da Qubole poderia assumir a role de outro cliente.

O problema é que o External ID não é segredo. Ele aparece em texto plano nos logs do CloudTrail e costuma estar salvo em arquivos de infraestrutura como código e em documentação de onboarding. A própria orientação da AWS sobre external ID já deixa isso explícito: é um controle de mitigação, não uma credencial.

Segundo a Wiz, toda chamada AssumeRole ligada ao atacante trazia o External ID correto e, por isso, era aceita normalmente pela AWS. A maioria das roles que o atacante assumiu estava sem uso ativo pelos próprios clientes, mas continuava confiando na conta da Qubole, o que bastou para o ataque funcionar.

O que o atacante fez depois de entrar

Dentro de cada conta, a atuação seguiu um padrão consistente de coleta de credenciais:

• leu variáveis de ambiente de funções Lambda;
• extraiu segredos do Secrets Manager;
• leu valores do SSM Parameter Store;
• rodou tudo isso pelo TruffleHog para validar quais credenciais ainda funcionavam, incluindo chaves de acesso AWS, client secrets do Entra ID e credenciais de cliente do Okta.

No S3, o atacante copiou dados de qualquer bucket que a role alcançava, sem direcionar a busca a um tipo específico de dado, e em algumas sessões baixou um bucket inteiro de uma vez. A Wiz não associou a campanha a nenhum grupo conhecido nem a atividade típica de ator estatal.

Um segundo incidente, por uma porta diferente

Além do abuso de AssumeRole, a Qubole também permite conexão por chaves de acesso AWS tradicionais em vez de role. Entre 8 e 11 de outubro, outro atacante usou chaves de acesso dos próprios clientes, aparentemente configuradas para uso com a Qubole, para comprometer alguns ambientes de nuvem. A Wiz não encontrou ligação entre esse episódio e o abuso de roles que ocorreu nas semanas seguintes, o que sugere duas frentes de exposição distintas dentro da mesma integração.

O que checar agora no CloudTrail

Se sua organização já conectou o Qubole à AWS em algum momento, mesmo que não use mais o serviço, a Wiz recomenda revisar logs do CloudTrail desde 1º de outubro em busca de:

• requisições AssumeRole em que userIdentity.accountId é 805246085872 e sourceIPAddress não pertence a um endereço AWS (o tráfego legítimo da Qubole, segundo a Wiz, só veio de dentro da AWS);
• atividade do IAM principal AIDA3W7DIFLYOLTK63SFS, usado exclusivamente pelo atacante nas contas examinadas;
• atividade do IAM principal AIDAJYRRH5Y3A7AAJM2HW vinda de fora da AWS (esse principal também é usado em tráfego legítimo da Qubole, então o filtro é a origem, não o ID);
• os IPs 57.129.54.120 e 2001:41d0:70d:7800::, hospedados na OVH, e os IPs de VPN Mullvad 45.83.220.211, 185.209.199.73 e 89.37.63.175 (compartilhados com outros usuários da VPN, portanto não são prova isolada);
• nomes de sessão iniciados por quiam-, como quiam-enum;
• chamadas GetCallerIdentity com user agent do TruffleHog, cruzadas com os IPs acima e com os logs de login do seu provedor de identidade.

Um ponto que a Wiz destacou como limitação prática: eventos de gerenciamento do CloudTrail registram cada AssumeRole e cada listagem de bucket, mas não qual objeto do S3 foi lido. Isso exige data events do S3 ou logs de acesso ao servidor S3 habilitados antes do incidente. Em vários clientes afetados, essa telemetria não existia, e os respondentes não conseguiram determinar o que exatamente havia sido lido.

O que decidir neste trimestre

Para quem responde pela conta AWS da empresa, o incidente do Qubole não é sobre trocar de fornecedor de data lake. É sobre um padrão de arquitetura que se repete em dezenas de integrações: role de confiança ampla, concedida uma vez no onboarding e nunca revisada depois.

Uma condição de IP de origem sozinha teria bloqueado toda assunção de role que observamos.

A source IP condition alone would have blocked every role assumption we observed.Pesquisadores da Wiz, análise técnica do incidente

A recomendação prática, e o item que cabe entrar no checklist de governança deste trimestre, tem cinco frentes:

1. Trocar o :root genérico na trust policy por um IAM principal específico, nos fornecedores que suportam isso.
2. Adicionar condição aws:SourceIp ou aws:SourceVpce restringindo AssumeRole às faixas de rede documentadas do fornecedor.
3. Tratar o External ID como visível por definição: trocá-lo após qualquer incidente e usar um valor diferente por role, nunca um único valor compartilhado entre integrações.
4. Remover roles de fornecedores que não são mais usados, em vez de deixá-las ociosas e confiando na conta de terceiros.
5. Revisar o escopo de cada role de fornecedor: o próprio guia de setup da Qubole traz como exemplo uma política de S3 que libera leitura de todos os buckets da conta, concedida por conveniência.

Em resumo: o custo de não decidir agora não é teórico. Se a sua conta tiver uma role do Qubole sem uso, com trust policy ampla e sem logging de data events no S3, você está exposto ao mesmo vetor e sem telemetria para saber, se já foi explorado, o que exatamente saiu do bucket. Para empresas brasileiras sob LGPD, essa lacuna de visibilidade vira um problema regulatório, não só técnico: sem saber qual objeto foi lido, não há como avaliar se houve incidente de dados pessoais a reportar.

Quem administra IAM no dia a dia deve tratar toda role de terceiro, usada ou não, como superfície ativa: alertas para AssumeRole vindo de rede não documentada do fornecedor, revisão trimestral de trust policies e, nos fornecedores críticos, pedido formal de faixa de IP fixa para a condição aws:SourceIp. Nem Qubole nem Idera haviam publicado comunicado sobre o incidente até o fechamento desta matéria, e a Wiz não informou se as credenciais usadas pelo atacante já foram desativadas.

Fonte: The Hacker News