Every powerful security mechanism contains within it the potential for abuse. Firewalls can be reconfigured to block defenders. Encryption can shield attackers' communications. Audit logs can be manipulated to erase evidence. The pattern is consistent: the deeper a technology reaches into a system's internals, the more dangerous it becomes when turned against the system it was designed to protect.

Extended Berkeley Packet Filter (eBPF) is the latest and perhaps most consequential example of this duality. Originally designed for efficient packet filtering, eBPF has evolved into a general-purpose framework for running sandboxed programs within the Linux kernel—without modifying kernel source code or loading traditional kernel modules. This capability has made eBPF the foundation of modern cloud-native security and observability. It has also made eBPF a compelling concealment mechanism for sophisticated rootkits.

The Research Landscape: eBPF as Security Infrastructure

The ACM SIGOPS community and the eunomia.dev research group have independently documented eBPF's central role in Kubernetes security architecture, where three tools dominate the landscape:

Cilium provides eBPF-based networking and network security for Kubernetes clusters. By attaching eBPF programs to kernel network hooks, Cilium enforces policies at the kernel level—faster and more granular than iptables. Cilium inspects traffic based on application-layer identity (Kubernetes labels, service names) rather than ephemeral IP addresses.

Falco uses eBPF to intercept system calls and generate security alerts in real time. When a container executes an unexpected binary or establishes an unusual outbound connection, Falco captures the event at the kernel level. User-space evasion techniques cannot hide from kernel-level sensors.

Tracee provides runtime security and forensics by tracing kernel and user-space events through eBPF. It loads programs dynamically and detects container escapes, privilege escalation, and fileless malware execution.

Together, these tools have established what the research literature describes as "autonomous security"—systems that detect, classify, and in some cases respond to threats without human intervention, operating at kernel speed rather than human speed.

The Other Face: eBPF as Rootkit Platform

The same properties that make eBPF effective for security—kernel-level access, dynamic loading, system call interception, network traffic manipulation—make it equally effective for concealment.

Traditional rootkits load kernel modules (LKMs) that modify system call tables—leaving detectable artifacts in lsmod output and memory regions. eBPF programs, by contrast, operate within the kernel's sanctioned execution framework. An eBPF rootkit can:

Intercept and modify system call results — hiding files, processes, and network connections from user-space tools by filtering what the kernel returns to applications

Manipulate network traffic — redirecting, dropping, or modifying packets at the kernel level, invisible to user-space packet capture tools

Evade traditional detection — because eBPF programs run through the kernel's own verified execution path, they may not trigger the same alerts as unauthorized kernel modules

Persist across reboots — through systemd service files or init scripts that reload the eBPF programs at boot, using the same mechanism that legitimate security tools use for persistence

The research notes that several proof-of-concept eBPF rootkits have been demonstrated, and the security community has documented techniques for using eBPF's bpf_probe_write_user helper to modify user-space memory from kernel context—a capability that traditional security models did not anticipate.

Critical Analysis

<

Claim	Source Evidence	Verdict
eBPF is now core infrastructure for Kubernetes autonomous security	Cilium, Falco, Tracee adoption documented across ACM SIGOPS and industry surveys	✅ Supported — widespread production deployment
eBPF can be exploited as rootkit concealment within kernel space	Proof-of-concept demonstrations documented; architectural analysis confirms feasibility	✅ Supported — demonstrated capability
Verifier improvements are being studied to restrict malicious eBPF use	Active research on enhanced verification, capability restriction, and runtime monitoring	✅ Supported — ongoing research track
Privilege restrictions can mitigate eBPF rootkit risks	CAP_BPF separation and unprivileged eBPF restrictions documented	⚠️ Partial — reduces but does not eliminate risk for privileged attackers

The Verifier Paradox

The eBPF verifier—the kernel component that checks eBPF programs before execution—is designed to prevent crashes, infinite loops, and out-of-bounds memory access. It was not originally designed to distinguish between benign and malicious intent. A program that intercepts system calls and filters results is structurally identical whether it serves a security monitoring purpose or a rootkit concealment purpose.

