New BPFDoor variants hide deeper in telecom networks with stateless C2 and ICMP relays
5 min. read 
Published on
BPFDoor has returned with new tricks that make an already stealthy Linux backdoor even harder to spot. Rapid7 says the latest variants use stateless command routing and ICMP relay to keep command traffic flexible, avoid fixed infrastructure, and blend into trusted network activity inside telecom environments.
The short answer is yes, this is a serious escalation. According to Rapid7 Labs, researchers analyzed nearly 300 samples and identified seven new BPFDoor variants, with two primary families named httpShell and icmpShell. The company says these versions improve operational security and help attackers maintain near-undetectable persistence in global telecommunications infrastructure.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
What makes BPFDoor different is how it waits. Instead of opening a normal listening port, the malware abuses Berkeley Packet Filter functionality in Linux to inspect traffic inside the kernel and wake up only when it receives a specially crafted trigger packet. That design leaves far fewer obvious signs for defenders to catch with traditional scans.
Why these new variants matter
Rapid7 links the broader campaign to a China-nexus threat actor known as Red Menshen and says the activity fits a long-term espionage model, not a quick smash-and-grab intrusion. In its March 26 report, the company said the group had embedded covert access inside telecom infrastructure with the apparent goal of supporting intelligence collection, including against government networks.
The newer samples push that tradecraft further. Rapid7 says the updated BPFDoor code introduces stateless C2 routing through a magic packet structure that includes a Hidden IP, or HIP, field. When the malware sees a special -1 flag, represented as 255.255.255.255, it can ignore a hardcoded controller address and instead send its reverse shell to the source IP contained in the triggering packet.
That change matters because it removes a fixed destination defenders might track or block. Rapid7 says this gives operators more freedom to work behind NAT or VPN infrastructure without exposing a stable command-and-control endpoint in the payload itself.
How the ICMP relay helps attackers stay hidden
Rapid7 also says both major variants support ICMP relay. In practice, that means an infected system can forward crafted ICMP Echo Request traffic toward an internal target using the HIP field, turning the compromised machine into a quiet relay node inside the network. For defenders, that raises the risk that ordinary-looking ping traffic could help move commands deeper into internal segments.
The company adds that these variants can open parallel sockets for TCP, UDP, and ICMP traffic, which gives the malware fallback options if one path gets blocked. That multi-channel design improves resilience and makes containment harder during live response.
Rapid7’s reporting also shows the malware trying to look like a normal service. Researchers describe process name spoofing, on-disk persistence in newer samples, and anti-forensic behavior such as timestomping and wiping file descriptors. Together, those steps reduce noise and help the implant stay buried for longer.
What security teams should watch for
Here is a quick view of the main changes security teams should care about:
| Feature | What Rapid7 observed | Why it matters |
|---|---|---|
| Kernel-level packet inspection | BPFDoor inspects traffic through BPF and waits for a magic packet | No obvious listening port, fewer traditional indicators |
| Stateless C2 routing | -1 flag lets the malware reply to the source IP in the trigger packet | Removes the need for a fixed controller address |
| ICMP relay | Infected hosts can forward crafted ICMP packets toward internal targets | Can hide command routing inside allowed network traffic |
| Multi-channel sockets | Samples use TCP, UDP, and ICMP paths | Gives attackers fallback communications options |
| Process disguise and anti-forensics | Masquerading, timestomping, and FD wiping | Makes host-based detection and triage harder |
Defenders should review Linux systems that sit close to core networking, telecom signaling, or containerized infrastructure first. Rapid7 says modern variants may no longer rely on older /dev/shm behavior, so teams should not limit hunts to fileless patterns alone.
Practical hunting steps include:
- Monitor for suspicious raw socket activity on Linux hosts.
- Inspect unusual internal ICMP traffic, especially traffic that does not fit normal diagnostics patterns.
- Audit process names that mimic legitimate services but do not match expected binaries or paths.
- Review active BPF filters on sensitive systems. Linux kernel documentation confirms BPF attaches packet filters at the socket and kernel level, which explains why this technique gives attackers a low-visibility trigger path.
- Use Rapid7’s published detection materials, including its BPFDoor check script and IOCs repository.
FAQ
BPFDoor is a Linux backdoor that abuses Berkeley Packet Filter functionality to inspect incoming traffic in the kernel and activate only when it receives a specially crafted trigger packet.
Rapid7 says the new variants add stateless C2 routing, ICMP relay, process masquerading, and anti-forensic behavior. Those features reduce obvious network indicators and make host artifacts harder to spot.
Rapid7 attributes the wider telecom-focused campaign to Red Menshen, which it describes as a China-nexus threat actor involved in long-term espionage activity.
Rapid7 says telecom environments carry sensitive government and commercial communications and rely on specialized protocols and core infrastructure that offer valuable long-term access for espionage operations.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages