Detailed Analysis of BPFDoor targeting South Korean Company

Author: S2W TALON

First Published : Apr 30, 2025
Last Modified : May 13, 2025

Photo by Andrey Volk on Unsplash

Executive Summary

• (Threat Hunting) S2W의 위협 연구 및 인텔리전스 센터 TALON은 최근 국내 기업을 대상으로 유포된 BPFDoor 악성코드를 확인하여 분석을 진행함.
• (Malware) BPFDoor는 BPF(Berkeley Packet Filter) 기술을 악용하여 고도화된 은닉성과 탐지 회피 기능을 통해 리눅스 시스템 내 장기 은닉을 목표로 하는 악성코드임.
  - BPFDoor는 리버스 셸 연결 및 명령어 실행을 지원하는 백도어 악성코드로, TCP/UDP/ICMP 프로토콜을 통해 비표준 통신을 수행함.
  - 통신 시 필터에 정의된 매직 시퀀스를 활용하여 정상 트래픽에 은닉하며, 포트 개방 없이 패킷 수신이 가능하도록 설계되어 있음.
• (Key Features) BPFDoor는 BPF(Berkeley Packet Filter)를 악용하여 커널 레벨에서 특정 트리거 패킷만 수신하며, 229개의 BPF Instruction Set을 사용함.
  - BPFDoor의 버전에 따라 Instruction Set의 개수 및 매직 시퀀스가 일부 다르게 나타남.
  - 프로세스 이름 위장 및 데몬화, 메모리 기반 복제 및 실행 은닉, 히스토리 기록 차단 등 다양한 Anti-Forensic 기술을 적용함.
• (Attribution) BPFDoor는 2021년 PwC에 의해 최초로 명명된 악성코드로, 중국 배후의 APT 그룹 Earth Bluecrow(Red Menshen)의 사용이 확인됨.
  - 현재까지 Earth Bluecrow 이외의 그룹에 의해 사용된 정황은 발견되지 않았으며, 통신 패턴과 사용된 매직 시퀀스(0x5293, 0x39393939, 0x7255)가 일관되게 나타남.
  - 공격자는 측면 이동 및 장기 은닉을 위해 BPFDoor를 지속적으로 활용하는 것으로 분석됨.
• (Mitigation) S2W는 이번 침해사고에 사용된 BPFDoor 샘플과 변종을 탐지할 수 있는 YARA 룰을 별도로 제공함.
  - BPF 필터 조회, 매직 시퀀스 검색, Salt 문자열 탐지, 포트 개방 점검 등을 통한 사전 감염 탐지가 권장됨.
  - 리눅스 서버 운영 시 비정상적인 소켓 연결 모니터링과, 실행 파일 위변조 및 프로세스 이름 변조 여부에 대한 주기적 점검이 필요함.

Introduction

최근 국내외 통신 업계를 대상으로 한 BPFDoor 악성코드의 공격 빈도가 증가하고 있다. 2025년 4월 25일, 한국인터넷진흥원(KISA)은 주요 시스템을 겨냥한 BPFDoor 악성코드 유포 사례를 확인하고 이에 대한 보안 권고문을 발표하였다.

• 참고자료: 최근 해킹공격에 악용된 악성코드, IP 등 위협정보 공유 및 주의 안내
• 참고자료: 최근 해킹공격에 악용된 악성코드 위협정보 공유 및 주의 안내 (2차)

BPFDoor는 2021년 PwC에 의해 처음 명명 및 공개된 악성코드로, BPF(Berkeley Packet Filter) 기술을 악용하여 탐지를 회피하고 사용자 공간에서 직접 패킷을 수신할 수 있도록 설계되었다. 해당 악성코드는 TCP, UDP, ICMP 등 다양한 프로토콜을 지원하고, 비표준 방식으로 통신을 수행함으로써 탐지를 더욱 어렵게 한다. 이러한 고도화된 은폐성과 지속성 확보를 통해 BPFDoor는 리눅스 시스템 내에서 장기간 은닉 활동을 이어갈 수 있다. 특히, BPFDoor 악성코드의 소스코드는 2022년에 Github에 업로드 되기도 하였다.

