Linux eBPF Abuse: Detection and Hardening

eBPF is a programmable kernel interface, not one technique

Linux eBPF abuse detection starts by identifying which program was loaded, who loaded it, what capabilities authorized the operation, where it attached, and what it changed or observed. “BPF activity” alone is too broad: modern networking, observability, performance, and security agents use the same subsystem legitimately.

The kernel libbpf lifecycle documentation separates open, load, attachment, and teardown. During load, programs and maps are created and bytecode is verified. During attachment, a program binds to a tracepoint, kprobe, cgroup hook, network path, LSM hook, or another supported point. Runtime behavior then depends on program type, helpers, maps, events, and the hook’s authority.

Abuse can support covert observation, network manipulation, execution monitoring, hiding, or interference with security tooling. Those outcomes require precise evidence. MITRE ATT&CK rootkit guidance describes the broader goal of hiding programs, files, network connections, or services; an eBPF program is one possible mechanism, not automatic proof of a rootkit.

Inventory programs, maps, links, and the process that created them

Use a trusted administrative path to enumerate loaded objects. bpftool prog show, bpftool map show, bpftool link show, and JSON output can provide program ID, type, name, tag, load time, UID, map references, and attachment context depending on kernel and tool versions. The kernel BPF inspection documentation also explains why some relationships require deeper inspection than the normal user-space API exposes.

This is an authored bpftool-style example, not live telemetry:

{
  "id": 431,
  "type": "kprobe",
  "name": "tcp_watch",
  "tag": "7a4d3c21b0189e44",
  "loaded_at": "2026-11-10T10:18:33Z",
  "uid": 0,
  "map_ids": [812, 813],
  "btf_id": 97,
  "pinned": "/sys/fs/bpf/tcp_watch"
}

Preserve program and map identifiers, bytecode or object digest where obtainable, BTF information, pinned path, loader executable and signer/package, process ancestry, user namespace, container or cgroup, capabilities, attachment target, and lifecycle. Program names are short and attacker-controlled; a reassuring name is not provenance.

A root-level view can still be incomplete if the kernel or inspection path is compromised. Compare live enumeration with boot-time inventory, package state, orchestration declarations, audit records, and an independent response environment when confidence matters.

Detect unauthorized loading and suspicious attachment behavior

Monitor the bpf() syscall and related object lifecycle at the strongest trustworthy layer available. The eBPF syscall documentation distinguishes commands such as map creation, program load, object pinning, link creation, and token operations. Capture command, caller, credentials and capabilities, namespace, program and attach type, result, and object identifiers without logging sensitive map contents by default.

High-confidence patterns include a new loader outside the approved package set; BPF activity from an application service account; unexpected kprobe, fentry/fexit, LSM, cgroup, traffic-control, or XDP attachment; pinned objects in novel paths; programs surviving after their expected agent stops; map access by unrelated processes; or endpoint discrepancies after attachment.

Compare independent views. If network connections exist in flow telemetry but disappear from host tools after a new program loads, or process execution appears in remote audit but not local enumeration, investigate possible observation tampering. These inconsistencies support escalation more strongly than a program type alone.

Preserve kernel evidence before detaching programs

Isolate the host according to its workload role and collect program, map, link, BTF, pinned-object, process, package, audit, namespace, and network evidence. Capture identifiers and hashes before detaching; removing a link or killing a loader can destroy the state needed to understand behavior.

Do not execute unknown tooling on the suspect host merely to gain visibility. Use a trusted response method and consider memory acquisition or offline analysis when kernel integrity is uncertain. Compare remote logs with local results. Rotate secrets accessible to the affected workload and investigate downstream systems if the program could observe credentials or redirect traffic.

If trust in the running kernel cannot be restored, rebuild from a known-good image and correct the access path that allowed loading. Detachment alone is not durable recovery.

Reduce who can load and attach programs without disabling observability

Inventory legitimate eBPF consumers first. Restrict CAP_BPF and program-specific capabilities, apply service capability bounding, constrain privileged containers, control access to BPF filesystem mounts and pinned objects, and set the distribution-supported unprivileged BPF policy. Keep kernels and eBPF tooling updated.

The verifier enforces program safety, not organizational intent. Emerging signing support can add provenance where the deployed kernel and LSM policy enforce it, but a signature does not replace capability checks or the verifier. Treat availability carefully: abruptly blocking BPF can disable networking, observability, or endpoint security agents that depend on it.

Roll out through inventory, allowlist design, canary hosts, monitored enforcement, and expiring exceptions. Validate both program load and teardown so controls do not create orphaned objects.

Make eBPF a governed endpoint capability

Next step: add eBPF to the organization’s endpoint security capabilities inventory. For each approved agent, record loader, package, program types, hooks, maps, pinned paths, capabilities, expected lifetime, owner, and upgrade behavior. Then run one authorized load-and-attach simulation and confirm that program and consequence telemetry remain available.

Review the result against telemetry quality and blind spots and telemetry lineage and integrity. The durable outcome is not a ban on eBPF; it is an attributable, least-privilege kernel-programming boundary with independent evidence when that boundary changes.