Hackers invadem contas AWS de clientes da Qubole e roubam credenciais e dados armazenados

Hackers comprometeram contas da Amazon Web Services (AWS) pertencentes a diversos clientes da Qubole, plataforma de gerenciamento de dados da Idera, explorando credenciais de uma conta confiável utilizada pela própria fornecedora para acessar ambientes corporativos. Os ataques ocorreram entre 14 e 26 de outubro de 2026 e resultaram no roubo de informações armazenadas, credenciais e segredos de autenticação.

A campanha foi identificada pela empresa de segurança em nuvem Wiz, que constatou que os invasores utilizaram credenciais de uma conta AWS pertencente à infraestrutura da Qubole para assumir permissões dentro dos ambientes de seus clientes. A origem do comprometimento dessas credenciais ainda não foi esclarecida.

O ataque explorou uma relação de confiança previamente estabelecida entre as organizações e a plataforma, permitindo que os hackers acessassem recursos internos sem precisar comprometer diretamente as credenciais individuais de cada cliente.

Como os hackers exploraram a relação de confiança na AWS

A Qubole opera dentro das contas AWS de seus clientes para executar atividades relacionadas ao processamento e gerenciamento de dados. Para permitir essa integração, as organizações configuram funções do AWS Identity and Access Management (IAM), conhecidas como IAM Roles, que concedem permissões específicas à plataforma.

Essas funções possuem políticas de confiança que autorizam uma conta AWS da Qubole a assumir temporariamente determinadas permissões por meio da operação AssumeRole, do serviço AWS Security Token Service (STS).

Como mecanismo adicional de validação, cada solicitação precisa apresentar um identificador chamado External ID, associado à integração.

Segundo a Wiz, os invasores conseguiram realizar solicitações AssumeRole utilizando a conta confiável da Qubole e os respectivos identificadores exigidos pelas políticas de acesso.

Todas as solicitações maliciosas analisadas continham um External ID válido e foram aceitas pela AWS.

O problema não estava em uma vulnerabilidade conhecida do serviço IAM, mas no abuso de credenciais autorizadas e de relações de confiança que continuavam ativas nos ambientes dos clientes.

Um detalhe importante identificado pelos pesquisadores é que muitas das funções exploradas já não eram utilizadas pelas organizações. Entretanto, como suas políticas ainda autorizavam a conta da Qubole, os invasores conseguiram assumir essas permissões normalmente.

Credenciais da AWS, Microsoft Entra ID e Okta foram acessadas

A atividade suspeita foi inicialmente identificada pela empresa de segurança Sentra em ambientes de diversos clientes, que posteriormente alertou os pesquisadores responsáveis pela investigação.

Após obter acesso às contas AWS, os invasores concentraram suas ações na localização de credenciais e informações sensíveis armazenadas nos serviços de nuvem.

Entre os recursos acessados estavam:

• AWS Lambda: leitura de variáveis de ambiente que poderiam conter credenciais e informações de configuração.

• AWS Secrets Manager: recuperação de segredos utilizados por aplicações e serviços.

• AWS Systems Manager Parameter Store: acesso a parâmetros armazenados, incluindo valores sensíveis.

• Amazon S3: cópia de arquivos e conjuntos de dados armazenados em buckets.

As informações coletadas incluíam chaves de acesso da AWS, segredos de aplicações do Microsoft Entra ID e credenciais de clientes do Okta.

Os hackers utilizaram a ferramenta TruffleHog, normalmente empregada para identificar segredos expostos, para verificar se as credenciais encontradas ainda estavam válidas.

Essa etapa permitia identificar quais informações poderiam ser utilizadas para autenticação em outros serviços e ambientes.

Invasores copiaram dados de buckets inteiros do Amazon S3

Além da coleta de credenciais, a investigação identificou atividades de exfiltração de dados armazenados no Amazon S3.

Segundo a Wiz, os responsáveis não demonstraram interesse em localizar arquivos específicos. Em vez disso, tentaram recuperar todos os dados aos quais as funções IAM comprometidas concediam acesso.

Em algumas situações, os invasores conseguiram baixar o conteúdo completo de um bucket durante uma única sessão.

Esse comportamento foi facilitado pelas permissões excessivamente amplas atribuídas a determinadas integrações de terceiros.

Os pesquisadores observaram que a documentação de configuração da Qubole inclui um exemplo de política que permite acesso de leitura a todos os buckets S3 de uma conta AWS.

Quando permissões desse tipo são concedidas a fornecedores externos, o comprometimento de uma única identidade confiável pode expor grandes volumes de informações.

A investigação não informou o número total de organizações afetadas nem a quantidade de dados efetivamente extraídos.

Ataques anteriores utilizaram chaves de acesso de clientes

A Wiz também identificou outra atividade suspeita ocorrida entre 8 e 11 de outubro de 2026, antes da campanha principal.

Nesse período, um invasor utilizou chaves de acesso AWS pertencentes aos próprios clientes, que, segundo os pesquisadores, provavelmente haviam sido configuradas para integração com a Qubole.