표 1. BPFDoor 악성코드 버전에 따른 특징

BPF는 원래 운영체제 커널 레벨에서 동작하는 경량화된 가상 머신(Virtual Machine) 기술로, 다양한 훅 지점에서 안전하게 바이트코드를 실행할 수 있도록 설계되었다. 특히 네트워크 인터페이스를 통해 수신되는 패킷에 대해 커널 공간에서 직접 필터링 조건을 적용함으로써, 불필요한 패킷을 사용자 공간으로 전달하지 않고 효율적으로 처리할 수 있는 구조를 제공한다. 이러한 구조는 시스템 성능과 보안성을 모두 향상시키는 데 기여하며, 관측 도구 및 다양한 보안 솔루션에서 널리 활용되고 있다. 그러나 이 같은 기능이 악성코드에 의해 악용될 경우, 탐지 회피와 은닉성 강화 수단으로 작용할 수 있다.

S2W 위협 연구 및 인텔리전스 센터(TALON)는 2024년 4월, BPFDoor 악성코드의 특징과 동작 방식에 대해 선제적으로 공개한 바 있다. 본 보고서에서는 최근 국내 기업을 대상으로 유포된 BPFDoor 악성코드 사례를 중심으로, 악성코드의 상세 동작 원리와 이를 탐지 및 대응하기 위한 방안을 체계적으로 분석하고자 한다.

Detailed Analysis

그림 1. BPFDoor의 동작 흐름

1. BPFDoor Controller

• MD5: a8c54d5b028714be5fdf363957ab8de2
• SHA256: 1925e3cd8a1b0bba0d297830636cdb9ebf002698c8fa71e0063581204f4e8345

BPFDoor Controller는 침해된 서버에서 측면 이동(Lateral Movement)을 수행하거나, 동일 네트워크 내 다른 감염된 호스트에 접근하기 위해 사용되는 악성코드다. 현재까지는 중국계 APT 그룹인 Earth Bluecrow(일명 Red Menshen)에 의해 독점적으로 사용된 것으로 알려져 있다.

Controller는 실행 시 설정된 16개의 옵션에 따라 통신 프로토콜, Remote IP, Port 번호 등을 설정하며, -o 또는 -x 옵션을 통해 별도의 매직 시퀀스 값을 지정할 수도 있다. Trend Micro 보고서에 따르면 Controller가 지원하는 전체 옵션은 16개지만, 공개된 샘플에서는 14개의 옵션이 확인되었다.

표 2. BPFDoor Controller 옵션 목록(*Bold: 추가된 옵션)

TCP Mode

BPFDoor Controller의 TCP 모드에서는 감염된 호스트와 통신하기 위해 매직 시퀀스 0x9352가 포함된 TCP 패킷을 전송한다. IP 및 TCP 헤더를 직접 구성하여 sendto() 함수를 통해 전달하는 Raw 소켓 방식을 사용하며, 이러한 방식으로 인해 일반적인 TCP 세션을 수립하지 않는다. 이를 통해 방화벽이나 침입 탐지 시스템(IDS/IPS)의 탐지를 효과적으로 우회할 수 있다. 또한 BPFDoor 백도어는 매직 바이트 기반 식별 방식을 사용하여 정상 트래픽에 섞여 은밀하게 명령을 수신할 수 있도록 구성되어 있다. 패킷 전송 후 소켓을 종료하며, 만약 direct 모드가 활성화된 경우 추가로 리버스 셸 연결을 시도한다.

UDP Mode

-d 옵션을 사용하는 경우, Controller는 UDP 프로토콜을 통해 감염된 호스트와 통신한다. 이때 UDP 소켓을 생성한 뒤, 고정된 24바이트 크기의 패킷을 지정된 대상 IP 및 포트로 전송한다. 패킷에는 전역 변수로 관리되는 매직 시퀀스 0x5572와 원격 제어를 위한 메타데이터(IP 주소 및 포트)가 포함된다. 전송이 완료되면 소켓을 정리하고 종료한다.

