How to catch BPFDoor before it strikes: Smart telco detection tips

In recent years, Advanced Persistent Threat (APT) groups have turned their focus toward mobile networks, seeking access to high-value assets such as subscriber data and the ability to conduct large-scale surveillance. Recently, an alarming case involved an intrusion at a mobile operator using a stealthy backdoor known as BPFDoor, which exposed millions of subscribers’ sensitive Universal Subscriber Identity Module (USIM) data. The attackers cleverly abused legitimate security mechanisms to gain a foothold and then remained hidden within the network for years, silently exfiltrating confidential data. The breach led to devastating consequences — from subscriber churn and hefty regulatory fines to personal accountability for C-level executives.

In this blog post, we will delve into the tactics employed by attackers to infiltrate mobile networks and leverage tools such as BPFDoor. Next, we will explore the crucial factors that enable these attacks in the mobile network and shift our focus to effective detection strategies. We will present compelling examples of detection approaches and outline the essential steps needed for the timely identification of such APTs in a mobile network. 

BPFDoor in telecom network

BPFDoor is a stealthy and persistent backdoor that seemingly has its roots all the way back to 2006. Since then, after multiple mutations, the present versions of BPFDoor were first detected in multiple telecommunication providers in 2021. It is believed to be linked with Red Menshen (also known as Earth Bluecrow), and the group has been active in targeting multiple telecommunication providers in Asia, the Middle East, and the African region since 2021. In this most recent case with a Southeast Asian mobile operator, multiple versions of the malware were used to establish backdoors inside the 4G Core network, including the Home Subscriber Server (HSS) that acts as a repository for subscriber credentials.

Fig 1: BPFDoor exploitation timeline in mobile networks

How does BPFDoor work?

The Berkeley Packet Filter (BPF) is a kernel feature that allows user-space programs, such as tcpdump (common utility to capture network traffic), to inspect raw network traffic without needing to open sockets on specific ports. It works by attaching a filter program to a network interface, which then decides which packets are delivered to which process.  

Using the BPF, the BPFDoor malware installs itself as a stealthy listener, monitoring all incoming packets. This allows it to detect a specific “magic packet” to trigger the malware and to open a connection to the Command and Control (C2) server. Once BPFDoor is installed, it becomes stealthy and difficult to detect. Behavior-based detection capability of common Endpoint Detection and Response (EDR) systems, which rely on process activity, is blind to a dormant BPFDoor malware. These characteristics make it a rather lucrative backdoor for telecom networks, where effective EDR systems are often absent.

Fig 2: BPFDoor targeting telecom network

To grasp the effectiveness of BPFDoor and to learn how to detect and protect against it, it is crucial to understand the Tactics, Techniques, and Procedures (TTP) employed by the attacker. Figures 2 and 3 provide insights based on observed cases.

1. The attacker begins by probing publicly accessible servers of the target. In a mobile network, management servers or jump hosts are typically exposed to remote access for use by internal employees or contractors. The attacker can employ several techniques to gain access to these Internet-facing servers, including password brute-forcing, utilizing commonly known passwords, and exploiting both known and unknown vulnerabilities.  

2. Once gaining foothold on the public-facing server, the attacker can harvest access credentials and recon network paths for other high value servers e.g., Home Subscriber Server (HSS) in the network. This opens doors for the attackers to laterally move and further infect the network. 

The attacker maintains persistence in the network through compromised servers. They can use a variety of tools for persistence, such as installing multiple backdoors, creating new Operations, Administration, and Maintenance (OAM) accounts, and using enduring or default passwords for continued access. The attacker can secretly maintain Command and Control (C2) communication over the backdoors they have installed.

3. Once the attacker gains access to internal nodes, they deploy BPFDoor along with other backdoors such as CrossC2, Sliver, and TinyShell to ensure the infection persists within the network. BPFDoor requires elevated privileges to operate. In the context of cloud-native 5G deployments, this means that the attacker can run it in privileged containers or directly on the nodes that host the workloads. For both virtualized and physical network functions, BPFDoor can often be installed as long as the attacker has access to the Linux environment or can escape from restricted shells to execute the payload.

