1. 개요
- 국내 대표 이동통신사업자 가운데 하나인 SK텔레콤(SKT)에서 고객 유심(USIM) 정보 유출사고 발생
2. 타임라인
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3. 요약
- 2025년 4월 18일, SK텔레콤(SKT)은
외부로의가입자인증시스템(HSS)와 과금정보관리서버(WCDR) 사이 이상 트래픽 증가를 감지하였습니다.하며 잠재적 사이버 위협을 인지했습니다.이는 APT(Advanced Persistent Threat)의 목표달성(데이터 유출)단계로초기 징후로보입니다.
※ APT 공격은 대체로 아래와 같이 7단계에 걸쳐 체계적으로 수행됩니다.
초기침투 > 거점확보 > 권한상승 > 내부정찰 > 내부이동 > 지속실행 > 목표달성
- 4월 19일 오후 11시에 과금정보관리서버(WCDR)에서 악성코드 감염 및 가입자인증시스템(HSS: Home Subscriber Server)에서 유심(USIM) 정보 유출이 확인되었습니다.
- 유출된 데이터는 9.82기가바이트(가입자당 유심(USIM) 관련 정보는 100~300 킬로바이트(Kbyte) 수준)에 이르고 전화번호, 유심(USIM) 인증 코드(Ki), 이동가입자식별번호(IMSI,International Mobile Subscriber Identity)
, 단말기고유식별번호(IMEI,International Mobile Equipment Identity)총 2695만7749건을 포함(SKT 가입자(알뜰폰 포함) 총 숫자인 2천500만여 명보다 조금 많지만, 사물인터넷(IoT) 회선 등이 합쳐진 숫자로 추정됩니다.)하며, 1차 보고 당시 이름, 주민등록번호 등 민감한 정보는 유출되지 않았다고 밝혔습니다.
※ 조사 초기 IMEI가 저장된 서버 38대를 점검했을 당시에는 악성코드 감염이 확인되지 않아 유출 가능성을 배제했지만, 이후 진행된 전수조사에서 IMEI가 서비스 중 임시로 저장된 서버들이 추가로 발견됐습니다.
- 현재까지 2차 피해는 보고되지 않았습니다.
으나, 신원 도용, 복제폰 제조, SIM 스와핑 등의 위험이 존재합니다. - SKT는 사고 발견 즉시 악성 코드를 삭제하고 서를 격리했으며, 4월 20일 한국인터넷진흥원(KISA)에 신고하고, 4월 22일 개인정보보호위원회에 보고하면서 경찰 수사를 요청했습니다.
- 서울지방경찰청 사이버수사대는 4월 23일부터 수사에 착수했으며, 해커의 신원과 침투 경로를 조사 중입니다. SKT는 고객 보호를 위해 무료 유심(USIM) 보호 서비스 가입을 권고하고, 불법 유심(USIM) 기기 변경 및 비정상 인증 시도를 실시간으로 차단하는 시스템(FDS,Fraud Detection System) 정책을 최고 수준으로 격상해 운영하고 있습니다.
- 그러나 4월 18일 밤 해킹 공격을 받은 사실을 최초로 확인했음에도 관계기관에 '사고 인지 24시간 이내' 신고해야 한다는 규정 위반 논란이 발생했습니다.
- 5월 19일 개인정보보호위원회는 SKT 개인정보 유출 건 조사 과정에서 기존 유출경로로 확인된 가입자인증시스템(HSS) 등 5대 외에도, 통합고객시스템(ICAS) 서버 2대를 포함 총 18대 서버에 악성코드가 추가 감염된 것을 확인했다고 밝혔습니다.
※ ICAS(Intergrated Customer Authentication System)는 티월드 등 SKT 내부 시스템과 사전 인가된 협력사를 대상으로 가입자의 가입 상태, 개인정보 및 가입 상품 정보를 조회할 수 있는 애플리케이션 프로그래밍 인터페이스(API)를 제공하는 시스템입니다.
- 해당 서버에는 이름, 생년월일, 휴대전화번호, 이메일, 주소, 단말식별번호(IMEI) 29만1천831건, 가입자식별번호(IMSI) 등 고객의 중요 개인정보를 포함해 총 238개 정보(컬럼값 기준)가 암호화되지 않은 상태로 저장돼 있으며, 개인정보위는 악성코드에 최초 감염된 시점이 오래된 점을 고려해 감염경위, 유출정황 등을 면밀히 조사하고 있다고 설명했습니다.
- 서버에 저장된 29만1천831건의 IMEI는 지난해 12월 3일부터 올해 4월 24일까지는 유출되지 않은 것으로 확인됐지만, 최초로 악성코드가 설치된 시점인 2022년 6월 15일부터 2024년 12월 2일까지는 로그기록이 남아있지 않아 유출 여부가 불확실하다고 합니다.
※ 정보통신망법은 정보통신서비스 제공자가 침해사고가 발생한 것을 알게 된 때로부터 24시간 이내에 침해사고의 발생 일시, 원인 및 피해 내용 등을 과학기술정보통신부장관이나 한국인터넷진흥원(KISA)에 신고해야 한다고 규정하고 있습니다.
※ 개인정보보호법은 1천명 이상의 민감정보 또는 고유식별정보가 유출됐을 경우 72시간(2일)이내 개인정보보호위원회나 한국인터넷진흥원(KISA)에 신고해야 한다고 규정하고 있습니다.
4. 공격 정보
- 피해 대상:
3종, 5대 서버(2025.04.25)25종(BPFDoor계열 24종+웹셸 1종) , 23대 서버(2025.05.19) - 해킹 원인: 통상 가입자 정보를 관리하는 네트워크는 방화벽을 두고 외부 인터넷프로토콜(IP)에서 접속이 불가능한 구조로 설계되어 이론상 해킹이 불가하지만, 불가피하게 외부 인터넷망과 연결된 과금정보관리서버(WCDR)를 통해 가입자인증시스템(HSS)로 침투하여 유심(USIM) 관련 데이터가 유출되었습니다. 2차 발표에 따르면 웹셸 이후 BPF도어(BPFDoor) 악성코드가 설치됐다고 합니다.
- 유출 경로: 가입자인증시스템(HSS)에 있던 정보가 과금정보관리서버(WCDR)를 통해 싱가포르 IP로 넘어간 흔적이 있었다고 합니다.
- 유출 정보: 가입자 전화번호, 이동가입자식별번호(IMSI) 등 유심(USIM) 복제에 활용될 수 있는 4종과 유심(USIM) 정보 처리 등에 필요한 SKT 관리용 정보 21종 등(여기에 단말기고유식별번호(IMEI) 정보는 없었다는게 과학기술정보통신부의 설명)입니다. 5월 19일 민관합동조사단 2차 발표에 따르면 감염이 확인된 서버 중 2대는 통합고객인증 서버와 연동되는 기기들로 고객 인증을 목적으로 호출된 단말기 고유식별번호(IMEI)와 개인정보가 일정 기간 임시로 관리되는 서버로 밝혀졌습니다. 개인정보는 이름, 생년월일, 전화번호, 이메일 등 휴대전화 가입 시 남기는 정보들로 추정되고 있습니다. 1차 발표 때 IMEI 정보 유출은 없다와는 다르게 IMEI 정보 유출 여부는 알 수 없다고 밝혔습니다.
※ SKT는 이번에 해킹을 당한 가입자인증시스템(HSS) 외 단말장치 등록기(EIR: Equipment Identity Register, 단말기의 정보를 저장하는 서버)에서 단말기고유식별번호(IMEI)를 관리하고 있습니다. 단말기고유식별번호(IMEI)는 제조사가 단말기를 제작할 때 부여하는 15자리 숫자로 된 번호이며 단말기 제조사와 모델, 일련번호 등의 정보를 담고 있습니다.
※ 유심(USIM·가입자식별장치) 관련 정보: SKT 가입자 정보를 분산한 서버는 총 14대이며, 기본적으로 전화번호, 유심(USIM) 인증키(Ki), 이동가입자식별번호(IMSI), 유심(USIM) 카드 식별자(ICCID), 서비스 가입 정보가 들어가 있습니다. 회사에 따라 단말기고유식별번호(IMEI)가 들어가기도 합니다. 통신사는 이동가입자식별번호(IMSI) 와 단말기고유식별번호(IMEI) 두 가지 정보를 결합해서 가입자를 인증하고 과금합니다. 유심 정보를 알면 가입자의 요금 정보나 로밍 기록을 확인할 수 있습니다. 다만 이용자의 금융 계좌 비밀번호나 공동인증서 비밀번호 등은 유심(USIM)에 저장되지 않습니다.
- 침투 방식: 이반티(Ivanti) VPN 장비 취약점(CVE-2025-22457)을 통해 이뤄졌을 가능성이 보안업계에서 제기되고 있습니다(한국인터넷 진흥원 보안공지(2025.04.04): Ivanti 제품 보안 업데이트 권고). CVSS Base Score가 10점 만점에 9.8점으로 시스템에 치명적인 영향을 미칠 수 있기 때문에 Pulse Connect Secure 9.X의 경우 24년 12월 31일 EoL(End Of Life, 제품의 수명이 끝남)되었음에도 패치를 제공한 것을 볼 수 있습니다.
- 아래는 OSINT(Open Source Intelligence, 공개적으로 접근 가능한 정보원을 활용하여 정보를 수집하고 분석하는 과정) 결과입니다. 2025.05.07 기준 무료 OSINT로 취약버전 사용여부 확인은 어렵지만 이반티(Ivanti) VPN 장비 사용여부는 찾을 수 있었습니다. 그러나 history 정보를 제공하는 유료 OSINT에서 4월 16일 기준 EoL 버전 정보를 확인할 수 있었습니다.
- OSINT 정보에 따르면 Ivanti VPN 장비의 버전은 9.1.14.25049(9.1R14.5)이며
한국인터넷 진흥원 보안공지(2024.02.15): Ivanti 제품 보안 업데이트 권고는 패치,
한국인터넷 진흥원 보안공지(2024.04.04): Ivanti 제품 보안 업데이트 권고는 미패치,
한국인터넷 진흥원 보안공지(2025.01.13): Ivanti 제품 보안 업데이트 권고는 EoL로 패치 지원 종료 안내,
한국인터넷 진흥원 보안공지(2025.04.04): Ivanti 제품 보안 업데이트 권고는 EoL 대상도 긴급 보안 업데이트를 제공하였으나 미패치로 보입니다.
 |