ICMP Mode

-i 옵션이 지정되면, Controller는 ICMP Echo Request 패킷을 생성하여 전송한다. 이 과정에서는 socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)를 호출해 Raw 소켓을 생성하며, 실패 시 즉시 종료한다. 패킷 생성 시 ICMP 타입을 8(Echo Request)로 설정하고, 본문에 매직 시퀀스 0x5572를 삽입한다. Identifier 필드에는 상수값 1234, Sequence Number 필드에는 현재 프로세스 ID를 저장하여 세션 구분이 가능하도록 한다.

모든 필드를 설정한 뒤 체크섬을 계산하고, 설정된 목적지 호스트로 패킷을 전송한다. 성공 시 소켓을 닫고 종료하며, 실패할 경우 오류 메시지를 출력한다. ICMP 모드는 TCP/UDP 포트를 사용하지 않기 때문에, 일반적인 네트워크 탐지 시스템을 효과적으로 우회할 수 있다.

Set Password

BPFDoor Controller는 감염된 호스트와 TCP 연결을 수립한 뒤, 매직 시퀀스, Remote IP, Port 번호, 그리고 비밀번호를 포함하는 페이로드를 전송한다. 이때 비밀번호 문자열은 최대 14바이트로 제한되며, 전송된 비밀번호의 해시 값이 BPFDoor 샘플에 하드코딩된 해시 값과 일치해야 명령 처리가 가능하다.

공개된 소스코드에서는 기본 비밀번호가 justforfun으로 설정되어 있지만, 최근 유포된 샘플에서는 공격자가 지정한 비밀번호와 BPFDoor 악성코드 내 하드코딩된 Salt 문자열을 조합하여 생성한 MD5 해시 값을 비교하는 방식으로 변경되었다.

• Hash(1): 73b9989bb8dd522b8e172f2e985810eb
• Hash(2): d46bf5d43cffd7793665d40fc767ed86

Reverse Shell

BPFDoor Controller는 감염된 호스트와 연결 직후 “3458” 문자열의 수신 여부를 확인한다. 이 값은 통신 암호화 여부를 결정하는 데 사용된다. 이후 소켓과 터미널 간 양방향 데이터 송수신을 처리하며, 터미널 크기 변경 이벤트 또한 지원하여 자연스러운 원격 시스템 조작이 가능하게 한다. 통신이 종료되면 소켓을 닫고 터미널 상태를 원복하는 구조로 되어 있다.

공개된 BPFDoor 소스코드에는 “3458” 문자열을 전송하는 코드가 포함되어 있었으나, 최근 발견된 변종에서는 Remote IP로 해당 문자열을 전달하는 로직이 삭제된 것으로 나타났다.

2. BPFDoor

• Filename: smartadm
• MD5: 227fa46cf2a4517aa1870a011c79eb54
• SHA256: 3f6f108db37d18519f47c5e4182e5e33cc795564f286ae770aa03372133d15c4

2.1. Create Mutex File

BPFDoor는 “/var/run/hald-smartd.pid” 파일이 존재하거나, 해당 파일에 접근(읽기)할 수 있는지 확인한다. 파일이 존재하거나 접근이 가능한 경우, 이미 BPFDoor 프로세스가 실행 중인 것으로 판단하고 프로그램을 종료한다. 이는 전형적인 Mutex(Mutual Exclusion) 방식으로, 동일 프로세스의 중복 실행을 방지하기 위한 목적을 가진다. Mutex 파일명은 샘플에 따라 다르게 나타난다.

• Filepath: /var/run/hald-smartd.pid

2.2. Check Priviledge

현재 실행 중인 프로세스의 User ID를 확인하고, 반환된 값이 0(root)인지 검사한다. 이는 프로세스가 루트 권한으로 실행되고 있는지를 확인하는 과정으로, 루트 권한을 보유한 경우에만 이후 동작을 수행한다. 즉, BPFDoor는 이미 권한 상승이 완료된 상태에서 실행되고 있음을 전제로 한다.