4. Finally, the attacker collects sensitive data with a range of techniques, including running queries in the database and monitoring network traffic. Data is exfiltrated via C2 channel, or a separate proxy connection via a server with access to the Internet.

Now, let's focus on two key characteristics of BPFDoor that distinguish it from other types of malware: stealthiness and persistence. Stealthiness allows BPFDoor to conceal its presence, even when detection tools are active. Persistence ensures that it remains functional even after a system reboot or partial cleaning. Below, we will outline notable evasion and persistence techniques employed by BPFDoor and explain why they are difficult to detect with detection tools.

Why detecting BPFDoor in mobile network is challenging?

When it comes to detecting advanced threats like BPFDoor in a mobile network, it is essential to first step back and look at the network architecture and operational model of a mobile network. A secure telco environment should follow defense-in-depth and zero trust principles as recommended in industry guidance.

The foundation starts with secure product development — building telco applications in line with 3GPP security requirements and proven secure coding practices. Once deployed, these applications must be hardened and run within properly segmented networks supported by layered security controls (e.g., firewalls, IDS/IPS, anomaly detection). Finally, the Security Operations Center (SOC) layer comes into play: enforcing policies, monitoring deviations, and ensuring rapid detection and response to incidents that bypass preventive defenses. 

But here is the challenge: mobile networks are not static. Operators often run multi-generation deployments (2G, 3G, 4G, and 5G) in parallel. This means supporting a mix of legacy PNFs, virtualized VNFs on different OS versions, and modern cloud-native containerized network functions. The result is a highly complex ecosystem with varied security postures across generations. For SOC teams, maintaining visibility and enforcing consistent security controls in such an environment is non-trivial.

The ability to detect threats such as BPFDoor in the telecom network requires extensive visibility into the various assets deployed in the network, and this can often be a challenge on its own. In general, modern cyber threat detection heavily relies on EDR solutions together with log aggregation to SIEM due to the level of visibility and detection capability they can often provide. In mobile networks, having and deploying an EDR solution is not as straightforward as in IT networks due to multiple differences and challenges.

Mobile network functions are purpose-built applications that often run on top of a customized Linux operating system. The applications and the OS can be customized at a very low level to improve network throughput or reduce latency, effectively creating highly purpose-built functions for the network. EDR systems rely on components and features of operating systems to provide the required visibility and telemetry for threat detection. These components and features can include hooking library functions, utilizing the auditd framework, using Windows ETW, kernel modules, and eBPF probes. When demanding very high uptime (99.999 percent) and high throughput, the margins for error get very low. EDR that introduces low-level changes in the operating system and latency in processing operating system API calls can have a negative impact on the network functions. Therefore, thorough testing and evaluation of the EDR solution is essential for safe deployment.

After the challenges of deploying an EDR solution in a mobile network are overcome, the second round involves telecom and operating system-specific threat detection capability. EDR is a well-established concept in the Windows operating system, and most of the vendors provide exceptionally good capabilities there. When it comes to Linux, there are fewer options, and they are overall less mature compared to Windows. Telco networks and customized applications and practices also introduce a heap of false positive cases. Most EDR vendors lack expertise in 4G or 5G networks to tailor EDR capabilities, and to provide low-noise threat detection capability on mobile network functions. Not to mention the shortcomings of expertise on application-level threat detection or the lack of focus in the telecom domain. 

As a summary, general EDR solutions are, by default, not suitable for telecom networks due to a lack of testing, a lack of telecom domain focus and expertise, noise-level, and basic Linux support. Mobile operators deploying EDR solutions should pay close attention to coverage and effectiveness of the detection techniques for telco applications and protocols, compatibility with deployed telco nodes, and efficiency it can bring for SOC operations. 

Detecting BPFDoor in Telco network

In this section, we focus on effective detection of BPFDoor within mobile networks, specifically by analyzing the Tactics, Techniques, and Procedures (TTPs) employed by attackers. 

