Analyse eines doppelten AWS-EC2-Botnet-Befalls direkt nach dem Launch (von Security Groups bis zur Docker-Isolation)

Ich habe vor Kurzem QA Arena gelauncht, eine praxisnahe Übungsplattform zur Erstellung von Testcode für QA-Ingenieur:innen.

Nach dem Launch dachte ich mir: „Ich sollte mal einen Vorstellungsbeitrag auf GeekNews posten“ – stattdessen veröffentliche ich zuerst eine Rückschau auf einen AWS-Sicherheitsvorfall (Post-Mortem).
Ich teile, welche Folgen Sicherheitskonfigurationen hatten, die im Prozess der schnellen Entwicklung mit „Vibe Coding“ übersehen wurden, und wie ich aus QA-Perspektive darauf reagiert habe.

1. Incident Timeline & Analysis

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

  • Symptom: Auf der Instanz wurden Anzeichen von IoT-Exploit-Angriffen wie CVE-2017-18368 sowie ungewöhnliche Kommunikation erkannt.
  • Ursache: Der Egress-Ausgang der Security Group war für All Traffic geöffnet, sodass der infizierte Prozess mit externen Systemen kommunizieren konnte.
  • Erste Maßnahme: Isolierung der kompromittierten Instanz und Einführung von AWS Systems Manager (SSM), um den Administratorzugriff einzuschränken.

• Phase 2 (2026.01.14): Docker Container Escape

  • Symptom: Vom AWS Trust & Safety Team ging ein Abuse Report mit dem Hinweis „Kommunikation mit einem Botnet-C&C-Server erkannt“ ein. (IP: 72.62.195.44)
  • Root Cause: Auf den Docker-Containern, die vom Nutzer eingereichten Code ausführen, war keine Netzwerkisolation angewendet. Bei der Verwendung von KI-generiertem Code fehlte die Einstellung network_mode.**

2. Mitigation (technische Gegenmaßnahmen)**
   Unmittelbar nach Erkennen des Vorfalls habe ich den QA-Prozess auf den Infrastruktur-Bereich ausgeweitet und folgende Maßnahmen umgesetzt.

• Network Isolation: Alle aktiven Verbindungen zur bösartigen IP wurden blockiert.
• Security Group Hardening: Outbound-Traffic wurde strikt auf HTTPS (443) begrenzt.
• Code Patch: Durch eine Änderung im Code von docker_service.py wurde für alle Worker-Container network_mode="none" verbindlich gesetzt.

3. Fazit
Gegenüber AWS wurden die oben genannten Maßnahmen mit Nachweisen (Evidence Attached) dargelegt, woraufhin der Fall abschließend als [Resolved] eingestuft wurde.
[IMG] Bild als Nachweis der AWS-Lösung

Dieser Vorfall zeigt, dass „sich der Umfang von QA über den Anwendungscode hinaus bis auf die Infrastrukturkonfiguration erweitern muss“.
Das ist QA-Arena, das eine harte Feuertaufe und sogar die Sicherheitsprüfung hinter sich hat. Ich freue mich über viel Feedback.

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

[orange]

Ich habe ein durch den Einsatz von AI entstandenes Sicherheitsproblem mit AI gelöst und den Prozess mit AI für GeekNews dokumentiert.

[roxie]

Meine Güte..