공개된 소스코드에서는 루트 권한 확인 이후 하드코딩된 명령어를 통해 자가복제를 수행하지만, 분석 대상 샘플에서는 해당 자가복제 함수 호출 부분이 제거되어 있다.

그림 2. 공개된 BPFDoor 소스코드(좌) / 최근 발견된 BPFDoor(우)

2.3. Change Process Name

BPFDoor는 실행 중인 프로세스의 이름을 하드코딩된 값으로 변경한다. 공개된 소스코드 상에서는 하드코딩된 중 랜덤하게 설정된 이름을 사용하였지만, 최근 발견된 BPFDoor 악성코드는 샘플마다 하드코딩된 프로세스명이 1개 존재한다.

• Changed name: /usr/sbin/smartd -n -q never

표 3. 공개된 소스코드에 하드코딩된 프로세스 명 목록

BPFDoor는 다음 두 가지 레벨에서 프로세스 이름을 변경한다:

메모리 상 실행 인자(argv) 변경

• argv[0] 값을 덮어써서 실행 중인 프로세스의 인자 목록을 수정한다.
• 이에 따라 cat /proc/[pid]/cmdline 명령어로 확인할 때, 덮어쓴 새로운 프로세스 이름이 표시된다.

그림 3. 변경된 BPFDoor 프로세스명(1)

커널 레벨 프로세스 이름 변경

• prctl() 함수를 호출하여 커널에서 관리하는 프로세스 이름을 변경한다.
• 다만, prctl로 설정할 수 있는 프로세스 이름은 최대 15바이트로 제한되므로, 실제로는 /usr/sbin/smart까지만 적용된다.

그림 4. 변경된 BPFDoor 프로세스명(2)

2.4. Daemonization

BPFDoor는 이후 자신을 데몬 프로세스로 전환한다. 이 과정에서 fork() 함수를 호출해 자식 프로세스를 생성하고, 자식 프로세스의 작업 디렉토리를 루트(/) 경로로 변경한다.

또한, 표준 입력(stdin), 표준 출력(stdout), 표준 오류(stderr)를 /dev/null로 리다이렉션하여 사용자로 하여금 입출력이나 오류 메시지를 인지할 수 없게 만든다.

BPFDoor는 프로세스 종료 시 Mutex 파일을 삭제하기 위한 종료 핸들러를 설정한다. 운영체제나 사용자가 프로세스 종료를 요청할 때 발생하는 SIGTERM 시그널을 수신하면, 초기 저장된 PID와 현재 PID가 일치하는 경우에만 Mutex 파일을 삭제하고 즉시 종료하도록 설계되어 있다. 이를 통해 시스템에 추가적인 흔적을 최소화한다.

2.5. Create Mutex File

이후, 실행 중인 프로세스의 PID를 확인하고 앞서 언급한 Mutex 파일을 새롭게 생성한다. Mutex 파일은 소유자 읽기/쓰기, 그룹 및 기타 사용자 읽기 권한(0644)으로 생성되며, 파일 내에는 별도의 데이터가 기록되지 않는다. 이 파일은 BPFDoor 악성코드의 실행 여부를 나타내는 표시로 사용된다.

2.6. Connect Reverse Shell

2.6.1. Set BPF Filter

BPFDoor는 수신 패킷을 필터링하기 위해 BPF(Berkeley Packet Filter)를 설정한다. 수신한 네트워크 패킷이 설정된 필터를 통과할 경우에만 응답 루틴이 활성화된다.
이 필터는 Linux Classic BPF 규격을 따르며, 각 BPF Instruction Set는 다음과 같은 구조를 가진다:

• code (2 bytes) : BPF 명령어 (예: LD, JEQ, RET 등)
• jt (1 byte) : 조건이 참일 경우 점프할 오프셋
• jf (1 byte) : 조건이 거짓일 경우 점프할 오프셋
• k (4 bytes) : 비교 또는 로드할 상수값

분석 대상 샘플에서는 총 229개의 BPF Instruction Set가 정의되어 있었으며, 이는 Trend Micro에서 언급한 BPFDoor.D 버전에서 확인된 필터 구조와 동일한 것으로 나타났다.

