국내 해킹 사고 6건 — 어떻게 뚫렸고 무엇을 했어야 했나

2025~2026년에 터진 국내 해킹 사고 여섯 건을 한 번에 정리한다. 기업마다 어떻게 뚫렸는지, 그리고 무엇을 했어야 했는지를 나란히 두면 공통점이 보인다.

대부분은 관리 안 된 자격 증명(평문 비밀번호, 코드에 박힌 키)이나 방치된 입구(잃어버린 기지국 장비, 검증이 약한 API)에서 시작됐다. 그리고 절반 넘게, 사고 뒤의 대응(늦은 신고, 감염 미신고, 조사 전 서버 재설치·폐기)이 피해를 키웠다.

강남언니는 아직 조사 중이고, 예스24는 침투 경로가 공개되지 않았다.

1. SKT — 유심 정보 2,696만 건 유출 (2025년 4월 발견)

어떻게 뚫렸나

• 2021년 8월, 공격자가 인터넷에 노출된 서버로 들어왔다.
• 그 서버에 평문으로 저장된 계정 정보를 찾아 내부 서버와 핵심망으로 옮겨 갔다.
• 가입자 인증 서버(HSS) 관리 계정까지 탈취해 리눅스 백도어 악성코드 ‘BPFDoor’를 심었다.
• 서버 28대가 감염됐고 악성코드 33종이 나왔다. 유심 정보 25종, 약 2,696만 건(9.82GB)이 빠져나갔다.
• BPFDoor는 국가 배후 해킹 조직이 오래 숨어 있으면서 정보를 빼 갈 때 주로 쓰는 도구라, 조직적인 공격으로 추정된다.
• 정부는 계정 정보 평문 저장, 유심 정보 등 중요 정보 미암호화, 2022년 악성코드 감염 미신고, 신고 지연, 포렌식 방해, 로그 보관 부족을 과실로 지적했다.

어떻게 했어야 했나

• 계정 정보는 금고형 저장소에 보관하고 주기적으로 바꾸고, 관리자 접속에는 다중 인증(MFA)을 걸어야 했다.
• 인터넷에 노출된 영역과 핵심망을 떼어 놓고, 망 안에서도 서버 사이 접근을 최소한으로만 허용했어야 한다.
• 유심 인증키 같은 핵심 데이터는 암호화하고, 할 수 있다면 HSM(하드웨어 보안 모듈)에 넣어야 했다.
• 리눅스 서버에도 EDR(엔드포인트 탐지·대응)을 깔고, BPFDoor 같은 은닉형 백도어를 정기적으로 찾아야 했다.
• 2022년 감염 때 신고하고 전수 조사를 했다면 3년 넘게 들키지 않는 일은 막을 수 있었다. 추적이 가능하도록 로그도 충분히 오래 보관했어야 한다.

2. KT — 불법 초소형 기지국 무단 소액결제와 감염 미신고 (2025년 8~9월)

어떻게 뚫렸나

• 공격자가 KT의 초소형 기지국(펨토셀) 장비를 손에 넣어 관리자 권한을 얻었다.
• 소형 컴퓨터와 LTE 에그, 배터리를 붙여 들고 다닐 수 있는 가짜 기지국으로 개조했다.
• 근처 휴대폰의 문자와 통화 신호를 가로채 인증 문자를 받아 내고, 피해자 명의로 소액결제를 했다.
• 불법 기지국 ID는 20개, 피해자는 368명, 피해 건수는 777건, 피해액은 319만 원이다.
• 근본 원인은 장비 관리 부실이다.
  • 기지국 인증 유효기간이 10년이라 사실상 방치 상태였다.
  • 2014~2015년에 들여온 기지국 약 3,000대의 행방을 모른다.
• 조사 과정에서, KT가 2024년 3~7월에 BPFDoor 등에 감염된 서버 43대를 발견하고도 정부에 신고하지 않고 자체 처리한 사실이 드러났다. 일부 서버에는 고객 이름, 전화번호, 이메일, 단말기 고유번호(IMEI)가 있었다.

어떻게 했어야 했나

• 기지국 장비는 등록·회수·폐기까지 전 과정을 추적하고, 인증서는 짧게 발급하고, 잃어버린 장비는 즉시 차단했어야 한다.
• 망에 붙는 기지국은 기기 인증을 강하게 하고, 등록되지 않은 기지국이 붙거나 위치가 이상하면 잡아내야 했다.
• 결제 인증을 문자 하나에만 맡기지 말고 이상 거래 탐지를 더했어야 한다.
• 감염 사실은 곧바로 신고하고 공개해야 했다. 신고하지 않은 대가는 신뢰 붕괴와 정부의 위약금 면제 검토로 돌아왔다.

