Atacante usou credenciais do Qubole AWS para assumir papéis em contas de clientes e roubar segredos

Entre 14 e 26 de outubro, um atacante explodiu credenciais associadas à conta da AWS que usa a plataforma de Qubole para acessar os ambientes de vários clientes e extrajo segredos e dados, segundo a análise dos pesquisadores de Wiz. O método empregado foi assumir papéis (AssumeRole) que os clientes haviam criado para permitir que Qubole atuasse dentro de suas contas; esses papéis confiavam na conta de Qubole (ID 805246085872) e requeriam um External ID, que neste caso o atacante pôde incluir corretamente. Os pesquisadores também documentam atividade anterior, entre 8 e 11 de outubro, na qual outro ator - ou possivelmente o mesmo com uma técnica diferente - usou chaves de acesso AWS de clientes configuradas para Qubole; essa etapa preliminar foi vinculada a compromissos em alguns ambientes, mas não foi correlacionada publicamente com o abuso de AssumeRole que seguiu.

Atos confirmados: Wiz publicou um relatório técnico que detalha a campanha, e a pesquisa foi iniciada após alertas da empresa Sentra. O atacante leu variáveis de ambiente de funções Lambda, extrajo segredos do AWS Secrets Manager, obteve parâmetros do SSM Parameter Store e descargou objetos de S3 – às vezes descarregando um bucket inteiro se o papel o permitia. Para validar credenciais extraídas, o atacante usou ferramentas automatizadas como TruffleHog. Além disso, os pesquisadores identificaram assinaturas operacionais reprodutíveis: a conta de Qubole 805246085872, dois IAM principal IDs relevantes (AIDA3W7DIFLYOLTK63SFS, associada ao atacante nos casos examinados, e AIDAJYRRH5Y3A7AAJM2HW, usada por Qubole e também pelo atacante desde 18 de outubro), endereços IP públicos ligados a OVH e servidores de VPN (por exemplo 57.129.54.120 e 45.83.220.211), sessões com nomes que começam por “quiam-” e registros GetCallerIdentity cujo user-agent mostrava TruffleHog.

O que permitiu o acesso e por que funcionou: tecnicamente, Qubole funciona dentro da conta do cliente mediante um papel IAM cuja política de confiança permite que a conta de Qubole assuma o papel. O AWS valida que o pedido AssumeRole provém da conta confiável e que o External ID coincida. O problema chave neste incidente não foi uma vulnerabilidade na AWS, mas as credenciais que o atacante tinha do lado do fornecedor (a conta de Qubole) puderam ser usadas para emitir pedidos válidos a papéis ainda configurados para confiar nessa conta. Além disso, o External ID não é segredo segundo o próprio guia da AWS: é registrado no CloudTrail e é visível em arquivos de infraestrutura e modelos, portanto seu conhecimento por parte do atacante não é surpreendente. Mais detalhes técnicos e recomendações gerais sobre vendo papéis encontram-se na página de pesquisa de Wiz e documentação da AWS sobre External ID ( Wiz Research, AWS External ID guidance).

A quem afeta e alcance prático: qualquer organização que tenha concedido um papel IAM a Qubole, mesmo que já não use ativamente a plataforma, está potencialmente afetada. Nos ambientes examinados, o atacante buscou e aproveitou segredos que poderiam desbloquear outros recursos e serviços: chaves de acesso AWS (que permitem operar diretamente a API), segredos de provedores de identidade (por exemplo, Entra/Okta) e credenciais de aplicativos. Onde faltavam logs detalhados de S3 (S3 data events ou server access logs), as equipes de resposta não puderam determinar com precisão quais objetos foram lidos ou copiados, o que agrava o risco de exposição de informações sensíveis.

Que partes do relato continuam sem se confirmar publicamente: Wiz e pesquisadores não declararam publicamente como as credenciais que permitiram ao atacante operar desde a conta de Qubole ou se essas credenciais já foram revogadas; tampouco Qubole ou sua matriz Idera emitiram uma declaração pública no momento em que a informação foi verificada. Também não há vinculação pública e confirmada entre esta campanha e outros incidentes maiores, nem indícios conclusivos de que se trate de uma operação patrocinada por um estado ator; Wiz aponta que os objetivos não se ajustam ao padrão habitual de grupos estatais.

Consequências reais e potenciais: A exposição de segredos e chaves de acesso pode permitir ao atacante escalado lateral dentro de contas, persistência mediante novas credenciais ou integrações, roubo de dados, e em ambientes integrados com outras nuvens ou SaaS, comprometimento de identidades federadas. A falta de registros detalhados impede a determinação do alcance exato da exfiltração em todos os afetados, o que complica a resposta e remediação.

Medidas concretas e imediatas que você deve tomar qualquer equipe afetada ou que tenha usado Qubole com a AWS: Primeiro, rastree os eventos no CloudTrail a partir de 1 de outubro, procurando AssumeRole onde userIdentity.accountId = 805246085872 e sourceIPAddress não seja um endereço da AWS; investigue sessões cuja sessionName comece por “quiam-”, chamadas GetCallerIdentity com user-agent TruffleHog e atividade a partir das IPs assinaladas pelos pesquisadores. Active uma revisão exaustiva do Secrets Manager, SSM Parameter Store, variáveis de ambiente de Lambda e permissões de leitura do S3 que o papel poderia alcançar; rote imediatamente todas as credenciais (chaves de acesso, segredos de aplicações, client secrets) às quais o papel tinha visibilidade e mude senhas ou tokens externos que possam ter sido expostos. Tenha em conta que rodar um segredo não invalida sessões temporárias já emitidas; para bloquear sessões ativas, remover ou modificar a política de confiança do papel (por exemplo, eliminando a conta de Qubole da trust policy ou substituindo o principal de conta pelo IAM principal específico que o fornecedor documenta) e, se for caso disso, remova papéis não utilizados. Adicione condições ao trust policy, como aws:SourceIp ou aws:SourceVpce, para limitar de onde podem assumir os papéis — os pesquisadores indicam que, neste caso, uma condição de IP teria bloqueado as asunções observadas. Implemente um trail de organização e habilite S3 data events ou server access logs em buckets sensíveis para poder auditar leituras de objetos no futuro (ver guia CloudTrail: AWS CloudTrail).

Por fim, verifique e reduza o alcance de permissões concedidas a papéis de terceiros: é frequente ver papéis de fornecedores com permissão de leitura ampla sobre S3, acesso a Secrets Manager e parâmetros SSM “por conveniência”; limite essas permissões ao mínimo necessário e configure alertas para AssumeRole que provem de VPS, redes de hospedagem ou IPs de VPN não documentadas pelo fornecedor. Essas ações não garantem que um compromisso passado deixe de ter consequências, mas reduzem drasticamente a janela de abuso futuro e facilitam contenção e auditoria.

Este incidente sublinha que a confiança cruzada entre contas e a gestão de credenciais em integrações de fornecedores requer políticas e registros específicos: não basta delegar acesso, é necessário instrumentá-lo e restringir de forma proativa. Fique atento às comunicações oficiais de Qubole ou Idera e aos relatórios técnicos de Wiz para atualizações e detecções adicionais.