그림 5. BPF Filter

BPFDoor는 소켓에 BPF 필터를 attach하여 수신 패킷을 선별한다. 소켓 생성 시 socket() 함수의 두 번째 인자로 0x80002 (SOCK_DGRAM | SOCK_NONBLOCK) 값을 사용하여 Ethernet 헤더를 제외한 IP 패킷만 수신한다. 이후 recvfrom(fd, buf, 0x400, 0, 0, 0) 함수를 통해 수신된 버퍼에는 IP 패킷이 저장된다.

BPFDoor는 수신된 IP 패킷의 헤더 길이가 최소 20바이트 이상인지 검증하며, 이 기준을 만족하지 않는 패킷은 모두 무시한다. 유효한 IP 헤더를 가진 패킷이 확인되면, 이를 기반으로 통신 프로토콜을 파싱하고, 식별된 프로토콜에 따라 이후 동작을 분기하여 수행한다.

표 4. BPF Instruction set 의사코드

2.6.2. Dissecting the IP Header and Protocol Handling

BPFDoor는 수신된 IP 패킷을 파싱하여 통신 프로토콜을 식별하고, 프로토콜에 따라 패킷 해석 방식을 달리한다.

TCP

통신 프로토콜이 TCP인 경우, TCP 페이로드 시작 지점에서 26바이트 오프셋 위치에 존재하는 값을 확인하여 0x39393939와 일치하는지 검사한다. 만약 해당 값이 존재할 경우, 이후 TCP 페이로드 내에서 0D0A0D0A(\r\n\r\n) 구분자를 찾아, 구분자 이후의 데이터를 최종 페이로드로 추출한다. 반면, 0x39393939가 존재하지 않는 경우에는 TCP 페이로드의 시작 지점부터 전체를 최종 페이로드로 간주한다.

이처럼 26바이트 오프셋에 삽입된 매직 시퀀스(0x39393939)는 과거 Trend Micro 보고서에서도 언급된 바 있다.

UDP 및 ICMP

UDP 또는 ICMP 프로토콜인 경우, IP Header 이후 위치한 데이터를 그대로 페이로드로 사용한다.

2.6.3 Set Remote IP

공개된 Controller를 사용했을 때 BPFDoor에서 수신한 페이로드는 다음과 같이 구성되어 있다. 페이로드 내 오프셋 0x4 위치에는 리버스 셸 연결에 사용할 Remote IP가 기록되어 있으며, 만약 해당 필드가 비어있거나 유효하지 않은 값으로 설정되어 있는 경우, IP Header의 Source IP를 Remote IP로 대체하여 사용한다.

표 5. BPFDoor에서 수신하는 페이로드 예시

2.6.4. Verify Password

BPFDoor는 비밀번호 검증 결과와 페이로드 상태를 기반으로 주요 동작을 분기한다. 페이로드 내 0xA 오프셋부터 최대 14바이트 길이의 비밀번호 문자열을 추출하고, 고정된 Salt 문자열(I5*AYbs@LdaWbsO)을 앞에 붙여 전체 문자열을 구성한 후 MD5 해시를 계산한다. 계산된 해시는 하드코딩된 두 개의 해시 값과 비교되어 인증 여부를 결정한다.

• Hash(1): 73b9989bb8dd522b8e172f2e985810eb
• Hash(2): d46bf5d43cffd7793665d40fc767ed86

동일한 Salt 문자열을 사용하는 추가 샘플에서 발견된 비밀번호의 해시 값 목록은 아래와 같다.

표 6. 동일한 MD5 Salt 값 사용하는 비밀번호의 해시 값

첫 번째 해시와 일치하면 0을 반환, 두 번째 해시와 일치하면 1을 반환하고, 둘 다 일치하지 않으면 2를 반환한다.

BPFDoor는 다음 두 조건 중 하나라도 만족할 경우 fork()를 호출하여 자식 프로세스를 생성한다.

• 비밀번호 검증 결과가 0이 아닌 경우
• 페이로드 오프셋 24바이트(payload + 6) 값이 -1 또는 0인 경우

