Framework ARTEX usa agentes de IA para atacar contas AWS reais

A Datadog documentou o framework ofensivo ARTEX agindo contra ambientes AWS reais em outubro e novembro de 2026, usando chaves IAM vazadas e pools do Cognito abertos para caçar dados financeiros.

A Datadog documentou o framework ofensivo ARTEX agindo contra ambientes AWS reais em outubro e novembro de 2026, usando chaves IAM vazadas e pools do Cognito abertos para caçar dados financeiros.

Em outubro de 2026, a Datadog Security Labs observou atividade real de ARTEX contra várias contas AWS, com foco explícito em acessar dados financeiros. ARTEX é descrito pela pesquisadora Julie Agnes Sparks, do time de segurança da Datadog, como um framework de pentest nativo em IA: o operador informa um alvo e um objetivo, e um time de agentes baseados em LLM planeja e executa o ataque sozinho.

Até aqui, os relatos públicos sobre o ARTEX (inclusive da Wiz) tinham mirado principalmente provedores de identidade como Okta e Entra ID, e logs de aplicação web. O que a Datadog publicou é a primeira descrição detalhada do que o framework faz depois que ganha acesso a uma conta AWS: como ele se move pelo CloudWatch, pelo S3 e pelo Cognito usando as mesmas chamadas de API que qualquer engenheiro usaria no console, só que decididas por um agente autônomo.

No início de novembro de 2026, a equipe rastreou os IPs usados nos ataques até um console hospedado e, a partir daí, encontrou centenas de outros consoles do ARTEX expostos na internet, a maioria com página de login em mandarim e hospedados em provedores em Singapura e Hong Kong. A Microsoft já havia associado o framework ao Storm-0940, um ator alinhado à China ligado a um comprometimento recente de cadeia de suprimentos, e documentou o ARTEX atacando Okta, Entra ID e Cognito em empresas de TI e software nos últimos meses.

Por dentro do ARTEX: não é script, é um time de agentes com memória compartilhada

O operador sobe chaves de API de provedores de inferência e aponta o ARTEX para praticamente qualquer modelo, via três formatos de requisição: openai (cobre OpenAI, DeepSeek, Qwen, MiniMax e revendedores estilo OpenRouter), openai-responses e anthropic (que também cobre endpoints compatíveis, como o da própria DeepSeek). Quando um provedor bane ou corta uma chave, o ARTEX simplesmente migra para a próxima: uma única campanha pode atravessar vários provedores e chaves diferentes, o que torna inútil bloquear por vendor de modelo.

Um agente planejador distribui "intents" para um time de workers, que rodam três por vez por padrão, enquanto um agente principal conversa com o operador (com um comando /btw para perguntas paralelas). Tudo fica registrado num grafo chamado "blackboard", com tasks, goals, intents, facts, findings e resumos de compressão. Cada task carrega regras de permissão e bloqueio definidas pelo operador, um timeout com etapa de encerramento, e um heartbeat do planejador de ao menos 10 minutos.

Regras de interceptação de comando, escritas como regex ou string literal, podem permitir, negar ou pedir julgamento humano. Em algumas versões existe uma blocklist global de domínios .gov, .gov.cn, .edu e .edu.cn por padrão. Uma das versões analisadas pela Datadog vem com um engajamento de demonstração completo: do aplicativo web público até o foothold na DMZ, movimento lateral interno e, por fim, o domain controller do Active Directory, um roteiro de red team inteiro empacotado como exemplo.

Um hábito chama atenção para quem caça esse tipo de atividade: antes de cada rodada de fuzzing, o agente pede um caminho que não deveria existir, como /zzz-nonexistent-xyz123, para aprender como é a resposta de "não encontrado" daquele alvo. A Datadog viu o mesmo comportamento contra o S3, com chaves como zzz_nonexistent_abc.txt e Notexist-xyz. Uma requisição por um objeto com nome de placeholder, logo antes de uma rajada de tentativas, é um sinal de caça com bom retorno.

Dois jeitos de entrar numa conta AWS

Nas campanhas analisadas, todo acesso começou da mesma forma: requisições não autenticadas ao S3, aparecendo no CloudTrail com userIdentity.type igual a AWSAccount e accountId igual a anonymous, chamando GetObject, ListObjects e APIs de leitura parecidas. Depois disso, a Datadog viu dois vetores de entrada distintos.

Cluster 1: FilterLogEvents caçando fundo de hedge e segredo em log

Usando uma chave de longo prazo válida, a ação mais frequente do agente foi FilterLogEvents, com termos de busca combinando nomes de empresas de criptomoeda, fundos hedge e instituições financeiras com palavras como Fund, Invoice, Billing e LLC. Toda chamada vinha com limit fixado em 1000, abaixo do teto de 10.000 eventos da API, um padrão que se repetiu em várias sessões e sugere um comportamento deliberadamente discreto.

