침해 탐지

열린 문 없이 돌아오는 해커, BPFDoor 이야기

열린 포트만 살펴서는 놓칠 수 있는 백도어가 있어요. BPFDoor가 패킷을 기다리는 방식과 의심 신호를 해석하는 기준을 알아봐요.

이 글의 목차청진기를 도청기로 바꾼 백도어5
  1. 청진기를 도청기로 바꾼 백도어
  2. 2022년, 그림자에 이름이 붙다
  3. 2025년, 보안 용어가 일상 뉴스가 되다
  4. ‘의심’은 판결문이 아니다
  5. 저는 이 이름을 어떻게 만났나

다시 돌아올 생각이 있는 도둑은 매번 창문을 깨지 않아요. 담장 뒤에 작은 문을 만들고 화분으로 가려 둬요. 침입 자체보다 오래 남는 것은 그 문이고, 서버 침해에서도 조사의 무게중심은 어떻게 들어왔는가보다 무엇을 남겨 두었는가에 실려요.

수신 방식에 따른 포트 목록 가시성 전용 LISTEN 소켓이 없는 수신 경로는 포트 목록에 BPFDoor 항목을 남기지 않는다. 개념 도해 수신 방식에 따른 포트 목록 가시성 패킷 수신 경로 ① 패킷 도착 ② RAW 소켓 ③ BPF 조건 일반 패킷 조건 불일치 수신기 제외 매직 패턴 조건 일치 명령 통로 포트 목록 가시성 LISTEN 등록선 전용 LISTEN 전용 소켓 등록 목록 표시 RAW 소켓 · BPF 패킷 직접 수신 새 항목 없음 수신 경로 전용 LISTEN 소켓이 없는 수신 경로는 포트 목록에 BPFDoor 항목을 남기지 않는다. SOSHIN · DEV NOTES
BPFDoor는 평소 전용 포트를 열지 않고, 패킷 사이에서 약속된 신호만 기다려요.

컴퓨터를 침입한 공격자도 이런 길을 남겨요. 정상적인 로그인과 보안 검사를 건너뛰고 다시 들어오기 위한 숨은 통로를 백도어(backdoor)라고 불러요. 백도어가 꼭 화면에 보이는 새 계정이나 활짝 열린 통신 창구의 모습인 것은 아니에요. BPFDoor는 문을 드러내는 대신, 집 안에 귀를 숨겨 놓고 밖에서 들려올 약속된 신호를 기다렸어요.

청진기를 도청기로 바꾼 백도어

BPFDoor의 BPF는 Berkeley Packet Filter의 약자예요. 오가는 네트워크 데이터에서 필요한 것만 골라 관찰하는 기술이에요. 네트워크 데이터는 패킷(packet)이라는 작은 묶음으로 나뉘어 이동해요. 관리 도구는 BPF로 특정 종류의 패킷만 살펴 통신 문제를 찾을 수 있어요. BPF 자체가 악성 기술은 아니에요.

필터 조건에 따른 패킷 선별 BPF 필터는 정상 트래픽을 흘려보내고 약속된 매직 패턴과 맞는 패킷만 수신기에 남긴다. 개념 도해 필터 조건에 따른 패킷 선별 패킷 선별 경로 정상 트래픽과 약속된 신호 TCP DNS MAGIC UDP ① RAW 소켓 ② BPF 조건 조건 일치 ③ 매직 패킷 조건 불일치 선별 제외 필터 판정 결과 BPF 조건선 일반 패킷 조건 불일치 제외 매직 패킷 조건 일치 수신기 전달 판정 경로 BPF 필터는 정상 트래픽을 흘려보내고 약속된 매직 패턴과 맞는 패킷만 수신기에 남긴다. SOSHIN · DEV NOTES
BPF 자체는 정상 기술이에요. 실행 주체와 목적을 확인해야 진단 도구와 공격 수신기를 구분할 수 있어요.

BPFDoor는 이 관찰 기능을 악용했어요. 네트워크 패킷을 낮은 단계에서 살펴보는 RAW 소켓(raw socket)을 만들고 BPF 필터로 대부분의 패킷은 넘겼어요. 대신 미리 약속한 모양의 패킷을 기다렸죠. 이를 매직 패킷(magic packet)이라고 불러요. 특정 데이터를 신호로 삼아 동작을 시작한다는 뜻이에요.

보통 외부 연결을 받는 프로그램은 포트(port)라는 번호가 붙은 접수 창구를 열어 둬요. 그래서 서버 점검은 어떤 포트가 열려 있고 누가 쓰는지 확인하는 데서 자주 시작해요. 하지만 BPFDoor는 잠들어 있는 동안 자기 전용 포트를 열어 두지 않았어요. 이미 서버로 들어오는 패킷 사이에서 비밀 노크를 찾았기 때문에, 열린 창구만 세는 일반적인 점검으로는 숨어 있는 존재를 놓칠 수 있었어요. 신호를 받은 뒤에야 공격자가 명령을 내릴 통로를 만들었어요.

2022년, 그림자에 이름이 붙다

이 백도어는 이름을 얻기 전부터 움직이고 있었어요. 보안 컨설팅 기업 PwC는 2021년 사이버 위협 회고 보고서에서 그해 여러 침해 사고를 추적하며 발견한 맞춤형 백도어를 BPFDoor라고 불렀어요. PwC가 중국 기반 공격 집단으로 추적한 ‘Red Menshen’은 중동과 아시아의 통신사를 비롯해 정부, 교육, 물류 분야 조직을 노렸어요. 통신사는 수많은 사람의 연결 정보가 모이는 곳이어서 감시와 정보 수집을 노리는 공격자에게 가치가 컸어요.

2022년 5월 7일 보안 연구자 Kevin Beaumont가 BPFDoor를 세계 곳곳에서 활동해 온 감시 도구로 소개했고, 나흘 뒤 보안 업체 Sandfly는 공개된 소스 코드를 바탕으로 작동 방식을 해부한 기술 분석을 내놓았어요. 분석 속 BPFDoor는 메모리에 머물며 정상 시스템 프로그램처럼 이름을 꾸몄고, BPF 필터로 특별한 패킷을 기다렸어요. 공격 명령이 오기 전까지 눈에 띄는 통신과 컴퓨터 자원 사용을 줄이는 구조였어요.

여기서 최초 침입과 다시 들어오는 통로를 구별해야 해요. 공격자가 먼저 필요한 권한을 얻어 프로그램을 심고 실행해야 이런 동작이 가능해요. BPFDoor가 있다는 이유만으로 네트워크 바깥의 모든 차단까지 사라지는 것도 아니에요. 신호가 감염된 호스트에 도달할 길은 필요해요. 열린 리슨 포트가 없다는 관찰만으로 안전하다고 결론 낼 수 없다는 것이 이 사례의 핵심이에요.

2025년, 보안 용어가 일상 뉴스가 되다

2025년 4월 국내 대형 통신사가 악성코드로 유심 관련 정보가 유출된 정황을 발견했다고 고객에게 알렸어요. 유심(USIM)은 이동통신망이 가입자를 식별하고 서비스를 연결하는 데 필요한 정보를 다루는 작은 카드예요. 낯선 악성코드 이름은 유심 교체와 개인정보 유출이라는 생활 문제에 연결되면서 일반 뉴스에도 등장했어요.

7월 4일 민관합동조사단이 발표한 최종 조사 결과는 공격의 시간을 2021년까지 거슬러 올라가 재구성했어요. 공격자는 2021년 8월 다른 백도어로 첫 거점을 만든 뒤, 그해 12월부터 통신 인증 관련 서버에 BPFDoor를 심었어요. 이후 몇 년 동안 악성코드를 다시 설치하거나 갱신했고, 2025년 4월 유심 정보를 외부로 빼냈어요. BPFDoor 하나가 사고의 전부는 아니었지만, 오래 숨어 있던 공격 통로의 상징 같은 이름이 됐어요.

조사단은 전체 서버 42,605대를 살펴 28대에서 감염을 확인했고, 발견한 악성코드 33종 가운데 27종을 BPFDoor 계열로 분류했어요. 외부로 유출된 것은 가입자 식별번호인 IMSI를 포함한 유심 정보 25종, 약 2,696만 건이었어요. IMSI(International Mobile Subscriber Identity)는 통신망이 가입자를 구별할 때 쓰는 번호예요. 몇 년 동안 조용히 기다릴 수 있는 백도어가 왜 통신사 같은 기반 시설에서 특히 위험한지 보여 준 사건이었어요.

사건 시점에 따른 침해 가시성 침입, 설치, 공개 분석, 유출 발견은 서로 다른 시점의 기록으로 이어졌다. 개념 도해 사건 시점에 따른 침해 가시성 사건 재구성 경로 ① 2021.08 첫 거점 ② 2021.12 BPFDoor 설치 ③ 2022.05 공개 분석 ④ 2025.04 유출 발견 시간 순서 시점별 가시성 2025.04 · 사고 발견 서버 내부 BPFDoor 흔적 · 2021.12부터 개별 사고 확인 공개 정보 작동 방식 분석 · 2022.05부터 시간 순서 침입, 설치, 공개 분석, 유출 발견은 서로 다른 시점의 기록으로 이어졌다. SOSHIN · DEV NOTES
최초 침입과 BPFDoor 설치, 외부 공개, 정보 유출 발견은 서로 다른 시점에 일어났어요.