A utilização dessas credenciais permitiu comprometer alguns ambientes de nuvem.

Entretanto, os pesquisadores não conseguiram estabelecer uma relação entre essa atividade e os ataques posteriores baseados no abuso de AssumeRole.

A investigação também não associou a campanha a grupos hackers previamente identificados.

Segundo a Wiz, o padrão de seleção dos alvos não corresponde ao comportamento normalmente observado em operações conduzidas por grupos patrocinados por governos.

Wiz divulga indicadores para identificar contas comprometidas

A empresa recomenda que todas as organizações que tenham integrado a Qubole à AWS, inclusive aquelas que não utilizam mais a plataforma, revisem seus registros do AWS CloudTrail a partir de 1º de outubro de 2026.

O principal indicador envolve solicitações AssumeRole originadas da conta AWS 805246085872, utilizada pela infraestrutura da Qubole, quando associadas a endereços IP externos à AWS.

Os pesquisadores também divulgaram outros indicadores de comprometimento:

Indicador	Detalhes
Conta AWS	805246085872
IAM Principal ID	AIDA3W7DIFLYOLTK63SFS
IAM Principal ID	AIDAJYRRH5Y3A7AAJM2HW
IP OVH	57.129.54[.]120
IP OVH IPv6	2001:41d0:70d:7800::
IP Mullvad VPN	45.83.220[.]211
IP Mullvad VPN	185.209.199[.]73
IP Mullvad VPN	89.37.63[.]175
Padrão de sessão	quiam-, como quiam-enum
User-Agent	TruffleHog em chamadas GetCallerIdentity

O identificador IAM AIDA3W7DIFLYOLTK63SFS foi observado exclusivamente em atividades maliciosas nos ambientes analisados.

Já o identificador AIDAJYRRH5Y3A7AAJM2HW também é utilizado em operações legítimas da Qubole. Nesse caso, a análise deve considerar principalmente solicitações originadas de endereços externos à AWS.

Os endereços associados à Mullvad VPN são compartilhados por diferentes usuários, portanto sua presença isolada não comprova comprometimento.

A Wiz recomenda examinar todas as ações realizadas após cada sessão suspeita, especialmente acessos ao Secrets Manager, Parameter Store, Lambda e S3.

Ausência de logs dificultou a identificação dos dados roubados

A investigação também identificou limitações na capacidade de algumas organizações reconstruírem as atividades dos invasores.

Embora os eventos de gerenciamento do CloudTrail registrem operações como AssumeRole e listagens de buckets, eles não registram, por padrão, quais objetos individuais do S3 foram acessados.

Para obter esse nível de visibilidade, é necessário habilitar os eventos de dados do S3 no CloudTrail ou os registros de acesso do próprio serviço.

Como algumas vítimas não possuíam esses mecanismos habilitados, os responsáveis pela resposta aos incidentes não conseguiram determinar exatamente quais arquivos haviam sido consultados ou copiados.

Essa limitação dificultou a avaliação do alcance da exfiltração e dos possíveis impactos sobre informações corporativas.

Recomendações para reduzir o risco de novos ataques

A Wiz orienta que organizações potencialmente afetadas revisem imediatamente suas integrações com a Qubole e as permissões concedidas a fornecedores externos.

Caso uma função IAM tenha sido utilizada pelos invasores, a recomendação é substituir todas as credenciais e informações sensíveis às quais ela tinha acesso, incluindo segredos do Secrets Manager, parâmetros do SSM e variáveis de ambiente do Lambda.

Também é necessário revogar as sessões temporárias ainda ativas, pois a simples rotação de credenciais não encerra automaticamente sessões já emitidas.

Outras medidas incluem remover funções IAM desnecessárias, restringir as políticas de confiança a identidades específicas e limitar as solicitações AssumeRole por meio das condições aws:SourceIp ou aws:SourceVpce, quando compatíveis com a integração.

Segundo os pesquisadores, uma restrição baseada no endereço IP de origem teria bloqueado todas as tentativas de assumir funções observadas nessa campanha.

A empresa também recomenda não utilizar o External ID como único mecanismo de proteção. Esse identificador não é considerado um segredo pela AWS e pode aparecer em registros do CloudTrail e arquivos de infraestrutura como código.

Após um incidente, sua substituição deve ser coordenada com o fornecedor, preferencialmente utilizando valores diferentes para cada função.

Por fim, as organizações devem revisar permissões excessivas, configurar alertas para acessos de fornecedores originados de redes desconhecidas e habilitar registros detalhados de acesso a dados sensíveis.

Até a publicação das informações, não havia confirmação pública de que as credenciais comprometidas da Qubole tivessem sido desativadas ou de que toda a atividade maliciosa tivesse cessado. A Qubole e sua controladora, Idera, também não haviam publicado comunicados sobre o incidente em seus respectivos sites, segundo a verificação realizada pelo The Hacker News.