No dia 20 de outubro, a mesma chave reapareceu a partir do IP 103.54.154.40, associado ao provedor zeofast.cn, e a busca ficou mais ampla: links de armazenamento e presigned URLs (s3://, presigned, .pdf, .xlsx, .csv), além de rastros de banco de dados, IPs internos e segredos (mongo, prefixos 172. e 10., password, AKIA). Para quem opera a conta, isso é um lembrete direto de que logs de aplicação no CloudWatch viram um alvo de primeira linha quando carregam token, URL assinada ou credencial por engano.

Cluster 2: cadastro anônimo no Cognito travado pela Lambda de pré-cadastro

Em outra sessão, sem chave de longo prazo nenhuma, o ARTEX foi atrás de pools públicos do Cognito. A Wiz já havia reportado abuso de recuperação de conta via InitiateAuth, ForgotPassword e ResendConfirmationCode; a Datadog viu o agente ir além, se cadastrando de fato, coletando tokens, trocando-os por credenciais AWS e partindo para enumeração.

Um pico em 26 e 27 de outubro, a partir do IP 154.64.252.77, trouxe chamadas de SignUp com user agent Mozilla/5.0 ARTeX em parte das tentativas. O pool tinha um gatilho Lambda de PreSignUp validando o domínio do tenant, e o agente insistiu contra ele até errar de várias formas (domínio inválido, tenantId não bate com o domínio, atributo customizado sem schema definido) antes de conseguir avançar.

Uma vez registrado, o fluxo seguiu o padrão do Cognito: SignUp, InitiateAuth, RespondToAuthChallenge, GetUser e GetTokensFromRefreshToken, aparecendo no CloudTrail sob a sessão CognitoIdentityCredentials com credenciais temporárias. A partir daí o agente tentou quase toda chamada de descoberta somente leitura disponível: ListBuckets, GetBucket*, ListSecrets, DescribeParameters, ListTopics, DescribeLogGroups, GetRestApis, DescribeRepositories e ListFunctions20150331. Todas falharam, porque a role autenticada do identity pool não concedia essas permissões.

O que muda para quem desenha a role do identity pool

O Cluster 2 é, na prática, um estudo de caso de menor privilégio funcionando: o ataque foi contido não por um WAF nem por um alerta, mas porque a role anexada ao identity pool do Cognito simplesmente não tinha s3:ListBuckets, secretsmanager:ListSecrets nem equivalentes. É comum ver identity pools saindo de tutoriais com uma policy ampla demais anexada à role autenticada, porque "funciona" em desenvolvimento.

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

Uma policy mínima para esse tipo de role deveria restringir cada ação ao recurso exato que o app precisa, sem curinga em Resource nem em Action:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::meu-bucket-app/${cognito-identity.amazonaws.com:sub}/*"
 }
 ]
}

Usar * em Action ou Resource só se justifica em cenário muito específico (por exemplo, uma role de auditoria somente leitura num Account isolado de Organizations) e sempre com a ressalva documentada do porquê. Vale também tratar a Lambda de PreSignUp como parte do perímetro de identidade: validar domínio de tenant ali funcionou como um gate que gerou tentativas falhas registradas em log antes de qualquer coisa prosseguir.

Como caçar ARTEX na própria conta

A Datadog recomenda uma sequência de verificação que serve tanto pra quem usa a plataforma quanto pra quem monta a própria stack de detecção:

• Buscar nos logs de acesso (ALB, CloudFront, CloudTrail) os user agents associados ao framework, como artex-readonly/1.0, artex-pentest/1.0, artex-audit/1.0 e Mozilla/5.0 ARTeX, lembrando que user agent é trivial de falsificar e serve só como primeiro filtro.
• Cruzar IPs de origem com a lista de IOCs publicada, que inclui endereços ligados a provedores como Zeofast Network, NetLab Global e LUCIDACLOUD.
• Procurar por volume anômalo de erros AccessDenied, enumeração de objetos em logs do S3, uso de credenciais vindas de uma role de instância EC2 a partir de um IP fora da AWS, e eventos de CloudTrail que batem com técnicas catalogadas no Stratus Red Team ou no Cloud Security Atlas da Datadog.

Para quem já roda Cloud SIEM da Datadog, a lista de regras prontas inclui detecção de volume anômalo de AccessDenied, enumeração multi-região com chave de longo prazo, acesso anômalo a buckets S3, geração de credenciais temporárias para um usuário e recuperação de segredo por um principal IAM desconhecido no Secrets Manager. A própria Datadog também mantém regras de Cloud Security Misconfigurations que miram a causa raiz desses clusters: rotação de chaves de acesso a cada 90 dias ou menos, remoção de chaves de IAM inativas há mais de um ano e desativação de credenciais não usadas.

O que ainda fica em aberto

A Datadog é clara num ponto: as distribuições do ARTEX analisadas não têm uma metodologia opinativa de ataque em nuvem, o playbook fica por conta do modelo de LLM escolhido pelo operador, e varia bastante conforme o provedor de inferência. Isso significa que o comportamento observado em outubro e novembro de 2026 é uma amostra, não um padrão fixo, e pode mudar de campanha para campanha. Para quem quer entender melhor como diferentes modelos reagem ao receber chaves AWS comprometidas, a Datadog cita como leitura complementar a pesquisa "I Gave 14 LLMs AWS Keys. Here's What They Wanted to Do Next", de Adan Alvarez.

Fonte: Datadog Security Labs