|
 |
 |
※ 개인적으로 보안장비 로그인 웹 페이지 title 정보를 통해 장비정보가 노출되지 않도록 이를 제거하거나 수정하면 좋겠다는 생각을 해봅니다.
- 해외 보안업체 분석(Rapid7, Mandiant)에 따르면 CVE-2025-22457 취약점은 당시 Ivanti가 이 문제에 대해 제대로 이해하지 못했기 때문에 저위험 서비스 거부(DoS) 취약점으로 간주되었으며 제품 버그로 식별되었습니다. 그리고 2025년 2월 11일 출시된 Ivanti Connect Secure 버전 22.7R2.6에서 보안 취약점이 아닌 제품 버그로 패치되었습니다. 그러나 4월 3일, Ivanti는 일부 고객 환경에서 지원되는 Ivanti Connect Secure 및 지원 종료된 Pulse Connect Secure 어플라이언스에서 원격 코드 실행을 위한 알려진 악용 사례를 공개적으로 인정했습니다.
- CVE-2025-22457 익스플로잇(exploit) 은 2025년 3월 중순에 발견되었습니다. 중국과 연계된 위협 행위자가 2025년 2월 복잡성에도 불구하고 패치를 리버스 엔지니어링하여 취약점을 발견하고, 원격 코드 실행에 성공적으로 취약점을 악용한 것으로 드러났습니다.(CVE-2025-22457 PoC, Github)
※ 익스플로잇(exploit): 시스템이나 애플리케이션의 취약점을 이용하는 코드나 프로그램으로, 공격자가 시스템을 제어하거나 데이터를 탈취하는데 사용됩니다. 쉽게 말해, 프로그램의 버그나 보안 취약점을 이용해 공격을 가하는 방법이라고 할 수 있습니다.
- 또한 애플리케이션 취약점을 통한 침투 시나리오도 거론되고 있으며 한국인터넷진흥원(KISA)이 SAP의 '넷위버'에서 파일 업로드 취약점(CVE-2025-31324)을 발견했다고 합니다(한국인터넷 진흥원 보안공지(2025.04.28): SAP 제품 보안 업데이트 권고). 그리고 폐쇄망이라고하여 리눅스 커널 업데이트를 진행하지 않았다면 권한상승 취약점(CVE-2025-21756)이 존재할 것으로 보여집니다(한국인터넷 진흥원 보안공지(2025.04.30): 리눅스 커널 보안 업데이트 권고).
악성 코드가 내부 시스템에 삽입된 것으로 확인되었으나, 정확한 침투 경로는 조사 중입니다. 예를 들어, VPN 취약점이나 기타 취약점이 활용되었을 가능성이 제기되었으나, 구체적으로 확인되지 않았습니다.
※ SKT는 2000년부터 SAP의 ERP를 도입, 현재 S/4HANA라는 ERP 제품을 프라이빗 클라우드 환경에서 사용하고 있습니다.
- 공격 기술: 리눅스 기반 시스템에 침투해 BPF를 악용하여 보안 장비의 탐지를 우회하고, 외부 명령을 수신해 민감 정보를 유출하는 고도화된 BPFDoor 백도어 악성코드를 통한 데이터 유출이 주요 수법으로 확인되었습니다.
으나, 구체적으로 확인되지 않았습니다. - 침투 시점: 침투 시점은 명확하지 않으나
3월 중순에 익스플로잇(exploit)이 발견된 것과 3월 중순에 SKT 내 이상 트래픽 있었다는 제보에 따르면 3월경으로 보여집니다.민관합동조사단 2차 발표(2025.05.19)에 따르면 악성코드 설치시점은 2022년 6월 15일로 확인되었습니다.며, APT 특성상 장기간 잠복했을 가능성이 제기되었으나, 구체적으로 확인되지 않았습니다.
5. SKT의 대응 조치
5.1 대응조치
- 4월 19일 악성 코드 삭제 및 서버 격리.
- 4월 20일 한국인터넷진흥원(KISA) 신고, 4월 22일 개인정보보호위원회 보고 및 경찰 수사 요청.
- 4월 22일 무료 USIM 보호 서비스 가입 권고.
- 불법 USIM 기기 변경 및 비정상 인증 시도 차단 강화.
- 피해 의심 징후 발견 시 즉각적인 이용 정지 및 고객 안내.
- 휴대전화가 꺼져있더라도 비정상 인증 시도 차단 시스템(FDS)을 통해 불법 유심(USIM) 기기 변경 시도 최대한 차단.
- 전체 시스템 전수 조사
- 기관 및 경찰과 사고 분석 협력.
- 4월 28일 전고객 유심(USIM) 무상교체 실시, 기교체 고객은 비용 환급
- 5월 8일 해킹과 관련해 피해가 우려되는 서버 3만 3000대 3차례 조사(민관합동조사단이 4차 조사)
- 5월 9일 2564만명에 유심 해킹 관련 개인정보 유출 가능성 통지
- 5월 12일 SW로 유심(USIM) 데이터 초기화 실시
- 5월 14일 해외 로밍 포함 전 고객 유심(USIM) 보호서비스 자동 가입 완료
- 5월 18일 불법유심복제와 IMEI를 도용한 불법 복제폰 피해까지 차단할 수 있는 FDS 2.0으로 고도화해 운영 시작
5.2 문제점
- 알림 지연: 사고 발생 후 45시간 지연으로 사이버 침해사고 발생을 알게된 때부 24시간 이내 신고 의무 위반
- 고객 불만: 유출 사실 미통지 및 T-World 사이트 접속 지연으로 가입자 불만 증가
- 주요정보통신기반시설 미지정: 해킹 피해를 입은 SKT의 과금정보관리서버(WCDR), 가입자인증시스템(HSS), 가입자 인증키 저장 시스템, 유심(USIM) 관련 핵심 서버 등은 '국가·사회적으로 보호가 필요한 주요정보통신기반시설'로 지정되지 않은 상태. 현재 KT와 LG유플러스도 동일하게 관련 서버가 포함돼 있지 않은 상황.
- 축소 신고 : 신고당시 해킹 '의심정황'으로 축소 신고
- 한국인터넷진흥원(KISA) 지원거부 : 신고당시 한국인터넷진흥원(KISA)의 피해지원서비스·후속조치 지원 등 일체의 기술적 지원을 거부한 것으로 파악
- 로그보관주기: 방화벽 로그 기록을 5개월여로 짧게 보관한 점
- 개인정보 평문저장: 통합고객시스템(ICAS) 서버에 이름, 생년월일, 휴대전화번호, 이메일, 주소, 단말식별번호(IMEI) 29만1천831건, 가입자식별번호(IMSI) 등 고객의 중요 개인정보를 포함해 총 238개 정보(컬럼값 기준)가 암호화되지 않은 평문 상태로 저장
6. 이슈
- 보안 투자 감소: SKT는 2025년 해킹 사태 이전에 사이버보안 예산을 감축한 것으로 나타났습니다. SKT는 2년 동안 사이버보안 지출을 4% 줄였으며, 이는 경쟁사 KT와 LG유플러스에 비해 낮은 투자 수준입니다. 이 감소는 보안 인프라 강화 부족으로 이어졌을 가능성이 있으며, 전문가들은 예산 삭감이 보안 취약점을 간접적으로 악화시켰을 수 있다고 우려합니다.
- 한국인터넷진흥원(KISA) 무마의혹: SKT가 4월 20일 신고서를 접수할 때 해킹 인지 시점을 18일 오후 11시 20분으로 제출하려고 했지만, 한국인터넷진흥원(KISA)에서 4월 20일 오후 3시 30분으로 신고하도록 안내한 사실이 밝혀졌습니다. 제출된 신고서에 따르면 해킹을 인지한지 1시간 16분 만에 신고했기 때문에 법 위반으로 인한 과태로 3000만원을 납부할 필요가 없습니다. 한국인터넷진흥원(KISA) 측은 SKT의 해킹 신고를 접수하는 과정에서 회사 보안 책임자가 신고하자고 결정한 시점을 사고 인지 시점으로 보고 사전 접수 실무자가 시간을 정정했다며 해명했습니다.
- 국정원 전문인력 투입 검토: 과학기술정보통신부는 4월 23일 최우혁 정보보호네트워크정책관을 단장으로 한국인터넷진흥원(KISA)과 보안업계 민간 전문가 등으로 구성된 민관합동조사단을 꾸리고 사고 원인 파악과 피해 확산 방지책 마련에 돌입했습니다. 조사단은 당초 11명에서 5명을 추가로 투입해 16여명으로 구성됐습니다. 정보통신망법에 따라 국정원은 직접 조사에 참여할 수 없고, 조사된 정보를 공유받을 수는 있습니다. 당초 국정원은 SKT 조사에 기술 지원을 하겠다고 밝혔지만, 과학기술정보통신부에서 법에 따라 거절했습니다. 국가정보원법(국가정보원의 설치 및 운영에 관한 법률)에 따르면 국정원은 ① 국가안전보장에 관련되는 정보 및 보안업무 ② 국외 정보 및 방첩 업무 ③ 테러, 사이버 위협 등 국가안보에 대한 위협 대응 ④ 그 밖에 대통령령으로 정하는 직무가 가능해, ‘국가안보 차원에서의 사이버 위협’에 대응하는 업무만 할 수 있기 때문입니다. 이에 따라 개별 민간기업의 해킹 사건은 국가안보 사안으로 판단되지 않는 한 직접 조사하거나 개입할 권한이 없습니다.
- 해킹 한달전 비정상 트래픽 감지: SKT 내부 인증서버에선 3월12일부터 20일 사이 비정상 트래픽이 발생했으나 조치를 취하지 않았다는 제보가 있었다고합니다. SKT는 "해당 기간 이상 징후가 없었던 것으로 확인됐다"는 입장을 전했다고합니다.
- 민관합동조사단의 SKT 침해사고 조사결과 2차 발표에 따르면 해킹 공격이 3년 전부터 시작되었다고 합니다. 총 29만1831건의 IMEI가 담긴 서버에 2022년에 심어진 악성 코드가 있었다는 사실이 발견되었으며 1차 발표 때와는 다르게 단말고유식별번호(IMEI)와 개인정보 유출여부는 확인이 어렵다고 하였습니다.
| 별첨 1: 한국인터넷진흥원 보안공지 |
| ◎ 한국인터넷진흥원 보안공지(2025.04.25) : 최근 해킹공격에 악용된 악성코드, IP 등 위협정보 공유 및 주의 안내 □ 침해사고 위협정보 1. 공격 IP : 165.232.174[.]130
|
|
 |
 |