만약 비밀번호 검증 결과가 0이고, 페이로드 조건 또한 fork() 조건을 만족하지 않는 경우, 별도의 fork() 없이 바로 공격자 서버로 ICMP Echo Request 패킷을 전송한다. 이 ICMP 패킷은 통신 트리거 역할을 하며, 공격자의 응답을 통해 세션 연결이나 명령 실행이 이어진다.

표 7. ICMP Echo Request

자식 프로세스 생성이 이루어진 경우, 다음과 같은 추가 작업을 수행한다:

• 프로세스 이름을 /usr/libexec/postfix/master로 위장
• 메모리 상 argv 값을 수정하고, prctl() 호출로 커널 레벨에서도 프로세스 이름 변경
• 한 차례 추가 fork()를 수행하여 setsid()를 호출, 새로운 세션 리더로 전환

이후 자식 프로세스는 로그인 결과(mode)에 따라 다음과 같이 동작을 분기한다.

Direct Mode (리턴 값 = 1)

리턴된 값이 1인 경우 Direct Mode로 동작한다. 공격자 IP에서 지정된 포트로 들어오는 TCP 트래픽을 내부의 랜덤 포트(42931~43390 범위)로 리다이렉트하기 위해 iptables 룰을 추가한다. 하드코딩된 명령어는 다음과 같다:

• 지정된 포트로 들어온 트래픽을 내부 랜덤 포트로 REDIRECT
• 공격자 IP에 대한 INPUT ACCEPT 룰 추가

이 방식은 리버스셸 포트가 외부에 직접 노출되지 않아 방화벽/IDS/IPS 탐지를 우회할 수 있다는 장점이 있다. 만약 연결이 실패할 경우, 추가했던 iptables 룰을 삭제한다.

표 8. iptables rules 추가 및 삭제 명령어

Reverse Shell Mode (리턴 값 = 0)

리턴 값이 0인 경우, 페이로드에 포함된 Remote IP 및 포트 정보를 이용하여 직접 Reverse Shell 연결을 시도한다. 별도로 지정된 데이터가 없는 경우에는 기본적으로 TCP 스트림을 통해 연결을 수립한다.

또한, 페이로드 내 특정 오프셋에 추가 데이터가 존재할 경우, 해당 IP를 사용해 ICMP Echo Request를 전송하여 연결을 유도하는 방식도 사용된다.

2.6.5. Reverse Shell

BPFDoor는 리버스쉘 세션을 생성할 때 execve 시스템 콜을 이용하여 /bin/bash를 실행한다. 이때 argv[0]을 “qmgr -l -t fifo -u”로 설정하여, 프로세스 목록 상에서는 정상 시스템 프로세스처럼 위장된다.

추가적으로 다양한 환경 변수도 설정하여 흔적을 최소화하며, 명령어 기록을 차단하고, 분석을 어렵게 만드는 전략을 사용한다.

표 9. 환경 변수 설정

BPFDoor는 리버스셸 통신 시 SSL 기반 암호화를 적용하며, 통신 암호화 여부는 내부 플래그 값에 따라 결정된다.

플래그 값이 1로 설정된 경우, BPFDoor는 프로그램 내부에 포함된 PEM 형식의 X.509 인증서와 RSA 개인키를 사용하여 SSL Context를 생성한다. 사용되는 인증서는 공식 인증 기관(CA)에서 발급된 것이 아니라, 자체 서명(self-signed)된 형태로 프로그램에 내장되어 있다.

SSL Context 설정 과정에서는 인증서와 개인키를 메모리에 로딩한 후, 두 값의 일치성 검증을 수행한다. 검증에 실패할 경우 프로그램은 오류 메시지를 출력하고 즉시 종료되며, 검증에 성공하면 RC4-MD5 암호화 스위트를 사용하여 SSL 핸드셰이크를 완료하고 암호화된 세션을 구축한다.

RC4-MD5는 이미 취약성이 알려진 구식 암호화 알고리즘이지만, BPFDoor는 탐지 회피 및 통신 흐름 은폐를 목적으로, 빠르고 간단한 암호화 채널을 구성하기 위해 이 스위트를 선택한 것으로 추정된다.

