SKT 해킹 가설: 유심 데이터 탈취와 BPFDoor 설치, 어떻게 이뤄졌나?

PLURA

핵심 한 줄 요약
2025년 4월 18일, SK텔레콤 HSS(Home Subscriber Server)가 해킹되어 최대 2,300만 가입자의 USIM 인증 정보가 노출되었으며, SKT는 4월 28일에 전 고객을 대상으로 무료 USIM 교체를 발표했습니다.

SKT 해킹 공격 시퀀스 다이어그램 예시

아래 문서는 “SKT 해킹 사건에서 BPFDoor를 설치하기 위한 주요 침투 벡터가 웹셸(WebShell)·RCE(Remote Code Execution) 중심이다“라는 가설을 전제로 작성하였습니다.

2018년 6월, LGU+ 해킹에서 웹셸을 이용한 공격, 2021년 6월, 한국원자력연구원(KAERI)·한국항공우주산업(KAI) 등에서는 SSL VPN 취약점을 이용한 RCE 공격 사례를 고려하였습니다.

물론 실제로는 계정 탈취, 내부자 악용 등의 다른 수단도 있을 수 있으나, 본 글에서는 웹셸·RCE 공격에 무게중심을 두고 전개합니다.

향후 새로운 증거가 나오면 이 가설 역시 수정될 수 있음을 염두에 두고 읽어주시기 바랍니다.

1. SKT 유심 해킹 사건과 BPFDoor 개요

  1. 사건 요약

    • 2025년 4월, SK텔레콤(이하 SKT) 핵심 서버인 HSS(Home Subscriber Server)가 해킹되어 BPFDoor 악성코드가 설치되었고, 대규모 유심(USIM) 가입자 정보가 탈취된 것으로 추정됨.
    • SKT 해킹은 중국계 APT 그룹(Red Menshen, Earth Bluecrow, APT41 등)과 연계된 정황이 유력하며, BPFDoor는 공격자가 장기간 은밀하게 서버 내부를 장악하기 위한 스텔스 백도어로 활용됨.

  2. BPFDoor의 특징

    • 커널 레벨(BPF) 필터 활용: 일반 포트 리스닝 대신 매직 패킷을 수신해야만 활성화되는 수동형 백도어.
    • 메모리 상주(fileless): /dev/shm 등에 복사 후 원본 삭제, 프로세스 위장·백그라운드 실행 등 은폐 기술을 다단계로 사용.
    • 광범위 APT 공격에 활용: 중동·아시아 등 통신사·금융기관에서 동일한 BPFDoor 변종 보고. 이번 SKT 사건도 그런 고도화된 공격의 연장선으로 평가됨.

2. 웹셸(WebShell)·RCE를 통한 BPFDoor 배포: 가설적 시나리오

이 문서의 핵심 가설은 다음과 같습니다:

“SKT 사건에서, 공격자들은 가장 흔하고 효율적인 웹 기반 공격(웹셸·RCE)을 통해 HSS 서버 내부권한을 확보한 뒤, BPFDoor를 설치했을 가능성이 높다.”

이는 2018년 6월, LGU+ 해킹에서 웹셸 사용 사례와 같이 흔하다는 점, 그리고 현장에서 자주 확인되는 APT 공격 흐름에 근거합니다. 또한 국내외 보고서에서도 웹셸 또는 RCE 취약점이 전체 침투의 ‘대다수’를 차지한다는 경험적 사실이 꾸준히 제시되고 있습니다.

2.1 일반적인 웹셸·RCE 공격 흐름

  1. 취약점 식별

    • 공격 대상 서버(예: WebLogic, Apache, Nginx, Tomcat, 자체 개발 웹 앱 등)에 존재하는 공개취약점(N-day) 또는 0-day를 공격자가 파악.
    • 또는 파일 업로드 기능이 존재하고, 확장자 필터가 허술하거나 우회가 가능한 경우, 웹셸 업로드 시나리오가 열림.

  2. 원격 코드 실행(RCE) 달성

    • 웹셸 업로드: .php, .jsp 같은 악성 스크립트를 업로드 → /uploads/… 등 경로에서 직접 호출 → 서버 내부 명령 실행.

    • RCE 취약점 이용: Log4Shell, WebLogic RCE, 역직렬화 취약점 등으로 HTTP 요청만으로 바로 OS 명령어 실행.

    • 이 단계에서 공격자는 낮은 권한(www-data, tomcat 등)으로도 서버에 진입할 수 있게 됨.

  3. 권한 상승 및 백도어 설치

    • sudo misconfig, 커널 취약점, 권한 상승 툴 등을 이용해 root 권한 획득.
    • 확실한 재진입 통로를 확보하기 위해, BPFDoor와 같은 고급 백도어를 심음.
    • SKT 사례에서는 백도어가 kdmtmpflush 등 이름으로 /dev/shm에 상주, 원본 삭제로 은폐.

  4. 지속적 침투

    • BPFDoor는 외부에서 특별한 매직 패킷을 수신해야만 활성화되는 수동형 C2 방식으로 은밀히 운영 → 장기간 서버 장악.
    • 이후 HSS DB 쿼리, 대량 유심 정보 탈취, 다른 내부 서버로 횡적 이동.

