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) 중심이다“라는 가설을 전제로 작성하였습니다.

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

물론 실제로는 계정 탈취, 내부자 악용 등의 다른 수단도 있을 수 있으나, 본 글에서는 웹셸·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를 설치했을 가능성이 높다.”

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

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

  1. 취약점 식별

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

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

    1. 웹셸 업로드: .php, .jsp 같은 악성 스크립트를 업로드 → /uploads/… 등 경로에서 직접 호출 → 서버 내부 명령 실행.
    2. 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 매핑은 사실상 업계 표준. 다른 조직·사건과 비교·분석하기 쉽고, 정보 공유도 수월.

상세 매핑 항목

1. Initial Access (TA0001)

  • Exploit Public-Facing Application (T1190)

    • 웹 RCE 취약점 공격: 공격자가 인터넷에 노출된 웹 서버(예: WebLogic, Tomcat 등)에 존재하는 RCE 취약점을 악용해 원격 코드 실행에 성공.
    • 의의: 대부분 APT 공격에서 가장 많이 발생하는 초기 침투 형태 중 하나. 망분리 환경이라도 80/443 포트는 열려 있으므로, 공격자가 이를 발판으로 내부망까지 진입 가능.

  • Drive-by Compromise (T1189) 또는 WebShell Upload (T1190의 하위 사례)

    • Drive-by Compromise: 보통 사용자가 악성 웹사이트를 방문해 감염되는 경우이지만, 여기서는 서버 측에서 “웹셸 업로드”가 발생할 수 있음.
    • WebShell Upload: 업로드 기능이 있는 웹 애플리케이션에 .jsp, .php 스크립트를 삽입해 웹셸을 생성.
    • 의의: 업로드 취약점으로 웹셸이 설치되면, 공격자는 서버 상에서 임의 명령을 실행할 수 있게 됨.

2. Execution (TA0002)

  • Command-Line Interface (T1059.004)

    • 웹셸 호출 시, shell_exec() 등으로 실제 OS 명령어 구동: JSP/PHP의 시스템 호출 함수를 이용해 쉘(commands)을 실행.

    • 의의: 공격자는 파일 탐색, wget/curl로 추가 악성코드 다운로드, 퍼미션 변경 등 모든 OS 명령을 원격에서 수행할 수 있음.

    • 예시:

      • system("uname -a"), shell_exec("cat /etc/passwd") 등.

3. Persistence (TA0003)

  • 웹셸 자체는 HTTP 요청만 있으면 재실행 가능

    • 특정 URL(예: /uploads/shell.jsp)에 접근할 때마다 웹셸 코드가 실행 → 재부팅하더라도 파일이 지워지지 않는 한 반영구적으로 사용 가능.

  • BPFDoor는 별도 디스크 등록 없이 메모리에 상주

    • /dev/shm 등 임시 디렉토리로 복사 후 원본 삭제.
    • 의의: 파일리스(fileless) 특성을 극대화해, 포렌식 시 발견이 어려움.

주의: 웹셸은 HTTP GET/POST만 있으면 언제든 실행된다. BPFDoor는 서버가 재부팅되지 않으면 계속 상주. 둘 다 Persistence에 해당하나, 실장 방식이 다름.

4. Privilege Escalation (TA0004)

  • Exploitation for Privilege Escalation (T1068)

    • 커널 취약점, SUID, sudo misconfig 등을 악용하여 관리자(root) 권한 획득.
    • 의의: 웹서버 기본 계정(tomcat, www-data)은 권한이 제한적이므로, 공격자는 추가적인 루트 권한 확보가 필요. 이 단계 성공 시 BPFDoor 같은 고급 백도어 설치도 자유로워짐.

주의: “웹셸=곧바로 root”가 아니라, 대부분 낮은 권한이므로 권한 상승이 중간에 꼭 필요.

5. Defense Evasion (TA0005)

  • 웹셸: 파일 확장자 우회, MIME 헤더 위장

    • 공격자는 .jsp 파일을 .jpg 혹은 .php.jpg로 업로드, MIME 헤더 조작으로 보안 솔루션을 우회.
    • 의의: 단순 확장자 필터로는 차단 어려우며, 심층 본문 분석 필요.

  • BPFDoor:

    • 파일 삭제 (T1070.004): /dev/shm/kdmtmpflush 원본 삭제로 디스크 흔적 제거.
    • 타임스템핑 (T1070.006): utimes()로 변경 시간을 조작, 오래된 정상 파일처럼 위장.
    • 프로세스 위장 (T1036): prctl()로 프로세스 이름·인자를 정상 데몬(systemd-journald 등)처럼 보이게 함.
    • 의의: 백도어가 존재해도, 관리자나 보안 솔루션이 쉽게 눈치채지 못함. 은밀성을 극대화.

6. Command and Control (TA0011)

  • BPFDoor: Traffic Signaling (T1205.002), Non-standard port (T1571), Encrypted Channel (T1573)

    • Traffic Signaling(T1205.002): 소켓 필터를 이용한 매직 패킷 감시 → “매직 바이트” 패턴이 일치해야만 통신 채널 생성.
    • Non-standard port(T1571): ICMP, TCP 등 관습적이지 않은 포트나 패킷을 사용. 방화벽 우회 목적.
    • Encrypted Channel(T1573): RC4 등 커스텀 암호화로 C2 트래픽을 평문 감추고, 침입방지솔루션(IPS) 탐지를 어렵게 함.
    • 의의: 일반 C2(80/443 포트 고정 리슨)와 달리, BPFDoor는 “수동형” 백도어. 포트 스캐닝으로 찾기 매우 어려움.

7. Exfiltration (TA0010)

  • 공격자 셸(웹셸 or BPFDoor 역방향 셸)에서 DB 파일을 압축·전송

    • 대량의 가입자 정보(예: USIM 인증키, IMSI, 전화번호)를 DB 덤프로 만든 뒤, HTTP·FTP·DNS 등 다양한 방식으로 외부로 빼돌림.
    • 의의: APT 공격의 마지막 단계로, 금전적·정보 수집 목적 달성. SKT 사건에서 2,300만건 유심 정보가 유출된 것으로 추정.

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 난독화/암호화된 스크립트, 실행 파일 사용

정리: 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 사건을 교훈 삼아, 중요 서버(특히 통신·금융·공공 등 기간망)에 대한 웹 공격 방어와 리눅스 보안 강화가 시급하다는 점을 재확인해야 합니다.

📺 함께 시청하기

📖 함께 읽기

Tags