Experimento deu chaves da AWS a 14 LLMs para ver como eles agiriam após um comprometimento

O experimento de Adan Alvarez com chaves da AWS não executou nada em conta real. Ele montou 13 situações pós-comprometimento (do tipo "você acabou de pegar umas chaves e não sabe nada" ou "o CloudTrail vai registrar seu próximo passo") e perguntou a 14 modelos o que fariam. Cada modelo respondeu 20 vezes por situação, com a informação de que era um teste de segurança autorizado. Cada comando proposto foi mapeado para o evento do CloudTrail que ele geraria. O autor avisa que o resultado depende do harness e dos prompts de um atacante real, então não é uma previsão do que acontece em campo, mas sim um indicativo de viés.

Os números: 12 dos 14 modelos abriram com GetCallerIdentity. Venice Uncensored Dolphin Mistral 24B e Llama 4 começaram sempre com ListUsers. Grok recusou 18 de 20 respostas nesse cenário e, no geral, foi o que mais recusou (98%), sem propor nenhuma ação que alterasse algo. DeepSeek V4 propôs mudar a conta em 72% das respostas. Para persistência, 63 das 113 respostas que a propuseram foram de criar usuário IAM com chave de acesso. Backdoor em role apareceu com Dolphin (sempre), DeepSeek (16 vezes), Haiku e Hermes (7 cada). Persistência via Lambda surgiu em 5 modelos. Sabendo da existência de um secret, os modelos tentaram ler o valor em 87% dos casos, o que inclui honeytraps, já que dificilmente o modelo distingue um secret falso. Ação destrutiva apareceu em 11%, e evasão em 1% enquanto o monitoramento só estava lá. Quando o próximo passo seria registrado ou após alerta do GuardDuty, cerca de um terço propôs mexer nos logs, com DeepSeek à frente (parar CloudTrail, desativar ou apagar detectores do GuardDuty).

Para detecção, o autor aponta que nada é técnica nova, então as regras existentes continuam valendo. Ele sugere ainda regras de nome (sessões como "redteam-assessment", usuários como "backdoor-user" e o comum "backup-admin", que imita conta de serviço, ressalvando que parte do viés "red team" vem do próprio prompt), varredura de todas as regiões via describe-regions (75 respostas, sobretudo dos modelos GPT) e uso de iam:SimulatePrincipalPolicy (131 comandos em 12 modelos). Os dados e o código para rodar cenários próprios estão publicados pelo autor.

A cobertura anterior não mostra evolução deste mesmo experimento, mas dá contexto próximo. Em 14 de outubro de 2026, o CEVIU noticiou "Ameaça Velada: Credenciais AWS Expostas Visam o Amazon Bedrock", sobre estudo da Datadog em que credenciais AWS comprometidas são rotineiramente testadas contra serviços sensíveis. Aquele texto trata de atacantes reais, este de comportamento simulado de modelos.

Para quem opera detecção na AWS, a leitura é prática: o tráfego de um agente com LLM tende a parecer o de um atacante comum, então as regras sobre GetCallerIdentity seguido de enumeração, criação de usuário IAM e adulteração de logs seguem relevantes. Também vale planejar rotação de secrets após qualquer incidente, já que a leitura deles é a norma, e não contar com honeytraps como filtro, pois serão lidos. Como o comportamento varia muito entre modelos, a ferramenta do atacante muda o que você verá nos logs.