Recent research explores extending the verifier to enforce security policies beyond safety properties—restricting which eBPF program types can be loaded by which processes, limiting access to sensitive helper functions, and requiring cryptographic attestation of eBPF programs before loading. These approaches treat the verifier as a policy enforcement point rather than purely a safety mechanism.

Privilege as the Defense Boundary

The primary defense against eBPF rootkits is privilege restriction. Loading eBPF programs requires specific Linux capabilities (CAP_BPF, CAP_SYS_ADMIN, or CAP_NET_ADMIN depending on program type). In properly configured systems, only trusted security tools have these capabilities. The attack scenario requires that an adversary first achieves privilege escalation—at which point they have access to many attack vectors, not just eBPF.

However, in container environments where security tools themselves run as privileged containers with eBPF capabilities, compromising the security tool's container grants the attacker exactly the eBPF access needed for rootkit deployment—using the security tool's own privileges.

Open Questions

Attestation frameworks: Can eBPF programs be cryptographically signed and verified before loading? Research prototypes exist, but production-grade attestation for dynamically generated eBPF programs remains unsolved.

Runtime behavioral monitoring: If the verifier cannot distinguish malicious from benign programs structurally, can runtime monitoring detect anomalous eBPF behavior? This creates a recursive problem—who monitors the monitor at kernel level?

Container security architecture: Should security tools requiring eBPF capabilities run inside the container environment they protect, or at a separate trust layer? Privileged security containers create a bootstrapping vulnerability.

Closing Reflection

eBPF's dual nature is not a flaw to be fixed but a fundamental characteristic to be managed. The research trajectory—verifier enhancements, privilege restrictions, attestation frameworks—represents an attempt to preserve defensive benefits while constraining offensive potential. Whether that balance is achievable, or whether eBPF will follow the historical pattern of dual-use technologies where offensive and defensive capabilities co-evolve indefinitely, remains an open question.

면책 조항: 이 게시물은 정보 제공 목적의 연구 동향 개요이다. 학술 연구에서 인용하기 전에 특정 연구 결과, 통계 및 주장을 원본 논문과 대조하여 검증해야 한다.

eBPF의 두 얼굴: 커널 보안 센서이자 루트킷 은신처

모든 강력한 보안 메커니즘에는 악용될 수 있는 잠재적 가능성이 내재되어 있다. 방화벽은 방어자를 차단하도록 재설정될 수 있다. 암호화는 공격자의 통신을 보호하는 수단이 될 수 있다. 감사 로그는 증거를 지우기 위해 조작될 수 있다. 이 패턴은 일관적이다. 기술이 시스템 내부 깊숙이 파고들수록, 보호하도록 설계된 시스템을 공격하는 데 사용될 때 더욱 위험해진다.

Extended Berkeley Packet Filter(eBPF)는 이러한 이중성의 가장 최근, 그리고 아마도 가장 중대한 사례이다. 원래 효율적인 패킷 필터링을 위해 설계된 eBPF는 커널 소스 코드를 수정하거나 전통적인 커널 모듈을 로드하지 않고도 Linux 커널 내에서 샌드박스 프로그램을 실행하는 범용 프레임워크로 발전했다. 이 기능 덕분에 eBPF는 현대 클라우드 네이티브 보안 및 관찰 가능성(observability)의 토대가 되었다. 또한 eBPF는 정교한 루트킷을 위한 매력적인 은폐 메커니즘이 되기도 했다.

연구 현황: 보안 인프라로서의 eBPF

ACM SIGOPS 커뮤니티와 eunomia.dev 연구 그룹은 Kubernetes 보안 아키텍처에서 eBPF가 핵심적인 역할을 담당하고 있음을 독립적으로 문서화했으며, 이 분야에서는 세 가지 도구가 주류를 이루고 있다.

Cilium은 Kubernetes 클러스터를 위한 eBPF 기반 네트워킹 및 네트워크 보안을 제공한다. eBPF 프로그램을 커널 네트워크 훅(hook)에 연결함으로써 Cilium은 iptables보다 빠르고 세밀하게 커널 수준에서 정책을 시행한다. Cilium은 일시적인 IP 주소가 아닌 애플리케이션 계층 ID(Kubernetes 레이블, 서비스 이름)를 기반으로 트래픽을 검사한다.

