Show GN: 런칭 직후 겪은 AWS EC2 봇넷 감염 2연타 분석 (Security Group부터 Docker 격리까지)

QA 엔지니어를 위한 테스트 코드 제작 실전 연습 플랫폼, QA Arena를 얼마전에 런칭하였습니다.

서비스를 런칭하고 "긱뉴스에 소개 글을 한번 올려야지" 생각하고 있었는데, 소개보다 AWS 보안 사고 회고(Post-Mortem)를 먼저 올리게 되었습니다.
'바이브 코딩(Vibe Coding)' 으로 빠르게 개발하는 과정에서 놓친 보안 설정이 어떤 결과를 초래했는지, 그리고 QA의 관점에서 어떻게 대응했는지 공유합니다.

1. Incident Timeline & Analysis

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

  • 증상: 인스턴스에서 CVE-2017-18368 등 IoT 익스플로잇 공격 징후 및 비정상 통신 감지.
  • 원인: Security Group의 Egress(출구)가 All Traffic으로 열려있어, 감염된 프로세스가 외부와 통신 가능.
  • 1차 조치: 오염된 인스턴스 격리 및 AWS Systems Manager (SSM) 도입으로 관리자 액세스 제한.

• Phase 2 (2026.01.14): Docker Container Escape

  • 증상: AWS Trust & Safety 팀으로부터 "Botnet C&C 서버와 통신 감지" 라는 Abuse Report 수신. (IP: 72.62.195.44)
  • Root Cause: 사용자 제출 코드를 실행하는 Docker 컨테이너에 네트워크 격리가 적용되지 않음. AI 생성 코드 사용 시 network_mode 설정 누락.**

2. Mitigation (기술적 대응)**
   사고 인지 직후, QA 프로세스를 인프라 영역에 적용하여 다음과 같이 조치했습니다.

• Network Isolation: 악성 IP와의 모든 활성 연결 차단.
• Security Group Hardening: Outbound 트래픽을 HTTPS(443)로 엄격히 제한.
• Code Patch: docker_service.py 코드 수정을 통해 모든 워커 컨테이너에 network_mode="none" 강제 적용.

3. Conclusion
AWS 측에 위 조치 사항(Evidence Attached)을 소명하여 최종 [Resolved] 판정을 받았습니다.
[IMG] AWS 해결 증빙 이미지

이번 사고는 "QA의 범위가 애플리케이션 코드를 넘어 인프라 구성(Configuration)까지 확장되어야 함" 을 시사합니다.
혹독한 신고식을 치르고 보안 검증까지 마친 QA-Arena입니다. 많은 피드백 부탁드립니다.

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

[orange]

AI를 사용하다가 생긴 보안 문제를 AI로 해결하고 과정을 AI로 정리해서 긱 뉴스에 포스팅