반면, 플래그 값이 0으로 설정된 경우에는 인증서나 개인키를 사용하지 않고, SSL 인증서 교환이나 상대방 검증 과정 없이 RC4-MD5 스위트를 기반으로 단순 암호화 채널만을 구축한다. 이 경우에도 통신 내용은 암호화되지만, TLS 통신 본래의 인증 및 무결성 검증 기능은 제공되지 않는다.

결과적으로, BPFDoor의 리버스셸 통신은 SSL 기반 암호화를 통해 명령어 송수신 및 통신 내용을 외부 감시로부터 은폐하도록 설계되어 있다.

표 10. BPFDoor 악성코드 내 하드코딩된 X.509 인증서

Mitigation

BPFDoor 악성코드는 매직 시퀀스(Magic Sequence)로 불리는 특정 값을 BPF 필터에 포함하고 있다. 이를 기반으로 감염된 호스트 내 BPF 필터를 조회하여 특정 바이트 시퀀스의 존재 여부를 확인할 수 있다.

아래 명령어는 Trend Micro에서도 언급된 방법으로, 시스템에 설정된 BPF 필터를 조회하고 매직 시퀀스(0x7255, 0x5293, 0x39393939)를 검색하는 데 사용된다.

또한, 국가정보원과 한국인터넷진흥원은 BPFDoor 감염 여부를 점검할 수 있는 추가적인 방법을 공개하였다. 이들은 BPFDoor가 Controller로부터 수신한 비밀번호를 MD5 해시할 때 사용하는 고유 Salt 문자열을 검색하거나, 감염 시스템 내 특정 포트가 열려 있는지를 확인하는 절차를 제시하였다.

BPFDoor는 실행 시 하드코딩된 정상 프로세스명으로 위장하기 때문에, 프로세스명을 통한 감염 탐지가 일정 부분 가능하다. 그러나 프로세스명은 샘플마다 변경될 수 있고 정상 프로세스명을 악용하는 경우도 있어, 프로세스명만으로는 완전한 탐지가 어려우며, 네트워크 통신, 소켓 상태, BPF 필터 존재 여부 등을 함께 분석하는 행위 기반 탐지가 필요하다.

표 11. BPFDoor 악성코드가 사용한 프로세스 이름

이외에도, S2W는 이번 침해 사고에 사용된 4개의 BPFDoor 샘플을 탐지할 수 있는 YARA 룰과, 다양한 BPFDoor 악성코드의 변종을 탐지할 수 있는 추가 YARA 룰을 Appendix B에 수록하였다.

BPFDoor 점검 도구(1)

2025년 5월 8일, Piolink는 BPFDoor 점검 도구를 공개하였으며, 해당 도구를 통해 감염 여부를 확인 가능하다.

• 참고 링크: BPFDoor 악성코드 점검 도구 배포 안내

Piolink에서 공개한 점검 도구의 기능 및 사용 방법은 아래와 같다.

• 지원 OS: Linux 계열 (CentOS, Ubuntu 등)
• 형식: Shell 스크립트 (.sh)

주요 기능 및 점검 항목

• 공개된 12종의 BPFDoor 악성코드 파일 검사
• 공개된 C2 서버와의 통신 상태 확인
• 의심스러운 프로세스 및 서비스 탐지
• 시스템에 로드된 BPF 관련 프로그램 확인

※ 보안 점검 대상 시스템이 Linux 기반일 경우, 해당 스크립트를 활용한 1차 점검이 유효할 수 있습니다.

사용 방법

1. script.sh에 실행 권한 부여

• Command: $ chmod +x script.sh

2. root 권한으로 실행 (권한이 없을 시 스캔이 제한적으로 동작)

• Command: $ sudo ./script.sh

3. bpftool은 BPFDoor 악성코드 탐지를 위한 부가적인 도구 (*script.sh 파일과 동일 경로에 위치되어야 함)

결과 예시