3. LG유플러스 — 통합 계정 관리 서버(APPM) 정보 유출 (2025년 7~8월)

어떻게 뚫렸나

• 해킹 잡지 Phrack에 실린 북한 해킹 조직 분석 보고서(“APT Down: The North Korea Files”)로 처음 알려졌다.
• 서버 접근 권한과 비밀번호를 한곳에서 관리하는 시스템(APPM)이 뚫렸다.
• 그 결과 소스코드와 DB, 서버 8,938대 정보, 계정 4만 2,526개, 임직원·협력사 직원 167명의 실명과 ID가 빠져나갔다.
• 개인정보위 조사가 시작되기 직전인 2025년 8월에 관련 서버의 운영체제를 다시 깔고 일부는 폐기했다.
• 그래서 유출 경로와 추가 피해를 밝히지 못했고, 개인정보위는 공무집행방해 혐의로 경찰에 수사를 의뢰했다.

어떻게 했어야 했나

• APPM처럼 모든 권한을 쥔 시스템은 가장 강하게 지켜야 하는 자산이다.
  • 따로 떨어진 망에 두고, 다중 인증을 걸고, 누가 무엇을 조회했는지 모두 감사해야 했다.
  • 계정은 필요할 때만 잠깐 권한을 주고(JIT), 쓰고 나면 비밀번호를 바꾸는 방식으로 운영했어야 한다.
• 정황을 통보받은 순간 증거부터 보존했어야 한다.
  • 디스크 이미지를 뜨고 로그를 백업했다면 원인도 밝히고 의혹도 피할 수 있었다.
  • 서버 재설치와 폐기는 포렌식이 끝난 뒤에 해야 했다.

4. 예스24 — 랜섬웨어 두 번 (2025년 6월, 8월)

어떻게 뚫렸나

• 2025년 6월 9일 랜섬웨어에 감염돼 5일 동안 서비스가 멈췄고, 8월 11일에 다시 감염돼 약 7시간 멈췄다.
• 침투 경로는 공개되지 않았다. 과기정통부와 개인정보위가 공개 범위를 두고 조율하지 못해 조사가 길어졌다.
• KISA는 가장 큰 문제로 주요 데이터를 다른 곳에 두는 백업(오프사이트 백업)이 없었다는 점을 꼽았다.
• 공식 발표는 없지만, 업계에서는 해커와 협상해 수십억 원대 비트코인을 지급한 것으로 알려졌다. 2분기 잡손실 48억 원도 대부분 해킹 관련 비용으로 추정된다.
• 전문가들은 두 가지를 재공격 원인으로 꼽았다.
  • 몸값을 낸 전례가 알려지면 다시 표적이 되기 쉽다.
  • 처음 뚫린 경로를 완전히 막지 않은 채 서비스를 재개하면 재침투가 가능하다.
• 처음에는 개인정보 유출이 없다고 했지만, 조사에서 회원 정보에 대한 비정상 접근 흔적이 나왔다.

어떻게 했어야 했나

• 백업을 3-2-1 원칙으로 두어야 했다.
  • 사본 3개, 매체 2종, 그중 1개는 다른 장소에 둔다.
  • 그중 하나는 오프라인이나 수정 불가능한 저장소에 넣어, 몸값 없이도 복구할 수 있게 해야 한다.
• 복구 전에 처음 뚫린 경로와 심어진 백도어를 먼저 찾아 없애고, 비밀번호를 전부 바꿔야 했다.
• 몸값은 내지 않아야 했다. 내는 순간 “돈 내는 곳”으로 소문이 난다.
• 유출 여부는 조사가 끝나기 전에 단정하지 말고, 확인된 사실만 공지했어야 한다.

5. 티빙 — 3,954만 계정 유출 (2026년 5월 말, 9월 3일 정부 발표)

어떻게 뚫렸나

• 개발자 접속키가 소스코드에 그대로 박혀 있었다(하드코딩).
• 해커는 이 키로 개발 환경에 들어가 소스코드를 포함한 프로젝트 361건(30.35GB)을 가져갔다.
• 5월 30일 DB에서 첫 유출을 시도했다가 차단됐지만, 31일에는 내부에 가상 서버를 직접 만들어 이용자 정보 24GB를 밖으로 빼냈다.
• 휴대폰 번호와 이메일을 암호화한 키도 함께 새어 나가, 암호화가 사실상 무력해졌다.

• 유출 계정 수는 다음과 같다.

  구분	계정 수
  활성	2,206만
  휴면·탈퇴	1,737만
  테스트	11만