In mobile networks, Advanced Persistent Threat (APT) actors primarily target sensitive subscriber data. Due to the strategic importance and sensitive nature of this data, mobile operators implement strong security measures to protect these assets. However, threat actors employ various techniques to bypass these security controls. They may hide their traces, frequently change their tools, exploit known and unknown vulnerabilities, take advantage of misconfigurations, and operate persistently over extended periods to achieve their goals. For instance, in the case of BPFDoor, attackers may modify shell logging configurations to conceal their activities, utilize benign process names like smartd and apply BPF filters without open ports, all of which help them evade detection. By using TTP-based detection methods, defenders in mobile networks can correlate unusual events, flag kernel-level behaviors, and identify unusual persistence mechanisms. These tools enable mobile network defenders to identify the implant from multiple points despite its stealthy nature.

In Figure 3, we list typical TTPs used by the threat actor behind BPFDoor in the context of mobile network. The red boxes display the observed kill chain. Black boxes show a few examples of telco-specific techniques, while not observed to be used, an attacker may divert to succeed.

Fig 3: Threat actors kill chain in telecom network

Read above image as pdf

Example detection of BPFDoor and the threat actor in Kubernetes-based stack

Modern telecommunications applications are developed as Containerized Network Functions (CNFs) and are deployed on a telco-optimized cloud stack. At the base of this stack is the cloud infrastructure layer, which can include bare-metal servers, private clouds, and even public cloud resources. Above this layer, Kubernetes runs along with specialized extensions designed specifically for telecom needs, and CNFs operate on the Kubernetes platform. For instance, in the 5G core network, critical network functions such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Data Management (UDM) are deployed as CNFs within Kubernetes pods. 

In the following sections, we will explain how BPFDoor can be deployed within CNFs and Kubernetes-based environments, as well as outline an approach for detecting it using simplified TTP (Tactics, Techniques, and Procedures) steps. 

Initial access: In the context of a Kubernetes-based stack, threat actor could infiltrate the host running the CNF through several paths. They might exploit a vulnerable container image, abuse host or CNFs credentials, or exploit a privileged pod to gain host level access.  Detection at this stage can focus on identifying the attacker’s initial access techniques. For example, monitoring the kube-audit logs for unusual activity around Kubernetes secrets, suspicious new privileged containers, logins from unexpected locations, high number of failed logon attempts.

To prevent initial access, ensure that the baseline security configuration across the deployment adheres to security best practices.

Fig 4: BPFDoor detection in Kubernetes based telco stack

Persistence and defense evasion: Unlike typical malware, BPFDoor does not rely on open ports or obvious binaries. Instead, it installs Berkeley Packet Filters (BPF) into the Linux kernel, enabling it to silently inspect network packets. In a Kubernetes environment, this means that even if pods are rescheduled or restarted, the backdoor can persist at the node level. As mentioned earlier, BPFDoor is particularly adept at evading detection; it disguises itself as legitimate system processes and disables command history. Since Kubernetes observability tools primarily focus on pod-level metrics and logs, BPFDoor’s presence would remain unnoticed without specialized runtime security tools. Detection strategies in this context concentrate on:

1. Use known indicators of process names for detection inside containers or host nodes. New process monitoring requires enabling and using an auditd framework or an EDR solution with container awareness.
2. Monitor syscalls related to the BPF functionality: a process creating a socket and setsockopt(SO_ATTACH_BPF) activity for installing a new Berkeley Packet filter. This approach requires an EDR with Linux syscall monitoring capability and relevant threat detection rules.
3. Monitor for processes where the process executable path does not exist on disk. This requires active scanning with a forensics-capable tool while the process is running or an EDR with the capability to compare processes against disk.
4. Alert on modifications to the HISTFILE environment variable and on deleting shell history files. Implement relevant auditd rules and collect the log events or use an EDR with visibility over Linux environment variables and file system changes.

These detection approaches can be noisy, as BPF is legitimately used by utilities such as tcpdump. Therefore, it is important to understand how BPF filters are being utilized by existing telco applications and filter out false positives.

Lateral movement: The attacker moves laterally with harvested credentials. In a Kubernetes deployment, traffic often flows through pod-to-pod, node-to-node, or node-to-pod. An attacker can use Kubernetes credentials to move towards other pods. Detection here can focus on:

1. SSH authentication or kubectl exec activity from/to unusual destinations, unusual times, or accounts.
2. In a Kubernetes core deployment, activity from nodes towards pods can take place as part of cluster management/debugging activity. It is also possible that OAM activity towards CNF OAM interfaces originates from the Kubernetes infrastructure. Identifying the abnormality of this traffic activity is one way to identify lateral movements.

C2 and exfiltration: BPFDoor handles Command and Control (C2) and Exfiltration in ways that can blend into Kubernetes networking. Instead of maintaining a clear external connection, it listens to magic packets that activate its C2 channel. Because Kubernetes clusters rely heavily on east–west traffic between services, these packets can be disguised as normal pod-to-pod communication. Once triggered, BPFDoor can start collecting subscriber data using several techniques. Detection here can focus on:

1. Detection of anomalous activity around the subscriber database management system, e.g. attempts to directly access the sensitive containers via the container orchestration layer, attempts to access sensitive data directly in the memory of the running processes, attempts to generate or configure process memory dumps, attempts to extract sensitive keys related to protecting subscriber data.
2. Monitor suspicious database queries in sensitive data storage, e.g., UDR database queries. Monitor for service-based interface (SBI) for suspicious activity around network functions accessing UDM/UDR interfaces. Extensive SBI API logs and collection are required to provide monitoring capability.
3. An alternative method to endpoint and log-based threat detection with network monitoring; looking for anomalous outbound data flows and sudden large data transfers across hosts which normally don't do such activity.

In summary, effectively detecting BPFDoor within Kubernetes environments requires tracing the attacker’s TTPs in the specific context of a telco deployment. To minimize false positives, it is essential to understand the characteristics of telecom infrastructure, workloads, and normal application behavior.

Conclusion

BPFDoor poses a significant threat to telecom security. Its stealth, persistence, and kernel-level packet inspection capabilities enable it to infiltrate the most sensitive parts of the telecom core while remaining undetected for years. It can be deployed across various generations of telecom networks, from legacy network functions to cloud-native functions in 5G. The implications of BPFDoor could compromise subscriber privacy, undermine trust in mobile operators, and potentially disrupt national communications infrastructure. For these reasons, Advanced Persistent Threats (APTs) and tools like BPFDoor present serious risks that must be systematically addressed.

First and foremost, a telecom environment should adopt defense-in-depth and zero trust principles to limit an attacker’s exposure to the network. Additionally, telecom network operations should maintain extensive visibility into the various assets deployed throughout the network without compromising performance. This can be accomplished by deploying purpose-built detection tools specifically designed for telecom workloads, ensuring minimal performance impact. Finally, a purpose-built detection tool equipped with tuned attacker tactics, techniques, and procedures (TTP) can provide effective detections from multiple points while minimizing noise from false detection. This approach results in quicker detection times, even when the implant operates stealthily.

Holistic protection from APTs using Ericsson Security Manager

Ericsson Security Manager is the 5G cybersecurity platform that addresses the needs of next-generation security operations by making security visible and automating the security processes. Ericsson Security Manager is pre-integrated with the Ericsson product portfolio, with multivendor capability to fully automate orchestration flows, including discovery of network assets. It offers purpose-built cyber defense capabilities for mobile networks.

Extended Detection and Response (XDR), a key ESM feature, delivers purpose-built detection and response against APTs across the telecom stack. It operates at all levels – from an operating system to telecom applications and services – covering all generations of networks in a comprehensive manner. This feature delivers fine-tuned and tested threat detection specifically for mobile networks, effectively addressing APTs. Additionally, it provides crucial situational awareness and can quickly and automatically share detections with security operations through seamless integration of tools and processes.

References

• MITRE BPFDoor
• Zero Trust Architecture for advancing mobile network security operations
• Securing networks against sophisticated threats – Ericsson’s approach
• Telecom security for a safer connected world

Read more:

Discover how 5G core unleashes a new era of scalable and service-rich cloud-native networks.

Explore 5G core solutions that make it possible for you to deploy, scale and evolve your operations across multiple deployment scenarios.

Explore the fundamentals of modern network architecture and how it is driving a new era of agile, cloud-native network operations.

Learn more about zero trust security and how it protects most of today's ICT infrastructures worldwide.