3. 왜 웹셸·RCE가 핵심인가?

  1. 공격자 입장에서 가장 손쉬운 초기 진입

    • 통상 기업망에서 웹 서비스는 외부에 노출되어 있고, 프레임워크·플러그인·파일 업로더 등 공격 표면이 넓음.
    • 패치가 미비하거나 취약점이 새로 공개되면, 자동화 스캐너로 수많은 표적을 신속히 탐색해 한꺼번에 침투 가능.

  2. 웹셸 vs. RCE, 결과는 동일: 서버 장악

    • 웹셸: 업로드 취약점을 통해 .jsp 파일 등 실행 가능 스크립트를 배치 → 웹서버 권한으로 명령어 실행.
    • RCE: 업로드 없이도 특정 취약점(PHP deserialization, Log4j, WebLogic 등)으로 곧바로 명령 실행.
    • 한 번이라도 서버 명령어(shell)를 획득하면, BPFDoor 같은 백도어 설치가 매우 간단.

  3. 2023년 1월, LGU+ 해킹에서 웹셸 사용 사례

    • 이런 상황에서 웹셸 공격이 성공하면 측면이동(Lateral Movement)으로 계속 깊숙이 내부망에 침투할 수 있습니다.

  4. 피해 스케일 확장

    • 특히 통신사·금융기관 등은 수십~수백 대의 웹 서버를 운영 → 공격 표면 다수.
    • 방화벽·VPN 관제보다도, 웹서비스는 잦은 업데이트가 필요해 취약점 패치 누락이 빈번할 수 있음.
    • 실제 침해사고 현장에서도 “웹셸로 시작” 혹은 “RCE로 한 번에 뚫림”이 대다수 사례를 차지한다는 보고 많음.

4. 구체적 BPFDoor 설치 시나리오 (웹 기반 가정)

아래는 이번 SKT 사건에 대해 가설적으로 구성한 웹셸·RCE 중심 시나리오입니다. 실제 침해경로가 다를 수 있으나, “웹 공격이 주력”이라는 가정 아래 보면 일관성이 높습니다.

  1. (가정) WebLogic, Tomcat, 혹은 자체 웹앱 취약점

    • HSS 관리 혹은 관련 웹 서버(운영·개발용 등) 중 하나가 취약 버전이었다고 가정.
    • 공격자가 자동 스캔 후, curl -F file=@shell.jsp … 같은 방식으로 웹셸을 업로드하거나, RCE 익스플로잇을 사용.

  2. Low-privilege 셸 획득

    • 웹서버 계정(tomcat, www-data) 권한으로 시스템 내부에 진입.
    • 공격자: uname -a, cat /etc/passwd 등으로 환경 탐색 → 추가 권한 상승 루트 파악.

  3. Root 권한 확보

    • SUID 파일, 커널 버그, sudo misconfig 등 악용 → root 권한 상승.
    • 이제 BPFDoor 설치가 가능(커널 소켓 필터 등록에는 높은 권한 필요).

  4. BPFDoor 업로드 & 실행

    • /dev/shm/kdmtmpflush 등 임시 디렉터리에 복사 → 원본 파일 삭제.
    • 백도어 프로세스가 부모 프로세스와 분리되며 메모리에 상주.
    • BPF 필터 세팅 → “매직 패킷”이 올 때만 셸 연결을 열어둠.

  5. HSS DB 접근 및 자료 탈취

    • BPFDoor를 통해 공격자가 언제든 재접속 가능.
    • HSS 내부 DB(유심 인증키, 가입자 IMSI 등)에 대량 쿼리 → 결과 파일 유출.
    • 최종적으로 SKT 고객 유심 정보 대규모 노출 사태 발생.

5. MITRE ATT&CK 매핑 (웹셸·RCE 기반)

왜 MITRE ATT&CK을 매핑했는가?

MITRE ATT&CK은 전 세계 보안 전문가들이 공격자의 전술(Tactics)과 기법(Techniques)을 체계적으로 정리해놓은 지식 베이스입니다. 이번 SKT 해킹 사례에서 BPFDoor가 최종적으로 설치·활동했다면, 그전에 APT 공격 특유의 여러 단계(웹셸 업로드, 권한 상승, 내부 정찰 등)가 이미 발생했을 가능성이 큽니다.
실제로 BPFDoor 같은 고급 백도어는 공격 막바지(후반 단계)에 투입되는 경우가 많은데,
MITRE ATT&CK 관점에서 보면 초기 침투(Initial Access) → 실행(Execution) → 권한 상승(Privilege Escalation) → … 등 여러 전술을 거치므로, 사전에 여러 이벤트를 탐지할 기회가 존재했다는 뜻입니다.

따라서 APT 공격 전체가 어떤 전술·기법을 거쳤는지 표준화된 방식으로 살펴봄으로써,

  1. BPFDoor를 설치하기 전에 이미 발생했을 징후(웹셸, RCE 공격, 커널 취약점 악용 등)를 놓치지 않았는지 확인하고,
  2. 체계적인 대응 방안(각 단계별 탐지·차단)을 마련하는 것이 필수적입니다. 이처럼 SKT 해킹과 BPFDoor 시나리오를 MITRE ATT&CK에 매핑하면, 공격자의 구체적 행위(웹셸 업로드, 커널 취약점 악용, 백도어 C2 등)를 전술·기법에 따라 분류하여 사전 탐지 기회를 극대화하고 재현성 높은 방어전략을 세울 수 있습니다.

MITRE ATT&CK 매핑의 세 가지 주요 장점

  1. 객관적 기준

    • 공격 흐름을 명확히 분류하므로, “이 공격이 어느 단계에 속하고, 어떤 기법을 사용했는지”를 표준화된 용어로 설명할 수 있음.
    • APT 공격이 진행될 때 ‘BPFDoor 설치’ 직전에도 각종 지표가 남았을 것이므로, 놓친 경고 신호가 무엇이었는지 체계적으로 점검 가능.

  2. 보안 운영 최적화

    • 각 전술·기법마다 대응 방안이 구체적으로 제시되어 있어, 조직의 보안 로드맵(방어 전략)을 수립할 때 참고.
    • “Execution(T1059.004) 단계에서 쉘 명령어 실행이 있었다면, EDR 행위 모니터링은 충분했나?” 등 구체적 점검이 가능해짐.

  3. 산업 표준 준수

    • APT 보고서나 침해사고 분석 시, MITRE ATT&CK 매핑은 사실상 업계 표준. 다른 조직·사건과 비교·분석하기 쉽고, 정보 공유도 수월.

5.1 BPFDoor 공격 그룹과 LoL(Living off the Land) 기법

BPFDoor를 사용하는 해킹 그룹은 주로 중국계 APT 그룹으로 분류되며, 대표적으로 APT27(Emissary Panda)가 보고되었습니다. 이들은 탐지 회피와 은밀한 장기 침투를 위해 LoL (Living off the Land) 기법을 광범위하게 활용하고 있습니다.

아래 표는 MITRE ATT&CK 프레임워크 기반으로, BPFDoor 관련 공격 그룹이 자주 사용하는 LoL 기술을 요약한 것입니다.

MITRE ATT&CK 기반 LoL 기법 (BPFDoor 관련)

Tactic (전술) Technique (기법) ID 설명
Execution (실행) Command and Scripting Interpreter: Bash T1059.004 Bash 셸을 통한 명령 실행
Command and Scripting Interpreter: PowerShell T1059.001 PowerShell로 메모리 내 악성 코드 실행 (Windows 시)
Persistence (지속성) Modify System Binary T1543.003 시스템 바이너리 변조 또는 서비스 등록
Privilege Escalation (권한 상승) Sudo and Sudo Caching T1548.003 합법적 권한 상승 도구 악용
Defense Evasion (탐지 회피) Masquerading T1036 정상 프로세스 이름으로 위장 (예: sshd, syslogd 등)
Obfuscated Files or Information T1027 난독화/암호화된 스크립트, 실행 파일 사용

5.2 BPFDoor TID 기반 탐지 필터 설계

앞 절에서 살펴본 LoL 기법과 전술(Tactic) 흐름을 기반으로, 실제 운영 환경에서 BPFDoor의 은밀한 동작을 식별하기 위한 탐지 필터를 설계했습니다.

BPFDoor는 다양한 공격 기술을 조합해 리눅스 시스템 내에서 은밀하게 동작하므로, 이를 효과적으로 탐지하기 위해 MITRE ATT&CK 프레임워크의 TID(Technique ID)를 기준으로 특성과 일치하는 행위를 분류하고, 그에 대응하는 필터를 구성했습니다.

이 필터는 단순한 시그니처 탐지를 넘어서 공격자의 행동 패턴(TTP)에 기반한 로그 분석과 행위 기반 탐지를 병행하도록 설계되었습니다. 아래는 실제로 BPFDoor 탐지를 위해 구성한 주요 필터 목록과 해당 기술에 매핑된 TID입니다.

필터명 매핑된 TID 매핑 이유 설명
BPFDoor_리버스 쉘 T1059.004 (Unix Shell) "Initiated=false" + sshd + 특정 내부 IP로 리버스 접속 시도는 BPFDoor의 RC4 인증 후 리버스 셸 기능과 일치. 실제 쉘 실행 행위에 해당하며 Unix Shell로 분류됨.
BPFDoor 파일 삭제 T1070.004 (File Deletion) 공격자가 흔적을 지우기 위해 rm 명령으로 실행 파일 등 제거 → 지표 제거를 위한 파일 삭제에 해당함.
BPFDoor 프로세스 T1036.011 (Masquerading: Overwrite Process Arguments) console-kit-daemon, udevd 등 정상 데몬 이름으로 위장한 프로세스 → 프로세스 인자 위조로 위장하는 TTP에 해당.
BPFDoor 초기화 실행 T1036.009 (Masquerading: Break Process Trees) --init 플래그 사용은 부모 프로세스를 init으로 바꿔 분석 우회 시도 → PPID 단절 행위.
BPFDoor 위장 프로세스 T1036.011 (Masquerading: Overwrite Process Arguments) qmgr -l -t fifo -u는 Postfix 정상 프로세스를 흉내 낸 문자열 인자 위조 → 프로세스 위장.
BPFDoor 환경 변수 설정 T1562.003 (Impair Command History Logging) HISTFILE=/dev/null 경로 포함된 환경 변수 설정 → 명령 기록을 방지하려는 목적.
BPFDoor 파일 삭제(hex 기반) T1070.004 (File Deletion) Base16 인코딩된 rm -f /var/run/haldrund.pid → 파일 삭제를 은닉하여 수행 → 지표 제거 목적의 은폐된 삭제.
BPFDoor 파일 생성 T1480.002 (Execution Guardrails: Mutual Exclusion) BPFDoor는 /var/run/kdevrund.pid, /var/run/haldrund.pid, /var/run/syslogd.reboot, /var/run/xinetd.lock 등의 파일을 중복 실행 방지용으로 생성

해당 필터들은 실제 분석된 BPFDoor 샘플의 동작과 시스템 로그에서 나타나는 패턴을 기반으로 하여 작성되었으며, 로그 기반 탐지와 행위 기반 정합성 검증을 동시에 수행할 수 있도록 설계되었습니다.

⚠️ 주의: 탐지 필터의 구체적인 정규 표현식이나 차단 명령어는 보안상 이유로 공개하지 않으며, 본 문서에서는 탐지 전략의 개념적 접근만을 설명합니다.

이를 통해 단일 이벤트가 아닌 TTP 조합을 탐지할 수 있는 고급 필터링 체계를 구성하였으며, 실제 운영 환경에서는 이러한 매핑 기반 탐지를 통해 은밀한 백도어 행위를 효과적으로 탐지할 수 있었습니다.

5.3 TID 기반 탐지 필터의 실시간 EDR 대응 연계

앞서 정리한 BPFDoor에 대한 TID 매핑을 바탕으로 설계한 탐지 필터는 EDR과 연동하여 실시간 대응이 가능하도록 구성되었다. 필터에 의해 의심 행위가 탐지되면, 다음과 같은 방식으로 탐지 즉시 대응이 이루어지도록 구성하였습니다.

  • 임시 파일 및 PID 파일 생성에 대한 대응

BPFDoor는 감염 이후, /dev/shm, /var/run 등의 디렉터리에 임시 실행 파일 또는 PID 파일을 생성하여 중복 실행을 방지하고, 실행 상태를 은닉하려는 경향이 있습니다. 이러한 파일은 정상 시스템 운영 시 생성되는 파일들과 유사한 형태를 띠기 때문에, 단순한 경로 기반 필터링으로는 탐지가 어렵습니다.

이에 따라 다음과 같은 조건에 기반한 탐지 및 자동 차단 로직을 적용하였습니다:

  • 특정 경로에 존재하는 의심 파일명 패턴이 로그에 등장할 경우,

  • 해당 파일을 자동으로 백업한 후 즉시 삭제하여,

  • 사후 분석을 지원하면서도 감염 확산을 사전에 차단할 수 있도록 구성

  • 위장된 프로세스 탐지 및 종료

BPFDoor는 시스템 내에서 console-kit-daemon, udevd, hald-runner 등 정상적인 데몬 프로세스를 위장해 실행됩니다. 겉으로 보기에는 정상 프로세스로 오인될 수 있으나, 명령행 인자나 실행 경로를 분석하면 비정상적인 패턴을 확인할 수 있습니다.

이에 따라 다음과 같은 조건을 기준으로 탐지 및 대응하도록 설계하였습니다:

  • 의심스러운 프로세스 이름과 명령행 인자가 특정 패턴과 일치할 경우 탐지

  • 로그에서 해당 프로세스의 PID를 자동 추출하고,

  • 실시간으로 종료하는 스크립트를 실행하여 은폐된 악성 프로세스를 즉시 차단

  • 정상 프로세스 위장 실행 차단

BPFDoor는 qmgr -l -t fifo -u와 같은 명령행 인자를 사용해, 실제 Postfix 구성요소처럼 보이도록 위장하는 방식도 활용합니다. 이러한 위장은 표면적으로 정상적인 명령처럼 보이기 때문에, 일반적인 탐지 기준만으로는 우회될 가능성이 높습니다.

이에 따라 다음과 같은 탐지 및 차단 절차를 구성하였습니다:

  • 실행 중인 프로세스 목록에서, 정규식 기반으로 위장된 인자 패턴을 탐지

  • 일치하는 항목의 PID를 자동 추출한 후,

  • 해당 프로세스를 즉시 종료하여 후속 악성 동작을 원천 차단

  • 비대칭 암호화 유출 차단

BPFDoor는 scp, sftp 등과 같은 비 C2 프로토콜 기반의 전송 도구를 악용하여 외부로 데이터를 유출하는 방식을 사용할 수 있습니다. 이러한 명령은 SSH 기반 비대칭 암호화를 활용하기 때문에, 보안 장비에 의한 내용 분석이 어렵고 평문 탐지나 트래픽 분석 우회가 가능한 특징이 있습니다.

특히 scp는 운영 환경에서 정상적으로도 자주 사용되기 때문에, 단순 명령어 탐지 기준만으로는 오탐 가능성이 매우 높습니다. 이에 따라 실행 경로, 명령어 인자, 호출 패턴을 기준으로 한 정규식 기반 정밀 탐지 로직이 필요합니다.

이에 따라 다음과 같은 탐지 및 차단 절차를 구성하였습니다:

  • 로그에서 scp, sftp 등의 명령어가 비정상 경로에서 호출되는 패턴 탐지 (/usr/bin/scp 외 호출 등)
  • 정규식 조건과 일치하는 커맨드라인 인자 존재 시 프로세스 ID 자동 추출
  • 탐지된 프로세스를 즉시 종료하여 데이터 유출 행위를 선제적으로 차단

이처럼 BPFDoor의 은폐된 동작에 대응하는 탐지 필터와 실시간 차단 체계를 MITRE ATT&CK 전술·기법에 기반하여 구성함으로써, 단순 이벤트가 아닌 공격자의 행위 전체 흐름(TTP)을 식별하는 고도화된 대응이 가능해집니다.

이를 바탕으로, BPFDoor 설치 이전의 초기 침투 단계에서도 다수의 탐지 기회가 존재했음을 확인할 수 있으며, 각 탐지 요소는 ATT&CK 매핑을 통해 체계적으로 분류되고 대응될 수 있습니다.

정리: MITRE ATT&CK 매핑의 의미

  • BPFDoor가 설치·활동했다면, 그 이전 단계(웹셸 업로드, OS 명령 실행, 권한 상승 등)에서도 충분히 탐지할 수 있었을 이벤트들이 발생했을 가능성이 높습니다.
  • MITRE ATT&CK은 이 일련의 단계를 표준화해 조직 보안팀이 놓쳤거나 취약했던 지점을 빠르게 파악·개선하도록 돕습니다.
  • 최종적으로 BPFDoor를 막는 것은 중요하지만, 초기 침투(Initial Access)와 실행(Execution)을 사전에 차단했다면 피해를 크게 줄였을 것이라는 관점에서, MITRE ATT&CK 매핑이 큰 가치를 가집니다.

6. 보안팀을 위한 현실적 대응 전략 (웹 공격 관점)

일반적으로 웹 애플리케이션 보안강화, WAF 설정, 서버 하드닝, BPFDoor 탐지·차단, 침해사고 대응 프로세스 마련이라는 다섯 가지 방법론이 표준 해법처럼 제시되곤 합니다. 그러나 실제 기업·기관에서 정보보안을 전담하기는 쉽지 않습니다. 개발자·운영자·보안 담당자가 각각 다른 우선순위를 가지고 있고, 인력과 예산이 부족한 상황에서는 아래와 같은 현실적인 어려움이 발생합니다.

참고: 마이터 어택(MITRE ATT&CK) 관점에서 보면, BPFDoor가 최종 설치·동작하기 전 단계(Initial Access, Execution, Privilege Escalation 등)에서 충분히 탐지 가능한 이벤트들이 일어났을 것이 자명합니다. 그럼에도 보안팀이 이를 놓쳤다는 것은 아래와 같은 현실적 여건—인력 부족, 부서 간 우선순위 충돌, 솔루션 방치—때문에 APT 공격 흐름을 감지·차단하는 데 실패했음을 시사합니다.

1) 정보보안 운영의 현실적인 어려움

  • 현장 인력 부족
    대부분 IT 부서가 개발, 인프라 운영, 사용자 지원 등 업무에 과도하게 몰려 있어, “보안만 전담하는 팀”을 별도로 두기 어렵습니다. 공격 징후가 발생해도 즉각적인 모니터링이나 사고 조치가 잘 안 이루어지는 이유입니다.

  • 장비·솔루션 도입 후 방치
    WAF, IDS 같은 장비가 도입되어 있어도, 규칙 업데이트·로그 분석이 제때 이루어지지 않으면 유명무실합니다. 공격자는 최신 RCE 취약점을 활용하지만, 조직은 6개월 전 시그니처에 머물러 있는 경우가 흔합니다.

    • 마이터 어택 시사점: ‘Initial Access(TA0001)’ 단계에서 수많은 공격 시도가 로그에 남았을 텐데, 솔루션이 제대로 운영되지 않아 탐지·분석이 이뤄지지 못했을 가능성이 높습니다.

  • 웹 애플리케이션 업데이트 속도
    WebLogic, Tomcat, CMS 등은 패치 주기가 잦고, “N데이 취약점”이 하루아침에 터지기도 합니다. IT 인력이 충분치 않으면 이런 업데이트를 따라가기 벅찹니다.

    • 마이터 어택 시사점: 공격자가 T1190(Exploit Public-Facing Application)을 이용했다면, 패치 누락이 주요 원인일 가능성이 큽니다.

2) 보안 담당자 vs. 시스템 운영·개발자 간 우선순위 불일치

  • 개발 일정 vs. 보안 점검
    개발자는 기능 구현과 배포 속도를 중시하지만, 보안 담당자는 “코드 리뷰, 침투 테스트, 업로드 필터링” 등을 요구할 수 있습니다. 배포 일정이 촉박하면 보안 점검이 후순위로 밀려나거나 생략됩니다.

    • 마이터 어택 시사점: 예컨대 웹셸 업로드 시나리오(T1190 하위)가 막히려면 업로드 필터나 WAF 룰이 갖춰져야 하는데, 개발 일정 우선순위에 밀려 적용하지 못했을 수 있습니다.

  • 서비스 가용성 vs. 하드닝
    운영자는 “서비스 중단 없는 24/7 가용성”을 목표로 하지만, 보안 담당자는 “SELinux 강화나 /dev/shm noexec 옵션” 같은 하드닝을 강조합니다. 하드닝은 운영 리스크(호환성 문제)를 유발해 서로 충돌이 생깁니다.

    • 마이터 어택 시사점: Persistence(TA0003) 관점에서, /dev/shm noexec 옵션만 적용되었어도 BPFDoor 파일이 실행되지 않았을 가능성이 있습니다.

  • 장비 정책 충돌
    WAF 규칙을 너무 빡빡하게 잡으면 정상 트래픽까지 차단되어 운영 부서가 불만을 제기합니다. 반대로 규칙을 느슨하게 하면 보안 취약점이 커집니다. 이런 이견 차이를 매번 수동으로 조율하기엔 시간과 전문성이 부족합니다.

    • 마이터 어택 시사점: Execution(TA0002) 단계에서 의심스러운 명령 패턴을 WAF가 차단해야 하나, 느슨한 정책 때문에 놓쳤을 수 있습니다.

3) 다중∙계층 보안, 역효과가 더 클 수 있다

“보안 솔루션은 많을수록 좋다”는 믿음으로 다양한 보안 제품(WAF, IDS, IPS, EDR, NDR 등)을 겹겹이 도입하는 경우가 있습니다.
하지만 복잡성이 커질수록, 전체 시스템의 동작 원리를 완전히 이해하는 사람이 아무도 없는 상황이 발생합니다.
결국 보안을 위한 설계가 오히려 보안의 사각지대를 만드는 아이러니를 낳게 됩니다.

  1. 솔루션 간 충돌·비효율

    • 각 제품마다 API 연동이나 로그 포맷이 달라, 일관성 있는 관제가 어렵습니다.
    • 경보(이벤트) 관리가 중복되거나 분산되어, 정작 중요한 위협 신호를 놓칠 가능성이 커집니다.

  2. 성능 부담·예산 분산

    • 여러 개의 에이전트를 깔면 서버 리소스가 과도하게 소모되고, 라이선스·유지보수 비용이 중복 발생합니다.
    • 그 결과, 중요 자산을 보호하는 핵심 역량에 충분한 예산과 인력을 투입하기 어려워집니다.

  3. 알람 피로(Alert Fatigue)

    • 서로 다른 솔루션이 동시에 경보를 쏟아내면, 보안 담당자는 오탐까지 모두 확인해야 하며, 업무 과중과 집중력 저하로 이어집니다.
    • 결국 실제 침입 시도(T1190, T1059.004 등)를 제때 대응하지 못할 위험이 커집니다.

결론: 다중∙계층 보안 모델이 항상 나쁜 선택은 아닙니다.
하지만 그 한계와 비용, 인력 부담을 명확히 인식하고, 이를 통합 솔루션으로 보완하는 전략이 반드시 필요합니다.

이처럼 보안 솔루션이 분산되어 있으면, 일관된 관제와 즉각적인 대응이 사실상 불가능해지며,
결과적으로 APT 공격의 초기 이벤트(웹셸 업로드·RCE 등)조차 놓칠 위험이 큽니다.

따라서, 한정된 인력과 예산으로 실질적인 방어 역량을 확보하려면, 다중∙계층 보안보다는 ‘통합’ 중심의 전략을 먼저 고려해야 합니다.

💡 결국, 통합 정보보안 플랫폼(PLURA-XDR) 도입이 올바른 선택

이러한 인력·시간·전문성 한계와 부서 간 의견 충돌 문제로 인해, APT 공격 전 단계(웹셸 업로드, 권한 상승 등)에서 충분히 감지할 기회를 놓친다면, BPFDoor 같은 스텔스 백도어가 최종 설치되는 시점에는 이미 피해가 클 수밖에 없습니다. 이를 예방하려면, 여러 보안 기능을 단일 플랫폼에서 종합적으로 운영·관리하는 통합 정보보안 플랫폼이 필수적입니다. 특히 PLURA-XDR(Extended Detection & Response)이 최고의 선택지입니다.

아래는 PLURA-XDR이 WAF 정책이 느슨한 환경에서도 초기 단계 공격을 어떻게 보완·탐지해줄 수 있는지를 강조한 문단 예시입니다. “원론적으로 이번 공격을 초기부터 탐지했을 것”이라는 메시지를 담았으며, 마이터 어택 관점에서 왜 PLURA-XDR이 사전 인지가 가능한지 구체적으로 설명합니다.

요컨대, PLURA-XDR 같은 통합 플랫폼은 기존 분산된 보안 솔루션으로 인해 발생하는 사일로(Silo) 문제와 전문인력 부족을 극복하게 합니다. 정보보안 담당자 한두 명이 최소한의 리소스로도 다양한 공격 벡터(웹셸, RCE, 권한 상승, 파일 무결성 훼손 등)를 실시간으로 모니터링·차단할 수 있으므로, 마이터 어택 관점에서 여러 공격 단계를 사전에 인지할 수 있고, 실제 조직 보안 수준이 체감적으로 올라갑니다.

특히 WAF 정책이 느슨하거나 규칙 업데이트가 늦어져서 파일 업로드 공격이나 RCE 페이로드를 걸러내지 못하는 상황에서도, PLURA-XDR은 웹 요청 본문(HTTP Body)과 서버 내부 행위(EDR)를 행위 기반으로 연계 분석하여 초기 침투(Initial Access) 시점부터 이상 징후를 포착할 가능성이 큽니다. 예컨대,

  1. 웹 서버 로그에서 “shell.jsp 업로드”와 같은 패턴을 감지,
  2. 이어서 shell_exec() 또는 system() 호출이 발생,
  3. 프로세스 생성 이벤트(실시간 EDR)에서 권한 상승(T1068) 시도가 관찰 하는 식으로 APT 공격 흐름을 단계별로 잡아낼 수 있습니다. 결과적으로, 마이터 어택 상 Execution(TA0002)와 Privilege Escalation(TA0004) 단계에서 이미 경고를 발생시킬 수 있으므로, BPFDoor가 설치되는 Persistence(TA0003) 단계 이전에 정확하게 탐지해 낼 여지가 충분합니다.

정리: PLURA-XDR은 WAF나 IPS가 놓칠 수 있는 초기 공격(RCE·웹셸 업로드)조차 통합 탐지해주므로, “원론적으로 이번 공격도 초기 단계부터 추적했을 것”이라고 평가할 수 있습니다. 만약 PLURA-XDR이 도입·운영되고 있었다면, 웹셸 호출 흔적이나 권한 상승 시도를 단계별로 알림받아, BPFDoor 같은 스텔스 백도어가 설치되기 전에 선제 대응을 했을 가능성이 높습니다.

결론

  • IT 현장에서 웹 공격 방어(애플리케이션 보안, WAF 설정, 하드닝, 백도어 탐지, 침해 대응 프로세스)라는 표준 방법론은 중요하지만, 현실적인 인력·예산·조직 구조를 고려하면 쉽지 않습니다.
  • MITRE ATT&CK 초기 침투~전개 단계에서 이미 여러 징후가 있었음에도 보안팀이 놓쳤다면, 이는 결국 부서 간 우선순위 불일치와 솔루션 운영 부실 탓일 수 있습니다.
  • 통합 정보보안 플랫폼이 그 간극을 메워줄 수 있습니다. PLURA-XDR을 통해 웹셸·RCE 공격부터 BPFDoor 같은 스텔스 백도어 감지까지, 단일 인터페이스로 일관성 있게 관리하는 것이 궁극적인 해법이라 할 수 있습니다.

7. PLURA-XDR 정보보안 통합 플랫폼: 웹 요청 본문 분석을 통한 추가 방어

앞서 제시한 웹 공격 대응 전략(웹 애플리케이션 보안강화, WAF 활용, 서버 하드닝, BPFDoor 탐지/차단, 침해사고 대응 프로세스 확립)만으로도 기본적인 방어 체계를 구축할 수 있습니다. 그러나 최근 APT 공격에서는 웹 요청을 교묘히 위장하거나 파일 업로드를 암호화하여 전통적 규칙 기반 솔루션(WAF, IPS)을 우회하는 사례가 많아졌습니다. 이때 웹 요청 본문(HTTP Body) 분석까지 수행하는 PLURA-XDR 같은 통합 보안 플랫폼이 큰 도움이 될 수 있습니다.

7.1 PLURA-XDR의 핵심 기능

  1. 다계층 이벤트 연계(Extended Detection & Response)

    • PLURA-XDR은 네트워크, 엔드포인트, 클라우드, 웹 트래픽 등 다양한 이벤트를 통합 분석하여, 단편적 징후가 아닌 행위 기반(Behavior-based) 상관관계로 공격을 식별합니다.
    • 예: 웹서버의 HTTP Body 이상행위 + /dev/shm 내 악성 파일 실행 + 특정 C2 IP 접속이 연쇄적으로 감지되면, 고위험 공격이라고 바로 판단해 알림을 발생시킵니다.

  2. HTTP Body/Payload 고급 분석

    • 일반적인 WAF/IPS는 URI, 헤더, 쿠키 위주로 검사하지만, PLURA-XDR은 HTTP Body(파일 업로드, POST 데이터) 내용을 심층 분석해 의심 명령어, 웹셸 코드를 식별할 수 있습니다.
    • 예: Base64로 인코딩된 JSP 웹셸 스니펫이 Body에 포함되어 있는지, 스크립트로 의심되는 난독화 문자열이 있는지 AI·패턴 매칭을 결합해 실시간 탐지.

  3. Zero-day 위협 탐지(행위 기반 룰)

    • 시그니처 기반 방식을 넘어서, “POST 바디에 쉘 명령어 패턴이 보임”, “업로드된 파일 내부에 JSP/PHP 문법” 등 행위형 룰을 설정 가능.
    • 웹셸·RCE 취약점이 알려지지 않았더라도, PLURA-XDR은 명령 패턴/프로세스 실행 흐름에서 이상 징후를 탐지해 선제적으로 차단할 수 있습니다.

  4. 자동 대응(Automated Response)

    • 위험도가 높은 이벤트(예: shell.jsp 업로드 시도 + 서버 내부 쉘 실행) 감지 시, PLURA-XDR이 자동으로 IP 차단, 프로세스 격리, 알림 발송 등을 수행.
    • 별도의 보안 인력이 24시간 모니터링하기 어려운 환경에서도 즉각적 방어를 제공.

7.2 웹 요청 본문 분석이 중요한 이유

  • 파일 업로드 기반 웹셸: 일반 WAF가 확장자 .jsp, .php만 검사한다면, 공격자는 .jpg 등으로 위장 + Body 내용에 JSP 코드를 넣어 통과할 수 있습니다. PLURA-XDR은 실제 Body 내부를 열어, 스크립트/명령어 패턴을 탐지할 수 있음.
  • 복잡한 RCE 페이로드: 공격자들은 Log4Shell 같은 취약점을 노릴 때, 요청 본문에 JNDI URL이나 역직렬화 페이로드를 숨겨 전송합니다. 이때 PLURA-XDR은 다단계 분석을 통해 Request Body에 숨어 있는 조작된 객체, 난독화 문자열 등을 인지.
  • HTTP/2, SSL, HTTP Chunked 등 다양한 프로토콜 변형에도 대응: PLURA-XDR은 SSL/TLS 트래픽 복호화 및 HTTP 스펙 변형 처리까지 제공하면, 공격자가 특수 인코딩을 이용한 우회 시도를 줄일 수 있습니다.

7.3 PLURA-XDR 도입 시 기대 효과

  1. 웹셸·RCE 실시간 감지 및 차단

    • 기존 WAF와 달리, 심층 본문 분석 + 행위 기반 룰을 결합하여 의심스러운 업로드, 특정 명령어 삽입 시나리오를 곧바로 차단.
    • 웹셸이 업로드되더라도, PLURA-XDR이 서버 엔드포인트(EPP/EDR)와 연계해 프로세스 실행을 실시간 모니터링하므로, 추가적 루트 권한 상승 시도도 탐지.

  2. BPFDoor 같은 은밀한 백도어 탐지

    • BPFDoor는 커널 레벨 BPF 소켓 필터를 사용하지만, 결국 C2 통신은 ICMP/TCP를 통해 발생. PLURA-XDR이 네트워크 트래픽 + 호스트 프로세스 활동을 통합 시나리오로 분석하여 은밀한 C2를 드러낼 수 있음.
    • 예: iptables 규칙이 순간적으로 변경되고(Host EDR 이벤트), 직후 특정 ICMP Ping에 패킷이 삽입되는 흐름(Network D&R 이벤트)을 연계 인지.

  3. 종합 위협 인텔리전스 적용

    • PLURA-XDR은 보안 정보(SIEM), 위협 인텔리전스(Threat Intelligence)를 통합 관리하므로, BPFDoor IOC(매직 바이트, C2 IP 등)나 최신 RCE 익스플로잇 패턴을 자동 업데이트해 공격을 더 빠르게 방어할 수 있음.

  4. 자동화된 포렌식 및 보고

    • 침해사고가 의심되는 시점에서 PLURA-XDR 콘솔에서 관련 이벤트(HTTP 요청, 파일 실행, 프로세스 생성, 네트워크 연결)를 자동으로 수집·시각화.
    • 사고 직후 신속히 공격 경로를 재현하고, 유출 범위를 추산할 수 있어 대응 시간을 크게 단축.

