Análisis de dos infecciones consecutivas por botnet en AWS EC2 justo después del lanzamiento (desde Security Group hasta el aislamiento de Docker)

Hace poco lanzamos QA Arena, una plataforma de práctica real para crear código de pruebas dirigida a ingenieros de QA.

Después de lanzar el servicio, estaba pensando: "debería publicar una presentación en GeekNews", pero terminé publicando primero una retrospectiva del incidente de seguridad en AWS (Post-Mortem).
Comparto qué consecuencias trajeron las configuraciones de seguridad que se nos pasaron en el proceso de desarrollar rápidamente con "Vibe Coding", y cómo respondimos desde la perspectiva de QA.

1. Incident Timeline & Analysis

• Phase 1 (2025.12): Inbound/Outbound Policy Failure

  • Síntoma: Se detectaron señales de ataques de exploits IoT, como CVE-2017-18368, y comunicaciones anómalas desde la instancia.
  • Causa: El Egress (salida) del Security Group estaba abierto con All Traffic, por lo que el proceso infectado podía comunicarse con el exterior.
  • Primera medida: Aislamiento de la instancia contaminada y adopción de AWS Systems Manager (SSM) para restringir el acceso administrativo.

• Phase 2 (2026.01.14): Docker Container Escape

  • Síntoma: Se recibió un Abuse Report del equipo de AWS Trust & Safety indicando "comunicación detectada con un servidor C&C de botnet". (IP: 72.62.195.44)
  • Root Cause: No se aplicó aislamiento de red al contenedor Docker que ejecuta el código enviado por los usuarios. Al usar código generado por IA, se omitió la configuración de network_mode.**

2. Mitigation (respuesta técnica)**
   Apenas identificamos el incidente, aplicamos el proceso de QA al área de infraestructura y tomamos las siguientes medidas.

• Network Isolation: Bloqueo de todas las conexiones activas con la IP maliciosa.
• Security Group Hardening: Restricción estricta del tráfico saliente únicamente a HTTPS (443).
• Code Patch: Se modificó el código de docker_service.py para forzar network_mode="none" en todos los contenedores worker.

3. Conclusion
Explicamos a AWS las medidas anteriores (Evidence Attached) y finalmente recibimos la resolución [Resolved].
[IMG] Imagen de evidencia de resolución de AWS

Este incidente sugiere que "el alcance de QA debe extenderse más allá del código de la aplicación hasta la configuración de la infraestructura (Configuration)".
Así llega QA-Arena, que pasó por un durísimo bautismo de fuego y completó incluso la validación de seguridad. Agradeceré mucho sus comentarios.

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

[orange]

Resolví con IA un problema de seguridad que surgió al usar IA y organicé el proceso con IA para publicarlo en GeekNews

[roxie]

Vaya...