{
	"id": "ffb294a6-e54f-4b28-8736-256638595ee3",
	"created_at": "2026-04-06T00:10:26.960865Z",
	"updated_at": "2026-04-10T03:33:12.090722Z",
	"deleted_at": null,
	"sha1_hash": "cfc697ef692ebb109dce35cb62ae14df98a7b36f",
	"title": "BPFdoor in Telecom Networks: Sleeper Cells in the Backbone",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 8927695,
	"plain_text": "BPFdoor in Telecom Networks: Sleeper Cells in the Backbone\r\nBy Rapid7 Labs\r\nPublished: 2026-03-26 · Archived: 2026-04-05 22:32:31 UTC\r\nExecutive overview\r\nThe strategic positioning of covert access within the world’s telecommunication networks\r\nA months-long investigation by Rapid7 Labs has uncovered evidence of an advanced China-nexus threat actor,\r\nRed Menshen, placing some of the stealthiest digital sleeper cells the team has ever seen in telecommunications\r\nnetworks. The goal of these campaigns is to carry out high-level espionage, including against government\r\nnetworks.\r\nTelecommunications networks are the central nervous system of the digital world. They carry government\r\ncommunications, coordinate critical industries, and underpin the digital identities of billions of people. When\r\nthese networks are compromised, the consequences extend far beyond a single provider or region. That level of\r\naccess is, and should be, a national concern as it compromises not just one company or organization, but the\r\ncommunications of entire populations.\r\nOver the past decade, telecom intrusions have been reported across multiple countries. In several cases, state-backed actors accessed call detail records, monitored sensitive communications, and exploited trusted\r\ninterconnections between operators. While these incidents often appear isolated, a broader pattern is emerging.\r\nWhy telecom networks are strategic espionage targets\r\nTelecommunications infrastructure provides a uniquely valuable strategic positioning.\r\nModern telecom networks are layered ecosystems composed of routing systems, subscriber management\r\nplatforms, authentication services, billing systems, roaming databases, and lawful intercept capabilities. These\r\nsystems rely on specialized signaling protocols such as SS7, Diameter, and SCTP to coordinate identity, mobility,\r\nand connectivity across national and international boundaries.\r\nPersistent access within these environments enables far more than a conventional data breach. An adversary\r\npositioned inside the telecom core may gain visibility into subscriber identifiers, signaling flows, authentication\r\nexchanges, mobility events, and communications metadata. In the most concerning scenarios, this level of access\r\ncould support long-term intelligence collection, large-scale subscriber tracking, and monitoring of sensitive\r\ncommunications involving high-value geopolitical targets.\r\nTelecommunications networks sit at the intersection of identity, mobility, and global connectivity. Compromise at\r\nthis layer carries national and international implications.\r\nA structured campaign, not isolated incidents\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 1 of 17\n\nWhat looks like discrete breaches increasingly resembles a repeatable campaign model designed to establish\r\npersistent access inside telecommunications infrastructure.\r\nOur investigation uncovered a long-term and ongoing operation attributed to a China-nexus threat actor. Rather\r\nthan conducting short-term intrusion activity, the operators appear focused on long-term positioning by embedding\r\nstealthy access mechanisms deep inside telecom and critical environments and maintaining them for extended\r\nperiods.\r\nIn effect, attackers are placing sleeper cells inside the telecom backbone: dormant footholds positioned well in\r\nadvance of operational use.\r\nAcross investigations and public reporting, we observe recurring elements: kernel-level implants, passive\r\nbackdoors, credential-harvesting utilities, and cross-platform command frameworks. Together, these components\r\nform a persistent access layer designed not simply to breach networks, but to inhabit them.\r\nFigure 1: Actors, tools and regions in which specific threat groups target the telecom sector\r\nHow BPFdoor enables covert, deep-seated persistence\r\nAt the center of this activity is BPFdoor, a stealth Linux backdoor engineered to operate within the operating\r\nsystem kernel.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 2 of 17\n\nUnlike conventional malware, BPFdoor does not expose listening ports or maintain visible command-and-control\r\nchannels. Instead, it abuses Berkeley Packet Filter (BPF) functionality to inspect network traffic directly inside the\r\nkernel, activating only when it receives a specifically- crafted trigger packet. There is no persistent listener or\r\nobvious beaconing. The result is a hidden trapdoor embedded within the operating system itself.\r\nThis approach represents a shift in stealth tradecraft. By positioning below many traditional visibility layers, the\r\nimplant significantly complicates detection, even when defenders know what to look for.\r\nOur research indicates BPFdoor is not an isolated tool, but part of a broader intrusion model targeting telecom\r\nenvironments at scale.\r\nHow attackers gain initial access to telecom environments\r\nThese findings reflect a broader evolution in adversary tradecraft. Attackers are embedding implants deeper into\r\nthe computing stack — targeting operating system kernels and infrastructure platforms rather than relying solely\r\non user-space malware.\r\nTelecom environments — combining bare-metal systems, virtualization layers, high-performance appliances, and\r\ncontainerized 4G/5G core components — provide ideal terrain for low-noise, long-term persistence. By blending\r\ninto legitimate hardware services and container runtimes, implants can evade traditional endpoint monitoring and\r\nremain undetected for extended periods.\r\nFor defenders, the implications are significant. Many organizations lack visibility into kernel-level operations, raw\r\npacket-filtering behavior, and anomalous high-port network activity on Linux systems. Addressing this threat\r\nrequires expanding defensive visibility beyond the traditional perimeter to include deeper inspection of operating\r\nsystem behavior and infrastructure layers.\r\nSharing intelligence responsibly\r\nOur investigation to identify potential victims is ongoing and, where potential compromise has been discovered,\r\nwe have notified affected parties through relevant authorities or direct communication with our customers.\r\nAs part of our responsible research process, we have collaborated with government partners and national CERTs\r\nto share findings and indicators associated with this activity. When our analysis identified infrastructure that may\r\nhave been impacted, we proactively notified the relevant organizations and provided detection guidance to assist\r\nwith investigation and response while the research was still underway.\r\nRapid7 Intelligence Hub customers have access to the full technical details and indicators of compromise within\r\nthe platform, including Surricata rules. Those rules are also available through AWS Marketplace, where we offer\r\nour curated AWS firewall rule sets. \r\nTechnical analysis\r\nThe sections that follow examine how modern telecommunications networks are structured, how initial access is\r\nestablished, and how BPFdoor and related tooling enable infrastructure-level persistence inside the telecom\r\nbackbone.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 3 of 17\n\nModern telecom network structure\r\nTo understand why telecom environments are such attractive strategic targets, it helps to visualize their layered\r\narchitecture (Figure 2). At the outer edge sit customer-facing services and access infrastructure: mobile base\r\nstations (RAN), fiber aggregation routers, broadband gateways, DNS services, SMS-controllers, roaming\r\ngateways, security appliances like firewalls, proxies, VPNs, and internet peering points. These edge systems\r\nconnect into the operator’s IP core and transport backbone, where high-capacity routers and switches move\r\nmassive volumes of voice, data, and signaling traffic across regions and international borders.\r\nFigure 2: Simplified version of a telecom provider’s network\r\n⠀\r\nDeeper inside lies the control plane, the heart of the telecom network, built around subscriber management\r\nsystems such as HLR/HSS or UDM, authentication platforms (AuC), policy control functions, billing systems,\r\nlawful intercept platforms, and roaming databases. These systems communicate using specialized telecom\r\nsignaling protocols such as SS7, Diameter, and increasingly SCTP-based signaling for LTE and 5G core\r\ncomponents. At the foundation, much of this infrastructure ultimately runs on hardened, but often standard, Linux\r\nor BSD-based bare-metal servers, virtualization stacks, and high-performance network appliances. When an\r\nadversary implants a persistent backdoor at the kernel level within these environments, they are not simply\r\ncompromising a server, they are positioning themselves adjacent to subscriber data, signaling flows, and the\r\nmechanisms that authenticate and route national and international communications.\r\nInitial access\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 4 of 17\n\nTelecom intrusions rarely begin deep inside the core. Instead, attackers focus on exposed edge services and\r\ninternet-facing infrastructure. Techniques such as exploitation of public-facing applications (T1190) and abuse of\r\nvalid accounts (T1078) are repeatedly observed. Devices commonly targeted include: Ivanti Connect Secure VPN\r\nappliances, Cisco IOS and JunOS network devices, Fortinet firewalls, VMware ESXi hosts, Palo Alto appliances,\r\nand even web-facing platforms like Apache Struts. These systems sit at the boundary between external traffic and\r\ninternal telecom environments, making them high-value entry points. Once compromised, they provide\r\nauthenticated pathways into the provider’s network, often without triggering traditional endpoint detection\r\nmechanisms.\r\nLet’s highlight some of the tools we observed during initial access and attempt to get more credentials for lateral\r\nmovement.\r\nCrossC2\r\nOnce initial access is secured, the operators frequently deploy Linux-compatible beacon frameworks such as\r\nCrossC2. This Cobalt Strike-derived loader enables beacon functionality on Linux hosts and has been repeatedly\r\nobserved in PRC-aligned intrusion campaigns. It provides the same post-exploitation capabilities traditionally\r\nseen in Windows environments, command execution, pivoting, staging, but tailored for Linux-heavy telecom\r\ninfrastructure. CrossC2 allows operators to blend into server environments that form the backbone of telecom\r\noperations, particularly edge devices and core routing systems. Just as with the Cross C2 configuration, investing\r\nreveals the C2 server. For example:\r\nFigure 3: CrossC2 configuration\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 5 of 17\n\n⠀\r\nTinyShell\r\nFor long-term persistence, actors often rely on TinyShell, an open-source passive backdoor framework repurposed\r\nand customized by multiple APT groups. TinyShell is frequently observed on boundary devices such as firewalls,\r\nVPN appliances, and virtualization hosts. Compiled for Linux and FreeBSD, it is designed with stealth in mind:\r\nminimal network footprint, passive communication model, and reliable remote command execution capabilities. \r\nKeyloggers and bruteforcers\r\nAfter foothold establishment, attackers focus on persistence and lateral movement. Tooling such as Sliver,\r\nCrossC2, and TinyShell are complemented by SSH brute forcers and custom ELF-based keyloggers. In some\r\ncases, operators deploy brute-force utilities containing pre-populated credential lists tailored for telecom\r\nenvironments, even including specific usernames like “imsi,” referencing subscriber identity systems. This level\r\nof contextual awareness indicates reconnaissance and targeting aligned with telecom operational terminology. The\r\ngoal is clear: move laterally, harvest credentials, and reach control-plane systems where subscriber data and\r\nsignaling infrastructure reside.\r\nBPFdoor\r\nBPFdoor first came to broader public attention around 2021, when researchers uncovered a stealthy Linux\r\nbackdoor used in long-running espionage campaigns targeting telecommunications and government networks. The\r\nBPFDoor source code reportedly leaked online in 2022, making the previously specialized Linux backdoor more\r\naccessible to other threat actors. Normally, BPF is used by tools like tcpdump or libpcap to capture specific\r\nnetwork traffic, such as filtering for TCP port 443. It operates partly in kernel space, meaning it processes packets\r\nbefore they reach user-space applications.\r\nBPFdoor abuses this capability. Rather than binding to a visible listening port, the implant installs a custom BPF\r\nfilter inside the kernel that inspects incoming packets for a specific pattern, a predefined sequence of bytes often\r\nreferred to as a “magic packet” or “magic byte.” If the pattern does not match, nothing happens. The traffic\r\ncontinues as normal. No open port or obvious process-accepting connections. But when the correct sequence is\r\ndelivered to the correct destination port, the behavior changes instantly.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 6 of 17\n\nFigure 4: Overview of BPF and how early BPFdoor variants are operating\r\n⠀\r\nImagine retrieving a parcel from a secure pickup locker. The locker sits quietly in public view, no alarms, no\r\nobvious signs of activity. It only opens when the correct code is entered.\r\nBPFdoor behaves the same way.\r\nThe implant remains dormant inside the Linux kernel, passively inspecting network traffic. It does not advertise\r\nitself. It does not respond to scans. But when an operator sends the correct “code”, the specific magic byte\r\nsequence embedded in a crafted packet, the BPF filter recognizes the pattern and triggers the next stage.\r\nInstead of opening a physical door, it spawns a bind shell or reverse shell. Importantly, this activation can occur\r\nwithout a traditional listening service ever being visible in netstat or ss. To a defender, the system appears clean;\r\nthere is no persistent open port to detect.\r\nBefore we showcase this, something important to note is that BPFdoor operations consist of two distinct\r\ncomponents: the implant and the controller. \r\nThe implant is the passive backdoor deployed on the compromised Linux system, where it installs a malicious\r\nBPF filter and silently inspects incoming traffic for a predefined “magic” packet. It does not continuously beacon\r\nor expose a listening port, making it extremely stealthy. \r\nThe controller, on the other hand, is operated by the attacker and is responsible for crafting and sending the\r\nspecially formatted packets that activate the backdoor and establish a remote shell. While it can be run from\r\nattacker-controlled infrastructure such as compromised routers or external systems, the controller is also designed\r\nto operate within the victim’s environment itself. In this mode it can masquerade as legitimate system processes\r\nand trigger additional implants across internal hosts by sending activation packets or by opening a local listener to\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 7 of 17\n\nreceive shell connections, effectively enabling controlled lateral movement between compromised systems. In\r\nessence, the implant acts as the hidden lock embedded within the system, while the controller functions as the key\r\nthat can activate it. A deeper technical analysis of the controller architecture and its role in lateral movement will\r\nbe covered in a forthcoming technical blog.\r\nTo demonstrate how these first backdoors work, we created the video below, in which we are running a BPFdoor\r\nmade visible. Next, we send the magic packet and instructions to the IP address and port we are listening on. Then\r\nthe BPFdoor opens up the “safe” and creates the tunnel. In the final part of the demo, we see that on our Netcat\r\nlistener, we have a remote shell and can query the system.\r\n⠀\r\nNext, we will highlight how we started to hunt for BPFdoor.\r\nHunting for BPFdoor variants\r\nSince we were aware of several BPFdoor attacks and samples circulating, we started hunting for more samples\r\nand developed internal tools to extract, compare, and detect early indicators of new features. One threat hunting\r\nangle Rapid7 Labs really loves to focus on is code similarity of samples. Code similarity of malware samples can\r\nresult in clusters of samples with similar activity, but most importantly, also demonstrate outliers that are potential\r\ncandidates for research since they do not share commodity with the other samples.\r\nThe BPFdoor samples we collected and hunted for are all Executable and Linkable Format (ELF) files, but we are\r\naware of samples compiled for running on Solaris. ELF is the standard binary file format for executables, object\r\ncode, shared libraries, and core dumps on Linux and Unix-like operating systems. For the ELF files, we wrote a\r\ncustom tool for clustering ELF/BPFdoor. By extracting .text section byte code blocks, generating MinHash\r\nsignatures, and completing a few other steps, it will then compute exact Jaccard similarity and export the resulting\r\nsimilarity graph for visual cluster analysis.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 8 of 17\n\nFigure 5: Code Similarity clustering of BPFdoor samples\r\n⠀\r\nIn our visualization, we clearly observe certain clusters of BPFdoor, but also outliers and smaller clusters that\r\nwere up for investigation. The thicker the line, the more similar the code is to the samples it is attached to. By\r\ncreating a feature comparison/extraction tool, we started to discover interesting features in the samples, which led\r\nus to a new controller discovery and security bypass feature. For example, we discovered a variant we dubbed “F”\r\nthat uses a 26 BPF instruction filter with new magic packets.\r\nAlthough it was previously reported that some samples support the Stream Control Transmission Protocol (SCTP),\r\nthere is a tendency to read over it and not put it into the right context of what the consequences are. SCTP is not\r\ntypical enterprise traffic; it underpins Public Switch Telephone Network (PSTN) signaling and real-time\r\ncommunication between core 4G and 5G network elements. By configuring BPF filters to inspect SCTP traffic\r\ndirectly, operators are no longer just maintaining server access, they are embedding themselves into the signaling\r\nplane of the telecom network. This is a fundamentally different level of positioning. Instead of sitting at the IT\r\nperimeter, the implant resides adjacent to the mechanisms that route calls, authenticate devices, and manage\r\nsubscriber mobility.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 9 of 17\n\nFigure 6: Example of SCTP route extracted from the BPF code\r\n⠀\r\nAccess to SCTP traffic opens powerful intelligence collection opportunities. In legacy and transitional\r\nenvironments, improperly secured signaling can expose SMS message contents, IMSI identifiers, and\r\nsource/destination metadata. By observing or manipulating traffic over SCTP commands such as\r\nProvideSubscriberLocation or UpdateLocation, an adversary can track a device’s real-world movement. In 5G\r\nenvironments, traffic over SCTP carries registration requests and Subscription Concealed Identifiers (SUCI),\r\nallowing identity probing at scale. At this point, the compromise is no longer about server persistence; it becomes\r\npopulation-level visibility into subscriber behavior and location. Translated, you could track individuals of\r\ninterest. \r\nInteresting observations\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 10 of 17\n\nThe bare-metal to telecom equipment link\r\nDuring the code investigations, we discovered that some BPFdoor samples are using code to mimic the bare-metal\r\ninfrastructure, particularly enterprise-grade hardware platforms commonly deployed in telecom environments. By\r\nmasquerading as legitimate system services that run only on bare metal, the implant blends into operational noise.\r\nThis is especially relevant in environments leveraging HPE ProLiant and similar high-performance compute\r\nsystems used for 5G core and edge deployments. \r\nFigure 7: Example of code mimicking HP Proliant servers\r\n⠀\r\nIn the above screenshot of one of the BPFdoor samples, we observed the processname “hpaslimited”.\r\nBy mimicking legitimate service names and process behavior of HPE ProLiant servers, attackers ensure the\r\nimplant appears native to the hardware environment, a tactic that significantly complicates detection. Several of\r\nthese service names have been observed in BPFdoor samples, but this name stood out. The hpasmlited.pid creates\r\nprocess threads, and mimics daemon-style behavior consistent with hardware monitoring services. The real\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 11 of 17\n\nhpasmlited process belongs to HPE’s Agentless Management Service, which runs on bare-metal ProLiant servers\r\nto expose hardware telemetry and system health data.\r\nBy adopting this name and writing a corresponding PID file, the malware blends into expected operational noise\r\non telecom-grade ProLiant infrastructure. Of course this is not accidental naming, it demonstrates environment\r\nawareness and targeting intent. The operators appear to know they are running on physical HPE hardware\r\ncommonly deployed in 4G/5G core and edge systems. By impersonating a trusted hardware management daemon\r\nthat administrators expect to see, the implant reduces suspicion during forensic review while embedding itself\r\ndirectly into the physical backbone layer of telecom infrastructure. This tactic reflects a broader strategy: hide not\r\njust in Linux, but in the hardware identity of the telecom environment itself.\r\nMimicking containers\r\nA second strategy involves spoofing core containerization components. Critical 5G core components such as the\r\nAccess and Mobility Management Function (AMF), Session Management Function (SMF), and User Data\r\nManagement (UDM) run as cloud native network functions inside Kubernetes pods. The following code excerpt\r\ndemonstrates that the implant is aware of it.\r\nFigure 8: Code showing the mimicking of container/docker service\r\n⠀\r\nDocker Daemon (/usr/bin/dockerd) and containerd: The malware is executed with root privileges and adopts the\r\nexact command-line arguments of a legitimate Docker daemon (e.g., -H fd:// --\r\ncontainerd=/run/containerd/containerd.sock).\r\nRecap for a moment\r\nUp to this point, what we’ve described in our technical analysis has, more or less, been publicly available\r\ninformation; however, these pieces have not been assembled in a way that provides the context Rapid7 Labs has\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 12 of 17\n\ndiscovered through its in-depth investigation. Therefore, before we deep dive into some of the new technical\r\nfindings that completes the picture of what is truly happening here, let’s pause for a moment to sync up on what\r\nwe’ve just described. \r\nSo far, our findings illustrate that BPFdoor is far more than a stealthy Linux backdoor. The kernel-level packet\r\nfiltering, passive activation through magic packets, masquerading as legitimate hardware management services,\r\nawareness of container runtimes, and the ability to monitor telecom-native protocols such as SCTP, point to a tool\r\ndesigned for deep infrastructure positioning. Rather than targeting individual servers, the operators appear to focus\r\non the underlying platforms that power modern telecommunications networks: bare-metal systems running\r\ntelecom workloads, cloud-native Kubernetes environments hosting Containerized Network Functions, and the\r\nsignaling protocols that coordinate subscriber identity, mobility, and communication flows. In this context,\r\nBPFdoor functions as an access layer embedded within the telecom backbone, providing long-term, low-noise\r\nvisibility into critical network operations.\r\nWhat Rapid7 found in newer BPFdoor variants\r\nThe following sections provide a high-level overview of several newly observed capabilities and behavioral\r\npatterns in recent BPFdoor samples. While these findings highlight important technical developments, this blog\r\nintentionally focuses on the architectural implications and operational context rather than a full reverse-engineering deep dive. Detailed technical analyses, including code-level breakdowns, will be published in\r\nupcoming research posts.\r\nDuring our investigation, we identified a previously undocumented variant of BPFdoor that introduces several\r\narchitectural changes designed to improve stealth and survivability in modern enterprise and telecom\r\nenvironments. We will highlight these features and illustrate how the malware continues to evolve beyond the\r\nearlier “magic packet” activation model.\r\nNetwork-level invisibility: The BPF trapdoor\r\nAs we described before, the early BPFdoor installed a Berkeley Packet Filter inside the Linux kernel that\r\ninspected incoming network traffic. When a specially crafted “magic packet” containing a predefined byte\r\nsequence arrived at the correct port, the backdoor would activate and spawn a shell. Because the system never\r\nactually opened a port, tools such as netstat, ss, or nmap saw nothing unusual.\r\nThe newly observed variant evolves this concept. Instead of relying on a simple magic packet that could\r\npotentially be detected by intrusion detection signatures, the trigger is now embedded within seemingly legitimate\r\nHTTPS traffic. The attacker sends a carefully crafted request that travels through standard network infrastructure\r\nsuch as reverse proxies, load balancers, or web application firewalls. Once the traffic reaches the compromised\r\nhost and is decrypted as part of normal SSL termination, the hidden command sequence can be extracted and used\r\nto activate the backdoor. In essence, in our previously mentioned analogy explaining the magic packet mechanism,\r\nthe safe still requires a code, but now the code is concealed inside normal, encrypted web traffic, allowing it to\r\npass through modern security controls before unlocking the trapdoor.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 13 of 17\n\nFigure 9: Overview of how the new sample communicates\r\nLayer 7 camouflage and the “magic ruler”\r\nTo remain reliable across proxy layers, the attackers introduced a clever parsing mechanism. HTTP proxies often\r\nmodify headers by inserting additional fields such as client IP addresses, timestamps, or routing metadata. These\r\nchanges can shift the position of data within the request and break traditional signature-based triggers. To solve\r\nthis problem, the attackers designed a mathematical padding scheme that ensures a specific marker, in the\r\nobserved samples the string “9999”, always appears at a fixed byte offset within the request.\r\nThis is where the 26-byte or 40-byte “magic ruler” comes into play. Rather than parsing the entire HTTP header,\r\nwhich can vary depending on proxy behavior, the malware treats the request body as a predictable coordinate\r\nspace. By carefully padding the HTTP request with filler bytes, the attacker ensures that the marker always lands\r\nexactly at the 26th byte offset of the inspected data structure. The implant simply checks this fixed position; if the\r\nmarker appears at that byte location, it interprets the surrounding data as the activation command.\r\nBecause the header itself can fluctuate while the padded payload remains predictable, the malware does not need\r\nto understand or parse the full HTTP structure. Instead, it relies on this fixed “measurement point”, effectively\r\nusing the 26-byte offset as a ruler inside the packet. This technique allows the trigger to survive proxy rewriting\r\nand header injection while still remaining hidden inside otherwise normal HTTPS traffic. The 26-byte rule is used\r\nin case of a socket creation with the “SOCK_DGRAM” flags, but in case of a “SOCK_RAW” flag, it will use a\r\n40-byte ruler.\r\nIn practice, this turns the messy, variable HTTP protocol into something the malware can treat like a fixed\r\ncoordinate system, enabling what could be described as dynamic Layer-7 camouflage, a surprisingly simple but\r\neffective technique for hiding command triggers inside legitimate encrypted web traffic.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 14 of 17\n\nThe RC4-MD5 paradox\r\nAnother interesting feature of the new controller is its continued use of the legacy RC4-MD5 encryption routine.\r\nWhile this combination is considered deprecated in modern cryptographic standards, it still appears in several\r\nmalware samples. In this case, the RC4-MD5 implementation is not part of TLS, but rather a lightweight\r\nencryption layer applied to the interactive command-and-control channel after the backdoor is activated. RC4\r\nprovides extremely fast stream encryption suitable for interactive shells, introducing minimal latency during\r\ncommand execution. In addition, the use of older or non-standard encryption routines can sometimes confuse\r\ninspection systems, particularly when traffic does not follow typical protocol expectations. Finally, reuse of older\r\ncryptographic modules often reflects code lineage and operational efficiency, adversaries frequently recycle\r\nproven components across campaigns. In this case, code comparison revealed similarities with routines that have\r\ncirculated in Chinese-nexus malware families such as RedXOR and PWNIX for several years.\r\nICMP control channel: “phone home”\r\nWhile earlier BPFdoor variants focused primarily on covert activation, the new sample also introduces a\r\nlightweight communication mechanism built around Internet Control Message Protocol (ICMP). The code excerpt\r\nshows the malware preparing an ICMP payload and inserting a specific value  “0xFFFFFFFF”  into a field\r\nbefore transmitting the packet using a dedicated routine (send_ICMP_data). At first glance this appears trivial, but\r\nthe logic reveals something more interesting: The ICMP packet is not just a signal back to the operator, it is also\r\nused as a control mechanism between compromised systems.\r\nFigure 10: ICMP Tunneling\r\n⠀\r\nIn this model, ICMP functions as a minimal command channel between infected hosts. One compromised server\r\ncan forward specially crafted ICMP packets to another, effectively passing along execution instructions without\r\nrequiring traditional command-and-control traffic. The key marker in this mechanism is the value 0xFFFFFFFF\r\n(signed as -1), which acts as a destination signal embedded inside the packet structure. When a receiving host\r\ndetects this value, it interprets the packet as a terminal instruction rather than something to be forwarded further.\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 15 of 17\n\nIn practical terms, Server A is telling Server B: “You are the final destination.” Instead of relaying the signal\r\nonward, the receiving system executes the next stage, typically triggering the reverse shell or command handler.\r\nThis simple signaling mechanism allows the operators to control how far a command propagates through\r\ncompromised infrastructure without introducing additional protocol complexity.\r\nWhat makes this mechanism notable is its simplicity. Rather than expanding the structure of the activation packet\r\nor introducing additional fields, the attackers reuse an existing value within the packet structure to signal the end\r\nof the chain. By setting this field to 0xFFFFFFFF, they effectively create a “do not forward” flag inside their\r\ncommunication channel. This allows them to manage hop behavior across compromised nodes while keeping the\r\npacket format compact and consistent. \r\nKey takeaways\r\nTaken together, the newly observed capabilities demonstrate how BPFdoor has evolved beyond a stealth backdoor\r\ninto a layered access framework. The updated variant combines encrypted HTTPS triggers, proxy-aware\r\ncommand delivery, application-layer camouflage techniques, ICMP-based control signals, and kernel-level packet\r\nfiltering to bypass multiple layers of modern network defenses. Each technique targets a different security\r\nboundary, from TLS inspection at the edge, to IDS detection in transit, and endpoint monitoring on the host,\r\nillustrating a deliberate effort to operate across the full defensive stack.\r\nKernel-level backdoors are redefining stealth.\r\nTools like BPFdoor operate below traditional visibility layers, abusing Berkeley Packet Filter mechanisms to\r\ncreate network listeners that do not expose ports, processes, or conventional command-and-control indicators.\r\nTelecommunications infrastructure is a prime espionage target.\r\nModern 4G and 5G networks rely on complex stacks of signaling systems, Containerized Network Functions, and\r\nhigh-performance infrastructure. Access to these environments can enable long-term intelligence collection,\r\nsubscriber monitoring, and deep visibility into national communications infrastructure.\r\nSecurity controls can be turned into delivery mechanisms.\r\nIn the latest BPFdoor variant, attackers weaponize normal security workflows. Traffic that passes through TLS\r\ntermination and deep packet inspection can deliver malicious commands once it reaches the decrypted internal\r\nzone.\r\nBPF-based implants are likely the beginning of a larger trend.\r\nBPFdoor and new eBPF malware families like Symbiote demonstrate how kernel packet filtering can be abused\r\nfor stealth persistence. As defenders improve visibility at higher layers, adversaries are increasingly shifting\r\nimplants deeper into the operating system.\r\nHow defenders can detect BPFdoor activity\r\nDetecting these threats requires shifting visibility deeper into the operating system and network stack, focusing on\r\nindicators such as unusual raw socket usage, anomalous packet filtering behavior, and unexpected service\r\nmasquerading on critical infrastructure hosts. \r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 16 of 17\n\nTo support defenders in identifying potential BPFdoor activity, we developed a scanning script designed to detect\r\nboth previously documented variants and the newer samples discussed in this research. The script focuses on\r\nidentifying indicators associated with the stealth activation mechanism, kernel-level packet filtering behavior, and\r\nprocess masquerading techniques used by BPFdoor implants. By combining checks for known artifacts and\r\nbehavioral patterns, the scanner helps security teams quickly assess whether systems may be impacted.\r\nWe are making this tool available to the community to assist organizations in proactively identifying potential\r\ncompromises. The scanner can be used across Linux environments to search for artifacts linked to BPFdoor\r\nactivity, including indicators observed in both historical samples and the latest variant analyzed during this\r\nresearch. Our goal is to help defenders rapidly validate exposure and begin incident response investigations where\r\nnecessary.\r\nIn the video below, Rapid7 Labs demonstrates how our detection script would be run within the system of an\r\ninfected victim organization. The video starts with the right window, showing that the BPFdoor backdoor is\r\nrunning and the particular services that relate are highlighted. Then, in the bottom left screen, the BPFdoor is\r\nactivated by sending the right packet sequence and password, whereby a remote control shell is established. The\r\nattacker is running some commands on the victim machine and shows it can execute remote commands. Finally, in\r\nthe top window, we run our developed detection script that will show the detected processes, and the alerts are\r\nshowcased.  \r\n⠀\r\n⠀\r\nIndicators of compromise (IOCs)\r\nThe IOCs we discovered during our investigation surrounding the new controller, as well as samples and other\r\nrelevant data, can be found on our Rapid7 Labs Github page.\r\nInterested in learning more?\r\nCatch Sleeper Cells in the Telecom Backbone, Rapid7’s webinar via BrightTalk, led by Raj Samani, Chief\r\nScientist, and Christiaan Beek, VP of Threat Analytics.\r\nSource: https://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nhttps://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/"
	],
	"report_names": [
		"tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report"
	],
	"threat_actors": [
		{
			"id": "9c8a7541-1ce3-450a-9e41-494bc7af11a4",
			"created_at": "2023-01-06T13:46:39.358343Z",
			"updated_at": "2026-04-10T02:00:03.300601Z",
			"deleted_at": null,
			"main_name": "Red Menshen",
			"aliases": [
				"Earth Bluecrow",
				"Red Dev 18"
			],
			"source_name": "MISPGALAXY:Red Menshen",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434226,
	"ts_updated_at": 1775791992,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cfc697ef692ebb109dce35cb62ae14df98a7b36f.pdf",
		"text": "https://archive.orkl.eu/cfc697ef692ebb109dce35cb62ae14df98a7b36f.txt",
		"img": "https://archive.orkl.eu/cfc697ef692ebb109dce35cb62ae14df98a7b36f.jpg"
	}
}