7.4 요약: PLURA-XDR로 웹 공격 방어 체계 업그레이드

  • PLURA-XDR은 기존의 WAF, IPS, EDR 등을 한데 묶는 통합 플랫폼으로, 웹 요청 본문 분석 같은 고급 기능을 통해 웹셸·RCE 공격을 정밀 차단한다.
  • 특히 망분리 환경에서도 80/443 포트가 열려 있다면(2023년 1월, LGU+ 해킹에서 웹셸 사용 사례처럼), PLURA-XDR이 웹 트래픽을 철저히 검사함으로써 침입 루트를 봉쇄할 수 있다.
  • 추가적인 커널·엔드포인트 모니터링(BPFDoor·root킷 탐지), 자동화된 Incident Response(IP 차단, 프로세스 격리) 기능까지 제공하므로, APT급 공격에 강력한 방어 효과를 기대할 수 있다.

결론적으로, PLURA-XDR과 같은 정보보안 통합 플랫폼을 통해 웹 트래픽 본문 분석(Body Inspection)을 수행하면, 웹셸·RCE 공격의 숨은 페이로드를 찾기 수월해지고, 실제 서버 내부에서 발생하는 행위(백도어 설치, 시스템 명령어 호출)까지 연동 관제할 수 있습니다.
이는 SKT 해킹 사건처럼 BPFDoor 등 고도화된 APT 공격을 막는 실질적 방어력으로 이어질 것입니다.

8. 결론

  • 이번 SKT 해킹 사례를 웹 공격(웹셸·RCE) 중심으로 해석하면, 공격자는 인터넷 노출된 웹 서비스를 발판 삼아 HSS 서버에 침투하고, BPFDoor를 설치하여 장기 거점을 확보했을 개연성이 높습니다.
  • 망분리 환경에서도 80/443 웹 포트는 거의 유일한 통로: 2023년 1월, LGU+ 해킹에서는 웹셸 사용 사례처럼, DMZ에서 내부망으로 향하는 연결은 웹서비스(80/443)정도만 열려있는 경우가 많습니다. 이는 공격자가 웹셸·RCE를 노려 침투·측면이동하는 주요 원인이 됩니다.
  • BPFDoor는 후속 은닉 수단: 웹 기반 초기 침투로 얻은 저권한 셸을 통해 root 권한을 획득한 뒤, BPFDoor를 투입해 스텔스성과 장기성을 극대화한 것입니다.

가설적 결론:

  1. SKT HSS 서버는 웹셸 or RCE를 통한 초기 장악 후,
  2. BPFDoor로 은밀히 C2를 구축,
  3. USIM/가입자 데이터 탈취로 이어졌을 가능성이 매우 높다.
    다른 경로(계정 탈취, 내부자 연루 등)도 배제할 수 없지만, 웹 공격이 가장 흔한 침투 벡터임을 고려하면, 본 시나리오는 충분히 합리적이다.

향후 검증 필요성:

  • 실제 로그·포렌식 정보가 추가 공개돼야 최종 경로를 확정 지을 수 있으나,
  • 기업망 침해사고의 절대다수는 웹 공격이라는 업계 경험칙을 고려하면, 본 가설이 맞을 확률은 상당히 높다고 할 수 있음.

마이터 어택(MITRE ATT&CK) 관점의 전술·기법별 대응 시스템(웹 요청 본문 분석, 이벤트 로그 추적, 권한 상승 모니터링 등)을 사전에 구축하지 않았다는 점은, 이번 공격을 초기 침투~BPFDoor 설치 단계에서 막지 못한 결정적인 원인이라 할 수 있습니다.
만약 보안팀이 PLURA-XDR 같은 통합 보안 플랫폼을 도입하여 웹 요청 본문부터 ATT&CK 전술·기법까지 연계 관제하고, 저권한 셸 획득(Execution)이나 권한 상승(Privilege Escalation) 같은 중간 이벤트를 실시간 감시했더라면, BPFDoor 은닉 백도어가 설치되기 이전에 충분히 경고를 받고 대응할 수 있었을 것입니다.

최종 제언

  • 웹셸 및 RCE 공격이 대규모 침해사고의 주력 통로라는 전제하에, 기업·기관은 웹 취약점 관리, 파일 업로드 통제, WAF 운영 등을 최우선 보안과제로 삼아야 합니다.
  • 침입 이후 BPFDoor 같은 스텔스 백도어가 설치되면 탐지·차단이 매우 까다로우므로, 초기 진입 자체를 봉쇄하는 것이 가장 효과적인 방법입니다.
  • 만일 침입이 감지되면 메모리 기반 포렌식 및 행위 모니터링을 통해 BPFDoor나 유사 악성코드 은닉을 철저히 수색해야 합니다.
  • PLURA-XDR 같은 통합 보안 플랫폼을 도입하면, 웹 요청 본문 분석은 물론 MITRE ATT&CK 단계별 탐지를 실시간으로 연계할 수 있어, 초기에 웹셸·RCE 공격을 차단하고 BPFDoor 설치 이전에 경고를 받을 수 있습니다.
  • 이번 SKT 사건을 교훈 삼아, 중요 서버(특히 통신·금융·공공 등 기간망)에 대한 웹 공격 방어와 리눅스 보안 강화가 시급하다는 점을 재확인해야 합니다.

📺 함께 시청하기

📖 함께 읽기

🆙 PLURA 업데이트 안내

Tags