Global S3: Canal C2 em Interpretadores de Código do AgentCore

O AgentCore da Amazon Bedrock, lançado globalmente no final de 2025, promete sandboxing seguro para execução de código em agentes de IA, mas sua documentação oficial permite acesso explícito ao S3, e isso virou um vetor operacional real para C2. Diferente de exfiltrações via DNS (já corrigidas), o canal S3 é ativo, bidirecional e silencioso: um atacante configura um bucket externo, injeta um script cliente no interpretador que lê comandos de um objeto e escreve saídas de volta, usando URLs pré-assinadas como mensageiro. Não há tráfego HTTP suspeito para fora do ambiente, porque tudo flui por endpoints S3 legítimos, o que escapa de firewalls de saída e ferramentas de detecção baseadas em padrões de rede.

Isso não é teórico: a CVE-2026-4269 (divulgada em 16/03/2026) já havia exposto falha de verificação de propriedade de bucket no Starter Toolkit v0.1.12 ou anterior, permitindo RCE no runtime. Agora, com a nova técnica, mesmo após essa correção, o canal persiste, porque o problema não está na autenticação do bucket, mas na confiança implícita no acesso S3 como 'seguro por padrão'. O modo VPC não é uma alternativa opcional; é a única forma de isolar o sandbox de serviços AWS públicos sem depender de políticas IAM frágeis.

A cobertura anterior do CEVIU sobre o Zapocalypse (06/06/2026) mostrou que sandboxes Python podem ser comprometidos por execução direta de os.system, mas ali o ataque dependia de permissões STS órfãs e era detectável por logs de Lambda. Aqui, o canal S3 é mais sutil: não exige credenciais válidas, não gera chamadas à API IAM, e opera inteiramente dentro dos limites do acesso autorizado ao S3. Também difere da campanha TrapDoor (28/05/2026), que atacava estações locais via scripts postinstall, este é um risco de infraestrutura de execução remota, no coração do pipeline de agentes de IA em produção.

Time de plataforma que opera AgentCore em produção precisa repensar o modelo de sandboxing: se o acesso a S3 está habilitado por padrão, ele deve ser tratado como um ponto de saída de rede, não como um serviço interno inofensivo. Isso impacta diretamente práticas de observabilidade (logs de acesso S3 devem ser correlacionados com execuções de código), segurança em pipelines (validação de buckets autorizados deve ser parte do CI/CD) e custo em nuvem (requisições S3 maliciosas geram custos reais e podem saturar quotas). Ignorar esse vetor significa assumir que 'serviço AWS aprovado = seguro', o que já falhou no Zapocalypse e agora se repete com maior sofisticação.