Em 9 de novembro de 2026, a Wiz publicou um relatório sobre uma campanha em que um invasor usou credenciais de uma conta da AWS associada à Qubole, plataforma de processamento de dados, para entrar em ambientes de clientes e levar dados. Este texto reúne o que o relatório e as reportagens de 10 de novembro registram, separando o que foi confirmado do que ainda não foi dito. A Ragnatela não atende a Qubole e não tem nenhuma informação interna sobre o caso.
O que a Wiz confirmou
- entre 14 e 26 de outubro de 2026, um invasor usou credenciais de uma conta AWS que a Wiz associa à plataforma da Qubole para assumir papéis de integração criados por clientes;
- a Sentra percebeu atividade suspeita em vários ambientes de clientes, reconheceu um ataque amplo à cadeia de fornecimento e repassou os dados à Wiz; a investigação teve a colaboração da Mandiant;
- não houve exploração de falha de software: o invasor seguiu o caminho legítimo da integração. Todas as tentativas de assumir papéis atribuídas a ele traziam o identificador de integração correto (o External ID) e todas deram certo;
- na maioria dos ambientes observados, os pedidos do invasor foram a única atividade da conta da fornecedora em outubro: eram papéis sem uso, mas a confiança continuava ativa;
- dentro dos ambientes, o invasor listou recursos, leu configurações e segredos (em funções Lambda, no Secrets Manager e no Parameter Store) e baixou dados do S3, em alguns casos buckets inteiros em uma única sessão;
- usou a ferramenta TruffleHog para testar credenciais que encontrou, de AWS, Microsoft Entra ID e Okta. Elas pertenciam às organizações afetadas, não à fornecedora.
O que não foi informado
O relatório da Wiz não diz como as credenciais da conta ligada à Qubole foram obtidas, não informa quantas organizações foram afetadas nem quais dados cada uma perdeu. Também não atribui a campanha a nenhum grupo: a Wiz diz não ter ligação com outras atividades já divulgadas e não saber como o invasor pretende usar o que levou. Segundo o Dataconomy, Qubole e AWS não responderam a pedidos de comentário; não encontramos, até a data desta apuração, comunicado oficial de nenhuma das duas. Número de clientes aparece de formas diferentes nas reportagens (“vários”, “mais de uma dúzia”, “dezenas”), e por isso este texto não o afirma.
O que a Wiz viu à parte
A Wiz identificou uma imagem de disco inicializável (arquivo ISO) hospedada na infraestrutura usada pelo invasor, que coleta informações da máquina e executa comandos recebidos. A empresa afirma que não identificou nenhuma implantação e não pode confirmar se ou como ela foi usada. Também registrou, de 8 a 11 de outubro, o uso de chaves de acesso AWS pertencentes a clientes, criadas, ao que se acredita, para integrações com a Qubole. A Wiz não conseguiu ligar essa atividade à campanha principal, e em apenas poucos casos houve comprometimento do ambiente.
O que a Wiz recomenda
- revisar os registros do CloudTrail desde 1º de outubro, em todas as contas que tenham um papel de integração, procurando pedidos de acesso vindos de redes que não sejam da AWS;
- remover integrações de terceiros que não são mais usadas;
- trocar a confiança em “toda a conta do fornecedor” por uma identidade específica e limitar a rede de origem do acesso;
- não tratar o identificador de integração como senha, porque ele aparece em texto nos registros;
- ao trocar segredos, revogar também as sessões já emitidas: trocar a credencial não encerra sessão temporária que já existe;
- ligar registros de acesso a objetos nos buckets sensíveis: sem eles, o registro padrão mostra quem entrou, mas não o que foi lido.
O que qualquer empresa pode aprender, sem apontar culpado
Dar acesso a um fornecedor é uma decisão comum e, quase sempre, certa: ninguém opera nuvem, backup, suporte remoto e sistemas sozinho. O caso mostra outra coisa: esse acesso vira, na prática, uma credencial para o seu ambiente, e vale enquanto ninguém a retirar. Quatro perguntas úteis:
- Quem tem acesso à sua infraestrutura hoje? Fornecedor, suporte remoto, integração, consultor que já saiu do projeto.
- Há acesso aberto que ninguém usa mais? Os papéis sem uso foram justamente o caminho aqui.
- Onde estão os segredos? Senhas e chaves em variáveis de função, parâmetros ou arquivos soltos viram o segundo passo do invasor.
- Alguém percebe um acesso de terceiro vindo de uma rede estranha? O sinal existia: o acesso legítimo vinha de infraestrutura conhecida, e o do invasor, de uma VPN e de um servidor de hospedagem.
Cinco conferências para fazer amanhã cedo
- Existe uma lista de todos os acessos de terceiros ao seu ambiente, com dono e data da última conferência?
- Algum desses acessos está sem uso há meses e continua ativo?
- Senhas e chaves estão em cofre, e não em variáveis de sistema, planilhas ou arquivos de configuração?
- Alguém enxerga, à noite e no fim de semana, um acesso de terceiro vindo de uma rede diferente da habitual?
- Os registros de acesso a dados dos ambientes críticos estão ligados e guardados por tempo suficiente?
Uma nota de honestidade: backup não impede que dados sejam copiados, e este caso, pelo que foi divulgado, é de roubo de dados, não de perda. O backup com restauração testada responde a outra pergunta, a de quanto tempo a operação leva para voltar. Já a vigilância contínua serve ao que aconteceu aqui: perceber o acesso estranho enquanto ele ainda está em curso.
Perguntas frequentes
A Qubole foi invadida?
A Wiz relata que credenciais de uma conta AWS associada à Qubole foram usadas por um invasor. O relatório não diz como essas credenciais foram obtidas, e não encontramos comunicado oficial da Qubole ou da AWS até a data desta apuração.
Foi uma falha no software da AWS?
Não é o que o relatório descreve. O invasor usou o mecanismo normal de papéis entre contas, com as credenciais e o identificador de integração corretos.
Minha empresa precisa fazer algo?
Se usa ou já usou a Qubole com a AWS, a Wiz recomenda revisar os registros desde 1º de outubro e remover integrações sem uso. Para qualquer empresa, vale a lista de acessos de terceiros e a conferência das cinco perguntas acima.
Como especialista em cibersegurança, a Ragnatela trabalha do jeito que este texto sugere: primeiro mapeia quem tem acesso ao ambiente do cliente, retira o que não se usa, guarda segredos em cofre, monitora acessos fora do padrão com NOC e SOC 24 horas e confere a restauração do backup. Se você quer ver como essas cinco conferências ficam na sua empresa, a gente faz esse levantamento com você, numa conversa sem custo.
Fontes
Fonte principal: Wiz Research, “Trusted by Default: Qubole Cross-Account Access Abused in the Wild”, 09/11/2026. ler relatório.
Imprensa: CSO Online, 10/11/2026 (ler matéria); Cyber Security News, 10/11/2026 (ler matéria); Dataconomy, 10/11/2026 (ler matéria).
Origem do tema: publicação do Instagram @cybersecuritybrazil em 10/11/2026, usada só como referência. Notícia de terceiro; informações sujeitas a atualização conforme a investigação.
Perguntas frequentes
A Qubole foi invadida?
A Wiz relata que credenciais de uma conta AWS associada à Qubole foram usadas por um invasor. O relatório não diz como essas credenciais foram obtidas, e não encontramos comunicado oficial da Qubole ou da AWS até a data desta apuração.
Foi uma falha no software da AWS?
Não é o que o relatório descreve. O invasor usou o mecanismo normal de papéis entre contas, com as credenciais e o identificador de integração corretos.
Minha empresa precisa fazer algo?
Se usa ou já usou a Qubole com a AWS, a Wiz recomenda revisar os registros desde 1º de outubro e remover integrações sem uso. Para qualquer empresa, vale a lista de acessos de terceiros e a conferência das cinco perguntas do artigo.
Fontes
- Trusted by Default: Qubole Cross-Account Access Abused in the Wild
- Qubole supply chain attack exposed AWS, Entra ID, and Okta credentials
- Hackers Exploit Trusted Qubole IAM Roles to Access AWS Accounts and Download Entire S3 Buckets
- Hackers Use Qubole AWS Credentials To Breach Customer Cloud Environments
