eBPF 기반 지속성(Persistence) 기법

eBPF(extended Berkeley Packet Filter)는 커널을 재컴파일하지 않고도 커널 내부에서 샌드박스된 프로그램을 실행할 수 있게 해주는 리눅스 기능이다. 원래는 네트워킹/트레이싱/모니터링 목적(Wazuh 같은 도구도 이걸 활용한다)이지만, 공격자 입장에서는 커널 레벨에서 프로세스·파일·네트워크를 몰래 조작할 수 있는 강력한 지속성 수단이 된다. BPFDoor 같은 실제 악성코드가 이 방식을 쓴다.

왜 강력한가

• 커널 레벨에서 실행되므로 유저스페이스 도구(ps, netstat 등)로 눈속임이 가능하다 — syscall 결과 자체를 조작할 수 있다
• RAW 소켓 기반이라 일반적인 포트 리스닝 형태가 아니어서, 방화벽/포트 스캔으로는 탐지되지 않는다 (BPFDoor의 매직 패킷 방식)

어떻게 지속성을 얻는가

• kprobe/kretprobe로 특정 커널 함수 호출을 후킹해서 파일·프로세스를 숨기거나 백도어 명령을 실행
• XDP(eXpress Data Path) 훅으로 네트워크 인터페이스에 도달하는 패킷을 커널 초입에서 가로채 매직 바이트를 검사하고, 조건이 맞으면 쉘을 실행

최소 예시 (정상적인 관찰·트레이싱 용도)

# execve 호출을 커널 레벨에서 실시간 관찰
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s %s\n", comm, str(args->filename)); }'

실제 공격에 쓰이는 eBPF 프로그램은 이 관찰 능력을 반대로 이용해서, 특정 조건에서 자기 자신의 흔적(프로세스, 소켓, 파일)을 결과에서 제외시키는 방식으로 은폐한다.

탐지와 방어

• 커널은 로드된 eBPF 프로그램을 자체적으로 추적한다 — bpftool prog list로 현재 로드된 모든 eBPF 프로그램을 점검할 수 있다
• 서명되지 않은 eBPF 프로그램 로드를 제한하는 커널 설정(kernel.unprivileged_bpf_disabled)
• BPFDoor 계열 탐지는 RAW 소켓을 여는 프로세스, BPF 필터의 매직 시퀀스, 뮤텍스/락 파일 흔적을 함께 확인해야 한다 (자세한 점검 항목은 BPFDoor 스캐너 프로젝트 글 참고)

커널이 이걸 그대로 허용하는 이유 — eBPF 검증기(Verifier)

eBPF 프로그램이 임의 커널 코드 실행처럼 보이는데도 커널이 로드를 허용하는 이유는, 로드 시점에 **커널 내장 정적 분석기(Verifier)**가 그 프로그램의 모든 실행 경로를 시뮬레이션해서 "메모리 접근 범위를 벗어나지 않는지", "루프가 종료되는지(무한 루프 금지)", "포인터 연산이 안전한지"를 검증하기 때문이다. 즉 eBPF는 "커널이 신뢰하지 않는 코드"를 실행하는 게 아니라, 검증기를 통과한 코드만 실행을 허용하는 구조다 — 공격자가 노리는 지점은 이 취약점이 아니라, 정상적으로 서명·검증을 통과한 eBPF 프로그램이 원래부터 갖고 있는 강력한 관찰·개입 권한 자체를 지속성 목적으로 정당하게(하지만 악의적으로) 사용하는 것이라는 점이 다른 커널 익스플로잇과 결이 다르다.

여기서 끝나지 않는다: 체이닝

• 초기 침투 이후의 "마지막 조각": SQLi/웹쉘/CVE로 얻은 root 셸에 eBPF 후킹을 심으면, 이후 취약점이 패치되거나 웹쉘이 삭제돼도 커널 레벨의 은폐된 백도어가 남아있어 재침투가 훨씬 쉬워진다 — PAN-OS CVE-2024-3400 글에서 언급한 "패치 이후에도 남는 지속성" 문제의 실제 구현 수단이 이것이다
• 탐지 우회의 연쇄: eBPF로 ps/netstat/파일 목록 결과를 조작해 자신을 숨기면, 이후 침해 대응 과정에서 도구 기반 조사(라이브 포렌식)가 무력화되고 별도의 커널 메모리 덤프·오프라인 분석이 필요해진다 — 탐지 난이도 자체를 한 단계 끌어올리는 체인이다