A campanha de ataques envolvendo a Qubole e a Amazon Web Services (AWS) expõe um risco frequentemente ignorado por empresas que utilizam serviços de terceiros: uma integração legítima pode se transformar em uma porta de entrada para invasores quando as credenciais do fornecedor são comprometidas. Em uma operação identificada por empresas de segurança, hackers utilizaram acessos IAM associados à plataforma Qubole para invadir ambientes AWS de diferentes organizações, roubar credenciais e extrair informações armazenadas na nuvem.
O incidente demonstra como relações de confiança entre contas podem ampliar o alcance de um comprometimento. Em vez de explorar individualmente uma vulnerabilidade em cada empresa, os criminosos aproveitaram permissões concedidas anteriormente à plataforma para assumir funções IAM e acessar recursos dos clientes.
As investigações conduzidas pela Wiz e pela Sentra, com participação de especialistas da Mandiant, identificaram atividades envolvendo o AWS Security Token Service (STS), o uso da ferramenta TruffleHog, a extração de segredos e o download de arquivos armazenados no Amazon S3. O caso serve de alerta para administradores de sistemas, engenheiros DevOps e profissionais de segurança responsáveis por ambientes multinuvem e integrações corporativas.
Como os hackers exploraram a integração da Qubole com a AWS
A Qubole é uma plataforma de processamento e análise de dados que utiliza recursos de infraestrutura em nuvem para executar operações sobre conjuntos de dados de seus clientes. Para funcionar, esse tipo de serviço precisa receber permissões específicas dentro das contas AWS das organizações contratantes.
Normalmente, essa integração é estabelecida por meio de funções do AWS Identity and Access Management (IAM). O cliente cria uma função e configura uma política de confiança que autoriza uma identidade pertencente ao fornecedor a assumir essa função.
O mecanismo utilizado para realizar essa operação é o AWS Security Token Service (STS), especificamente a API AssumeRole. Quando uma identidade autorizada solicita acesso, o serviço fornece credenciais temporárias que permitem executar operações de acordo com as permissões associadas à função.
Foi justamente essa relação de confiança que os invasores exploraram.
Segundo a investigação da Wiz, os criminosos utilizaram credenciais IAM comprometidas associadas à infraestrutura AWS da Qubole para solicitar acesso às funções configuradas pelos clientes. Como essas identidades já estavam autorizadas pelas políticas de confiança, as solicitações foram aceitas pelo STS.
A conta AWS identificada na investigação foi a 805246085872. Os pesquisadores também associaram as atividades maliciosas ao principal ID AIDA3W7DIFLYOLTK63SFS.
A partir desse acesso, os invasores conseguiram obter credenciais temporárias e executar operações dentro de diferentes ambientes de clientes, respeitando os limites das permissões concedidas às funções comprometidas.
É importante esclarecer que o problema não representa necessariamente uma vulnerabilidade no funcionamento do AWS STS. O serviço executou as solicitações conforme as políticas de autorização existentes. A falha de segurança estava no comprometimento de uma identidade confiável e na possibilidade de utilizá-la para acessar ambientes de terceiros.
Funções IAM antigas ampliaram o alcance do ataque
Um dos aspectos mais preocupantes identificados pelos pesquisadores foi a existência de funções IAM que continuavam autorizando acessos associados à Qubole, mesmo quando algumas organizações já não utilizavam a plataforma.
Essas funções permaneceram habilitadas e mantiveram suas políticas de confiança, criando oportunidades para que os invasores acessassem ambientes que, em determinadas circunstâncias, já deveriam ter sido desconectados do fornecedor.
O problema evidencia uma deficiência comum na administração de ambientes AWS: permissões concedidas para integrações temporárias acabam permanecendo ativas por tempo indeterminado.
Outro ponto importante envolve o uso do External ID, mecanismo empregado em integrações entre contas AWS para reduzir riscos de acesso indevido. Embora seja uma proteção relevante, ele não impede automaticamente a utilização maliciosa de uma identidade legítima quando o invasor também consegue obter as informações necessárias para assumir a função.
A campanha demonstra que políticas de confiança precisam ser revisadas continuamente. Não basta configurar corretamente uma integração no momento da implantação. Também é necessário acompanhar sua utilização, limitar permissões e remover acessos quando o serviço deixa de ser necessário.
Como ocorreu o roubo de credenciais e a exfiltração de dados
Depois de assumir as funções IAM dos clientes, os invasores começaram a identificar quais recursos estavam disponíveis em cada ambiente.
A atividade envolveu serviços importantes da AWS, incluindo Amazon S3, AWS Secrets Manager, Systems Manager Parameter Store, AWS Lambda, EC2 e IAM.
O interesse dos criminosos estava principalmente nas informações que poderiam facilitar novos acessos. Entre os recursos investigados estavam variáveis de ambiente de funções Lambda, parâmetros de configuração e segredos armazenados nos serviços de gerenciamento de credenciais da AWS.
No AWS Secrets Manager, os invasores utilizaram operações como ListSecrets e GetSecretValue para localizar e recuperar informações confidenciais.
Já no Systems Manager Parameter Store, foram identificadas operações como DescribeParameters e GetParameter, utilizadas para localizar e consultar parâmetros armazenados.
Esses recursos frequentemente concentram informações essenciais para o funcionamento de aplicações corporativas, incluindo senhas de bancos de dados, tokens de autenticação, chaves de API e credenciais utilizadas por serviços automatizados.
Quando uma função IAM possui permissões excessivas, o comprometimento dessa identidade pode revelar informações que ultrapassam o ambiente originalmente conectado à plataforma.
TruffleHog ajudou os invasores a identificar credenciais válidas
Um dos elementos mais relevantes da investigação foi o uso do TruffleHog, ferramenta conhecida por localizar segredos expostos em arquivos, repositórios e outros ambientes digitais.
Embora seja utilizada legitimamente por equipes de segurança para identificar vazamentos de credenciais, a ferramenta também pode ser empregada por criminosos para localizar e validar informações roubadas.
Na campanha investigada, os invasores utilizaram o TruffleHog para examinar credenciais encontradas nos arquivos e recursos acessados.
Entre os materiais identificados estavam:
- Credenciais da AWS: chaves de acesso pertencentes às organizações afetadas.
- Segredos do Microsoft Entra ID: informações de autenticação associadas a entidades de serviço.
- Credenciais do Okta: informações utilizadas em mecanismos de autenticação OAuth.
Para verificar a validade de credenciais AWS, os invasores utilizaram a operação GetCallerIdentity. Essa chamada permite identificar a conta e a identidade associadas às credenciais utilizadas, sem exigir permissões adicionais.
No Microsoft Entra ID, os criminosos tentaram autenticar-se utilizando segredos de clientes de entidades de serviço. Também foram identificadas tentativas de utilização de credenciais OAuth associadas ao Okta.
Isso indica que a campanha não se limitou à coleta de arquivos. Os invasores também procuraram credenciais que pudessem permitir acesso a outros serviços corporativos, ampliando as consequências do comprometimento inicial.
Download de arquivos do Amazon S3 ocorreu em poucos minutos
A velocidade das operações foi outro aspecto preocupante identificado pelas empresas de segurança.
Segundo os resultados apresentados pela Sentra, uma investigação identificou mais de 100 senhas e chaves acessadas em aproximadamente sete minutos, além de milhares de registros adicionais de credenciais presentes nos arquivos obtidos.
No Amazon S3, os criminosos utilizaram operações para listar buckets, enumerar objetos e recuperar arquivos por meio da API GetObject.
Em determinados ambientes, a atividade envolveu o download de grandes quantidades de dados, incluindo buckets inteiros.
A estratégia indica que os invasores procuravam aproveitar ao máximo as permissões disponíveis, sem necessariamente selecionar previamente cada arquivo que desejavam obter.
A Wiz também identificou infraestrutura externa utilizada durante a campanha, incluindo endereços associados à VPN Mullvad e um servidor hospedado na OVH.
Outro elemento encontrado foi uma imagem ISO suspeita chamada sso_agent.iso, hospedada em infraestrutura relacionada aos invasores. O arquivo apresentava características de um ambiente Linux preparado para coletar informações do sistema e receber comandos remotamente.
Entretanto, não foram encontradas evidências suficientes de que essa imagem tenha sido executada nos ambientes das vítimas. Sua utilização efetiva, portanto, não foi confirmada.
Como proteger ambientes AWS contra ataques semelhantes
O incidente envolvendo a Qubole demonstra que a proteção de uma infraestrutura AWS depende não apenas da segurança das aplicações, mas também do controle rigoroso das identidades e permissões concedidas a fornecedores externos.
Empresas que utilizaram a plataforma devem verificar se ainda existem funções IAM associadas à integração e investigar possíveis acessos indevidos.
A Wiz recomenda examinar os registros do AWS CloudTrail a partir de 1º de outubro de 2026, procurando eventos AssumeRole relacionados à conta AWS 805246085872.
Também merece atenção o principal ID AIDA3W7DIFLYOLTK63SFS, identificado na investigação como uma identidade utilizada nas atividades maliciosas.
A análise deve considerar os horários das solicitações, os endereços IP de origem, as funções assumidas e as operações realizadas posteriormente com as credenciais temporárias.
Entre as principais medidas de proteção estão:
1. Remover funções IAM abandonadas: exclua funções associadas a integrações que não são mais utilizadas. Acessos antigos não devem permanecer ativos sem justificativa operacional.
2. Restringir políticas de confiança: limite quais identidades externas podem assumir funções IAM. Sempre que possível, utilize condições adicionais para restringir origens e contextos de acesso.
3. Investigar sessões temporárias: identifique sessões STS suspeitas e aplique mecanismos de revogação quando necessário. A simples alteração de uma chave de acesso não encerra automaticamente todas as sessões temporárias existentes.
4. Rotacionar credenciais expostas: substitua senhas, tokens, chaves de API e credenciais de aplicações que possam ter sido acessadas pelos invasores.
5. Auditar buckets S3: procure downloads incomuns, acessos em grande volume e operações realizadas por identidades externas. Ative eventos de dados do CloudTrail para buckets que armazenam informações sensíveis.
6. Revisar integrações de terceiros: mantenha um inventário de fornecedores, funções IAM, permissões concedidas e responsáveis internos por cada integração.
Um cuidado adicional envolve a configuração dos registros de auditoria. O CloudTrail registra operações de gerenciamento, como AssumeRole e determinadas chamadas de listagem, mas a identificação de arquivos efetivamente baixados exige telemetria adequada, como eventos de dados do S3 ou logs de acesso do serviço.
Sem esses registros, uma organização pode identificar que uma identidade acessou seu ambiente, mas não necessariamente determinar quais arquivos foram extraídos.
O que o ataque à Qubole ensina sobre segurança na nuvem
A campanha demonstra como o comprometimento de uma identidade pertencente a um fornecedor pode afetar várias organizações que confiaram nessa mesma infraestrutura para integrar seus ambientes AWS.
O uso do STS AssumeRole, a exploração de funções IAM antigas, a coleta de segredos e a extração de arquivos do Amazon S3 revelam que permissões legítimas também podem se transformar em instrumentos de invasão.
As investigações da Wiz e da Sentra reforçam a necessidade de tratar integrações externas como componentes críticos da superfície de ataque. A confiança concedida a um fornecedor precisa ser acompanhada de controles técnicos, monitoramento e revisões periódicas.
Para administradores de sistemas e profissionais DevOps, a principal recomendação é revisar imediatamente as funções IAM existentes, eliminar permissões desnecessárias e verificar quais serviços externos ainda possuem acesso aos recursos corporativos.
Na segurança em nuvem, uma integração esquecida pode representar uma porta de entrada tão perigosa quanto uma vulnerabilidade recém-descoberta. Auditar essas relações de confiança é uma medida essencial para reduzir o risco de novas campanhas de invasão e proteger os dados armazenados na AWS.