‘의심’은 판결문이 아니다

숨는 악성코드를 찾는 도구는 이미 알려진 파일 이름만 확인할 수 없어요. 공격자가 이름과 모양을 조금만 바꾸면 놓치기 때문이에요. 그래서 자동 실행 흔적, 낯선 BPF 필터와 RAW 소켓, 특정 포트처럼 공격에서 자주 보이는 행동도 함께 표시해요. 문제는 정상적인 네트워크 프로그램과 관리 도구도 같은 행동을 할 수 있다는 점이에요.

점검 결과의 ‘Suspicious’, 곧 ‘의심’은 감염 확정이 아니라 조사를 시작하라는 표시예요. 정상 동작을 공격으로 잘못 잡은 결과를 오탐(false positive)이라고 해요. 경고를 무시해서도 안 되지만 경고 개수만으로 침해를 선언해서도 안 돼요.

판단을 가르는 것은 신호 자체가 아니라 그 신호에 붙은 맥락이에요.

확인할 것정상일 때 보이는 모습의심을 키우는 모습
그 동작을 만든 실행 파일패키지 관리자가 설치한 경로에 있다임시 디렉터리에 있거나 삭제된 상태로 떠 있다
프로세스의 이름과 실제 명령둘이 일치한다흔한 시스템 이름을 쓰지만 명령행이 다르다
그 통신을 여는 시점부팅이나 배포 시각과 맞는다설명되지 않는 시각에 혼자 생겼다

같은 신호라도 이 세 줄이 어느 쪽으로 읽히느냐에 따라 결론이 반대가 돼요. 그래서 자동 점검의 출력은 판정이 아니라 질문 목록으로 다뤄야 해요.

저는 이 이름을 어떻게 만났나

통신사 사고 뒤 저도 관리하던 리눅스 환경에서 BPFDoor의 흔적을 살폈어요. 자동 점검은 낯선 BPF 필터와 열린 통신 창구를 의심 신호로 표시했어요. 조용한 서버 안에서 드디어 숨은 문을 찾은 것처럼 보였어요.

점검 범위에 따른 BPFDoor 가시성 전용 포트가 없는 BPFDoor는 LISTEN 목록이 아니라 RAW 소켓과 BPF 필터의 실행 맥락에서 드러난다. 개념 도해 점검 범위에 따른 BPFDoor 가시성 점검 경로 포트 기준 ① LISTEN 목록 ② 열린 포트 전용 포트 없음 미검출 행위 기준 ① RAW 소켓 ② BPF 필터 ③ 실행 주체·용도 판별 가능 관찰 범위 전용 포트 RAW 소켓 BPF 필터 실행 맥락 열린 포트 점검 조회 미포함 미포함 미포함 수신 행위 점검 없음 조회 조회 조회 관찰 대상 전용 포트가 없는 BPFDoor는 LISTEN 목록이 아니라 RAW 소켓과 BPF 필터의 실행 맥락에서 드러난다. SOSHIN · DEV NOTES
자동 점검의 경고는 실행 주체와 원래 용도를 확인한 뒤에야 의미가 분명해졌어요.

하나는 운영체제의 기본 네트워크 기능이 주변 장비와 정보를 주고받기 위해 만든 정상적인 BPF 필터였어요. 다른 하저도 통신 창구의 주인을 따라가 보니 관리 작업에 쓰이는 정상 연결이었어요. 공격 도구와 비슷한 행동이 보였지만, 누가 왜 만들었는지를 확인하자 맥락은 완전히 달라졌어요.

확인한 신호들은 모두 정상 동작이었어요. 다만 그 확인에 걸린 시간이 문제로 남았어요. 어떤 프로세스가 왜 그 필터를 만들었는지 아는 사람이 없어서, 정상임을 밝히는 데 반나절이 들었어요.

그래서 그 뒤에 한 일은 탐지 규칙을 더 얹는 것이 아니라 평소 상태를 적어 두는 쪽이었어요. 어느 서버에서 무엇이 리슨하고 어떤 관리 도구가 어떤 통신을 여는지가 문서로 있으면, 같은 경고를 다음에 볼 때 비교할 기준이 생겨요. 침해 조사에서 가장 비싼 것은 탐지 도구가 아니라 정상이 무엇이었는지 모르는 상태였어요.

소신을 상징하는 까마귀 목판화 일러스트
작성자소신 · Soshin

웹과 서버를 만들고, 개발하며 배운 것들을 글로 남깁니다.

좌우로 움직여 보세요