• 사고를 알고도 24시간이 지난 뒤 신고해 과태료 대상이 됐다.
• 모의해킹에서 나온 취약점을 방치했다는 의혹도 있다.

어떻게 했어야 했나

• 접속키 같은 비밀 값은 코드가 아니라 전용 저장소(Vault, KMS 등)에 두고, 짧게 쓰고 자주 바꿔야 했다.
• 코드 저장소에 비밀 값이 올라가면 걸러 내는 도구(secret scanning)를 돌렸어야 한다.
• 암호화키는 데이터와 다른 곳에 둬야 한다. 키가 데이터와 같이 털리면 암호화는 의미가 없다.
• 개발 환경과 운영 DB를 분리하고, 권한이 없는 가상 서버가 새로 생기거나 데이터가 대량으로 나가면 경보가 울리게 했어야 한다.
• 휴면·탈퇴 계정 1,700만 개는 진작 파기하거나 분리 보관했어야 한다. 그랬다면 피해가 절반 가까이 줄었다.
• 모의해킹에서 나온 취약점은 기한을 정해 고쳐야 했고, 사고는 24시간 안에 신고했어야 한다.

6. 강남언니 — 22만 명 유출, 시술·상담 정보 포함 (2026년 9월 4일)

어떻게 뚫렸나 (조사 중)

• 웹과 앱에서 상담 내역을 조회하는 API에 비정상적인 접근이 들어왔다.
• 초기 대응을 하는 동안에도 다른 연동 경로로 다시 들어오려고 했다.
• 피해자는 국내 약 16만 명, 일본 4만 8,000명 등 모두 22만 명이다.
• 유출 항목은 다음과 같다.
  • 기본 정보: 이름, 연락처, 이메일, 생년월일
  • 민감 정보: 시술·병원·의사명, 상담 동기, 상담에 올린 사진, 결제 정보
• 구체적인 결함(권한 검증 누락 등)은 아직 공개되지 않았다.
• 회사는 KISA에 자진 신고했고, 경찰에 수사를 의뢰했다.

어떻게 했어야 했나 (API 대량 유출에 공통으로 쓰는 대책 기준)

• API가 요청을 받을 때마다 “이 사용자가 이 상담 건을 볼 권한이 있는가”를 서버에서 확인해야 한다(객체 단위 권한 검증).
  • 이게 빠진 경우(BOLA, Broken Object Level Authorization)가 API 유출의 가장 흔한 원인이다.
• 짧은 시간에 많은 건을 조회하는 요청은 rate limit으로 막고, 이상 조회는 탐지해 자동 차단해야 한다.
• 상담 사진이나 시술 내역처럼 민감한 정보는 목록 API에 싣지 말아야 한다.
  • 꼭 필요한 화면에서만, 가려서 보여 주고, 별도로 암호화한다.
• 연동 경로가 하나 막혀도 다른 경로로 들어오는 일이 없도록, 대응할 때는 연동 API 전체를 한꺼번에 점검했어야 한다.

공통 교훈

1. 자격 증명을 제대로 관리하지 않았다. SKT의 평문 계정 정보, 티빙의 하드코딩 키, LG유플러스의 APPM이 모두 여기에 해당한다.
2. 방치된 입구가 있었다. KT의 잃어버린 기지국, 강남언니의 API, SKT의 인터넷 노출 서버다.
3. 복구할 수단이 없었다. 예스24는 다른 곳에 둔 백업이 없었다.
4. 사고 뒤 대응이 피해를 키웠다.
   • 감염을 신고하지 않은 곳: SKT(2022년), KT(2024년)
   • 늦게 신고한 곳: 티빙
   • 조사 전에 관련 서버를 재설치·폐기한 곳: LG유플러스

   사고 자체보다 이런 대응이 제재와 신뢰 하락을 더 크게 만들었다.

출처

• SKT: 과기정통부 조사 결과 (바이라인네트워크) · SKT 해킹 4년 전 시작 (뉴스토마토)
• KT: 불법 펨토셀 (데일리안) · 감염 미신고·최종 결과 (뉴시스) · 피해 집계 (바이라인네트워크)
• LG유플러스: 개인정보위 수사 의뢰 (뉴시스) · 뒤늦은 신고 (디지털타임스)
• 예스24: 예스24는 왜 또 당했나 (바이라인네트워크) · 잡손실과 몸값 (한국경제) · 조사 9개월째 (ZDNet Korea)
• 티빙: 유출 분석 (뉴닉) · YTN
• 강남언니: 22만 명 유출 (ZDNet Korea) · 민감 정보 유출 분석 (보안뉴스)