Análise do duplo ataque de infecção por botnet em AWS EC2 logo após o lançamento (de Security Group ao isolamento do Docker)

Recentemente lançamos o QA Arena, uma plataforma prática de exercícios para criação de código de teste voltada a engenheiros de QA.

Depois de lançar o serviço, eu estava pensando em “fazer um post de apresentação no GeekNews”, mas acabei publicando antes uma retrospectiva (Post-Mortem) de um incidente de segurança na AWS.
Compartilho aqui quais consequências foram causadas por configurações de segurança que passaram despercebidas durante um processo de desenvolvimento acelerado com “Vibe Coding” e como respondemos a isso sob a perspectiva de QA.

1. Incident Timeline & Analysis

• Phase 1 (2025.12): Falha na política de Inbound/Outbound

  • Sintoma: Foram detectados na instância sinais de ataques de exploit de IoT, como o CVE-2017-18368, além de comunicações anormais.
  • Causa: O Egress (saída) do Security Group estava aberto como All Traffic, permitindo que processos infectados se comunicassem com o exterior.
  • Primeira ação: Isolamento da instância contaminada e adoção do AWS Systems Manager (SSM) para restringir o acesso administrativo.

• Phase 2 (2026.01.14): Escape de contêiner Docker

  • Sintoma: Recebimento de um Abuse Report da equipe de AWS Trust & Safety com a mensagem "detecção de comunicação com servidor Botnet C&C". (IP: 72.62.195.44)
  • Root Cause: Não havia isolamento de rede aplicado ao contêiner Docker que executava o código enviado pelo usuário. Ao usar código gerado por IA, a configuração network_mode foi omitida.**

2. Mitigation (resposta técnica)**
   Assim que o incidente foi identificado, aplicamos o processo de QA à área de infraestrutura e tomamos as seguintes medidas.

• Network Isolation: Bloqueio de todas as conexões ativas com o IP malicioso.
• Security Group Hardening: Restrição rigorosa do tráfego de saída apenas para HTTPS (443).
• Code Patch: Modificação do código docker_service.py para aplicar de forma obrigatória network_mode="none" a todos os contêineres de worker.

3. Conclusion
Após apresentar à AWS as medidas acima (Evidence Attached), recebemos por fim a classificação [Resolved].
[IMG] Imagem de comprovação da resolução da AWS

Este incidente mostra que "o escopo de QA precisa se expandir além do código da aplicação e alcançar também a configuração da infraestrutura (Configuration)".
Este é o QA-Arena, que passou por um batismo duro e concluiu até a validação de segurança. Agradecemos muito pelo feedback.

🔗 QA-Arena: https://qa-arena.qalabs.kr/

[orange]

Resolvi um problema de segurança que surgiu ao usar IA com IA e organizei o processo com IA para publicar no GeekNews

[roxie]

Nossa...