Falco는 eBPF를 사용하여 시스템 호출을 가로채고 실시간으로 보안 경고를 생성한다. 컨테이너가 예상치 못한 바이너리를 실행하거나 비정상적인 아웃바운드 연결을 시도할 때, Falco는 커널 수준에서 해당 이벤트를 포착한다. 사용자 공간(user-space) 우회 기법은 커널 수준 센서를 피할 수 없다.

Tracee는 eBPF를 통해 커널 및 사용자 공간 이벤트를 추적함으로써 런타임 보안 및 포렌식을 제공한다. 프로그램을 동적으로 로드하여 컨테이너 탈출, 권한 상승, 파일리스(fileless) 악성코드 실행을 탐지한다.

이 도구들은 함께 연구 문헌에서 "자율 보안(autonomous security)"이라고 설명하는 시스템을 구축했다. 즉, 인간의 속도가 아닌 커널 속도로 작동하며 사람의 개입 없이 위협을 탐지, 분류하고 일부 경우에는 대응하는 시스템이다.

다른 얼굴: 루트킷 플랫폼으로서의 eBPF

eBPF를 보안에 효과적으로 만드는 바로 그 특성들—커널 수준 접근, 동적 로딩, 시스템 호출 가로채기, 네트워크 트래픽 조작—은 은폐에도 똑같이 효과적으로 만든다.

전통적인 루트킷은 시스템 호출 테이블을 수정하는 커널 모듈(LKM)을 로드하는데, 이는 lsmod 출력과 메모리 영역에 탐지 가능한 흔적을 남긴다. 반면 eBPF 프로그램은 커널의 공인된 실행 프레임워크 내에서 작동한다. eBPF 루트킷은 다음과 같은 일을 할 수 있다.

시스템 호출 결과 가로채기 및 수정 — 커널이 애플리케이션에 반환하는 내용을 필터링하여 사용자 공간 도구로부터 파일, 프로세스, 네트워크 연결을 숨긴다.

네트워크 트래픽 조작 — 커널 수준에서 패킷을 리다이렉트, 드롭 또는 수정하며, 사용자 공간 패킷 캡처 도구에는 보이지 않는다.

전통적인 탐지 우회 — eBPF 프로그램은 커널 자체의 검증된 실행 경로를 통해 실행되기 때문에, 무단 커널 모듈과 동일한 경고를 유발하지 않을 수 있다.

재부팅 후에도 지속 — 부팅 시 eBPF 프로그램을 다시 로드하는 systemd 서비스 파일 또는 init 스크립트를 통해 지속성을 유지하며, 이는 합법적인 보안 도구가 지속성을 위해 사용하는 것과 동일한 메커니즘이다.

비판적 분석

<

주장	출처 근거	판정
eBPF는 현재 Kubernetes 자율 보안의 핵심 인프라이다	ACM SIGOPS 및 산업 조사에 걸쳐 문서화된 Cilium, Falco, Tracee 채택 현황	✅ 지지됨 — 광범위한 프로덕션 배포
eBPF는 커널 공간 내 루트킷 은폐 수단으로 악용될 수 있다	개념 증명(proof-of-concept) 시연이 문서화됨; 아키텍처 분석을 통해 실현 가능성 확인	✅ 지지됨 — 입증된 능력
악의적 eBPF 사용을 제한하기 위한 검증기(verifier) 개선이 연구되고 있다	향상된 검증, 권한 제한, 런타임 모니터링에 관한 활발한 연구	✅ 지지됨 — 진행 중인 연구 흐름
권한 제한이 eBPF 루트킷 위험을 완화할 수 있다	CAP_BPF 분리 및 비특권 eBPF 제한이 문서화됨	⚠️ 부분적 — 위험을 줄이지만 특권 공격자에 대한 위험을 완전히 제거하지는 못함

