Em 28 de novembro de 2025, pesquisadores da Equipe de Pesquisa de Ameaças da Sysdig documentaram um incidente que muda a forma como ataques em nuvem são compreendidos. Um invasor conseguiu assumir o controle completo do ambiente em nuvem de uma empresa em apenas oito minutos — um contraste brutal com invasões tradicionais, que normalmente se estendem por dias ou até semanas.
O ponto de partida foi um erro clássico, porém crítico: credenciais de teste estavam expostas em um bucket S3 configurado como público. Na Amazon Web Services (AWS), buckets S3 funcionam como repositórios de armazenamento na nuvem. Quando mal configurados, ficam acessíveis a qualquer pessoa na internet. Segundo a Sysdig, alguns desses buckets traziam até referências a “IA” no nome, o que os tornava alvos óbvios para agentes mal-intencionados em busca de dados sensíveis.
Reconhecimento total com acesso mínimo
As credenciais obtidas concediam apenas permissões de leitura, mas isso não impediu o avanço do ataque. Com esse nível básico de acesso, o invasor realizou um mapeamento completo do ambiente, consultando serviços como o Secrets Manager, onde ficam armazenadas senhas e chaves criptográficas, o RDS, responsável por bancos de dados, e o CloudWatch, sistema de monitoramento da AWS. Em poucos minutos, toda a infraestrutura estava catalogada.
Escalação de privilégios em tempo recorde
A virada ocorreu com a exploração de funções Lambda, pequenos programas que executam ações automáticas em resposta a eventos. O atacante injetou código malicioso nessas funções, modificando repetidamente uma rotina chamada EC2-init até conseguir comprometer uma conta administrativa identificada como “frick”. A partir daí, passou a ter controle total do ambiente em nuvem.
Inteligência artificial como acelerador do ataque
O que mais chamou a atenção dos pesquisadores foi a forte indicação de uso de Inteligência Artificial. A velocidade de execução e o padrão do código sugerem o apoio de modelos de linguagem de grande porte (LLMs) para automatizar etapas do ataque. O código apresentava comentários em sérvio e era produzido em um ritmo incompatível com digitação manual.
Além disso, foram identificados indícios clássicos de “alucinações” de IA, como IDs fictícios de contas AWS e referências a repositórios do GitHub que não existem. Esses erros são comuns quando modelos de linguagem tentam preencher lacunas de informação, funcionando como uma espécie de assinatura involuntária do uso de IA.
LLMjacking e abuso de recursos
O objetivo do ataque foi além do acesso não autorizado. O invasor utilizou a infraestrutura da vítima para executar modelos de IA de alto custo, prática conhecida como LLMjacking. Entre os modelos acionados estavam Claude 3.5 Sonnet, DeepSeek R1 e Amazon Titan.
Houve ainda a tentativa de criar uma máquina virtual de grande porte, apelidada de “stevan-gpu-monster”, destinada ao treinamento de modelos próprios. Caso tivesse sucesso, o custo mensal para a empresa ultrapassaria £18.000. Para reduzir as chances de detecção, o atacante utilizou um sistema de rotação de IPs, alternando entre 19 identidades diferentes.
A conta comprometida fazia parte de uma organização maior, e o invasor tentou se mover lateralmente para outras contas explorando uma função padrão chamada OrganizationAccountAccessRole.
Lições de segurança
O caso reforça como pequenos descuidos podem ter impactos massivos em ambientes de nuvem. Especialistas recomendam nunca armazenar chaves de acesso em locais públicos, priorizar o uso de perfis temporários de acesso (IAM roles) e monitorar sinais de enumeração em massa, quando um usuário passa a listar rapidamente todos os recursos disponíveis — um comportamento típico da fase inicial de reconhecimento em ataques modernos.
O episódio mostra que, com automação e IA, a linha entre um erro simples e um comprometimento total ficou perigosamente curta.
