📺 쿠팡 등 API 인증 키(JWT) 유출 사고, '행위 기반' 탐지로 방어하는 방법 (모의해킹 영상 포함)

By PLURA 2025-12-08

2025년 6월 24일부터 약 5개월간, 쿠팡은 정상 로그인 절차 없이도 고객 정보를 조회할 수 있는 인증 취약점을 공격자에게 노출한 채 운영했습니다.

정부 조사와 언론 보도를 종합하면, 사건의 근본 원인은 JWT 서명키 관리 실패 + 내부자(퇴사자)의 지식 악용 가능성으로 좁혀지고 있습니다.

이번 사건은 “내부 지식 및 키 유출이 결합된 외부 공격”이 얼마나 치명적인 결과를 초래할 수 있는지를 보여주는 대표 사례입니다.

특히 국내 대규모 플랫폼 서비스가 요청/응답 본문 기반 관제 부재로 인해, 장기간 진행된 대규모 데이터 유출을 전혀 감지하지 못했다는 점에서 심각한 경고 신호로 받아들여야 합니다.

coupang_authkey

먼저 보는 핵심 요약

이 사건의 핵심은 네 가지입니다.

JWT 서명키 유출은 곧 인증 체계 붕괴에 가깝습니다.
정수 기반 사용자 ID 설계는 전수 조회 공격을 쉽게 만들었습니다.
정상 200 OK 응답만 본 기존 보안 체계는 대규모 유출을 놓쳤습니다.
이런 사고는 IP가 아니라 행위 패턴, 요청/응답 본문, 민감 API 사용 흐름을 함께 봐야 막을 수 있습니다.

1. 사건 개요

정상 로그인 없이 3,370만 계정 정보 유출

정부 발표에 따르면 공격자는 쿠팡 내부 인증에 사용되던 JWT 서명키를 이용해, 정상 로그인 절차 없이도 서버가 신뢰하는 JWT 토큰을 직접 생성한 것으로 파악됩니다.
이 위조 토큰으로 API를 대량 호출해 이름·전화번호·주소·이메일·주문 정보 등 개인정보를 유출한 것으로 조사되었습니다.
초기에는 “4,500개 계정 노출” 정도로 알려졌지만, 이후 실제 피해가 약 3,370만 계정 유출로 확인되었습니다.
일부 배송지 메모에는 공동현관 비밀번호까지 포함되어 있어, 주거 침입·택배 사칭 등 2차 범죄로 이어질 위험도 지적되었습니다.

악성코드 흔적 없음 → 키 유출·내부 지식 악용 중심 사고

서버 내부에서 악성코드나 웹셸은 발견되지 않았습니다.
즉, 이번 사고는 전통적인 “취약점 침투 → 악성코드 설치”형 공격보다는, 내부 지식과 서명키 유출을 바탕으로 한 외부 API 남용 공격에 가깝습니다.

2. 공격에 사용된 핵심 취약점

JWT 서명키 유출: 인증 체계가 그대로 붕괴

JWT 서명키는 “이 토큰이 정말 서버가 발급한 것인지”를 검증하는 비밀키입니다.

이 키가 유출되면 공격자는 다음을 할 수 있습니다.

임의의 계정(sub)에 대한 토큰 생성
만료 시간(exp) 조작
권한(role) 또는 scope 조작
로그인 서버와 인증 서버를 우회하고 곧바로 API 호출

즉,

JWT 서명키 유출 = 인증 시스템 붕괴

라고 봐도 과장이 아닙니다.

서명키를 즉시 회수·교체하지 않는 한, 공격자는 반영구적으로 합법 사용자처럼 시스템을 악용할 수 있습니다.

퇴사자와 연관된 서명키가 폐기되지 않음

언론 보도에 따르면 관련 서명키는 쿠팡 인증 시스템 담당 전직원과 연관된 것으로 추정됩니다.
퇴사 이후에도 이 키가 즉시 폐기·교체되지 않은 채 서비스에 남아 있었다는 정황이 제기되었습니다.
공격자는 해외 VPS를 이용해 쿠팡이 발급한 것처럼 보이는 JWT를 대량 생성하며 API를 호출할 수 있는 상태였습니다.

3. 공격 흐름 분석

공격 시나리오 재구성

1) JWT 서명키 유출 또는 사전 지식 획득

인증 담당자는
- JWT 서명키 자체
- 또는 이를 재구성할 수 있는 설계 정보·환경 정보 에 접근할 수 있는 위치에 있었습니다.
퇴사 전후 과정에서 이 정보가 외부로 나갔고,
퇴사 후에도 키가 교체되지 않아 공격 가능 상태가 유지된 것으로 볼 수 있습니다.

2) 해외 VPS에서 위조 JWT 대량 생성

공격자는 해외 VPS 여러 대를 준비한 뒤,
유출된 서명키로 서버가 신뢰하는 형식의 JWT를 대량 생성합니다.

예를 들어 다음과 같은 요소를 정상처럼 맞춥니다.

Header: 서비스에서 사용하는 알고리즘과 동일
Payload:
- sub: 조회 대상 사용자 ID
- exp: 충분히 긴 만료 시간
Signature: 유출된 실제 서명키로 생성