연구에 따르면 여러 개념 증명(proof-of-concept) eBPF 루트킷이 시연된 바 있으며, 보안 커뮤니티는 eBPF의 bpf_probe_write_user 헬퍼를 활용하여 커널 컨텍스트에서 사용자 공간 메모리를 수정하는 기법을 문서화하였다. 이는 전통적인 보안 모델이 예상하지 못했던 기능이다.

검증기의 역설

eBPF 검증기(verifier)—실행 전 eBPF 프로그램을 검사하는 커널 구성 요소—는 크래시, 무한 루프, 경계 초과 메모리 접근을 방지하도록 설계되었다. 이는 원래 양성(benign) 의도와 악의적 의도를 구분하도록 설계된 것이 아니다. 시스템 호출을 가로채고 결과를 필터링하는 프로그램은, 보안 모니터링 목적으로 사용되든 루트킷 은폐 목적으로 사용되든 구조적으로 동일하다.

최근 연구는 검증기를 확장하여 안전성 속성을 넘어 보안 정책을 적용하는 방향을 탐색하고 있다. 여기에는 어떤 프로세스가 어떤 eBPF 프로그램 유형을 로드할 수 있는지 제한하고, 민감한 헬퍼 함수에 대한 접근을 제한하며, 로드 전 eBPF 프로그램의 암호화 증명(attestation)을 요구하는 방안이 포함된다. 이러한 접근 방식은 검증기를 순수한 안전 메커니즘이 아닌 정책 집행 지점으로 취급한다.

방어 경계로서의 권한

eBPF 루트킷에 대한 주요 방어 수단은 권한 제한이다. eBPF 프로그램을 로드하려면 특정 Linux 권한(프로그램 유형에 따라 CAP_BPF, CAP_SYS_ADMIN, 또는 CAP_NET_ADMIN)이 필요하다. 적절히 구성된 시스템에서는 신뢰할 수 있는 보안 도구만이 이러한 권한을 보유한다. 공격 시나리오는 공격자가 먼저 권한 상승을 달성해야 하며, 그 시점에서는 eBPF뿐만 아니라 다양한 공격 벡터에 접근할 수 있게 된다.

그러나 보안 도구 자체가 eBPF 권한을 가진 특권 컨테이너로 실행되는 컨테이너 환경에서는, 보안 도구의 컨테이너를 침해하는 것만으로 공격자가 루트킷 배포에 필요한 eBPF 접근 권한을 정확히 획득할 수 있다. 이는 보안 도구 자신의 권한을 이용하는 방식이다.

열린 질문들

증명 프레임워크(Attestation frameworks): eBPF 프로그램에 암호화 서명을 적용하고 로드 전에 검증하는 것이 가능한가? 연구 프로토타입은 존재하지만, 동적으로 생성된 eBPF 프로그램에 대한 프로덕션 수준의 증명은 아직 해결되지 않은 과제이다.

런타임 행동 모니터링: 검증기가 구조적으로 악의적 프로그램과 양성 프로그램을 구분할 수 없다면, 런타임 모니터링이 비정상적인 eBPF 동작을 탐지할 수 있는가? 이는 재귀적 문제를 야기한다—커널 수준에서 모니터를 감시하는 것은 누구인가?

컨테이너 보안 아키텍처: eBPF 권한이 필요한 보안 도구는 자신이 보호하는 컨테이너 환경 내부에서 실행되어야 하는가, 아니면 별도의 신뢰 계층에서 실행되어야 하는가? 특권 보안 컨테이너는 부트스트래핑 취약점을 생성한다.

마무리 성찰

eBPF의 이중적 특성은 해결해야 할 결함이 아니라 관리해야 할 근본적인 특성이다. 검증기 개선, 권한 제한, 증명 프레임워크 등의 연구 방향은 공격적 잠재력을 억제하면서 방어적 이점을 보존하려는 시도를 나타낸다. 이러한 균형이 달성 가능한지, 아니면 eBPF가 공격 및 방어 능력이 무한정 공진화하는 이중 사용 기술의 역사적 패턴을 따를 것인지는 여전히 열린 질문으로 남아 있다.