A significant shift is occurring in the Linux threat landscape. Threat actors are increasingly turning to eBPF (extended Berkeley Packet Filter) rootkits to maintain stealthy, persistent access to compromised Linux systems — and underground forums are accelerating the trend by openly sharing source code, tutorials, and operational guidance for building these implants. According to recent reporting from Flare, dark web communities are actively trading eBPF rootkit techniques that evade traditional detection methods by operating entirely within the kernel's legitimate BPF framework, without ever loading a traditional kernel module.
This matters because most Linux security tooling — including many EDR agents, file integrity monitors, and audit frameworks — was architected around detecting rogue kernel modules (LKMs), suspicious processes, and anomalous system calls. eBPF rootkits sidestep all three. They hook into kernel functions through the sanctioned BPF syscall interface, intercepting and filtering data before userspace tools ever see it. The result is an implant that can hide processes, network connections, files, and even its own presence from tools like ps, ss, netstat, ls, and lsof — all while appearing as a legitimate BPF program to the operating system.
If your organization runs Linux servers — web servers, container hosts, database backends, cloud workloads — you are in scope. The techniques being shared in underground communities are mature, well-documented, and increasingly accessible to actors who lack advanced kernel development skills. Defenders must adapt now.
Technical Analysis
What Are eBPF Rootkits?
eBPF is a legitimate, powerful Linux kernel technology originally designed for packet filtering and later extended to support tracing, observability, networking, and security enforcement. Programs written in eBPF are loaded into the kernel via the bpf() system call, verified for safety, and then executed in a sandboxed virtual machine context. Modern observability stacks like Cilium, Falco, and bpftrace rely on eBPF.
Threat actors have weaponized this same framework. An eBPF rootkit uses the BPF subsystem to attach malicious programs to kernel tracepoints, kprobes, kretprobes, and other hook points. Once attached, these programs can:
- Hide processes by intercepting
getdents64syscalls and filtering directory entries from/proc - Hide network connections by hooking socket-related tracepoints and filtering connection data before it reaches
ssornetstat - Hide files and directories by intercepting filesystem syscall return values
- Capture credentials by sniffing PAM authentication flows or intercepting SSH sessions
- Establish covert C2 channels by manipulating network packets at the socket buffer level, bypassing iptables/nftables rules
Why eBPF Rootkits Evade Traditional Detection
Traditional Linux rootkits relied on loadable kernel modules (LKMs) — the classic insmod rootkit.ko approach. Defensive tools learned to detect these through module listing (lsmod), kernel symbol table analysis (/proc/kallsyms), and integrity checking. eBPF rootkits bypass these controls entirely because:
- No kernel module is loaded. The BPF program exists in kernel memory but does not appear in
lsmodoutput or/proc/modules. - No traditional process exists. The BPF program executes in kernel context — it does not show up in
psoutput as a userspace process. - Legitimate syscall interface. The
bpf()system call is a standard kernel API. Loading a BPF program looks identical whether the program is a Cilium network policy or a rootkit. - No filesystem artifacts required. BPF programs can be loaded, pinned to BPF filesystems (
/sys/fs/bpf/), or exist entirely in memory with no on-disk binary. - Hooking is transparent. Because eBPF operates through the kernel's own tracing infrastructure, it can filter data at the source — before it ever reaches the userspace tools that analysts depend on.
Known eBPF Rootkit Projects
Several open-source eBPF rootkit projects have been publicly documented and are now circulating in underground forums:
- Boobytrap — A proof-of-concept eBPF rootkit demonstrating process hiding and syscall hooking.
- TripleCross — A comprehensive eBPF rootkit with process hiding, file hiding, network connection concealment, privilege escalation, and C2 capabilities. TripleCross demonstrated the ability to evade common Linux security products.
- ebpfkit — Another publicly available eBPF rootkit framework with network-level hiding and packet manipulation capabilities.
- BVP47-adjacent techniques — Advanced persistent threat actors have been observed using BPF-based network filtering for covert communications.
These projects serve as templates. Underground actors modify and extend them, adding custom C2 protocols, anti-forensics capabilities, and targeting specific application stacks.
Affected Systems
Any Linux system running a kernel with eBPF support is potentially affected. This includes:
- Kernel version 4.x and later (eBPF was significantly expanded starting around kernel 4.1, with major capabilities added through 4.x and 5.x)
- Distributions: Ubuntu, Debian, RHEL, CentOS, Fedora, Amazon Linux, Alpine, SUSE, and virtually any modern Linux distribution
- Container hosts: Docker, Kubernetes nodes, and containerd hosts running on eBPF-enabled kernels
- Cloud instances: AWS EC2, Azure VMs, GCP Compute Engine instances running Linux
Systems are at highest risk when:
- An attacker has already achieved initial access and root-level execution (eBPF program loading typically requires
CAP_BPForCAP_SYS_ADMIN) - The
kernel.unprivileged_bpf_disabledsysctl is set to0(allowing unprivileged BPF program loading), though this is less common - The organization lacks runtime security monitoring for BPF subsystem activity
Attack Chain
A typical eBPF rootkit deployment follows this pattern:
- Initial compromise — The attacker gains access through a vulnerability, stolen credentials, supply chain compromise, or misconfigured service.
- Privilege escalation — The attacker obtains root or
CAP_SYS_ADMIN/CAP_BPFprivileges (required for loading BPF programs in most configurations). - Rootkit deployment — The attacker compiles and loads the eBPF rootkit, typically using
libbpf,bpftool, or a custom loader binary. - Persistence — The BPF program may be pinned to the BPF filesystem (
/sys/fs/bpf/) or reloaded by a small userspace persistence mechanism (systemd unit, cron job, or modified service). - Stealth operation — The rootkit hooks kernel tracepoints and begins filtering data to hide attacker processes, connections, and files.
- C2 communication — The implant communicates with attacker infrastructure through channels that may bypass traditional network monitoring.
Exploitation Status
The availability of open-source eBPF rootkit source code and tutorials on underground forums means this is no longer a theoretical or APT-only threat. The barrier to entry has dropped significantly. While widespread commodity deployment has not yet been observed at the scale of traditional malware, the trajectory is clear — and security teams that wait for mass exploitation before building detection capabilities will be caught off guard.
Detection & Response
Detecting eBPF rootkits requires a shift in methodology. Since the rootkit actively filters the data that userspace tools rely on, defenders must look at the BPF subsystem itself — the programs loaded, the maps created, the syscalls made, and the tooling used.
Sigma Rules
The following Sigma rules target observable behaviors associated with eBPF rootkit deployment. These are designed for Linux environments with Sysmon for Linux or auditd-based logging forwarded to a SIEM.
---
title: BPF Program Loading via bpftool or bpffs
description: Detects use of bpftool to load, pin, or manage BPF programs — a key indicator of eBPF rootkit deployment. Legitimate use exists in Cilium and observability stacks, but unexpected bpftool activity warrants investigation.
status: experimental
references:
- https://www.bleepingcomputer.com/news/security/ebpf-rootkits-why-underground-actors-are-taking-notice/
- https://attack.mitre.org/techniques/T1014/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.t1014
- attack.t1059
logsource:
category: process_creation
product: linux
detection:
selection_img:
Image|endswith:
- '/bpftool'
- '/bpftrace'
selection_args:
CommandLine|contains:
- 'prog load'
- 'prog loadall'
- 'map create'
- 'prog attach'
- 'pin'
condition: selection_img and selection_args
falsepositives:
- Cilium or Calico CNI operations in Kubernetes clusters
- Falco or other eBPF-based security tooling
- Legitimate performance engineering with bcc/bpftrace
level: high
---
title: BPF Program Loaded via Direct bpf() Syscall
description: Detects direct invocation of the bpf() system call by non-standard processes, which may indicate eBPF rootkit loading. Requires auditd rules targeting the bpf syscall.
status: experimental
references:
- https://www.bleepingcomputer.com/news/security/ebpf-rootkits-why-underground-actors-are-taking-notice/
- https://attack.mitre.org/techniques/T1014/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.t1014
logsource:
category: process_creation
product: linux
detection:
selection:
CommandLine|contains:
- 'BPF_PROG_LOAD'
- 'bpf_prog_load'
- 'libbpf'
- 'bpf_object__load'
filter_known_bpf:
Image|endswith:
- '/cilium-agent'
- '/falco'
- '/bpftrace'
- '/bpftool'
- '/kube-proxy'
- '/calico-node'
- '/pixie-agent'
condition: selection and not filter_known_bpf
falsepositives:
- Custom observability agents using libbpf
- Development and testing environments
level: high
---
title: Suspicious BPF Filesystem Activity
description: Detects pinning of BPF programs or maps to the BPF filesystem, which provides persistence for eBPF rootkits across process restarts.
status: experimental
references:
- https://www.bleepingcomputer.com/news/security/ebpf-rootkits-why-underground-actors-are-taking-notice/
- https://attack.mitre.org/techniques/T1014/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.persistence
- attack.t1014
logsource:
category: file_event
product: linux
detection:
selection:
TargetFilename|startswith:
- '/sys/fs/bpf/'
filter_known:
TargetFilename|contains:
- '/sys/fs/bpf/cilium'
- '/sys/fs/bpf/tc'
- '/sys/fs/bpf/xdp'
- '/sys/fs/bpf/ip'
condition: selection and not filter_known
falsepositives:
- Container network interfaces using BPF for traffic control
- XDP-based DDoS mitigation
level: high
KQL Hunt Query (Microsoft Sentinel)
The following KQL queries hunt for eBPF rootkit indicators in environments forwarding Linux Syslog or auditd data to Sentinel. These work with both the Syslog connector and the Common Event Format (CEF) ingestion pipeline.
// Hunt for bpftool execution and BPF program loading activity
// Covers process execution logged via Syslog or auditd
Syslog
| where TimeGenerated > ago(24h)
| where ProcessName in~ ("bpftool", "bpftrace", "bpftrace8")
or (ProcessName =~ "bash" and SyslogMessage has_any ("bpftool", "bpf_prog_load", "BPF_PROG_LOAD", "bpffs"))
| where SyslogMessage has_any ("prog load", "prog loadall", "map create", "prog attach", "pin", "BPF_PROG_LOAD")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc
// Hunt for suspicious file activity in BPF filesystem paths
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("/sys/fs/bpf/")
| where SyslogMessage !has_any ("cilium", "calico", "tc", "xdp", "iproute2")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc
// Hunt for unprivileged BPF sysctl modification — attackers may attempt to relax restrictions
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("unprivileged_bpf_disabled", "kernel.unprivileged_bpf")
or (ProcessName =~ "sysctl" and SyslogMessage has "bpf")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc
Velociraptor VQL Hunt
For DFIR teams running Velociraptor across Linux endpoints, the following VQL artifact hunts for BPF program artifacts, suspicious bpftool execution, and BPF filesystem anomalies.
-- Hunt for eBPF rootkit indicators across Linux endpoints
-- Check for BPF filesystem mounts and pinned programs
SELECT
FullPath,
Mtime,
Size,
Mode
FROM glob(globs="/sys/fs/bpf/**/*")
WHERE NOT FullPath =~ "cilium|calico|tc|xdp"
-- Enumerate running processes using bpftool or loading BPF programs
SELECT
Pid,
Name,
CommandLine,
Exe,
Username,
CreateTime
FROM pslist()
WHERE CommandLine =~ "bpftool|bpftrace|bpf_prog_load|BPF_PROG_LOAD|bpffs|/sys/fs/bpf"
OR Name =~ "bpftool|bpftrace"
-- Check for loaded kernel modules as baseline comparison (eBPF rootkits won't appear here)
SELECT
FullPath AS ModuleFile,
Mtime
FROM glob(globs="/proc/modules")
-- Check network connections that may be hidden from userspace by eBPF
SELECT
Pid,
Name,
DestIP,
DestPort,
SrcIP,
SrcPort,
Status
FROM netstat()
WHERE DestPort IN (443, 8443, 4444, 53, 80)
AND DestIP !~ "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)"
Remediation and Hardening Script
The following Bash script audits BPF subsystem configuration, inventories loaded BPF programs, and applies hardening controls. Run it as root on each Linux endpoint.
#!/bin/bash
# eBPF Rootkit Detection and Hardening Script
# Run as root on Linux endpoints
# Author: Security Arsenal
echo "=== eBPF Rootkit Audit and Hardening ==="
echo ""
# --- SECTION 1: Audit current BPF subsystem state ---
echo "[+] Checking current BPF sysctl configuration..."
echo "kernel.unprivileged_bpf_disabled = $(cat /proc/sys/kernel/unprivileged_bpf_disabled 2>/dev/null || echo 'N/A')"
echo "kernel.bpf_stats_enabled = $(cat /proc/sys/kernel/bpf_stats_enabled 2>/dev/null || echo 'N/A')"
echo "net.core.bpf_jit_enable = $(cat /proc/sys/net/core/bpf_jit_enable 2>/dev/null || echo 'N/A')"
echo "net.core.bpf_jit_harden = $(cat /proc/sys/net/core/bpf_jit_harden 2>/dev/null || echo 'N/A')"
echo ""
# --- SECTION 2: Inventory loaded BPF programs ---
echo "[+] Listing all loaded BPF programs..."
if command -v bpftool &> /dev/null; then
bpftool prog show 2>/dev/null || echo "[!] Failed to list BPF programs"
echo ""
echo "[+] Listing all BPF maps..."
bpftool map show 2>/dev/null || echo "[!] Failed to list BPF maps"
echo ""
echo "[+] Listing BPF links..."
bpftool link show 2>/dev/null || echo "[!] Failed to list BPF links"
echo ""
echo "[+] Listing BPF cgroup attachments..."
bpftool cgroup tree 2>/dev/null || echo "[!] Failed to list cgroup attachments"
else
echo "[!] bpftool not found. Install with: apt install linux-tools-generic (Debian/Ubuntu) or yum install bpftool (RHEL)"
fi
echo ""
# --- SECTION 3: Check BPF filesystem ---
echo "[+] Checking BPF filesystem for pinned programs..."
if [ -d /sys/fs/bpf ]; then
ls -laR /sys/fs/bpf/ 2>/dev/null
echo ""
echo "[+] Checking for unexpected files in bpffs..."
find /sys/fs/bpf/ -type f 2>/dev/null | while read -r file; do
echo " Found: $file"
done
else
echo " BPF filesystem not mounted or not accessible"
fi
echo ""
# --- SECTION 4: Check for suspicious processes ---
echo "[+] Checking for suspicious BPF-related processes..."
ps aux | grep -iE 'bpf|bpftool|bpftrace' | grep -v grep || echo " No suspicious BPF processes found"
echo ""
# --- SECTION 5: Check auditd rules for BPF syscalls ---
echo "[+] Checking auditd rules for bpf() syscall monitoring..."
if command -v auditctl &> /dev/null; then
auditctl -l 2>/dev/null | grep -i bpf || echo " [!] No auditd rules found for bpf() syscall — add rules (see Section 7)"
else
echo " auditd not installed or not running"
fi
echo ""
# --- SECTION 6: Hardening recommendations ---
echo "[+] Applying hardening controls..."
echo ""
# Disable unprivileged BPF (should already be default on most modern distros, but verify)
echo "[+] Setting kernel.unprivileged_bpf_disabled = 1"
sysctl -w kernel.unprivileged_bpf_disabled=1
# Harden BPF JIT compiler
echo "[+] Setting net.core.bpf_jit_harden = 2"
sysctl -w net.core.bpf_jit_harden=2
# Enable BPF stats for observability
echo "[+] Setting kernel.bpf_stats_enabled = 1"
sysctl -w kernel.bpf_stats_enabled=1
# Persist settings
echo ""
echo "[+] Persisting sysctl settings..."
cat > /etc/sysctl.d/99-bpf-hardening.conf << 'SYSCTL_EOF'
# eBPF Hardening — Security Arsenal
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2
kernel.bpf_stats_enabled=1
SYSCTL_EOF
echo " Settings written to /etc/sysctl.d/99-bpf-hardening.conf"
# --- SECTION 7: Add auditd rules for BPF monitoring ---
echo ""
echo "[+] Adding auditd rules for bpf() syscall monitoring..."
if command -v auditctl &> /dev/null; then
auditctl -a always,exit -F arch=b64 -S bpf -k bpf_prog_load 2>/dev/null
auditctl -a always,exit -F arch=b32 -S bpf -k bpf_prog_load 2>/dev/null
echo " Runtime rules added for bpf() syscall"
# Persist in auditd rules
cat >> /etc/audit/rules.d/bpf-monitoring.rules << 'AUDIT_EOF'
# Monitor bpf() syscall for eBPF rootkit detection
-a always,exit -F arch=b64 -S bpf -k bpf_prog_load
-a always,exit -F arch=b32 -S bpf -k bpf_prog_load
AUDIT_EOF
echo " Persistent rules written to /etc/audit/rules.d/bpf-monitoring.rules"
else
echo " [!] auditd not available — install and configure auditd for BPF syscall monitoring"
fi
echo ""
echo "=== Audit and Hardening Complete ==="
echo ""
echo "NEXT STEPS:"
echo " 1. Review the BPF program inventory above for unexpected programs"
echo " 2. If unexpected BPF programs are found, dump them for analysis:"
echo " bpftool prog dump xlated id <PROG_ID>"
echo " 3. Consider deploying eBPF-aware runtime security (Falco, Tetragon, Tracee)"
echo " 4. Forward auditd logs to your SIEM for centralized BPF monitoring"
Remediation
Immediate Actions
1. Inventory your BPF attack surface. Run the audit script above across all Linux endpoints, especially internet-facing servers, container hosts, and Kubernetes nodes. Identify all loaded BPF programs and validate each one against known-good observability and networking tools (Cilium, Falco, Calico, Katran, etc.).
2. Disable unprivileged BPF loading. Ensure kernel.unprivileged_bpf_disabled=1 is set on all systems. This prevents non-root users from loading BPF programs. Verify that no container orchestration or observability tools depend on unprivileged BPF access.
3. Audit for CAP_BPF and CAP_SYS_ADMIN grants. Review systemd unit files, container security contexts, and Kubernetes pod security policies for unnecessary capability grants. eBPF program loading requires elevated capabilities — restricting them reduces the attack surface.
# Check which services have CAP_BPF or CAP_SYS_ADMIN
grep -r "CAP_BPF\|CAP_SYS_ADMIN\|AmbientCapabilities" /etc/systemd/system/ 2>/dev/null
# Check Kubernetes pods with elevated capabilities
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].securityContext.capabilities.add != null) | {namespace: .metadata.namespace, pod: .metadata.name, capabilities: .spec.containers[].securityContext.capabilities.add}' 2>/dev/null
4. Deploy eBPF-aware runtime security. Traditional Linux EDR may not monitor the BPF subsystem. Consider deploying tools purpose-built for eBPF observability:
- Falco — Uses eBPF probes to monitor system calls and can detect BPF program loading
- Cilium Tetragon — eBPF-based security observability and runtime enforcement
- Tracee — Aqua Security's runtime security and forensics tool using eBPF
- BPF LSM — Linux Security Module hooks implemented via BPF for policy enforcement
5. Implement auditd monitoring for the bpf() syscall. Every BPF program load triggers the bpf() syscall with the BPF_PROG_LOAD command. Logging these events provides a forensic trail of all BPF activity.
Medium-Term Hardening
6. Enable BPF token-based delegation (kernel 6.9+). Newer kernels support BPF tokens for fine-grained delegation of BPF capabilities, reducing the need for blanket CAP_SYS_ADMIN grants.
7. Implement signed BPF programs where possible. Some distributions and security frameworks are moving toward BPF program signing to ensure only authorized programs can be loaded.
8. Network segmentation and egress filtering. Since eBPF rootkits can manipulate network traffic at the kernel level, defense-in-depth requires network-layer controls that operate outside the compromised host. Implement egress filtering at the firewall/security group level to block unexpected outbound connections.
9. Incorporate BPF forensics into IR playbooks. When investigating a compromised Linux host, add these steps:
- Run
bpftool prog showandbpftool map showto inventory BPF artifacts - Check
/sys/fs/bpf/for pinned programs - Review auditd logs for
bpf()syscall activity - Compare network connections visible in
ss/netstatagainst raw packet captures (eBPF rootkits can hide connections from userspace tools but cannot hide actual packets on the wire) - Dump suspicious BPF programs for reverse engineering:
bpftool prog dump xlated id <ID>
Key Takeaway
eBPF rootkits represent a fundamental shift in Linux rootkit methodology. The kernel's own observability framework is being weaponized against defenders. The tools and techniques are freely available in underground communities, and the barrier to entry is dropping. Organizations that rely solely on traditional Linux security monitoring — file integrity checking, process listing, and kernel module auditing — are blind to this threat class.
The defensive response requires BPF-aware monitoring, capability restriction, syscall auditing, and updated incident response procedures. The time to build these capabilities is now, before eBPF rootkits become as common as their LKM predecessors.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.