Cloud 인프라 실제 침해사고 Case Study 분석

Cloud 인프라 실제 침해사고 Case Study 분석

이론으로 배운 보안은 한계가 있다. 실제 사례에서 교훈을 얻자.

들어가며

클라우드 보안을 공부할 때 가장 효과적인 방법 중 하나는 실제 침해사고 사례를 분석하는 것이다. "어떻게 뚫렸는가"를 이해해야 "어떻게 막을 것인가"를 설계할 수 있다.

이 글에서는 28회 해킹방지워크샵에서 발표된 Cloud 인프라 침해사고 사례들을 분석하고, 각 사례에서 얻을 수 있는 교훈과 대응 방안을 정리한다.

---

1. 사이버 생태계의 공격 패러다임 변화

클라우드 인프라를 겨냥한 공격은 과거와 질적으로 다르다.

전통적 공격 vs. 클라우드 공격

구분	전통적 공격	클라우드 공격
타겟	서버, 네트워크 장비	API, 자격 증명, 설정 오류
침투 경로	취약점 익스플로잇, 피싱	유출된 키, SSRF, 설정 미비
공격 속도	수일~수주	수분~수시간
자동화 수준	도구 기반	완전 자동화 파이프라인
피해 규모	단일 서버/네트워크	전체 클라우드 인프라 + 데이터

공격자의 관점

공격자는 다음과 같은 순서로 클라우드 인프라를 노린다.

1. 정찰: GitHub, Docker Hub 등에서 유출된 자격 증명 수집
2. 초기 접근: 유출된 키로 AWS API 호출 또는 SSRF로 IMDS 접근
3. 권한 상승: IAM 정책 오류를 악용하여 관리자 권한 획득
4. 지속성 확보: 백도어 IAM 사용자/역할 생성, Lambda 함수 삽입
5. 목표 달성: 데이터 탈취, 암호화폐 채굴, 랜섬웨어 배포

---

2. Case Study 1 — Snowflake 대규모 고객 데이터 유출 (2024)

2024년 최대 규모의 클라우드 보안 사고. 플랫폼 취약점이 아닌 고객의 자격 증명 관리 부재가 원인이었다.

사고 개요

2024년 2월~6월, 위협 행위자 UNC5537(ShinyHunters 연계)이 165개 Snowflake 고객 조직의 데이터를 유출했다.

공격 흐름

단계	내용
자격 증명 수집	2020년까지 거슬러 올라가는 인포스틸러 감염에서 탈취된 자격 증명 활용
MFA 부재 악용	피해 기업들이 Snowflake 계정에 MFA를 적용하지 않았음
데이터 탈취	대량 데이터 다운로드 및 다크웹 판매
피해 규모	Lending Tree(1.9억+ 개인정보), Truist Bank(6.5만 직원), Advance Auto Parts, Neiman Marcus(3,100만 이메일) 등

핵심 교훈

• Snowflake 플랫폼 자체의 취약점이 아니었다 — 고객의 자격 증명 관리 실패
• 수년 전 유출된 자격 증명이 여전히 유효했다는 점이 충격적
• MFA 하나만 적용했어도 대부분의 피해를 막을 수 있었음
• 2025년에도 같은 위협 그룹이 M&S, Co-op, Jaguar Land Rover 등을 공격

대응 방안

• [ ] 모든 클라우드 서비스에 MFA 필수 적용 — 예외 없이
• [ ] 인포스틸러 감염 대비 엔드포인트 보안(EDR) 강화
• [ ] 자격 증명 정기 교체 + 유출 모니터링 (Have I Been Pwned, Dark Web 모니터링)
• [ ] SaaS 서비스의 IP 허용목록 설정
• [ ] 과거 유출된 자격 증명 대비 Credential Stuffing 방어 설정

---

3. Case Study 2 — 자격 증명 유출을 통한 S3 데이터 탈취

사고 개요

한 스타트업의 개발자가 GitHub 퍼블릭 레포지토리에 AWS 액세스 키가 포함된 코드를 실수로 Push했다.

공격 타임라인

시간	이벤트
T+0분	GitHub에 액세스 키가 포함된 커밋 Push
T+7초	자동화된 봇이 키 탐지 및 수집
T+5분	키로 AWS API 호출 시작 — S3 버킷 목록 조회
T+15분	전체 S3 데이터 동기화(aws s3 sync) 시작
T+2시간	수십 GB 데이터 유출 완료
T+3시간	GuardDuty에서 비정상 API 호출 패턴 감지
T+4시간	보안팀 확인 및 키 무효화

교훈

• GitHub에 키가 올라가면 7초 안에 탈취된다 — 사람이 발견하기 전에 이미 끝남
• GuardDuty는 사후 탐지 — 유출을 막는 것이 아니라 알려주는 것
• 장기 액세스 키 자체를 사용하지 않는 것이 근본적 해결책
• 2025년부터는 Login for AWS local development로 로컬 개발 시 장기 키가 불필요해짐

대응 방안

• [ ] 장기 액세스 키 사용 금지 → IAM Role + 임시 자격 증명(STS) 사용
• [ ] git-secrets 또는 truffleHog로 커밋 전 키 탐지
• [ ] AWS Secrets Manager로 시크릿 중앙 관리
• [ ] GitHub에 push protection 활성화
• [ ] 키 유출 시 즉시 무효화 + 교체 프로세스 수립

---

4. Case Study 3 — SSRF를 통한 IMDS 메타데이터 탈취

사고 개요

웹 애플리케이션의 SSRF(Server-Side Request Forgery) 취약점을 통해 EC2 인스턴스의 IMDS(Instance Metadata Service)에 접근, IAM Role의 임시 자격 증명을 탈취한 사례.

