SKT 해킹 가설: 유심 데이터 탈취와 BPFDoor 설치, 어떻게 이뤄졌나?
핵심 한 줄 요약
2025년 4월, SK텔레콤은 악성코드로 인한 침해를 공개했고, 정부 합동조사 결과 유심 관련 데이터 유출과 다수 감염 서버가 확인되었습니다. 다만 최초 침투 경로와 정확한 공격 체인은 공개 정보만으로 단정할 수 없으며, 본 글은 웹셸·RCE → 권한 상승 → BPFDoor 설치가 유력한 가설이라는 전제 아래 사건을 해석합니다.
아래 문서는
“SKT 해킹 사건에서 BPFDoor를 설치하기 위한 주요 침투 벡터가 웹셸(WebShell) 또는 RCE(Remote Code Execution)였을 가능성이 높다”
는 가설을 바탕으로 작성했습니다.
공개된 사실은 분명합니다.
SK텔레콤은 2025년 4월 18일 비정상 대용량 외부 전송을 탐지했고, 이후 전 고객 대상 무료 USIM 교체를 발표했습니다. 정부는 민관 합동조사를 통해 유심 관련 데이터 유출, 다수 감염 서버, 다수 악성코드 존재를 확인했습니다. 그러나 최초 침투 지점, 정확한 취약점, 공격자의 전체 이동 경로는 공개 범위상 제한적입니다.
따라서 이 글은 다음 원칙을 따릅니다.
- 확인된 사실과 기술적 가설을 구분한다.
- 웹셸·RCE 가설을 중심에 두되, 계정 탈취나 내부자 악용 등 다른 가능성을 배제하지 않는다.
- 향후 포렌식 결과나 추가 공개 자료에 따라 가설은 수정될 수 있음을 전제로 한다.
1. SKT 유심 해킹 사건과 BPFDoor 개요
1) 공개된 사건 개요
2025년 4월 SK텔레콤은 유심 관련 정보 유출 사고를 공개했습니다.
이후 정부 조사 결과, 비정상 대용량 외부 전송이 4월 18일 밤 탐지되었고, 다수 서버 감염과 다수 악성코드가 확인되었습니다. SK텔레콤은 4월 28일부터 무료 USIM 교체를 시작했고, 이후 당국의 행정조치와 보안 강화 요구가 뒤따랐습니다.
이 사건에서 특히 주목할 점은 두 가지입니다.
- 단순 개인정보 노출이 아니라 통신 인증 인프라와 직접 연결되는 유심 관련 데이터 유출이었다는 점
- 리눅스 계열 고은닉 백도어로 알려진 BPFDoor 계열 위협이 함께 거론되었다는 점입니다.
2) BPFDoor의 특징
BPFDoor는 리눅스 환경에서 잘 알려진 은닉형 백도어입니다.
트렌드마이크로는 2025년 보고서에서 BPFDoor가 통신, 금융, 소매 분야를 겨냥했고, 한국을 포함한 여러 지역에서 활동 흔적을 확인했다고 밝혔습니다. 이 백도어는 BPF 기반 패킷 필터를 이용해 특정 “매직 시퀀스”가 담긴 패킷을 받을 때만 동작을 활성화하며, 역방향 셸을 열거나 특정 포트를 통한 셸 연결을 열 수 있습니다.
즉, BPFDoor의 핵심은 지속성 그 자체보다 은닉성과 장기 잠복성입니다.
- 일반적인 포트 리스닝 흔적이 약함
- 매직 패킷 기반 활성화
- 정상 프로세스처럼 위장 가능
- 메모리 상주 및 임시 경로 활용
- 장기 재진입과 횡적 이동에 유리
이 특성 때문에 BPFDoor는 보통 최초 침투 도구라기보다,
이미 어느 정도 내부 권한을 확보한 뒤 심는 후속 백도어로 보는 것이 더 자연스럽습니다.
2. 웹셸(WebShell)·RCE를 통한 BPFDoor 배포: 가설적 시나리오
이 글의 핵심 가설은 다음과 같습니다.
“SKT 사건에서 공격자들은 인터넷 또는 외부 연결 구간에 노출된 웹 기반 관리 경로, 운영 지원 경로, 혹은 그와 유사한 애플리케이션 취약점을 이용해 최초 셸을 얻고, 이후 권한 상승을 통해 BPFDoor를 설치했을 가능성이 높다.”
왜 이런 가설이 유력할까요.
첫째, 기업 침해사고에서 웹 기반 취약점 악용은 여전히 가장 흔한 초기 진입 방식 중 하나입니다. 트렌드마이크로의 리눅스 위협 보고서 역시 웹셸과 공개취약점 악용이 리눅스 서버 공격에서 매우 빈번하다고 설명합니다.
둘째, 통신사나 대기업의 핵심 서버가 직접 인터넷에 노출되지 않더라도, 현실에서는 다음 중 하나가 존재하기 쉽습니다.
- 운영·관제용 웹 콘솔
- 관리 API
- 내부용이지만 외부에서 우회 도달 가능한 웹 애플리케이션
- 배포·점검을 위한 파일 업로드 기능
- VPN/원격접속 장비와 연결된 관리 웹 인터페이스
셋째, BPFDoor는 일반적으로 낮은 권한의 웹 프로세스에서 바로 실행하는 도구라기보다,
좀 더 안정적인 내부 장악 뒤에 심는 장기 거점이라는 점에서
“웹셸·RCE → 권한 상승 → 백도어 설치” 흐름과 잘 맞습니다.
2.1 일반적인 웹셸·RCE 공격 흐름
-
취약점 식별
공격자는 공개 취약점(N-day), 패치되지 않은 관리 프레임워크, 취약한 파일 업로드 기능, 역직렬화 취약점, 인증 우회 취약점 등을 식별합니다. -
원격 코드 실행(RCE) 또는 웹셸 업로드
- 업로드 취약점이면
.jsp,.war, 스크립트 파일, 혹은 이와 유사한 실행 가능한 페이로드를 배치 - RCE 취약점이면 HTTP 요청만으로 시스템 명령 실행
- 이 단계에서 보통
tomcat,weblogic,www-data같은 서비스 계정 수준의 셸을 얻습니다.
- 업로드 취약점이면
-
환경 정찰
- 커널 버전, 프로세스 목록, DB 접속 정보, 애플리케이션 설정 파일, 크론, sudo 권한, 서비스 계정 키 등을 수집
- 내부 네트워크 구조와 HSS 인접 자산을 확인
-
권한 상승
- 잘못된 sudo 설정
- SUID 바이너리 악용
- 패치되지 않은 로컬 권한 상승 취약점
- 운영 스크립트/배치 계정 오남용
등을 통해 root 권한 획득을 시도
-
BPFDoor 설치 및 장기 거점화
- 임시 경로에 백도어 배치
- 프로세스 위장
- 매직 패킷 기반 활성화
- 필요 시 역방향 셸 개방
-
지속적 접근, 데이터 탈취, 횡적 이동
- HSS 관련 DB 질의
- 운영계정 자격증명 재사용
- 인접 시스템 이동
- 외부 유출 채널 확보
3. 왜 웹셸·RCE가 핵심 가설인가?
1) 공격자 입장에서 가장 현실적인 최초 진입점
웹 애플리케이션과 운영용 관리 웹 경로는 기업 환경에서 가장 흔한 외부 접점입니다.
특히 패치 주기가 빠르고, 기능 추가와 운영 편의 때문에 예외 규칙이 쌓이기 쉽습니다.
즉, 공격자 입장에서는
- 스캔이 쉽고
- 자동화가 가능하며
- 한 번 성공하면 즉시 셸 획득으로 이어지기 쉬운
가장 효율적인 경로 중 하나가 바로 웹 기반 침투입니다.
2) 웹셸과 RCE는 방법만 다를 뿐 결과는 같다
웹셸이든 RCE든, 본질은 같습니다.
- 서버 내부에서 명령을 실행할 수 있느냐
- 이후 권한을 올릴 수 있느냐
- 장기 거점을 심을 수 있느냐
결국 한 번이라도 셸을 얻으면,
BPFDoor 같은 백도어 설치는 그다음 단계의 문제가 됩니다.
3) SKT 환경에서 가정할 수 있는 취약점 유형
공개된 포렌식 결과가 제한적이므로 특정 제품명을 단정할 수는 없습니다.
다만 통신사급 대형 인프라에서 현실적으로 떠올릴 수 있는 취약점 유형은 다음과 같습니다.
- 관리 콘솔의 N-day 취약점
- 파일 업로드 기능 우회
- 운영·관제용 내부 웹 애플리케이션 취약점
- 역직렬화 또는 템플릿 인젝션
- 인증 우회 후 명령 실행
- 원격접속 장비 또는 웹 기반 관리 시스템과 연결된 RCE
여기서 중요한 것은 “어느 제품이었는가”보다
웹 기반 실행권한 획득이 가장 설명력이 높은 초기 단계라는 점입니다.
4) 왜 통신사 환경에서 특히 치명적인가
통신사는 일반 기업보다 더 많은 관리 시스템, 중계 시스템, 운영 웹 인터페이스, 인증 관련 핵심 인프라를 가집니다.
따라서 단 하나의 취약한 웹 경로가 뚫려도, 피해는 단순 웹서버 수준에 머물지 않습니다.
특히 HSS처럼 가입자 인증과 연동되는 시스템은
- DB 접근 가치가 높고
- 내부 인접 자산으로의 연결성이 크며
- 탈취 데이터의 악용 가능성도 높습니다.
그래서 통신사 침해사고에서는
웹 기반 최초 진입과 내부 중요 시스템 장악 사이의 간격이 매우 짧아질 수 있습니다.
4. 구체적 BPFDoor 설치 시나리오 (웹 기반 가정)
아래는 SKT 사건을 설명하기 위한 가설적 시나리오입니다.
실제 침투 경로가 다를 수 있지만, 공개된 사실과 BPFDoor 특성을 함께 놓고 보면 충분히 설득력 있는 흐름입니다.
1) 취약한 웹 경로 또는 관리 애플리케이션 침투
공격자는 인터넷 노출 또는 외부에서 도달 가능한 관리 웹 경로를 식별합니다.
이 지점에서 취약한 업로드 기능, 인증 우회, 공개 취약점, 또는 운영 도구의 RCE를 이용해 최초 셸을 확보합니다.
2) 저권한 셸 획득 후 내부 정찰
웹서버 계정 권한으로 진입한 뒤 다음을 탐색합니다.
- 애플리케이션 설정 파일
- DB 접속 문자열
- 계정 및 권한 구조
- 서비스 실행 계정
- 내부 네트워크 연결 대상
- 스크립트, 크론, 자동배포 도구
이 단계에서 공격자는 HSS 인접 자산, 또는 HSS 접근이 가능한 운영 경로를 찾았을 가능성이 큽니다.
3) 권한 상승
BPFDoor는 장기 잠복형 백도어이므로,
안정적으로 심기 위해서는 더 높은 권한이 필요했을 가능성이 큽니다.
가능한 권한 상승 경로는 다음과 같습니다.
- sudo misconfiguration
- 운영 스크립트 악용
- 로컬 취약점
- 잘못된 파일 권한
- 배치 계정 또는 관리 계정 탈취
4) BPFDoor 설치
권한 상승 이후 공격자는 임시 디렉터리나 눈에 덜 띄는 경로에 BPFDoor 계열 백도어를 배치합니다.
이후 원본 삭제, 프로세스명 위장, 메모리 상주, 매직 패킷 대기 형태로 장기 거점을 만듭니다.
BPFDoor 컨트롤러는 역방향 셸을 열 수 있어, 이후 더 깊은 내부 이동과 추가 장악에도 유리합니다.
5) 유심 관련 데이터 접근 및 탈취
이 단계에서 공격자는 단순히 백도어를 심는 데서 끝나지 않습니다.
실제 목표는 결국 데이터입니다.
가능한 흐름은 다음과 같습니다.
- HSS 또는 연계 DB 접근
- 가입자 식별자와 인증 관련 데이터 조회
- 결과를 임시 파일로 정리
- 정상 관리 도구처럼 보이는 방식으로 외부 반출
- 필요 시 여러 차례 분할 탈취
6) 추가 횡적 이동
트렌드마이크로는 BPFDoor 컨트롤러가 역방향 셸을 열 수 있어
더 깊은 내부 침투와 횡적 이동을 가능하게 한다고 설명합니다.
즉, BPFDoor는 단순 대기형 백도어가 아니라, 이후 추가 장악을 위한 교두보 역할도 했을 가능성이 있습니다.
5. MITRE ATT&CK 매핑 (웹셸·RCE 기반)
왜 MITRE ATT&CK으로 보는가?
이번 사건에서 핵심은
“BPFDoor가 설치되기 전에도 이미 여러 탐지 기회가 있었을 것”이라는 점입니다.
BPFDoor는 보통 공격의 맨 앞이 아니라,
어느 정도 내부 진입과 권한 확보가 끝난 뒤 등장하는 편입니다.
그렇다면 그 이전에는 반드시 다음 단계 중 일부가 있었을 가능성이 높습니다.
- 외부 노출 애플리케이션 악용
- 명령 실행
- 권한 상승
- 은폐
- 내부 정찰
- 지속성 확보
- 자료 수집
- 외부 전송
MITRE ATT&CK으로 보면,
우리는 사건을 단순한 “악성코드 발견”이 아니라
초기 침투부터 전개, 은닉, 탈취까지 이어지는 흐름으로 재구성할 수 있습니다.
핵심 ATT&CK 흐름 예시
| 전술 | 기법 | 의미 |
|---|---|---|
| Initial Access | Exploit Public-Facing Application | 외부 노출 웹/관리 서비스 악용 |
| Execution | Command and Scripting Interpreter | 웹셸, 쉘 명령, 스크립트 실행 |
| Privilege Escalation | Exploitation for Privilege Escalation / Sudo Abuse | root 권한 획득 |
| Defense Evasion | Masquerading / File Deletion / Hidden Files | 위장, 흔적 삭제, 임시 경로 은닉 |
| Persistence | Backdoor / Service Abuse | BPFDoor 장기 상주 |
| Discovery | System / Network / Account Discovery | 내부 구조 탐색 |
| Collection | Data from Information Repositories | HSS/DB 정보 수집 |
| Exfiltration | Exfiltration Over Alternative Protocol / Encrypted Channel | 외부 유출 |
이 관점이 중요한 이유는 분명합니다.
최종 악성코드를 못 막았더라도, 그 이전 단계를 잡을 수 있었는지 점검할 수 있기 때문입니다.
6. 보안팀을 위한 현실적 대응 전략 (웹 공격 관점)
이 사건에서 가장 중요한 교훈은
“BPFDoor 자체가 아니라, BPFDoor가 설치되기 전 단계를 얼마나 빨리 잡을 수 있었는가”입니다.
현실적인 대응 전략은 다음 네 가지로 정리할 수 있습니다.
1) 웹 본문까지 보는 방어 체계
URI, 헤더, 상태 코드만으로는 부족합니다.
웹셸 업로드, RCE 페이로드, 난독화된 요청은 HTTP Body에 숨어 있을 가능성이 큽니다.
따라서 다음이 필요합니다.
- 업로드 요청 본문 분석
- 관리자·고위험 URI 전량 로깅
- 응답 본문 이상 징후 확인
- 웹 요청과 서버 내부 행위의 연계 추적
2) 리눅스 호스트 행위 가시성 확보
BPFDoor는 결국 리눅스 호스트 안에서 동작합니다.
따라서 다음 행위를 반드시 볼 수 있어야 합니다.
- 의심 프로세스 생성
/dev/shm,/var/run등 임시 경로 파일 생성- 프로세스명 위장
- 권한 상승
- 비정상 외부 연결
scp,sftp, SSH 기반 외부 반출 시도
3) 웹 로그와 OS 로그의 상관분석
가장 중요한 것은 연결입니다.
예를 들어,
- 특정 업로드 요청 발생
- 직후 셸 명령 실행
- 몇 분 뒤
/dev/shm에 수상한 실행 파일 생성 - 이후 외부 특정 IP와 은밀한 통신
이 흐름이 이어져야 실제 공격으로 보입니다.
4) 초기 침투 단계에서 자동 대응
권한 상승과 백도어 설치 단계까지 기다리면 늦습니다.
다음 시점에 바로 대응할 수 있어야 합니다.
- 웹셸 업로드 의심
- 서버 명령 실행 의심
- 임시 경로 실행 파일 생성
- 위장 프로세스 실행
- 비정상 외부 전송 증가
즉, Execution과 Privilege Escalation 단계에서 끊는 것이 핵심입니다.
7. PLURA-XDR은 어디에서 도움이 되는가
이번 사건을 단순히 “고급 악성코드를 막아야 한다”로만 보면 답이 흐려집니다.
실제로 필요한 것은 웹셸·RCE → 권한 상승 → 백도어 설치 → 유출이라는 흐름을 한 번에 볼 수 있는 체계입니다.
이 지점에서 PLURA-XDR 같은 통합 플랫폼의 의미가 생깁니다.
1) 웹셸·RCE 탐지
- 웹 요청 본문 분석
- 업로드 파일 내용과 패턴 탐지
- 관리자 기능·고위험 URI 집중 감시
- 웹 요청과 서버 프로세스 실행 이벤트 연결
즉, WAF가 놓친 요청이라도
웹 본문 + 서버 행위를 함께 보면 초기 침투를 더 빨리 볼 수 있습니다.
2) BPFDoor 같은 fileless·은닉형 백도어 행위 탐지
BPFDoor는 은밀하지만, 완전히 무흔적이지는 않습니다.
- 임시 경로 파일 생성
- 위장 프로세스
- 비정상 PID 파일
- 프로세스 트리 이상
- 비정상 네트워크 활성화
- 리버스 셸 또는 SSH 기반 외부 유출 도구 사용
이런 징후는 시그니처 하나보다 행위 조합으로 보는 것이 더 효과적입니다.
3) HSS 서버 로그와 웹 로그의 실시간 상관분석
핵심은 “한 줄 로그”가 아닙니다.
- 웹 요청
- 계정 행위
- 프로세스 실행
- 파일 생성
- 네트워크 연결
- 외부 유출
이것을 한 흐름으로 묶어야
“지금 공격이 진행 중인지”를 판단할 수 있습니다.
4) 제품 설명이 아니라 운영 설명이어야 한다
PLURA-XDR의 의미는 기능 나열이 아닙니다.
이번 사건 같은 유형에서 중요한 것은,
웹에서 시작된 이상 행위가 서버 내부에서 어떤 명령 실행과 권한 상승으로 이어졌는지를 실시간으로 연결해 보는 것
입니다.
즉, PLURA-XDR은
웹 공격을 웹에서만 보지 않고,
호스트와 유출 단계까지 연결해 보는 운영 체계라는 점에서 의미가 있습니다.
8. 결론
이번 SKT 해킹 사건에서 공개된 사실은 분명합니다.
유심 관련 데이터 유출이 있었고, 다수 감염 서버와 악성코드가 확인되었으며, BPFDoor 계열 위협과 연결되는 정황이 거론되었습니다. 그러나 최초 침투 경로는 공개 정보만으로 확정할 수 없습니다.
그럼에도 기술적으로 가장 설명력이 높은 가설 중 하나는 여전히 다음입니다.
웹셸 또는 RCE로 최초 진입 → 저권한 셸 확보 → 권한 상승 → BPFDoor 설치 → HSS/연계 시스템 접근 → 유심 관련 데이터 탈취
이 가설이 중요한 이유는
단지 “맞을 가능성이 높다”는 데 있지 않습니다.
이 흐름이 맞든 일부만 맞든,
방어는 결국 초기 웹 진입과 권한 상승 단계에서 시작되어야 한다는 점을 분명히 보여주기 때문입니다.
이번 사건의 교훈은 단순합니다.
- BPFDoor는 마지막 단계에 가깝습니다.
- 진짜 승부는 그 이전 단계에서 납니다.
- 웹 요청 본문, 서버 행위, 권한 상승, 외부 전송을 연결해서 봐야 합니다.
- 단일 장비보다 통합된 가시성과 상관분석 체계가 더 중요합니다.
즉, 이번 사건은
“고급 백도어를 어떻게 잡을 것인가”보다
“왜 초기 침투를 더 일찍 보지 못했는가”를 먼저 묻게 만드는 사건입니다.
최종 제언
- 웹셸 및 RCE는 여전히 대규모 침해사고의 가장 현실적인 진입 통로 중 하나라는 전제로 방어체계를 설계해야 합니다.
- 중요 서버는 URI/헤더 수준이 아니라 웹 요청 본문까지 볼 수 있어야 합니다.
- 리눅스 핵심 서버는 프로세스·파일·권한·네트워크 행위를 구조적으로 남겨야 합니다.
- BPFDoor 같은 은닉형 백도어는 사후 탐지만으로는 늦기 때문에, 초기 침투와 권한 상승 단계를 먼저 잡아야 합니다.
- PLURA-XDR 같은 통합 플랫폼은 웹 공격과 호스트 행위를 하나의 흐름으로 연결해, BPFDoor 설치 이전 단계에서 대응할 가능성을 높여줍니다.
이번 SKT 사건은
웹 공격, 리눅스 장기 거점형 백도어, 통신 인프라 데이터 탈취가
한 줄로 이어질 수 있음을 보여준 사건입니다.
그래서 더 중요한 질문은 이것입니다.
우리는 악성코드 이름을 아는가가 아니라,
그 악성코드가 설치되기 전 단계를 볼 수 있는가?
⚖ 면책 조항
본 글은 공개된 정보와 일반적인 침해사고 분석 경험을 바탕으로 한 기술적 가설입니다.
실제 침투 경로와 공격 체인은 향후 공개될 포렌식 결과에 따라 달라질 수 있습니다.
📺 함께 시청하기
📖 함께 읽기
- SKT 유심 해킹 사건 총정리: 유출 원인, 피해 규모, 대응 방법까지
- SKT 해킹 악성코드 BPFDoor 분석 및 PLURA-XDR 대응 전략 (탐지 시연 영상 포함)
- SKT 해킹으로 본 NDR 기술 한계: BPFDoor 같은 스텔스 공격 대응법
- LG유플러스 고객인증 시스템 유출 시나리오