Ekaterina Gainullina, Security Vision
Introduction
If in first part we talked about espionage and surveillance, now we will talk about actions. An attacker who has gained access to a system rarely limits himself to passive information gathering - he needs control. And eBPF, as a universal kernel injection mechanism, gives this control literally "at the root": at the level of system calls, network stack, security and kernel subsystems.
The possibilities of interference are great in their precision and stealth. With eBPF, you can turn a Linux machine into a personalized firewall, a sabotage platform, a network repeater — and all this without a single byte on the disk, without a single line in cron, without a visible process in ps. In this part, I will analyze how an attacker can use eBPF to intercept, modify and sabotage system behavior: from filtering packets to manipulating process launches and implementing shadow security policies. This is not a fantasy, not a hypothesis — it has already happened. And it can happen again.
Part 2. Manipulation – filtering and changing traffic
It's not just about surveillance - eBPF allows not only eavesdropping, but also interference with the system. One of the most tempting possibilities for an attacker is to create a stealth firewall or backdoor at the kernel level. For example, eBPF programs like XDP (eXpress Data Path) are executed at the earliest stage of receiving a network packet, before the packet is processed by the Linux network stack. This means that malware with eBPF can drop unwanted packets, redirect them, or even spoof them, before any iptables or traffic monitoring tools. Similarly, programs at the tc (Traffic Control) can filter traffic at the input/output stages of a network interface.
Let's look at a simple example: suppose an attacker wants to block a certain type of traffic - say, ICMP Echo Request (ping) – so that its infected server is not pinged (hidden from simple scanners), or to filter out ICMP traffic from monitoring systems. Below is a fragment of the eBPF program XDP, which discards all ICMP packets passing through the network interface:
// XDP - program for blocking ICMP -packets
SEC("xdp")
int block_icmp(struct xdp_md *ctx) {
void *data = (void *)( unsigned long) ctx ->data;
void * data_end = (void *)( unsigned long) ctx -> data_end ;
// Examination the presence of an Ethernet header
if (data + sizeof (struct ethhdr) > data_end) {
return XDP_PASS;
}
struct ethhdr *eth = data;
// Interested IPv4 packets only
if (eth-> h_ proto ! = bpf_htons (ETH_P_IP)) {
return XDP_PASS;
}
// Check for the presence of an IP header
struct iphdr * ip = data + sizeof (struct ethhdr);
if ((void *) ip + sizeof (* ip) > data_end) {
return XDP_PASS;
}
// If protocol = ICMP (1) – discard packet
if (ip ->protocol == IPPROTO_ICMP) {
return XDP_DROP;
}
// Otherwise, skip the packet further
return XDP_PASS;
}
How it works: a program like XDP is bound to a network interface (e.g. eth 0) and is run for every incoming packet. In the code, we parse the Ethernet header, verify that it is an IPv4 packet, then read its IP header. If the protocol field is IPPROTO_ICMP (1), the function immediately returns XDP_DROP, telling the kernel to drop the packet. For all other packets, XDP_PASS is returned, and they continue to be processed normally by the network stack. So, while this eBPF program is active, any attempts to ping the machine or other ICMP traffic will be silently blocked at the lowest level - without the firewall or applications above knowing.
An attacker can filter not only ICMP. With minor changes, eBPF can block, for example, connections to certain ports or IP addresses. You can implement a blacklist of addresses directly in eBPF (via map) and drop any packets from these addresses. Or vice versa - quietly discard the traffic of port scanners, making a certain port visible only to "their own". In the publicly known backdoor BPFDoor, for example, the BPF socket filter was used, which allowed receiving commands on any port, viewing all incoming traffic and isolating special "magic" control packets. Such secrecy is achieved precisely because eBPF "eavesdrops" on packets before the network stack: BPFDoor did not open a listening socket on a fixed port, instead, the eBPF program inside the kernel checked each incoming packet for a command sign, and if a command was detected, it redirected it to the user backdoor process. From the administrator's point of view, no suspicious ports are visible in netstat, and commands come "out of nowhere".
In addition to dropping packets, eBPF also allows changing traffic on the fly. An XDP program can rewrite the contents of a packet (for example, replace addresses or ports) and send it on (XDP _ TX or XDP _ REDIRECT). At the tc level eBPF program can modify or delay packets. For an attacker, this opens the door to MITM attacks inside the kernel: it is possible to inject malicious code into transmitted data, obfuscate traffic, hide one's presence. For example, advanced malware Symbiote combined network function interception via LD_PRELOAD and BPF filtering: it inserted its filter when calling setsockopt() so that tcpdump and other sniffers did not see malware -related traffic .
It is important to emphasize that eBPF network-level programs operate very quickly (close to the processing speed of a network card) and with minimal overhead. Therefore, an attacker using eBPF can build a hidden and effective firewall for his own purposes. He can selectively block packets from security tools (for example, from SIEM agents or scanners) or, on the contrary, allow himself to bypass system policies. Moreover, classic monitoring tools may not even notice that packets are being dropped - they simply do not reach the level where they are usually logged.
But manipulations are not limited to network packets. An attacker can also use eBPF to interfere with system calls, introducing sabotage and restrictions directly at the kernel level. For this, so-called kprobes are used - mechanisms that allow intercepting the execution of any kernel function by name and launching their eBPF program at the moment of its call. For example, it is possible to interfere with the work of the execve call, which is responsible for launching new processes.
Consider this scenario: an attacker wants to temporarily disable an antivirus or security scanner to download a payload. Instead of deleting or modifying files, he can simply inject an eBPF program that will sabotage execve() calls to certain executables.
Here is an example eBPF program that blocks top and ps from running:
#include < vmlinux.h >
#include < bpf / bpf_helpers.h >
#include < bpf / bpf_tracing.h >
char TARGET1[] = "/ usr /bin/top";
char TARGET2[] = "/ usr /bin/ ps ";
// Kprobe: triggered when sys_execve is called
SEC("kprobe/sys_execve")
int block_execve(struct pt_regs *ctx) {
const char __user *filename = (const char *)PT_REGS_PARM1(ctx);
char buf [ 128];
// Read the executable file name from user space
bpf_probe_read_user_ str (buf, sizeof (buf), filename);
// Comparison with targets files
if (__ builtin_ memcmp (buf, TARGET1, sizeof (TARGET1)) == 0 ||
__ builtin_memcmp (buf, TARGET2, sizeof (TARGET2)) == 0) {
bpf_printk ("Blocked execve of: %s\n", buf);
// Ideally, return an error - but you can't change the behavior in kprobe,
// this will require using LSM or kretprobe.
}
return 0;
}
Note: Direct behavior modification is only possible via LSM hooks or kretprobe, but even logging attempts to launch monitoring utilities already gives the attacker an advantage: he can find out when they are trying to detect him - and go into the shadows in time.
This mechanism allows for "selective sabotage" to be implemented - for example, to prohibit the launch of only certain programs, masking the activity. Or, conversely, to allow the launch of only the "white list", turning eBPF in the kernel into an unofficial execution policy mechanism (similar to AppArmor, but invisible).
Intervention via LSM hooks. Since Linux 5.7, eBPF has gained the ability to connect to Linux hooks Security Modules (LSM). These are the same points through which SELinux, AppArmor, TOMOYO and other policies are implemented. Hooks are called when checking permissions to access files, processes, networks, etc.
If previously such policies were implemented as kernel modules or patches, now you can dynamically connect an eBPF program that will interfere with the decision-making process - allow or prohibit actions. Moreover, you can do this covertly and flexibly: for example, allow access to a closed file only with a certain UID, or hide a directory from all processes except one.
A program using the LSM hook file_open is triggered every time someone in the system tries to open a file. In an eBPF program, you can read the file name from the dentry structure and check if it belongs to a protected directory, such as /etc/hidden. If the file matches the specified criteria, an additional check is performed: the UID of the current process is compared. Only if the UID matches the "allowed" one (for example, 1337), access to the file will be allowed. Otherwise, the program returns an error - EACCES, thereby prohibiting opening the file. From the outside, this looks like a normal access error - as if the file is really closed to the user. Neither system logs, nor commands like strace, nor monitoring utilities like auditd can show the fact of interference. For all other processes, this file becomes "invisible".
This approach allows an attacker to flexibly and unnoticeably restrict access to confidential data. It is possible to hide configuration files, binaries, scripts or plugins associated with the backdoor. Moreover, this mechanism can replace or complement traditional security policies - such as SELinux or AppArmor - but at the same time remains completely unobvious to the administrator. Unlike official LSM profiles, these restrictions are not configured through configuration files, but are sewn directly into the kernel using eBPF. At the same time, the behavior can change dynamically: an attacker can "open" a directory for a while and "close" it again on a signal - all this without leaving any traces in the logs or on the disk.
Technically, loading eBPF programs that use LSM hooks requires superuser privileges: specifically, CAP_BPF and CAP_SYS_ADMIN. This means that this mechanism is most often used on an already compromised system, where the attacker has gained root access. However, after loading, the program can be pinned to the bpffs virtual file system, allowing it to survive process restarts and even persist between sessions without autoloading or modifying system files. In addition, this method of intervention does not require loading kernel modules: insmod is not used, no new entries appear in lsmod, and even an antivirus such as rkhunter may not notice anything.
Thus, LSM hooks turn eBPF into a tool not only for monitoring or filtering, but also for shadow security management, parallel to official mechanisms. This is especially dangerous if an organization relies on AppArmor or SELinux but does not monitor active eBPF programs - in this case, the rules can be overwritten by "invisible" policies right at the kernel level.
Conclusion
In this part, we saw how eBPF can transform from a “surveillance tool” into a full-fledged weapon of influence. From silently filtering network traffic at the XDP level to pinpointing system call sabotage via kprobe and injecting invisible security policies via LSM, an attacker can literally rewrite system behavior on the fly.
Stealth is especially dangerous: most of these manipulations leave no traces in logs, do not require additional processes, and are not written to disk. They live in kernel memory, under the protection of the verifier and CAP_SYS_ADMIN, but can remain invisible for years - if no one knows to look for them.
For an attacker, this gives complete control: from network traffic to process execution and data access. And for a defender, it's a call to action: if you don't track active eBPF programs, don't check hooks and attachment points, don't audit bpffs content, you're blind.
In the next part, we will talk about how an attacker can ensure the persistence of their eBPF tools in the system: hide from auditors, bypass EDR, survive reboots and stay under the radar. Because a real intrusion is not something that happens, but something that remains.
.jpg)
