롯데카드 해킹 사고 분석 - 왜 웹방화벽은 무용지물이 되었을까

By PLURA

2025년 8월 14일 19:21 첫 침해가 시작되어 15일까지 활동이 이어졌고, 조사 과정에서 웹셸(WebShell) 설치가 확인되었습니다. 이후 금융당국 합동조사 결과 총 유출량은 초기 보고(1.7GB)를 크게 상회하는 최대 200GB로 정정되었으며, 297만 명 규모의 고객 정보 포함이 공식화되었습니다. (금융위원회)

핵심: 공격자는 2017년에 공개·패치된 Oracle WebLogic 취약점(CVE-2017-10271)을 악용해 웹셸을 설치하고 장기간 내부에서 활동했습니다. 롯데카드는 8월 26일에야 악성코드 감염을 인지했고, 9월 1일 금융당국에 신고했습니다. (다음)

롯데카드 해킹 사건

1) 초기 침투 (Initial Access)

🔓 WebLogic RCE(CVE-2017-10271) 악용 (MITRE: T1190)

  • 취약한 WLS-WSAT SOAP/XML 역직렬화 경로를 통해 원격 코드 실행(RCE) 및 웹셸 업로드가 이뤄졌습니다. 패치는 2017년 10월 Oracle CPU에서 제공됐으나, 해당 업데이트가 누락된 상태였습니다. (다음)

2) 내부 장악·지속성 (Persistence & Lateral Movement)

🚨 웹셸 기반 권한 유지·확장 (MITRE: T1505.003, TA0003/TA0005)

  • 웹셸 설치 후 지속성 확보와 내부 탐색·확장이 진행되었습니다. 실시간 감시 미흡으로 2주 이상 인지 실패가 보도되었습니다. (다음)

3) 데이터 유출 (Exfiltration)

📂 최대 200GB 유출, 297만 명 정보 포함

  • 당초 1.7GB로 신고됐으나, 합동조사에서 8.14~8.27 기간 중 총 200GB 유출로 확인. 개인정보 포함 규모는 297만 명으로 집계되었습니다. 일부 고객군(약 28만 명)은 결제정보 관련 추가 조치 대상입니다. (금융위원회)

롯데카드는 유출 방식에 대해 “짧고 작은 전송을 반복해 야금야금 빼갔다”고 설명했습니다. 대용량 단일 전송이 아닌 소량 다회 전송 패턴이었음을 시사합니다. (경향신문)

4) 인지·보고 및 후속 조치

  • 8월 26일 악성코드(웹셸) 감염 최초 인지 → 8월 31일 유출 정황 파악 → 9월 1일 금융당국 신고. (다음)
  • 금융위원회/금감원은 현장검사와 함께 소비자 보호 대책(전용 센터, 재발급, 전액 보상 등)을 지시·점검했습니다. (금융위원회)

5) 공격 개념도

sequenceDiagram
    participant 공격자
    participant WAS as WebLogic 서버
    participant 내부망 as 내부 시스템
    participant 외부 as 외부 전송

    Note over 공격자,WAS: CVE-2017-10271 RCE (WLS-WSAT SOAP/XML 역직렬화)
    공격자->>WAS: 웹셸 업로드 (RCE 성공)
    WAS-->>공격자: 원격 명령/지속성

    Note over WAS,내부망: 내부 이동·권한 확장
    WAS->>내부망: 추가 명령·데이터 접근

    Note over 내부망: 대용량 유출(소량 다회 전송)
    내부망-->>외부: 최대 200GB 정보 반출(8/14~8/27)

6) 왜 WAF가 막지 못했나 — 핵심 요약

WAF가 “CVE-2017-10271 (WLS-WSAT SOAP/XML 역직렬화)”를 막지 못하는 흔한 이유는

  1. 본문(POST body) 심층 검사 미적용/제한,
  2. SOAP/XML 파싱·정규화 부재,
  3. 시그니처 미탑재/비활성,
  4. TLS 종단 위치/우회 경로 문제,
  5. 운영상 화이트리스트·예외,
  6. WAS 미패치가 겹치기 때문입니다.

이 취약점은 WLS-WSAT의 CoordinatorPortType 등 엔드포인트에서 java.beans.XMLDecoder 기반 역직렬화가 트리거되며, URL/헤더 룰만으로는 놓치기 쉬운 유형입니다. (금융위원회)

7) 운영 가설(의심) — “탐지 모드”·가시성 결핍

혹시 WAF가 ‘탐지 모드(Detect-only)’로 운용되었거나, 구조적으로 본문을 볼 수 없는 상태였을 가능성 공개 PoC 수준의 10271 트래픽을 기본 룰로도 잡을 수 있는데도 차단이 없었다면, ① 정책이 차단(Blocking) 대신 탐지 전용으로 임시(혹은 장기) 운용되었거나, ② TLS가 WAF 뒤에서 종단(SSL Passthrough)·본문 파싱/정규화 미적용(SOAP/XML)·WAF 비경유 우회 경로 등으로 탐지 자체가 어려운 구조였을 수 있습니다.

