Uma campanha de invasões a ambientes Amazon Web Services (AWS) mostrou como uma integração legítima com um fornecedor pode se transformar em porta de entrada para o roubo de dados e credenciais corporativas. Entre 14 e 26 de outubro de 2026, invasores utilizaram identidades associadas à conta AWS da Qubole para assumir funções de acesso em contas de clientes, consultar configurações, recuperar segredos e copiar informações armazenadas no Amazon S3. A investigação foi divulgada em 9 de novembro pela Wiz, em colaboração com Sentra e Mandiant, e coloca a gestão de acessos de terceiros no centro do problema.
O incidente não decorreu, segundo as informações disponíveis, de uma falha no serviço de infraestrutura da AWS. Em declaração ao The Register, a empresa afirmou que seus serviços não foram comprometidos e funcionaram conforme projetado. O que os atacantes exploraram foi uma relação de confiança configurada pelos próprios clientes: funções do AWS Identity and Access Management (IAM) autorizavam a conta da Qubole a solicitar credenciais temporárias para operar em ambientes de outras organizações. Parte dessas permissões continuava ativa mesmo depois de as integrações deixarem de ser utilizadas.
A Qubole oferece uma plataforma de processamento de dados em nuvem. Para executar tarefas em contas de clientes, integrações desse tipo podem usar funções IAM entre contas, conhecidas como cross-account roles, em vez de exigir que o cliente entregue chaves permanentes de acesso. Esse modelo é previsto pela arquitetura da AWS e pode ser seguro quando os relacionamentos de confiança são delimitados, monitorados e revogados ao término do contrato. O problema surge quando uma identidade do fornecedor é comprometida e consegue herdar permissões que permanecem abertas em diferentes organizações.
Como o acesso legítimo de um fornecedor foi transformado em ataque
A primeira atividade maliciosa identificada pela Wiz ocorreu em 14 de outubro. Requisições à API sts:AssumeRole partiram da conta AWS 805246085872, associada à operação da Qubole, e utilizaram uma identidade IAM que os investigadores observaram apenas na atividade do invasor. Inicialmente, as chamadas partiram de um endereço ligado a uma VPN; nos dias seguintes, também foram utilizados servidores de hospedagem externos. Em 18 de outubro, uma segunda identidade IAM da mesma conta passou a aparecer nas ações maliciosas, embora também estivesse presente em tráfego legítimo da plataforma.
O mecanismo técnico merece atenção porque não exigia que o atacante descobrisse uma vulnerabilidade de execução de código ou contornasse uma autenticação da AWS. Cada cliente havia criado uma função IAM cuja política de confiança aceitava a conta externa do fornecedor como principal autorizado. Ao chamar AssumeRole, a identidade associada à Qubole fornecia o identificador da função e um External ID válido; o AWS Security Token Service então emitia credenciais temporárias com as permissões concedidas à função do cliente. Segundo a Wiz, todas as requisições atribuídas ao invasor continham um External ID e foram bem-sucedidas.
O External ID é um controle importante para reduzir o problema conhecido como confused deputy, em que um terceiro autorizado é induzido a agir em nome da conta errada. Ele não é, porém, uma senha secreta nem substitui a restrição da identidade autorizada, da origem da conexão e dos recursos acessíveis. O caso mostra o limite de uma política que confia amplamente em uma conta externa e permanece ativa por tempo indefinido. Em muitos dos ambientes investigados, as requisições do atacante foram as únicas utilizações daquela integração durante outubro.
Uma vez dentro das contas dos clientes, os invasores realizaram reconhecimento de armazenamento, instâncias, redes, bancos de dados, funções IAM e chaves. Consultaram variáveis de ambiente de funções Lambda, buscaram valores no AWS Secrets Manager e no Systems Manager Parameter Store e testaram credenciais encontradas com a ferramenta TruffleHog. A atividade não ficou restrita à AWS: os pesquisadores observaram validação de segredos de aplicações Microsoft Entra ID e solicitações de tokens OAuth com credenciais Okta obtidas nos ambientes comprometidos.
A etapa seguinte foi o acesso a dados. Os registros analisados mostram uma sequência de enumeração de buckets S3, listagem e inspeção de objetos e chamadas GetObject para transferir informações. Em alguns casos, buckets inteiros foram copiados em uma única sessão. A dimensão exata do incidente e o número de organizações atingidas não foram divulgados pela Wiz. A Sentra identificou inicialmente atividades suspeitas em ambientes de clientes e compartilhou os achados, permitindo ampliar a investigação com a Wiz e a Mandiant.
Há limites importantes na atribuição. Os pesquisadores não divulgaram como as credenciais associadas à Qubole foram obtidas originalmente nem identificaram publicamente o grupo responsável. Uma imagem Linux suspeita, denominada sso_agent.iso, foi encontrada em infraestrutura associada ao invasor e analisada como possível ferramenta adicional, mas não há confirmação de que tenha sido implantada em vítimas. Também foi identificada outra sequência de ataques, entre 8 e 11 de outubro, envolvendo chaves AWS pertencentes a clientes e aparentemente criadas para integrações com a Qubole; a Wiz não conseguiu estabelecer vínculo conclusivo entre as duas atividades.
O custo de manter permissões de terceiros sem prazo de validade
O episódio revela uma fragilidade recorrente na governança de nuvem. Durante a contratação de um serviço, a organização concede permissões para que o fornecedor realize tarefas operacionais. Com o tempo, o projeto muda, a plataforma é substituída ou a integração deixa de ser usada, mas a função IAM e sua política de confiança continuam existindo. Se essa função permite consultar segredos, configurações de aplicações ou grandes conjuntos de dados, um comprometimento no fornecedor pode produzir efeitos que ultrapassam amplamente o serviço contratado.
A consequência empresarial não se resume ao vazamento de arquivos. Uma chave recuperada no Secrets Manager pode abrir caminho para outras aplicações; um segredo de um principal de serviço no Entra ID pode criar risco em sistemas Microsoft; credenciais OAuth da Okta podem ampliar a superfície de investigação para identidades e integrações fora da AWS. Não significa que todos esses acessos adicionais tenham sido efetivamente utilizados em cada vítima, mas demonstra por que a resposta precisa mapear as permissões e os segredos que cada função comprometida poderia alcançar, inclusive em ambientes externos à nuvem originalmente atingida.
A disponibilidade de logs é outro ponto crítico. Eventos de gerenciamento do AWS CloudTrail permitem observar chamadas como AssumeRole e a enumeração de recursos, mas não necessariamente registram cada leitura de objeto no S3. Para reconstruir a exfiltração, as equipes precisam ter habilitado eventos de dados do S3 no CloudTrail ou registros de acesso apropriados. Em ambientes sem essa telemetria, a investigação pode confirmar a presença do invasor e ainda assim não conseguir determinar exatamente quais arquivos foram acessados.
Notícias Relacionadas
O que investigar agora e como impedir uma nova exploração
Para empresas que utilizaram a Qubole, a orientação inicial é localizar todas as funções IAM que permitem acesso a partir da conta AWS 805246085872 e revisar os eventos CloudTrail desde 1º de outubro de 2026. Os investigadores recomendam atenção especial a chamadas AssumeRole originadas de redes externas à infraestrutura normalmente utilizada pelo fornecedor, às identidades IAM descritas no relatório da Wiz e a sessões com nomes iniciados por quiam-. Esses elementos devem ser correlacionados: o número da conta da Qubole também aparece em operações legítimas, e um endereço de saída de VPN isoladamente não comprova invasão.
Quando houver indícios de utilização indevida de uma função, a contenção deve interromper a relação de confiança afetada, revogar as sessões temporárias existentes e preservar os registros para análise. A simples rotação de uma chave não invalida automaticamente credenciais temporárias já emitidas pelo STS. Em seguida, a equipe precisa identificar todos os segredos, parâmetros e variáveis de ambiente que aquela função podia ler e realizar a substituição controlada das credenciais expostas ou potencialmente acessíveis, incluindo integrações com Entra ID, Okta e outros sistemas. Também deve verificar leituras de objetos S3, alterações em políticas e eventuais acessos posteriores com credenciais descobertas.
Para prevenir recorrência, a revisão precisa ir além da integração com a Qubole. É recomendável inventariar todas as funções que confiam em contas AWS externas, identificar seus responsáveis internos, a finalidade contratual e a data da última utilização. A confiança deve ser removida quando o serviço termina e revisada periodicamente enquanto estiver ativa. Onde o fornecedor oferecer suporte, a política deve apontar para um principal IAM específico, em vez de aceitar genericamente toda a conta externa, e incluir condições de origem como aws:SourceIp ou aws:SourceVpce compatíveis com a arquitetura real do serviço.
O princípio do menor privilégio também deve ser aplicado às funções de integração. Uma ferramenta que precisa processar um conjunto limitado de objetos não deve, por conveniência, receber leitura irrestrita de buckets, acesso a segredos de produção ou permissões administrativas. O External ID continua recomendado, preferencialmente com valor distinto por integração, mas não pode ser tratado como segredo suficiente para autenticar o fornecedor. Alertas sobre uso de funções por redes desconhecidas, contas inativas ou horários atípicos ajudam a detectar abuso antes que ele se transforme em extração massiva de dados.
Fornecedores de serviços SaaS compartilham essa responsabilidade. Uma identidade de sua conta AWS que pode assumir funções em dezenas de clientes representa um ponto de concentração de risco. O uso de identidades de carga de trabalho e credenciais temporárias, a restrição das redes de saída, a publicação dos endereços legítimos e o monitoramento de sessões destinadas a contas de clientes reduzem a possibilidade de um único comprometimento produzir múltiplas invasões.
A AWS afirmou que os serviços não foram comprometidos e recomendou a revisão de funções entre contas, a remoção de integrações desnecessárias, o menor privilégio e condições adicionais nas políticas de confiança. Até 11 de novembro, não havia atribuição pública do ataque nem esclarecimento definitivo sobre a obtenção inicial das credenciais associadas à Qubole. O caso demonstra que a segurança de nuvem depende não apenas da configuração correta dos serviços, mas da capacidade de controlar quem continua autorizado a utilizá-los — especialmente quando esse acesso pertence a outra empresa.
Be the first to comment