CAP_BPF/CAP_SYS_ADMIN
, enable LSMs (SELinux/AppArmor), and monitor /sys
+ pinned maps for anomalies.
What is eBPF, and why attackers love it
eBPF lets the OS run small, verified programs inside the kernel to observe and safely modify behavior—networking, syscalls, tracing, even security policy. It’s a defensive superpower (think modern XDP firewalls, observability, zero-copy telemetry) but, in hostile hands, the same hooks can cloak malware, block detection, and rewrite events before your EDR ever sees them.
Typical attack chain (real-world playbook)
- Initial foothold: weak SSH creds, vulnerable web app, or supply-chain script.
- Privilege escalation: kernel/driver bug, misconfig (sudo NOPASSWD), or container breakout.
- eBPF deployment: attacker loads BPF bytecode via
bpf()
syscalls; pins maps/programs under/sys/fs/bpf
. - Stealth hooks: kprobes/tracepoints uprobes to hide processes/ports, filter packets, and scrub logs.
- Persistence: services or cron that auto-re-pins programs at boot; masquerade as observability agents.
What an eBPF rootkit can do
- Process & file hiding: Filtered directory reads and procfs queries.
- Socket cloaking: Suppress specific ports from
ss
/netstat
. - Credential theft: Hook
read
/write
or TLS libraries via uprobes to skim secrets. - EDR blindspots: Tamper with audit/syscall events; drop packets before IDS sees them.
- Resilience: Pinned maps/programs survive process death; re-attachment on restart.
Who is most at risk?
- Kubernetes clusters with CNI plugins and observability stacks that already use eBPF.
- DevOps/SRE boxes where
CAP_SYS_ADMIN
is common and signing/enforcement is lax. - Telco/edge and cloud gateways using XDP/TC for performance tuning.
Detection: how to spot an “invisible” eBPF implant
- List loaded programs/maps:
bpftool prog show bpftool map show ls -al /sys/fs/bpf mount | grep bpf # unexpected mounts?
- Look for suspicious pins (odd names, unexpected owners), non-root namespaces mounting BPF, or BPF objects owned by service accounts.
- Audit BPF syscalls:
auditctl -a always,exit -F arch=b64 -S bpf -k bpf-load ausearch -k bpf-load
- Correlate with process ancestry (who invoked
bpf()
?) and recent privilege escalations.
Hardening checklist (immediate actions)
- Restrict capabilities: Drop
CAP_BPF
andCAP_SYS_ADMIN
in containers and systemd services by default. - Enable LSM enforcement: SELinux enforcing or AppArmor profiles that block unapproved BPF loads.
- Lock down BPF FS: Limit access to
/sys/fs/bpf
; disable unneeded BPF features on hardened hosts. - Signed eBPF programs only: Use a loader that verifies signatures; maintain an allow-list of approved BPF object hashes.
- Kubernetes: PSP/OPA/Gatekeeper constraints to ban privileged pods and cap dangerous capabilities; review CNI/eBPF agents.
- Monitoring: Ship regular
bpftool
inventories; alert on new pins, new mounts, or changes to BPF maps.
Incident response: if you suspect BPF-based stealth
- Isolate the node (cordon/drain in K8s, detach from load balancers).
- Snapshot BPF state:
bpftool prog dump xlated id <ID> bpftool map dump id <ID>
- Unpin and detach unknown programs; reboot if hooks re-attach.
- Rotate credentials touched by the host; redeploy from trusted images.
Related on CyberDudeBivash
Security Essentials (sponsored)
Disclosure: We may earn a commission if you buy via these links. It helps keep our research free.
#Linux #eBPF #Rootkit #KernelSecurity #XDP #Syscall #Kubernetes #EDR #SOC #DFIR #DevSecOps #CloudSecurity #RedTeam #BlueTeam #ZeroTrust #US #UK #EU #Australia #India
Comments
Post a Comment