2. 악성코드 해시값 및 파일정보
※ 이번 위협정보는 AWS Linux에 BPFDoor 악성코드가 발견돼 공지된 것으로 보여집니다. SKT는 AWS와 전략 파트너쉽을 맺었습니다. |
|
| ◎ 한국인터넷진흥원 보안공지(2025.05.03) : 최근 해킹공격에 악용된 악성코드 위협정보 공유 및 주의 안내 (2차) □ 침해사고 위협정보 1. 악성코드 해시값 및 파일정보
|
| 별첨 2: BPFDoor 악성코드 |
1. BPFDoor 악성코드 개요
1.1 BPFDoor
리눅스 및 솔라리스 시스템을 타깃으로 하는 스텔스형 백도어 악성코드로, 2017년경부터 약 5년간 탐지되지 않았습니다. 2021년 PwC 연구진에 의해 발견되었으며, 중국 기반 APT 그룹 Red Menshen(Trend Micro에서는 Earth Bluecrow로 추적)에 연관된 것으로 알려져 있습니다. 주요 특징은 다음과 같습니다:
- Berkeley Packet Filter(BPF) 활용: C&C 서버에 먼저 접속할 필요가 없고, BPF를 사용하여 네트워크 패킷을 모니터링하고 매직 바이트 시퀀스(예: 0x7255, 0x5293)를 사용해 특정 "매직 패킷"을 받으면 활성화됩니다. 이는 기존 포트(예: 22, 80, 443)를 활용해 추가 포트를 열지 않고도 작동 가능해 탐지가 어렵습니다.
- 스텔스 기법: 프로세스 이름을 일반적인 리눅스 데몬(예: dbus-daemon, hald-addon-acpi 등)으로 위장하고, /dev/shm 경로에 자신을 복사하여 메모리 기반으로 동작하며, 파일을 삭제하고 타임스탬프를 조작(예: 14년 전으로 설정)해 포렌식 분석을 방해합니다.
- 리버스쉘(Reverse Shell): 공격자가 원격으로 시스템에 접근할 수 있는 암호화된 리버스쉘을 생성하며, 42391~43390 포트 범위에서 쉘을 제공합니다.
- 다양한 프로토콜 지원: iptables를 조작하여 공격자의 접근을 허용하며 TCP, UDP, ICMP를 통해 C2 서버 없이도 명령을 수신할 수 있습니다.
- 최근 변종: 2023년 변종은 정적 라이브러리 암호화, 리버스쉘 통신, 하드코딩된 명령 제거로 탐지를 더욱 어렵게 만들었습니다.
- BPFDoor는 주로 통신, 정부, 물류, 교육, 금융, 소매 산업을 타깃으로 하며, 한국, 홍콩, 미얀마, 말레이시아, 이집트 등에서 활동이 관찰되었습니다.
1.2 SKT 해킹 사태와 BPFDoor
- 트렌드마이크로의 2025년 4월 14일 보고서: BPFDoor는 한국, 홍콩, 미얀마, 말레이시아, 이집트의 통신, 금융, 소매 산업을 타깃으로 한 공격에 사용되었습니다. 원문에서는 SKT를 명시적으로 언급하지 않고 한국 통신사에서의 악성코드 트래픽만 언급했습니다.
SKT의 HSS 서버에서 발견된 악성 코드는 BPFDoor일 가능성이 있지만, 이는 아직 추정 단계이며 공식 확인이 필요합니다.SKT의 과금정보관리서버(WCDR) 에서 발견된 악성 코드는 BPFDoor입니다.BPFDoor는 리눅스 기반그리고 가입자인증시스템(HSS)와 과금정보관리서버(WCDR) 사이 9.82기가바이트(GB)에 이르는 데이터를 이동하여 가입자인증시스템(HSS)에서 유심(USIM) 관련 데이터를 유출하였습니다.유출할 수 있는 능력을 갖추고 있으며, 이는 SKT 사건의 특성과 일치할 수 있습니다.
2. BPFDoor 사례
BPFDoor는 2017년경부터 활동이 시작된 것으로 추정되며, 2021년 PwC에 의해 처음 공개되었습니다. 2024년과 2025년의 주요 사례는 다음과 같습니다:
2024년 한국 및 동남아시아 공격:
- 트렌드마이크로에 따르면, BPFDoor는 한국(2024년 7월, 12월), 홍콩(2024년 1월), 미얀마(2024년 12월), 말레이시아, 이집트의 통신, 금융, 소매 산업을 타깃으로 했습니다 .
- 공격자는 /tmp/zabbix_agent.log, /bin/vmtoolsdsrv, /etc/sysconfig/rhn/rhnsd.conf와 같은 경로를 사용해 악성코드를 은폐했습니다.
- 새로운 컨트롤러가 발견되었으며, 이는 리버스쉘을 통해 네트워크 내 측면 이동을 가능하게 했습니다.
2021~2022년 중동 및 아시아 공격:
- Red Menshen은 중동과 아시아의 통신, 정부, 물류, 교육 부문을 타깃으로 BPFDoor를 사용했습니다. 피해는 미국, 한국, 홍콩, 터키, 인도, 베트남, 미얀마 등에서 확인되었습니다.
- 공격은 주로 월요일~금요일 01:00~10:00 UTC에 이루어져, 조직적인 작업 패턴을 보였습니다.
솔라리스 시스템 공격:
- 2019년 솔라리스 시스템을 타깃으로 한 변종이 2022년까지 탐지되지 않았으며, CVE-2019-3010 취약점을 악용한 것으로 확인되었습니다.
※ 트렌드마이크로 BPFDoor 분석 보고서(2025.04.14)
3. BPFDoor 기술적 분석
BPFDoor는 다음과 같은 기술적 특징을 갖습니다:
3.1 동작 방식
초기 실행:
- 실행 시 /var/run/initd.lock 파일을 생성해 런타임 락을 설정합니다.
- 포크(Fork) 프로세스를 생성해 부모 프로세스는 패킷 모니터링을, 자식 프로세스는 C2 통신을 담당합니다.
- 다양한 OS 시그널(SIGKILL 등)을 무시해 종료를 방지합니다.
패킷 스니핑:
- BPF 필터를 사용해 TCP, UDP, SCTP 트래픽(포트 22, 80, 443)을 모니터링합니다.
- 매직 바이트 시퀀스(예: 0x7255, 0x5293, 0x39393939)를 검색해 특정 패킷을 식별합니다.
명령 실행:
- 매직 바이트가 포함된 패킷을 수신하면, 하드코딩된 비밀번호를 확인 후 명령을 실행합니다.
- 지원 명령: 바인드 쉘(포트 42391~42491), 리버스쉘, iptables 규칙 수정 등.
은폐:
- 실행 후 바이너리를 삭제하고, /dev/shm/kdmtmpflush로 이름을 변경해 타임스탬프를 조작합니다.
- 프로세스 이름을 일반적인 리눅스 데몬으로 위장합니다.
3.2 탐지 회피
- 포트 비사용: 새로운 포트를 열지 않고 기존 서비스 포트를 활용합니다.
- C2 불필요: 특정 IP나 C2 서버 없이도 패킷을 통해 명령을 수신합니다.
- 암호화: 2023년 변종은 정적 라이브러리 암호화를 사용하며, 하드코딩된 명령을 제거해 시그니처 기반 탐지를 회피합니다.
- 안티-포렌식: 프로세스 환경 변수를 삭제하고, 메모리에 상주해 파일 스캔을 방지합니다.
3.3 취약점 악용
BPFDoor는 초기 침투를 위해 취약점을 악용하거나 사회공학적 기법을 사용합니다. 예:
- 솔라리스 시스템에서 CVE-2019-3010 취약점 활용.
- SysVinit 스크립트 수정으로 지속성을 확보합니다.
4. 탐지 및 대응
4.1 탐지 방법
네트워크 모니터링:
- TCP 패킷에서 24바이트 페이로드 시작 부분의 0x5293, UDP 패킷에서 0x7255 매직 바이트를 검색합니다.
- ss -0pb 명령어로 BPF 필터의 매직 넘버(0x7255, 0x5293, 0x39393939, 0x4430cd9f)를 확인합니다.
※ 주의: ss -0pb 명령어를 관리자 권한이 아닌 일반 유저권한으로 실행하면 bpf filter 값이 안보입니다.
| $ sudo ss -0pb | grep -EB1 --colour "$((0x7255))|$((0x5293))|$((0x39393939))|$((0x4430cd9f))" |
- HEX 7255: DEC 29269
- HEX 5293: DEC 21139
- HEX 39393939: DEC 960051513
- HEX 4430cd9f: DEC 1144049055
변종 대비 리눅스 시스템의 전체 소켓 상태를 조회하여 확인하는것도 방법이겠습니다.
| $ sudo ss -0pb |
프로세스 분석:
- /proc/*/stack에서 packet_recvmsg, wait_for_more_packets 함수 호출을 검색합니다.
- 의심스러운 프로세스 이름(예: hald-addon-acpi)을 확인합니다.
- TCP 포트 42391~43391 바인딩을 확인합니다.
| $ sudo netstat -lpn | grep -E ':42[3-9][0-9]{2}|43[0-3][0-9]{2}' |
파일 및 로그:
- /var/run/haldrund.pid 또는 /dev/shm/kdmtmpflush 파일 존재 여부를 확인합니다.
- iptables의 비정상적인 리디렉션 규칙을 점검합니다.
4.2 대응 방안
패치 관리: CVE-2019-3010과 같은 알려진 취약점을 패치합니다.BPF 분석: Radare2와 같은 도구를 사용해 BPF 바이트코드를 분석합니다.보안 솔루션: Trend Micro Vision One과 같은 AI 기반 플랫폼을 활용해 실시간 위협 탐지를 수행합니다.자동화 스캔: Sandfly와 같은 도구로 패킷 소켓을 사용하는 프로세스를 자동 스캔합니다.- 기 탐지 BPFDoor 악성코드: ss -0pb 명령어로 알려 매직 바이트 시퀀스 값을 찾거나 매직 바이트 시퀀스 값으로 열린 포트를 Github에 공개된 스캐너로 스캔하면 탐지가 가능합니다 (bpfdoor-scanner, Github) .
알려진 악성 프로세스명 검색. 알려진 Snort Rules 생성. - 변종 BPFDoor 악성코드: 관리자 권한으로 ss -0pb 명령어를 실행하여 BPF 필터가 조회되는 전체 프로세스에 대한 점검.
재컴파일, 매직 바이트 시퀀스 변경 시 스캔 무의미, Snort Rules 무의미, EDR 솔루션이 없다면 시스템에서 lsof 명령어로 외부통신 프로세스 직접 점검(이것도 점검시점에 외부 통신이 없다면 무의미) 및 의심스러운 프로세스 이름을 하나하나 점검하는 것 외 대응 방안 없음.
| #!/bin/bash sudo ss -0pb | while read -r line; do if [[ $line =~ ^(p_raw|p_dgr|udp|tcp) ]]; then socket_line="$line" continue fi if [[ $line =~ bpf\ filter ]] && [[ $line =~ $(printf '%d|%d|%d|%d|%d' 0x7255 0x5293 0x39393939 0x4430cd9f 0x5e142766) ]]; then if [[ $socket_line =~ users: ]]; then pid=$(echo "$socket_line" | grep -o 'pid=[0-9]*' | cut -d'=' -f2) if [ -n "$pid" ] && [ -d "/proc/$pid" ]; then filepath=$(sudo readlink -f "/proc/$pid/exe" 2>/dev/null || echo "Not found") cmdline=$(sudo cat "/proc/$pid/cmdline" 2>/dev/null | tr '\0' ' ' || echo "Not found") echo "PID: $pid, File: $cmdline, Path: $filepath" fi fi fi done |
bpf filter를 사용하는 프로세스가 존재하고, 파일이 삭제되지 않았다면 아래처럼 보일겁니다.
| # ./bpf_check.sh PID: 2629, File: ./hald-addon-acpi , Path: /proc/acpi/event/hald-addon-acpi |
| 별첨 3: 가입자인증시스템(HSS) 서버의 역할 및 아키텍처 |
| 1. 가입자인증시스템(HSS)이란? 가입자인증시스템(HSS,Home Subscriber Server)는 이동통신망에서 가입자 데이터를 관리하고 인증 및 권한 부여를 수행하는 중앙 집중형 데이터베이스입니다. 4G(LTE), 5G, IMS(IP Multimedia Subsystem) 네트워크에서 사용되며, 2G/3G 네트워크의 HLR(Home Location Register)와 AuC(Authentication Center) 기능을 통합합니다. 주요 기능은 다음과 같습니다:
|
|
 |
  |
| 2. HSS 서버 아키텍처 HSS는 중앙 집중형 데이터베이스로 설계되어 모든 가입자 정보를 단일 노드에 저장합니다. 주요 특징은 다음과 같습니다:
|
|
| 3. HSS 서버 통신 방식 HSS는 다양한 네트워크 엔티티와 통신하며, 주로 Diameter 프로토콜을 사용합니다. Diameter는 RFC3588에 정의된 AAA(Authentication, Authorization, Accounting) 프로토콜로, RADIUS의 후속입니다. 3.1 주요 인터페이스 및 프로토콜  Diameter 프로토콜:
이동통신망은 Diameter 프로토콜 등을 통해 HSS와 MME, AS 간 통신을 수행합니다. 이러한 프로토콜은 암호화 부족이나 인증 메커니즘의 약점으로 인해 보안 취약점을 가질 수 있습니다. |
|
| 4. HSS 서버 인증 방식 HSS는 가입자 인증 및 권한 부여를 담당하며, LTE 및 IMS 네트워크에서 다음과 같은 인증 메커니즘을 사용합니다: 4.1 EAP-AKA 인증 과정:
4.2 Diameter 기반 AAA 과정:
4.3 보안 메커니즘
|
|
'IT > News' 카테고리의 다른 글
| 2025.04.27 보험대리점(GA) 해킹 사고 (0) | 2025.04.28 |
|---|---|
| 2017.12.19 자유투어 개인정보 유출 (0) | 2018.01.19 |
| 2017.11.30 인터넷교차로 해킹 (0) | 2018.01.19 |
| 2017.11.20 애플 체험형 스토어 프리스비 고객정보 유출 (0) | 2018.01.19 |
| 2017.11.17 하나투어 100만여명 고객정보 유출 추가 (0) | 2018.01.19 |