# Ataque explora confiança em integrações AWS e expõe dados de clientes da Qubole

> Ataque à AWS via Qubole expõe falhas em integrações e políticas IAM, afetando dezenas de empresas. Entenda riscos para ambientes corporativos na nuvem.

Publicado em 11/11/2026 · Atualizado em 11/11/2026 · Wi-Fi & Segurança
ATLAS · Tech & Business Review, portal editorial da Upnetix · https://atlas.upnetix.com.br/ataque-explora-confianca-em-integracoes-aws-e-expoe-dados/

---

O recente ataque a clientes da Qubole, plataforma de big data hospedada na AWS, desafia uma das premissas mais confortáveis do mercado de nuvem: a crença de que integrações com fornecedores homologados são inerentemente seguras. Entre 14 e 26 de outubro de 2026, hackers exploraram credenciais de uma conta AWS confiável da própria Qubole para invadir ambientes de dezenas de empresas, exfiltrando credenciais e grandes volumes de dados. O episódio, detalhado por empresas de segurança como Wiz e Sentra, expõe não apenas falhas técnicas, mas uma complacência perigosa na gestão de relações de confiança entre organizações e fornecedores externos.

![Equipe de segurança cibernética analisando dados e códigos em telas em ambiente corporativo moderno.](https://upnetix.com.br/wp-content/uploads/2026/11/post47897-img1-intro.webp)

Equipe de segurança monitora incidentes após ataque que explorou credenciais IAM na conta AWS da Qubole entre 14 e 26 de outubro de 2026.

## Como o ataque foi articulado: abuso de relações de confiança

Segundo apuração da Wiz, publicada por CISO Advisor e CyberSec Brazil, o vetor inicial foi o comprometimento de dois usuários IAM (Identity and Access Management) da Qubole. Com essas credenciais, os atacantes conseguiram utilizar a operação *AssumeRole* do AWS Security Token Service (STS), assumindo funções em contas de clientes que haviam sido previamente configuradas para confiar na conta AWS da Qubole. Esse mecanismo, padrão em integrações SaaS, permite que fornecedores externos executem tarefas administrativas em ambientes de clientes sem a necessidade de credenciais diretas desses clientes.

O ataque não explorou uma vulnerabilidade técnica inédita, mas sim o abuso de credenciais legítimas e políticas de confiança que permaneceram ativas mesmo após o fim do uso efetivo da integração. A Wiz destaca que, em muitos casos, as funções IAM exploradas já não eram mais utilizadas, mas continuavam concedendo permissões amplas à conta da Qubole. Todas as solicitações maliciosas analisadas continham identificadores *External ID* válidos, exigidos pelas políticas de acesso dessas integrações.

## O que foi acessado: credenciais, segredos e buckets inteiros

Após assumir as funções IAM, os invasores mapearam recursos de nuvem, coletaram segredos armazenados no AWS Secrets Manager, no Systems Manager Parameter Store e leram variáveis de ambiente do AWS Lambda. De acordo com ambas as fontes, a ferramenta TruffleHog foi empregada para validar a utilidade das credenciais encontradas, incluindo chaves AWS, segredos de aplicações do Microsoft Entra ID e credenciais de clientes do Okta.

O alvo principal foi o armazenamento S3: os atacantes copiaram dados de todos os buckets aos quais tinham acesso, sem buscar por arquivos específicos. A Wiz relata que, em ao menos um caso, milhões de arquivos foram baixados de um único cliente em minutos. Esse comportamento oportunista foi facilitado por permissões excessivamente amplas concedidas a integrações de terceiros, como exemplificado pela própria documentação da Qubole, que sugere políticas de leitura para todos os buckets S3 da conta AWS do cliente.

![Diagrama ilustrativo do fluxo de AssumeRole entre a conta AWS da Qubole e contas de clientes, explicando abuso de credenciais IAM.](https://upnetix.com.br/wp-content/uploads/2026/11/post47897-img2-meio-1.webp)

Diagrama explicativo do uso da operação AssumeRole do AWS STS para assumir funções em contas clientes via credenciais IAM comprometidas.

## Impacto, limitações e o que não se sabe

O número total de empresas afetadas e o volume exato de dados exfiltrados permanecem incertos. Ambas as fontes confirmam dezenas de vítimas, mas não há consenso sobre a extensão do impacto. A Sentra, citada pelo CISO Advisor, relatou milhões de arquivos roubados de um único cliente, enquanto a CyberSec Brazil destaca que a investigação não associou a campanha a grupos hackers conhecidos nem detalhou o perfil dos alvos.

Uma limitação técnica relevante, apontada pela CyberSec Brazil, é a ausência de logs detalhados por padrão no AWS CloudTrail para acessos individuais a objetos S3. Muitas organizações não tinham eventos de dados do S3 habilitados, o que dificultou a reconstrução precisa das ações dos invasores e a identificação de quais arquivos específicos foram acessados ou copiados. Essa lacuna de visibilidade ampliou a incerteza sobre o alcance real do incidente.

## Resposta da AWS e recomendações do setor

Em nota ao BleepingComputer, a AWS afirmou que seus serviços funcionaram conforme projetado e que não houve comprometimento direto da infraestrutura da nuvem. O problema, segundo a empresa, decorre do uso de credenciais de um provedor terceirizado para assumir funções IAM que os próprios clientes haviam configurado para confiar nesse provedor. A AWS recomendou revisar funções IAM entre contas, remover integrações não utilizadas, aplicar o princípio do menor privilégio e adicionar restrições de IP de origem às políticas de confiança.

A Wiz e a Sentra sugerem que todas as organizações que tenham integrado a Qubole à AWS revisem seus registros do CloudTrail a partir de 1º de outubro de 2026, buscando solicitações *AssumeRole* originadas da conta AWS 805246085872 (da Qubole) e correlacionando com endereços IP externos à AWS. Também recomendam a rotação imediata de credenciais expostas, revogação de sessões de função ativas e auditoria detalhada de acessos ao Secrets Manager, Parameter Store, Lambda e S3.

![Servidor de armazenamento de dados em nuvem com múltiplos racks em ambiente corporativo moderno.](https://upnetix.com.br/wp-content/uploads/2026/11/post47897-img3-meio-2.webp)

Servidores que armazenam buckets S3 acessados e exfiltrados pelos atacantes durante o incidente envolvendo a Qubole.

## O contra-argumento: até que ponto a culpa é da integração?

O posicionamento da AWS, de que a infraestrutura operou conforme esperado, levanta um debate relevante sobre responsabilidade compartilhada. Por um lado, a configuração de políticas de confiança amplas e permissões excessivas é uma decisão do cliente, muitas vezes orientada por exemplos de documentação do próprio fornecedor. Por outro, a dependência de integrações SaaS para operações críticas de dados cria uma superfície de ataque que pode ser difícil de monitorar e restringir sem impacto operacional.

Há quem argumente que a exigência de *External ID* e a segregação de funções seriam suficientes para mitigar riscos, mas o caso mostra que, na prática, integrações antigas ou mal gerenciadas permanecem como pontos cegos. A ausência de logs detalhados por padrão no S3 também é criticada por especialistas em segurança, pois limita a capacidade de resposta a incidentes mesmo em organizações com governança madura.

## Implicações para empresas: o que muda na gestão de nuvem e conectividade

O episódio da Qubole expõe um risco subestimado por muitas organizações: a manutenção de relações de confiança e permissões amplas com fornecedores externos, mesmo após o fim do uso efetivo da integração. Para empresas que operam ambientes críticos na nuvem, especialmente no contexto do Polo Industrial de Manaus e setores que dependem de processamento intensivo de dados, o incidente reforça a necessidade de revisões periódicas de políticas IAM, segmentação de permissões e monitoramento contínuo de integrações SaaS.

Além disso, a limitação de visibilidade sobre acessos a dados estratégicos, como buckets S3, evidencia a importância de habilitar logs detalhados e de contar com infraestrutura de conectividade que permita respostas rápidas a incidentes. A dependência de integrações para automação e análise de dados não deve ser um álibi para negligenciar o controle sobre quem pode acessar, de onde e com que privilégios. O custo de uma brecha desse tipo, em termos de exposição de propriedade intelectual, dados de clientes e continuidade operacional, pode ser muito maior do que o investimento em governança e monitoramento proativos.

![Analista de segurança cibernética analisando logs do AWS CloudTrail em monitor no escritório.](https://upnetix.com.br/wp-content/uploads/2026/11/post47897-img4-fechamento.webp)

Análise dos logs do AWS CloudTrail evidenciando limitações na auditoria de acessos a objetos S3 durante investigação do ataque. O ataque à cadeia de confiança via Qubole deixa claro que, na nuvem, o elo mais fraco pode ser uma integração esquecida ou uma política de acesso herdada. Para quem decide em TI, o alerta é direto: revisar permissões, monitorar integrações e garantir visibilidade sobre acessos é tão crítico quanto investir em capacidade computacional ou largura de banda. Não basta confiar na reputação do fornecedor ou na robustez da plataforma, a superfície de ataque é tão ampla quanto a sua política de confiança permitir.

Fonte: https://atlas.upnetix.com.br/ataque-explora-confianca-em-integracoes-aws-e-expoe-dados/ · ATLAS, portal editorial da Upnetix (Manaus, Brasil) · uso com citação obrigatória.