즉시 확인 포인트: 사고 구간의 WAF 차단 카운터/로그(=0인지), 정책 모드(Detect vs Block), SSL 가시화(서버 키/브리징 적용 여부), /wls-wsat/*에 대한 본문 검사/정규화 설정, LB·관리망 등 WAF 비경유 경로 존재 여부.

8) (신규) AI 보조 WAF 우회는 어떻게 가능했을까 — “가능성” 관점의 기술 시나리오

전제: 본 사건에서 AI 사용이 ‘필수’였다는 직접 증거는 공개되지 않음. 다만 가능한 전술로서, 공격자가 LLM/에이전트를 보조 수단으로 사용했을 합리적 시나리오는 다음과 같습니다.

8-1. 페이로드 자동 변형·퍼징(soap/xml)

  • 문법 기반 생성(Grammar-guided): SOAP Envelope/Namespace/WSDL 스키마를 토대로 합법적 구조를 유지하면서 Action/Namespace/Prefix/Order를 수십~수백 가지로 자동 변형.
  • 정규식 우회 패턴 주입: java.beans.XMLDecoder, WorkContextXmlInputAdapter 키워드를 **엔티티/CDATA/유니코드 이스케이프/분절(=쪼개기)**로 변형.
  • 헤더/본문 동시 변형: Content-Type ↔ SOAPAction 불일치, 이중 인코딩(URL-encoding in XML), 압축(gzip/deflate), chunked 전송 등으로 WAF의 길이/바이트/디코딩 한계 타격.
  • 경계값 노리기: WAF Request Body 검사 한도(예: 8KB/1MB/8MB) 근처에서 의미 없는 패딩/노이즈 삽입 → 부분 검사/미검사 유도.
  • 오탐 회피 토큰화: 정상 서비스의 SOAPAction·네임스페이스·스키마를 학습시켜 “정상처럼 보이는” 조합으로 페이로드 위장.

8-2. 자동화된 피드백 루프

  • 블랙박스 최적화: 응답 코드(200/403/500), 차단 사유 문자열, 지연 시간 등을 취합해 강화학습/베이지안 최적화로 “우회 성공률↑” 조합 탐색.
  • 속도·은닉성 조절: 레이트 리밋/웜업을 적용해 탐지 임계치를 넘지 않도록 자동 조절(“Low-and-Slow”).

8-3. 인프라·타이밍 공략

  • 교란 연계: DDoS·오탐 유발 트래픽으로 운영상 차단 해제(Detect-only 전환) 를 유도한 뒤 우회 페이로드 투입.
  • 우회 경로 탐색: 관리망/직결 경로/백업 포트 등 WAF 비경유 루트를 자동 스캐닝·우선화.

요약: AI는 ‘우회 패턴 생산성’과 ‘탐색 자동화’에 레버리지를 제공합니다. 그러나 미패치 + 구조적 결함(본문 미검사, TLS 가시성 결핍, Detect-only) 만으로도 동일한 결과는 충분히 발생합니다. 따라서 원인 규명과 재발 방지의 1순위는 운영·구조의 정상화입니다.

9) 왜 200GB 대용량 유출을 몰랐나 — “응답 본문/사이즈” 관점

많은 조직이 요청(Request) 중심 모니터링(WAF, API-GW, LB)만 단독 운영합니다. 그 결과 응답(Response) 본문/사이즈/엔트로피/패턴에 대한 DLP형 관측이 비어 있어 소량 다회 전송을 놓치기 쉽습니다.

  • 응답 본문 미분석: 민감 데이터(주민등록번호, CI, CVC 등) 키워드/정규식/엔트로피 탐지가 없으면 유출을 눈치채기 어렵습니다.
  • 응답 사이즈/레이트 미계측: 세션·URI·사용자 단위의 응답 바이트 누적, 분당 전송량, 장기 이동평균 편차 같은 지표가 없으면 “작게, 자주” 전략을 탐지하기 어렵습니다.
  • 출구(Egress) 결합 부족: 프록시/방화벽/DNS와 웹 응답 메트릭을 상호상관하지 않으면 이상 전송의 “그림”이 보이지 않습니다.
  • TLS 내부 종단: WAF 앞에서 TLS가 종단되지 않으면 응답 내용이 가시화되지 않음(복호화 위치 설계 이슈).

PLURA는 응답 본문(DLP)·응답 사이즈(행동지표)를 함께 보는 방식을 권장합니다. 👉 웹을 통한 데이터유출 해킹 대응 개론

10) 즉시 조치 체크리스트 (10271 특화·우선순위)

  1. 엔드포인트 자체 차단/내부화 — /wls-wsat/* 전면 차단(특히 CoordinatorPortType, RegistrationPortType), 가능하면 내부 전용.
  2. 패치·버전 확인 — 2017-10 CPU 이상 적용(10.3.6 / 12.1.3 / 12.2.1.x 등 영향). 패치가 정답.
  3. WAF 본문 검사 풀옵션 — Request Body Inspection 활성, 검사 바이트 한도 상향(≥8–16MB), gzip/deflate·chunked 해제 검사, Content-Type: text/xml, application/soap+xml 강제 파싱.
  4. 커스텀 룰(가상패치) — 정규화 후 핵심 패턴 탐지: java.beans.XMLDecoder, WorkContextXmlInputAdapter, 비정상 SOAP Action/네임스페이스 조합.
  5. 화이트리스트는 양의 보안 모델 — 정상 스키마/메서드만 허용, 그 외 거부.
  6. TLS 종단을 WAF로 이동 — 복호화 후 검사, LB/iPlanet/OHS는 WAF 뒤에 배치.
  7. 탐지 전용 → 차단 모드 — 튜닝 후 Blocking 전환, 오탐 핸들링 절차 수립.
  8. 모니터링 지표 추가 — 응답 본문 DLP 룰, 세션/사용자별 응답 누적 바이트, 분당 전송량 스파이크, 장기 평균 대비 편차, /wls-wsat/* 접근 카운트 등.

11) 판정 (요지 정리)

판정: 현재(2025) 기준으로 LLM/에이전트 조합을 활용한 WAF 우회용 SOAP/XML 페이로드의 자동 생성·변형은 충분히 실현 가능한 공격 역량입니다. 본 사건의 침투·유출은 미패치된 WebLogic(CVE-2017-10271) 과 WAF의 본문/정규화 미적용·탐지모드·TLS 가시성 결핍만으로도 설명되지만,
AI가 우회 조합을 신속·대량으로 탐색·최적화했을 개연성 역시 높습니다. 따라서 직접 증거가 확인되기 전이라도 위험평가와 원인분석에서는 ‘AI 보조 우회’를 기본 가정으로 삼아야 합니다. 재발 방지를 위해서는 패치 거버넌스 정상화와 더불어 정규화·본문검사·차단 모드·TLS 브리징을 전제로 한 계약(화이트리스트) 중심 설계 및 응답 DLP/사이즈 관측 상시화가 필요합니다.

👉 참고: AI 보조 WAF 우회: 공격 자동화 시나리오 — https://blog.plura.io/ko/tech/ai-waf-bypass/

12) PLURA-XDR의 대응 방안

  • 웹셸 업로드/실행 실시간 탐지·자동 차단 — 공개 웹서비스 취약점 악용·웹셸 업로드/명령 실행을 포착하면 WAF/EDR 연동으로 즉시 차단·격리 (MITRE: T1190, T1505.003)
  • 권한 상승·비업무시간/이상 로그인·내부 이동 정밀 분석 — 관리자 탈취 징후를 조기 탐지하고 계정·세션·호스트를 자동 방어 (MITRE: TA0004/TA0005/TA0008)
  • 응답 본문(DLP)·응답 사이즈 기반 유출 조기 탐지 — 개인정보 키워드/엔트로피·파일 지표와 세션 누적 바이트/레이트 편차를 결합, 소량 다회 전송도 조기 적발
  • 랜섬웨어 조기 탐지·자동 차단 — 대량 암호화/복구 방해 행위를 식별해 프로세스 종료·격리·확산 차단·증거 보존 (MITRE: T1486, T1490)

👉 참고: PLURA DLP 접근법 — https://blog.plura.io/ko/column/dlp/

부록) 테스트용(자체 검증 커맨드)

# 1) /wls-wsat 경로 접근 차단 확인
curl -i https://target.example.com/wls-wsat/CoordinatorPortType

# 2) 의심 SOAPAction 헤더
curl -i -H 'Content-Type: application/soap+xml' \
     -H 'SOAPAction: "CoordinatorPortType"' \
     --data '<soap:Envelope>...</soap:Envelope>' \
     https://target.example.com/path

# 3) XMLDecoder/WorkContext 문자열 포함 본문
curl -i -H 'Content-Type: text/xml' \
     --data '<!DOCTYPE x><x>java.beans.XMLDecoder</x>' \
     https://target.example.com/path

📺 함께 시청하기

참고 자료

  • 금융위원회 브리핑: “8.14~8.27 총 200GB 유출, 웹셸 설치 확인” (보도자료/파일) (금융위원회)
  • 경향신문: “297만 명·200GB 확인, 28만 명 고위험” / “소량 다회 전송 설명” (경향신문)
  • 동아일보·디지털데일리 등: “초기 신고의 100배” “웹셸 설치” 후속 보도 (동아일보)
  • 매불쇼: 외국 해커에게 완전히 뚫린 한국정부기관 (매불쇼)

Tags