SKT 해킹으로 본 NDR 기술 한계: BPFDoor 같은 스텔스 공격 대응법

By PLURA 2025-05-02

📡 NDR(Network Detection and Response)은 네트워크 트래픽을 분석해 위협을 탐지하려는 기술입니다.
하지만 최근 SK텔레콤 유심 해킹 사건에서 다시 주목받은 BPFDoor 같은 고도화된 스텔스형 공격 앞에서는 분명한 구조적 한계를 드러냅니다.

본 문서는 다음 기사에 대응하고자 작성되었습니다.

이데일리 - 기존 보안으론 못 막아… 잇단 대형 해킹에 스텔스 위협 대응 촉구

이 글에서는 스텔스형 공격이 왜 기존 NDR 방식만으로는 탐지하기 어려운지 분석하고, 그 한계를 현실적으로 보완하려면 어떤 접근이 필요한지 정리합니다.

NDR 한계

1. 최근 스텔스형 공격의 특징

BPFDoor – 매직 패킷을 받기 전까지 ‘포트리스(portless)’ 상태로 은폐
Symbiote – 리눅스 정상 프로세스에 기생하는 루트킷으로, /proc와 각종 시스템 조회 결과를 조작해 존재 자체를 숨김
LummaC2 – 난수형 주기와 TLS 암호화 기반 C2 통신으로 네트워크 시그널을 최소화

이들의 공통점은 단순하지 않습니다.
단순히 “패턴이 약하다”는 수준이 아니라, 탐지에 필요한 시그널 자체를 줄이거나 없애는 방향으로 설계돼 있다는 점이 핵심입니다.

즉, 전통적인 시그니처 기반 보안은 물론이고, 네트워크 흐름 분석 중심의 탐지 체계에도 근본적인 부담을 줍니다.

2. NDR 기술의 명확한 한계 (요약)

구분	한계점	핵심 이유
① 패킷 부재로 인한 가시성 제로(0)	포트리스(portless)·매직 패킷 구조 → 관찰할 트래픽 자체가 없음	NDR·IDS가 전제하는 ‘보이는 패턴’이 애초에 존재하지 않음
② 행위 기반 통계 의존 한계	흐름 길이·세션 주기 등 미세 통계치에 의존	정상 세션까지 위협으로 오인(오탐) ↔ 패턴 부재 상황에선 미탐 → 경보 피로(alert fatigue) 가중
③ 시그널 제거·왜곡형 공격	BPFDoor·Symbiote·LummaC2 등 행위 시그널 자체를 없애거나 변조	NDR이 탐지해야 할 입력값이 사라져 탐지 논리 자체가 무력화

3. NDR 기술의 명확한 한계 (상세)

🔍 1) ‘패킷 부재’로 인한 탐지 불가능

포트리스(portless) 설계 – 서비스 포트가 열려 있지 않아 NDR·IDS·IPS가 관찰할 표본 패킷 자체가 없음
커널 영역 eBPF 훅으로 트래픽을 스니핑한 뒤 사용자 공간을 우회, 흔적 최소화
작동 조건은 공격자가 보내는 매직 패킷 단 한 번 → 평상시에는 정상 트래픽과 사실상 구분되지 않는 침묵 상태

NDR은 “패턴이 존재해야 탐지할 수 있다”는 가정 위에서 작동합니다.
하지만 BPFDoor는 그 전제를 정면으로 깨뜨립니다.
관찰 가능한 세션이 거의 없거나, 있어도 지속적이지 않기 때문에 네트워크 장비 입장에서는 분석할 입력 자체가 부족합니다.

🔍 2) 네트워크 행위 기반 탐지의 오·미탐 한계

흐름 길이, 세션 주기, 통신 빈도 같은 미세 통계치에 의존하면 정상 세션까지 위협으로 오인 → 오탐
반대로 패턴 부재 상황에서는 모델 입력이 사라져 미탐 발생
경보 피로(alert fatigue)가 누적돼 SOC의 대응 속도와 정확도가 함께 떨어짐

네트워크 행위 기반 탐지는 일부 영역에서 유용할 수 있으나,
본질적으로 오탐(false positives) 과 미탐(false negatives) 의 긴장 위에 서 있습니다.
특히 정상 업무 트래픽과 차이를 거의 드러내지 않는 스텔스 위협에서는,
경계를 민감하게 하면 오탐이 늘고, 보수적으로 하면 미탐이 늘어나는 구조적 딜레마가 생깁니다.

🔍 3) 탐지 우회형 공격 대응 불가능

BPFDoor — 매직 패킷 전까지 포트 오픈·DNS 질의 ZERO
Symbiote — 호스트 내부 /proc, 라이브러리 호출, 시스템 조회 결과를 조작해 분석자의 시야를 왜곡
LummaC2 — 난수형 주기 + TLS 암호화 비콘으로 시간·패턴 시그널 제거