공격 흐름

1. 취약한 웹 앱에 SSRF 공격
   → http://169.254.169.254/latest/meta-data/iam/security-credentials/

2. IAM Role의 임시 자격 증명 획득
   → AccessKeyId, SecretAccessKey, Token

3. 획득한 자격 증명으로 AWS API 호출
   → S3 데이터 접근, 추가 리소스 탐색

왜 IMDS v1이 위험한가?

IMDS v1은 단순 HTTP GET 요청으로 메타데이터에 접근 가능하다. SSRF 취약점이 있으면 공격자가 원격에서 메타데이터를 읽을 수 있다.

대응 방안

# IMDS v2 강제 적용 (PUT 요청 + 토큰 필요)
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

• [ ] 모든 EC2 인스턴스에 IMDS v2 강제 적용
• [ ] SSRF 취약점이 있는 애플리케이션 패치
• [ ] EC2 인스턴스의 IAM Role에 최소 권한 적용
• [ ] VPC Endpoint를 통한 S3 접근으로 인터넷 경유 차단

---

5. Case Study 4 — 과도한 IAM 권한을 통한 권한 상승

사고 개요

개발 환경의 EC2 인스턴스에 AdministratorAccess 정책이 부여된 IAM Role이 할당되어 있었다. 해당 인스턴스의 웹 애플리케이션 취약점을 통해 침입한 공격자가 전체 AWS 인프라를 장악한 사례.

공격 흐름

1. 개발 환경 EC2의 웹 앱 취약점으로 초기 접근
2. IMDS를 통해 AdministratorAccess 자격 증명 획득
3. 새로운 IAM 사용자 생성 (백도어)
4. CloudTrail 비활성화 시도
5. 전체 S3 버킷 데이터 유출
6. 프로덕션 환경까지 접근

교훈

• 개발 환경이라도 최소 권한 원칙은 필수
• AdministratorAccess를 EC2 Role에 부여하는 것은 극도로 위험
• 개발/스테이징/프로덕션 환경은 계정 수준에서 분리해야 함

대응 방안

• [ ] 최소 권한 원칙 — 필요한 서비스와 액션만 허용
• [ ] Permission Boundaries 적용
• [ ] AWS Organizations + SCP로 계정별 권한 상한 제어
• [ ] 개발/스테이징/프로덕션 계정 분리 (AWS Organizations)
• [ ] IAM Access Analyzer로 과도한 권한 정기 점검

---

6. Case Study 5 — 암호화폐 채굴 공격

사고 개요

유출된 자격 증명으로 AWS 계정에 접근한 공격자가 고사양 EC2 인스턴스를 대량으로 생성하여 암호화폐 채굴에 악용한 사례.

피해

• 하루 만에 수천 달러의 AWS 비용 발생
• 전 세계 리전에 걸쳐 EC2 인스턴스 생성
• 정상 서비스에 영향 (리소스 한도 초과)

대응 방안

• [ ] AWS Budgets 알림 — 일별 비정상 비용 급증 즉시 감지
• [ ] 미사용 리전 Opt-out — 사용하지 않는 리전 비활성화
• [ ] SCP로 리전 제한 — 필요한 리전에서만 리소스 생성 허용
• [ ] GuardDuty — 암호화폐 채굴 활동 탐지 (CryptoCurrency 탐지 유형)
• [ ] 비정상 EC2 대량 생성 시 자동 알림 + 차단 Lambda 구성

---

7. 침해사고 대응 조직과 프로세스

사고 대응 조직도 구성

CISO / 보안 책임자
├── 침해사고 대응팀 (CSIRT)
│   ├── 포렌식 담당
│   ├── 인프라 담당
│   └── 커뮤니케이션 담당
├── 클라우드 운영팀
├── 개발팀 (앱 취약점 대응)
└── 외부 파트너
    ├── AWS Support / CIRT
    └── 3rd Party 보안 업체

긴급 연락망

사고 발생 시 30분 이내에 핵심 인력에게 연락할 수 있는 체계를 갖추어야 한다.

• 보안팀 → CISO → 경영진 에스컬레이션 경로
• AWS Support 케이스 즉시 오픈 절차
• 법률팀 / 규제 기관 보고 절차 (개인정보 유출 시)

---

8. 종합 교훈

사례	핵심 원인	대응 키워드
Snowflake 대규모 유출	MFA 미적용 + 과거 유출 자격 증명	MFA 필수, 자격 증명 모니터링, EDR
S3 데이터 탈취	장기 액세스 키 유출	STS, git-secrets, Secrets Manager
IMDS 메타데이터 탈취	IMDS v1 + SSRF	IMDS v2 강제, 웹 앱 패치
권한 상승	과도한 IAM 권한	최소 권한, Permission Boundary, SCP
암호화폐 채굴	자격 증명 유출 + 리전 미제한	Budgets, 리전 Opt-out, GuardDuty

공통 교훈:

1. 장기 자격 증명은 최대한 사용하지 말 것
2. 최소 권한 원칙을 예외 없이 적용할 것
3. 탐지 → 격리 → 분석의 자동화 파이프라인을 사전 구축할 것
4. 사고가 터지기 전에 플레이북과 모의 훈련을 갖출 것

---

이 글은 제28회 해킹방지워크샵 발표 내용과 AWS 보안 모범 사례를 기반으로 작성되었습니다. 2024년 Snowflake 침해사고(CSA 분석 보고서)를 추가하여 업데이트되었습니다. 클라우드 보안 시리즈 [8/10]