pile·
보안·카카오 스타일 (지그재그)카카오 스타일 (지그재그)·

AWS Abuse Report

AWS 로부터 Abuse Report 메일을 받고 EMR 클러스터가 암호화폐 채굴에 이용된 것을 확인하기까지의 대응 기록이다. 원인은 데이터 팀이 내부 사용을 위해 EMR 마스터 노드 포트를 전 세계에 열어 둔 것이었고, 9분 만에 익명 사용자가 들어왔다.

핵심 포인트
  • 05:30 에 EMR 마스터 노드 포트를 열었고 05:39 에 `dr.who` 라는 익명 사용자가 클러스터에 접근을 시작했다. 9분 만이다.
  • 10:00 까지 수초~10여 분짜리 hadoop 작업 수천 개가 실행됐고, 리포트를 받은 3개 인스턴스는 CPU 100% 를 유지했다.
  • 11:04 첫 대량 트래픽 발생 → 11:06 AWS Abuse 메일 발송 → 11:09 확인 → 11:24 인스턴스 종료 → 12:55 해결 확인. 탐지에서 차단까지 20분이었다.
  • 처음에는 계정이 털려 누군가 인스턴스를 만든 줄 알았으나 확인해 보니 자사가 만든 인스턴스였고, 다시 읽어 보니 트래픽 과다 리포트였다.
  • DDoS 를 의심했지만 데이터 팀 분석 결과 알려진 사례와 유사한 로그를 발견해 **암호화폐 채굴**로 잠정 결론 냈다.
상세 정리
  • 최초 인지 과정이 현실적이다. 광고성 메일인 줄 알고 넘기려다 제목의 불안한 단어가 눈에 들어와 열어 봤다.
  • 메일 앞부분에 EC2 Instance Id 가 보여 계정 노출을 먼저 의심했다는 점에서, 같은 메일도 읽는 순서에 따라 오진할 수 있음이 드러난다.
  • 해당 인스턴스는 데이터 팀이 분석용으로 띄워 둔 EMR 작업 노드였고, EMR 로그에서 알 수 없는 사용자의 YARN 애플리케이션 실행 이력을 발견했다.
  • 대응은 분석보다 차단이 먼저였다. 상황 파악 전에 EMR 클러스터를 먼저 종료했다.
  • 남은 의문도 기록한다. hadoop 애플리케이션은 10:00 에 끝났는데 트래픽은 11:00 에 발생해 시점이 어긋났다.
  • 총 3개 인스턴스에 대해 메일을 받았으며, EMR 에는 작업 노드가 더 있었지만 그중 3개만 CPU 100% 였다.
  • 같은 시기의 다른 사건들도 함께 적는다. 22일 오전 AWS 서울 리전 장애(지그재그는 구조상 전면 중단은 피했지만 영향을 받음), 25일 KT 아현지사 화재로 해당 IDC 서버 피해.
  • 결과적으로 트래픽 비용이 조금 발생하는 선에서 끝났지만, 최악의 상황에도 데이터는 보존되도록 해야겠다는 교훈으로 맺는다.
  • 개발팀이 커지고 작업 범위가 늘수록 보안 사고 가능성도 커진다는 점을 마지막에 짚는다.
왜 읽나내부용이라며 잠깐 포트를 열어 두는 관행이 얼마나 빨리 악용되는지(9분), 그리고 Abuse Report 를 받았을 때의 대응 순서를 타임라인으로 보여준다.
카카오 스타일 (지그재그)
카카오 스타일 (지그재그) 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 보안·gitlab-engGitLab Blog·

    Serena MCP 에이전트의 치명적 원격 코드 실행 취약점 분석

    GitLab 보안팀이 AI 코딩 에이전트 Serena(월 PyPI 다운로드 13.6만 건)에서 치명적 원격 코드 실행 취약점을 발견했다. Jinja2 비샌드박스 환경과 신뢰 모델의 미검사 경로가 결합해 개발자가 악의적 저장소를 열기만 해도 코드가 실행된다. serena-agent 1.7.0에서 SandboxedEnvironment 교체로 수정 완료됐다.

    요약 이어보기
    #mcp#security#rce+2