3) 정수 기반 사용자 ID가 대량 조회를 쉽게 만듦

이번 사고에서 특히 치명적인 부분은
사용자 ID가 난수형 UUID가 아니라 정수 기반 식별자(1, 2, 3, …) 였다는 점입니다.

이 경우 공격자는

sub=1 토큰 생성 → 사용자 1 정보 조회
sub=2 토큰 생성 → 사용자 2 정보 조회
sub=3 토큰 생성 → 사용자 3 정보 조회

처럼 매우 단순한 방식으로 전체 고객을 순회할 수 있습니다.

즉,

JWT 서명키는 만능 도장이고,
정수형 ID는 누구를 찍을지만 정하면 되는 번호표가 됩니다.

4) 왜 5개월 동안 탐지되지 않았는가

모든 호출이 정상 HTTP 200 OK 응답
JWT 서명도 정상
해외 IP라 해도 속도 조절 시 “트래픽이 조금 많은 이용자”처럼 보일 수 있음
그리고 가장 중요한 문제는:

요청과 응답 본문에 어떤 데이터가 오갔는지,
그 전체 흐름을 관제하는 체계가 사실상 없었다는 점입니다.

4. 왜 막지 못했는가 — 구조적 보안 실패

4.1 JWT 서명키 관리 실패

퇴사자와 연관된 서명키를 즉시 폐기 또는 교체하지 않음
서명키 하나가 전체 인증 체계의 단일 실패 지점(SPOF)이 됨

4.2 사용자 ID 설계 취약

정수 기반 식별자 사용으로 전수 조회 공격이 쉬운 구조
외부 노출 영역에서는 최소한 난수형 ID / 토큰화 / 추가 검증 로직이 필요했으나 미흡했습니다

4.3 대량 조회 이상행위 탐지 부재

“해외 IP + 반복 호출 + 민감 API + 응답 크기 증가”를 하나의 시나리오로 묶어 탐지하는 체계가 없었습니다
단순 분당 호출 수만 보면 속도 조절이 들어간 공격은 놓치기 쉽습니다

4.4 요청/응답 본문 기반 관제 부재

이 사건의 핵심 구조적 문제는 이것입니다.

응답 본문 안에
- 이름
- 전화번호
- 주소
- 이메일
- 주문 내역
- 공동현관 비밀번호
같은 민감정보 덩어리가 반복적으로 실려 나갔는데도, 이를 아무도 유출 징후로 보지 않았습니다.

요청/응답 본문을 보지 않는 한,
“정상 200 응답”과 “대량 데이터 덤프 응답”을 기계적으로 구분하기는 매우 어렵습니다.

5. 왜 기존 방어 체계는 놓쳤을까?

이 사건은 흔한 악성코드 사고가 아니었습니다.
그래서 전통적인 방어 체계는 다음과 같은 이유로 무력화될 수 있습니다.

기존 보안 장비가 놓치기 쉬운 이유

관점	기존 방식	이번 사고에서의 한계
인증 검증	토큰 서명 유효 여부 확인	유출된 실제 키로 만든 토큰은 정상처럼 보임
IP 차단	블랙리스트 / 국가 차단	해외 VPS 분산, 속도 조절 시 우회 가능
WAF/방화벽	비정상 요청 차단	요청 자체는 정상 API 호출처럼 보일 수 있음
응답 분석	대개 제한적	200 OK 응답 안의 민감정보 대량 반환을 놓침
대량 조회 탐지	단순 임계치 기반	장기 저속 공격, 분산 공격에 취약

즉, 이 사고는
“유효한 토큰을 가진 정상 사용자가 민감 데이터를 너무 많이 본다”는
행위 기반 문제였지, 전통적인 시그니처 기반 문제만은 아니었습니다.

6. PLURA-XDR: 유출된 키도 ‘행위’로 막아야 합니다

PLURA-XDR과 PLURA-WAF는
키 유출 사실 자체를 즉시 알아내지 못하더라도,
그 결과로 나타나는 비정상적 데이터 접근 행위를 실시간으로 탐지하고 차단하는 데 초점을 둡니다.

이 상황에서 보안 담당자는 반드시 두 가지 최악의 시나리오에 답할 수 있어야 합니다.

내부 개발자가 악의를 품고 JWT 마스터 키를 가지고 퇴사했다면?
개발자의 실수로 마스터 키가 유출되었고, 해커가 이를 습득했다면?

이 경우 공격자는 기술적으로는 정상 인증 권한을 가지고 들어옵니다.
따라서 단순히 “유효한 토큰인가?”만 보면 대부분 통과합니다.

그래서 필요한 것은
누가 들어왔는가가 아니라,
그들이 무엇을 하고 있는가를 보는 것입니다.

7. PLURA의 행위 기반 탐지는 무엇을 보는가?

핵심은 IP 숫자가 아니라 패턴입니다.

PLURA가 보는 주요 행위 기준 예시

