Analyse d’une double infection par botnet sur AWS EC2 juste après le lancement (du Security Group à l’isolation Docker)

J’ai récemment lancé QA Arena, une plateforme d’entraînement pratique à la création de tests pour les ingénieurs QA.

Après le lancement du service, je me disais que j’allais publier un post de présentation sur GeekNews, mais avant cela, j’ai fini par publier d’abord un retour d’expérience (post-mortem) sur un incident de sécurité AWS.
Je partage ici les conséquences d’une configuration de sécurité oubliée pendant un développement rapide en « Vibe Coding », ainsi que la manière dont j’y ai répondu du point de vue QA.

1. Chronologie et analyse de l’incident

• Phase 1 (2025.12) : échec de la politique d’entrée/sortie

  • Symptôme : détection sur l’instance de signes d’attaques par exploit IoT, dont CVE-2017-18368, ainsi que de communications anormales.
  • Cause : la règle Egress (sortante) du Security Group était ouverte sur All Traffic, ce qui permettait au processus infecté de communiquer avec l’extérieur.
  • Première mesure : isolation de l’instance contaminée et mise en place de AWS Systems Manager (SSM) pour restreindre l’accès administrateur.

• Phase 2 (2026.01.14) : échappement de conteneur Docker

  • Symptôme : réception d’un Abuse Report de l’équipe AWS Trust & Safety indiquant « détection de communications avec un serveur Botnet C&C ». (IP : 72.62.195.44)
  • Cause racine : aucune isolation réseau n’était appliquée au conteneur Docker exécutant le code soumis par l’utilisateur. Lors de l’utilisation de code généré par IA, la configuration network_mode avait été omise.**

2. Mitigation (réponse technique)**
   Dès la prise de connaissance de l’incident, j’ai appliqué le processus QA au domaine de l’infrastructure et pris les mesures suivantes.

• Isolation réseau : blocage de toutes les connexions actives avec l’IP malveillante.
• Renforcement du Security Group : limitation stricte du trafic sortant à HTTPS (443).
• Correctif de code : modification du code docker_service.py pour imposer network_mode="none" à tous les conteneurs worker.

3. Conclusion
Après avoir communiqué à AWS les mesures ci-dessus (Evidence Attached), l’incident a finalement été classé [Resolved].
[IMG] Image de preuve de résolution AWS

Cet incident montre que « le périmètre de la QA doit s’étendre au-delà du code applicatif jusqu’à la configuration de l’infrastructure ».
Après un baptême du feu particulièrement rude et une validation de sécurité complète, voici QA-Arena. Tous vos retours sont les bienvenus.

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

[orange]

J’ai rencontré un problème de sécurité en utilisant l’IA, je l’ai résolu avec l’IA et j’ai résumé le processus avec l’IA pour le publier sur GeekNews

[roxie]

C'est quelque chose...