Hackers usaram IAM role da Qubole para roubar dados de clientes na AWS

O que aconteceu

A empresa de segurança Wiz relatou que um invasor usou credenciais de uma conta AWS pertencente à Qubole, plataforma de gestão de dados da Idera, para acessar contas de múltiplos clientes e roubar segredos e dados armazenados. A atividade maliciosa ocorreu entre 14 e 26 de outubro de 2026. A origem das credenciais usadas pelo invasor não foi divulgada até o momento.

A Qubole se integra às contas AWS dos clientes por meio de um modelo comum em plataformas SaaS de dados: o cliente cria uma IAM role com uma trust policy que concede à conta da Qubole permissão para assumir aquela role via sts:AssumeRole. O invasor, segundo a Wiz, chegou às contas das vítimas através da conta 805246085872, que pertence à própria Qubole.

Outra firma de segurança, a Sentra, identificou a atividade em diversos ambientes de clientes de forma independente e alertou os pesquisadores. Antes mesmo desse episódio, entre 8 e 11 de outubro, outra atividade separada foi detectada: indivíduos não identificados usaram diretamente chaves de acesso de clientes configuradas especificamente para a integração com a Qubole.

Como o invasor se moveu dentro das contas

O padrão de ataque descrito pela Wiz segue uma sequência reconhecível para quem lida com resposta a incidentes em nuvem:

1. Após assumir a role, o invasor lia configurações de serviços na conta comprometida.
2. Coletava chaves de acesso (access keys) encontradas nessas configurações.
3. Testava essas chaves contra diferentes serviços para mapear o que elas abriam.
4. Copiava dados em massa dos buckets de armazenamento das vítimas, baixando pastas inteiras em uma única sessão.

O invasor operou a partir de endereços hospedados na OVH e usou serviços com reconhecimento de localização para mascarar a origem geográfica das conexões. Esse detalhe importa: ele sugere preocupação em escapar de alertas baseados em geolocalização, um controle que muitas equipes ainda tratam como suficiente.

O ponto cego: confiar numa role sem auditoria contínua

Em resumo: o problema não foi uma falha na AWS, foi a falta de monitoramento sobre uma role de terceiro que, uma vez concedida, muitas equipes nunca mais revisam. A trust policy que permite a um parceiro assumir uma role na sua conta é, na prática, uma porta permanente. Se a credencial do lado do parceiro vaza, a porta continua aberta do seu lado até que você perceba.

Isso é diferente de uma chave de acesso estática vazada, caso em que a rotação resolve o problema na origem. Aqui, o vetor é a própria confiança configurada na trust policy: enquanto a role existir com aquela condição de Principal, qualquer um que controle as credenciais do parceiro pode assumi-la, não importa quantas vezes o cliente rotacione as próprias chaves.

O que ainda está em aberto

Até o momento da análise, nem a Qubole nem a Idera haviam publicado comunicados em seus sites sobre o incidente. A fonte da credencial comprometida da conta 805246085872 não foi divulgada, o que significa que não há confirmação pública se o problema foi phishing, vazamento em repositório, chave exposta em log, ou outro vetor. Os pesquisadores publicaram instruções para quem usa a integração com a Qubole revisar logs de atividade a partir de 1º de outubro.

Checklist para quem administra IAM com integrações de terceiros

Para quem configura e audita IAM roles em produção, o episódio dá um roteiro prático de verificação que vale rodar hoje, independente de usar Qubole:

• Liste toda role com trust policy para conta externa. Rode aws iam list-roles e filtre as roles cujo documento de confiança tenha um Principal do tipo AWS apontando para uma conta que não é a sua, ou use o IAM Access Analyzer para gerar automaticamente os achados de acesso externo.
• Confirme o uso de ExternalId. Se a trust policy de uma integração com terceiro não exige a condição sts:ExternalId, ela é mais fácil de ser abusada por quem descobrir apenas o ARN da role, mesmo sem comprometer a conta do parceiro.
• Revise CloudTrail por AssumeRole fora do padrão. Um comando como aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole --start-time 2026-10-01T00:00:00Z ajuda a localizar sessões assumidas fora do horário ou volume costumeiro.
• Restrinja a sessão. Reduza o MaxSessionDuration da role ao mínimo necessário para a tarefa do parceiro, o que limita a janela de uso de uma credencial de sessão roubada.
• Audite o escopo da policy anexada. Se a role concede mais do que o parceiro realmente usa, o raio de ação de um eventual abuso cresce junto. Vale reduzir para o conjunto mínimo de ações e recursos.

O que muda na prática

Para arquitetos e times de SRE que desenham ambientes multi-conta, o episódio reforça um ponto do pilar de segurança do Well-Architected Framework que costuma ficar esquecido: a revisão de acesso externo não é uma tarefa de configuração única, é um processo contínuo. Toda vez que uma ferramenta de terceiro pede uma IAM role na sua conta, essa role vira parte da sua superfície de ataque, com o atenuante de que você não controla a segurança operacional de quem está do outro lado.

Uma prática que reduz esse risco é tratar toda integração de terceiro como um recurso monitorado por GuardDuty e por regras de AWS Config, com alerta automático quando a role for assumida fora de um intervalo de IPs ou de um padrão de uso esperado. Isso não substitui a responsabilidade do parceiro de proteger as próprias credenciais, mas dá à equipe que opera a conta AWS um sinal independente de que algo mudou, em vez de depender só do aviso do fornecedor.

Fonte: DEV Community — #aws