• 감염 의심 흔적 발견 시 : 경고 메시지 출력
• 결과 파일은 실행된 스크립트 경로에 결과 파일 생성

BPFDoor 점검 도구(2)

2025년 5월 12일, 한국인터넷진흥원은 BPFDoor 악성코드 점검 가이드를 배포하였다.

• 참고 링크: BPFDoor 악성코드 점검 가이드 배포

한국 인터넷 진흥원에서 공개한 BPFDoor 및 BPFDoor Controller의 감염여부 점검 방법은 아래와 같다.

BPFDoor 악성코드 감염여부 점검 방법

• 악성코드 뮤텍스/락(Mutex/Lock) 파일 점검
• 악성코드 자동 실행 파일 점검
• BPF(Berkeley Packet Filter) 점검 (가이드 內 ‘[붙임1] BPF 점검 스크립트’ 활용)
• RAW 소켓 사용 점검
• 프로세스 환경변수 점검 (가이드 內 ‘[붙임2] 환경변수 점검 스크립트’ 활용)
• 특정 포트 확인 및 네트워크 장비를 이용한 패킷 점검

BPFDoor 컨트롤러 감염여부 점검 방법

• 실행 중인 프로세스 명 점검

악성 의심 파일에 대한 추가 점검 방법

• 문자열 기반 초동 점검
• YARA* Rule 기반 점검 (가이드 內 ‘[붙임3] BPFDoor YARA Rule’ 활용)
  * 악성 파일을 시그니처 기반으로 판별 및 분류 할 수 있게 하는 툴

대응방안

• 첨부된 점검 가이드를 참고하여 자체적으로 보안점검 후, 침입흔적 및 침해사고가 확인되면 보호나라를 통해 침해사고 즉시 신고

Conclusion

• S2W의 위협 연구 및 인텔리전스 센터 TALON은 최근 국내 기업을 대상으로 유포된 BPFDoor 악성코드를 확인하여 분석을 진행함.
• BPFDoor는 BPF(Berkeley Packet Filter) 기술을 악용하여 고도화된 은닉성과 탐지 회피 기능을 통해 리눅스 시스템 내 장기 은닉을 목표로 하는 악성코드임.
• BPFDoor는 BPF(Berkeley Packet Filter)를 악용하여 커널 레벨에서 특정 트리거 패킷만 수신하며, 229개의 BPF Instruction Set을 사용함.
  - BPFDoor의 버전에 따라 Instruction Set의 개수 및 매직 시퀀스가 일부 다르게 나타남.
  - 프로세스 이름 위장 및 데몬화, 메모리 기반 복제 및 실행 은닉, 히스토리 기록 차단 등 다양한 Anti-Forensic 기술을 적용함.
• 공격에 사용된 BPFDoor는 중국 배후의 APT 그룹 Earth Bluecrow(a.k.a. Red Menshen)이 사용하는 것으로 알려져 있으며 최근 해당 그룹이 독점적으로 사용하는 BPFDoor Controller가 발견됨.
• S2W는 이번 침해사고에 사용된 BPFDoor 샘플과 변종을 탐지할 수 있는 YARA 룰을 별도로 제공함.
• BPF 필터 조회, 매직 시퀀스 검색, Salt 문자열 탐지, 포트 개방 점검 등을 통한 사전 감염 탐지가 권장됨.
  - 리눅스 서버 운영 시 비정상적인 소켓 연결 모니터링과, 실행 파일 위변조 및 프로세스 이름 변조 여부에 대한 주기적 점검이 필요함.

Appendix A. IoCs

IoC list can be found our github

Appendix B. Detection Rules

Detection Rule can be found our github

Appendix C. MITRE ATT&CK

Execution

• (T1059.004) Unix Shell
• (T1106) Native API

Persistence

• (T1133) External Remote Services

Defense Evasion

• (T1036.005) Match Legitimate Resource or Location
• (T562.003) Impair Command History Logging
• (T1562.004) Disable or Modify System Firewall

Command and Control

• (T1095) Non-Application Layer Protocol
• (T1205) Traffic Signaling
• (T1205.002) Socket Filters