이들 스텔스 백도어와 루트킷은 NDR이 의존하는 행위 시그널 자체를 제거하거나 왜곡합니다.
결국 아무리 정교한 NDR이라도, “거의 드러나지 않는 세션” 혹은 “은폐된 세션”을 탐지해야 하는 논리적 한계에 부딪힐 수밖에 없습니다.

4. 한계를 극복하는 현실적 대안: 네트워크 밖까지 보는 접근

문제의 핵심은 단순합니다.
네트워크에서 보이지 않는 공격을, 네트워크만으로 찾으려 하기 때문입니다.

특히 BPFDoor처럼 포트리스·매직 패킷 구조를 활용하는 공격은 네트워크 경계 장비의 관찰 면적 밖에서 오래 잠복할 수 있습니다.
여기에 TLS 1.3, QUIC 같은 암호화 확산까지 겹치면, 패킷 기반 관찰만으로는 위협의 실체를 파악하기가 더욱 어려워집니다.

따라서 필요한 것은 NDR을 버리는 것이 아니라, NDR이 보지 못하는 계층을 함께 관찰하는 것입니다.
이 지점에서 필요한 것이 엔드포인트, 애플리케이션, 로그를 함께 보는 통합형 XDR 접근입니다.

✅ PLURA-XDR의 통합 접근

1) 애플리케이션 로그로 “네트워크 밖의 흔적”을 본다

스텔스 공격은 패킷을 줄일 수는 있어도, 실제 침해 목적을 수행하는 과정에서는 흔적이 남습니다.

예를 들어,

웹 요청·응답 본문 변화
비정상 인증 시도
권한 상승 이후의 관리 기능 호출
데이터 조회·유출 징후

같은 기록은 네트워크 장비만으로는 충분히 보이지 않을 수 있지만,
애플리케이션 로그와 웹 로그에서는 더 선명하게 드러날 수 있습니다.

2) 엔드포인트 행위에서 은폐 이전과 이후를 추적한다

BPFDoor, Symbiote 같은 계열은 결국 호스트 내부에서 실행됩니다.
따라서 다음과 같은 호스트 행위 로그가 중요해집니다.

비정상 프로세스 실행
권한 상승 및 계정 사용 패턴 변화
커널/유저 영역 은폐 시도
비정상 파일 접근 및 지속성 확보 흔적

네트워크가 조용하더라도, 프로세스·계정·파일·시스템 호출 수준의 변화는 남기 쉽습니다.
즉, 스텔스 공격 대응은 “패킷을 더 정교하게 보는 문제”만이 아니라, 호스트에서 무슨 일이 일어났는지를 함께 보는 문제입니다.

3) 개별 이벤트가 아니라 ‘연결된 흐름’으로 본다

스텔스 공격은 이벤트 하나만 봐서는 정상처럼 보이기 쉽습니다.
하지만 서로 다른 계층의 이벤트를 연결하면 의미가 달라집니다.

예를 들어,

웹에서 드문 요청 발생
직후 서버에서 비정상 프로세스 실행
이후 특정 계정 권한 사용 증가
이어서 외부 통신 혹은 데이터 접근 증가

이런 흐름은 각각 따로 보면 약한 신호일 수 있습니다.
하지만 웹·시스템·행위 로그를 함께 상관 분석하면 “하나의 침해 시나리오”로 읽히기 시작합니다.

4) 제로데이 대응의 출발점은 시그니처가 아니라 기록이다

알려지지 않은 공격은 시그니처만으로는 대응이 어렵습니다.
결국 중요한 것은 공격 이름을 먼저 맞히는 것이 아니라,

어떤 행위가 일어났는지
어떤 계정이 사용됐는지
어떤 프로세스가 실행됐는지
어떤 데이터 접근이 뒤따랐는지

를 실시간으로 기록하고 연결해서 해석할 수 있는가입니다.

이 점에서 PLURA-XDR의 의미는 “NDR을 대체한다”가 아니라,
NDR이 놓치는 구간을 로그·엔드포인트·애플리케이션 가시성으로 메운다는 데 있습니다.

5. 정리: 스텔스 공격 시대에는 관찰 범위를 넓혀야 한다

스텔스형 위협 시대에는 NDR만으로 완전한 대응을 기대하기 어렵습니다.
그 이유는 단순한 성능 부족이 아니라, 애초에 관찰 대상이 사라지거나 왜곡되는 공격이 존재하기 때문입니다.

따라서 현실적인 방어 전략은 다음과 같습니다.

네트워크 트래픽은 계속 보되,
그것만 믿지 말고,
엔드포인트·애플리케이션·로그까지 함께 보아야 합니다.

BPFDoor 같은 공격이 던지는 메시지는 분명합니다.
이제는 “패킷을 얼마나 잘 보느냐”보다,
보이지 않는 구간까지 어떻게 기록하고 연결하느냐가 더 중요합니다.

PLURA-XDR은 바로 이 지점에서,
NDR이 놓치기 쉬운 스텔스 구간을 엔드포인트·애플리케이션·로그 상관 분석으로 보완하는 현실적 접근이 될 수 있습니다.