eBPF rootkit in Linux: DB leak via contractor

eBPF Rootkit via Contractor: Detecting Hidden Database Leaks in Linux

A database server running Ubuntu was generating 5–10% more outbound traffic than inbound traffic for a month. Logs and processes appeared clean, and the provider confirmed normal network operation. An audit revealed an eBPF rootkit deployed through a compromised laptop belonging to a DBA contractor. Attackers used the supply chain to install a program that hid processes and exfiltrated PII data to a C2 server.

First Clue: Suspicious iptables Rule

In /etc/iptables/rules.v4, a rule appeared allowing outbound TCP connections to an IP from the contractor's VPN pool:

-A OUTPUT -d xxx.xxx.xxx.xxx -p tcp --dport YYYY -j ACCEPT

This rule was not part of the base configuration. It allowed stealthy transmission of compressed database table dumps. Analysis of /var/log/auth.log showed SSH key login from the contractor with an IP from the same pool. Server access was revoked after work, but the VPN remained active.

Mismatch in /proc Pointed to Rootkit

The ps auxf command displayed standard processes, but the number of directories in /proc exceeded the PID count by one. This indicated interception of the getdents and getdents64 system calls. Checking /proc/modules and analyzing kernel memory with a LiveCD revealed no LKM modules—the list matched the baseline.

eBPF as the Rootkit Foundation: Implementation Details

The bpftool utility revealed eBPF programs attached to kprobe points __x64_sys_getdents and __x64_sys_kill. An additional socket program redirected traffic. In /usr/share/man/man3/, a binary named systemd-snoop was found, loading eBPF via libbpf.

The malware dumped PII tables at night, compressed them, and sent them to the C2 server. eBPF is not visible in the module list because it loads via the bpf() syscall. Detection requires root privileges for bpftool or kernel memory analysis. In this case, the objects were not hidden.

Attack Scenario

• Contractor's laptop compromised.
• During scheduled work via SSH key—login to the server.
• Addition of iptables rule and installation of systemd-snoop.
• Nightly data exfiltration via eBPF proxy.

Methods for Detecting eBPF Rootkits

Standard AIDE is ineffective—eBPF does not modify files in /lib/modules. Recommended approaches:

• Periodic collection of bpftool prog list and bpftool map list with forwarding to SIEM.
• Auditing the bpf() syscall via auditd or ebpf_exporter.
• Monitoring with Falco, Tracee, or Osquery for anomalous eBPF activity.
• Analyzing NetFlow for traffic discrepancies and correlating with GeoIP.

Protecting the Supply Chain from Contractors

Authentication and Access

• Mandatory 2FA for SSH even with keys.
• Minimal privileges: no root access, only through a bastion host with session logging.
• Key rotation every 6 months, revocation within 24 hours upon termination.
• Temporary VPN sessions with auto-disconnect.

Infrastructure

• GitOps for firewall: iptables changes only via Ansible with Git control.
• Centralized ELK/Graylog + SIEM for correlating logs, NetFlow, and GeoIP.

Key Takeaways

• eBPF rootkits hide processes, are not visible in /proc/modules, and are detected via bpftool.
• Attack via contractor: laptop compromise + lingering VPN access.
• Symptoms: traffic asymmetry, PID mismatch in /proc.
• Protection: 2FA, bastion host, bpf() auditing, NetFlow monitoring.
• Tools: Falco, Tracee, ebpf_exporter for runtime detection.

This case demonstrates how a minor traffic anomaly uncovered a year-long data exfiltration. Implementing proactive eBPF monitoring and strict access control minimizes risks from external teams.

— Editorial Team