짧은 시간 안에 반복되는 민감 API 호출
동일 리소스 또는 유사 리소스에 대한 순차 조회
정상 사용자 대비 비정상적으로 높은 요청 밀도
응답 본문 크기 증가 또는 민감정보 패턴 반복
동일 토큰 또는 동일 세션에서 지속되는 자동화 호출
국가, IP, 토큰, 세션이 바뀌어도 유지되는 공격 패턴의 일관성

예를 들어,

10초 내 20회 이상 민감 API 호출
동일 세션에서 연속적인 사용자 ID 증가 패턴
응답 본문에 반복적으로 개인정보 필드 포함
정상 사용자 평균 대비 과도한 반복 조회

같은 기준은
단순 IP 차단보다 훨씬 더 현실적인 탐지 기준이 됩니다.

즉,

공격자는 IP를 분산할 수 있어도,
자동화된 조회 패턴과 데이터 접근 흐름까지 완전히 숨기기는 어렵습니다.

8. [영상 시연] 유출된 JWT를 이용한 대량 조회 공격 방어

아래 시연은
탈취된 JWT를 이용해 정상 사용자처럼 API를 호출하면서
짧은 시간 안에 대량 조회를 시도하는 상황을 보여줍니다.

📺 탈취된 JWT 토큰의 역습, 3천만 계정은 어떻게 털렸나? | PLURA의 API 브루트포스 탐지 시연

영상 요약

공격 발생
공격자가 탈취한 JWT로 인증을 통과한 뒤, 스크립트를 이용해 수십~수백 번의 API 요청을 전송합니다.
PLURA 탐지
PLURA-XDR은 단일 IP나 토큰보다 과도한 요청 패턴 자체를 기준으로
[Brute Force] API 과요청과 같은 고신뢰도 이벤트를 생성합니다.
즉시 차단
미리 설정된 임계치를 초과하면 즉시 차단하여
대규모 데이터 유출로 이어지는 것을 막습니다.

9. 왜 일반 방화벽은 못 막을까?

일반적인 보안 장비는 보통 이렇게 묻습니다.

“이 키가 유효한가?”

하지만 훔친 키도 기술적으로는 유효한 서명을 갖고 있습니다.
그래서 일반 장비는 이를 정상 사용자처럼 통과시킬 수 있습니다.

반면 PLURA-XDR은
인증 자체를 넘어 다음을 봅니다.

“인증된 사용자가 왜 같은 패턴으로 수십, 수백 번 민감 API를 조회하는가?”

즉, 차이는 토큰의 유효성이 아니라
행위의 비정상성을 볼 수 있느냐입니다.

10. 대형 플랫폼이 반드시 점검해야 할 5가지 항목 ✅

항목	핵심 질문	체크
서명키 관리	퇴사자·전환 인력 발생 시 키 즉시 폐기/교체 절차가 있는가?	□
ID 설계	외부 노출 식별자가 순차형 정수로 설계되어 있지 않은가?	□
민감 API 탐지	대량 조회, 순차 조회, 반복 호출을 별도 탐지하는가?	□
요청/응답 본문 관제	어떤 데이터가 요청·응답으로 오가는지 실시간으로 볼 수 있는가?	□
자동 차단 운영	임계값과 차단 정책이 실제로 켜져 있고 검증되고 있는가?	□

11. 위협 인사이트: 키 하나로 플랫폼 전체가 털릴 수 있다

이번 사고가 보여주는 핵심 교훈은 다음과 같습니다.

내부 지식 및 키 유출은 외부 공격 못지않게 치명적입니다.
인증 체계와 데이터 사용 관제는 반드시 함께 가야 합니다.
퇴사자·내부자 위협 모델링은 더 이상 선택이 아닙니다.
플랫폼 규모가 클수록 단일 키 실패의 피해는 기하급수적으로 커집니다.

즉,

JWT 서명키 하나가 3,370만 계정 전체 유출로 이어질 수 있다면,
문제는 단순 인증이 아니라 운영 전체의 구조입니다.

✍️ 결론

이번 쿠팡 사고는
“키가 유출되면 끝”이라는 단순한 이야기로 끝나지 않습니다.

더 정확히 말하면,

키는 왜 즉시 교체되지 않았는가
왜 정수형 ID가 그대로 외부 조회에 사용되었는가
왜 민감 API의 대량 조회를 감지하지 못했는가
왜 요청/응답 본문 속 데이터 유출 징후를 보지 못했는가

이 질문에 답해야 합니다.

그리고 그 답은 결국 하나로 모입니다.

인증만 봐서는 부족합니다.
실제 데이터 접근 행위와 응답 흐름까지 함께 봐야 합니다.

이 사건은
Q21에서 다룬 “퇴사자 키 유출 + Brute Force 대응” 문제를
실제 대규모 사고 사례로 입증한 대표적 사건이라고 볼 수 있습니다.

즉, 필요한 것은:

키 즉시 교체
행위 기반 탐지
자동 차단
요청/응답 본문 기반 관제
운영되는 보안 체계

입니다.

보안은 기술을 보유하고 있다는 사실이 아니라,

설정이 켜져 있는가,
실제로 탐지되는가,
실제로 차단되는가

로 판단해야 합니다.