Hunting State Actors in Telco Networks: The Window Before They Disappear

A state-sponsored threat group has been embedding itself in telecommunications infrastructure worldwide for at least five years. Once their implant is installed, it's nearly invisible. It lives in the kernel, has no open ports, doesn't beacon and disguises itself as legitimate system processes. Standard network scanning won't find it. Most security tooling won't flag it.

And from that position, deep inside the systems that run telco core networks, a threat actor could intercept signaling data, track subscriber locations, access customer databases and communications metadata at scale, or perhaps even disrupt core services.

That's the bad news.

The good news is that getting to that point requires at least four steps of noisy, detectable activity. Every one of those steps leaves traces. And there are detection opportunities that most telco defenders aren't using yet.

This post pieces together what we know about the full intrusion chain from public threat research, explains why the implant itself is the wrong place to focus detection and looks at what defenders can do in the window before these actors disappear into the infrastructure.

The implant: BPFDoor

Rapid7 dropped their BPFDoor research last week and it's one of the better pieces of threat research to come out this year. If you haven't read it, here it is. It reads like months of work and careful technical analysis, pulling together the evolution of a threat that's been documented in fragments since at least 2021. BPFDoor is associated with a China-nexus threat group tracked as Red Menshen (also reported as DecisiveArchitect by CrowdStrike), which has been targeting telecommunications providers across Asia, the Middle East and Europe.

BPFDoor uses Berkeley Packet Filter to inspect packets inside the kernel networking stack before they reach userland applications. No open ports and no beaconing. Invisible to netstat, ss and nmap. Newer variants disguise activation packets to resemble normal HTTPS traffic and Rapid7 documents exactly how this survives proxy header rewriting through a clever fixed-offset marker technique they call the "magic ruler." The thing masquerades as HPE hardware daemons on bare metal or Docker processes in containerised environments. It can monitor SCTP traffic, a transport protocol used by telco signaling systems in 4G/5G core networks. It's a technically impressive piece of malware to reverse engineer.

Once this implant is loaded, you're in forensics territory. Rapid7's scanning script and Trend Micro's detection rules for the controller's specific packet signatures are useful tools and you should deploy them. But they answer the question "are we already compromised?" That's important, but it's not the same as catching the intrusion while it's happening.

The kill chain before the implant

BPFDoor is persistence. That's worth saying clearly because the way it gets covered can make it sound like the whole attack. It's not. Based on public reporting across multiple investigations between 2021 and 2026, BPFDoor appears late in the intrusion lifecycle, after initial access, credential theft and lateral movement are well underway. It's what the attackers install once they have root on a system they care about.

No single public report documents the entire chain end-to-end. What follows is a reconstruction from Rapid7's research, Trend Micro's controller analysis, CrowdStrike's DecisiveArchitect reporting and PwC's original Red Menshen attribution, which consistently describe the same pattern:

Step 1. Exploit an internet-facing device. VPN appliance, firewall, web platform or compromised account. Reporting across multiple investigations names products from Ivanti, Cisco, Fortinet, Palo Alto and VMware among the targets.

Step 2. Deploy post-exploitation frameworks. Across multiple sources over several years, tooling associated with these intrusions has included CrossC2 (a Cobalt Strike-derived loader for Linux), Sliver and TinyShell. These give the operators command execution, file transfer and pivoting capability.

Step 3. Harvest credentials. PwC documented Mimikatz usage for dumping credentials from memory. CrowdStrike observed secretsdump.py extracting cached hashes from domain controllers. Rapid7 found custom ELF-based keyloggers capturing credentials as they're typed. They also had SSH brute-forcers with telco-specific wordlists (usernames like "imsi") as a supporting technique. The primary pattern: compromise a host, dump everything and reuse what you find.

Step 4. Move laterally, and not just on Linux. CrowdStrike documented Red Menshen pivoting into Windows environments using Impacket tools like secretsdump, psexec and wmiexec, run from compromised Linux boxes to target Active Directory infrastructure. PwC's original attribution documented Mangzamel (a custom Windows backdoor), Gh0st RAT variants, Mimikatz and Metasploit in the same campaigns. The BPFDoor controller, first documented by Trend Micro, operates from inside the victim network triggering implants across internal Linux hosts. This is a multi-platform operation touching bare metal, virtualisation layers, Active Directory and containerised 5G core components.

Step 5. Install BPFDoor. The kernel implant goes in. The magic packet filter gets loaded. Process names get spoofed.

Step 6. Go dormant. Rapid7 calls them "sleeper cells." The implant sits in the kernel, waiting for a trigger packet that may come months later, embedded in HTTPS traffic that your security stack won't flag.

Step 7. Conduct espionage. Access to telco core systems could enable interception of signaling data, subscriber metadata, location information and other communications intelligence. This is the objective that justifies the entire operation.

The detection window

Steps 2 through 4 are where defenders actually have a fighting chance, because this part of the operation is noisy.

CrossC2 beacons have to establish communication with command infrastructure. Sliver implants phone home. TinyShell requires deployment: files hitting disk, processes spawning and network connections establishing. But the credential harvesting is where it really gets loud. Mimikatz touching LSASS memory. Secretsdump pulling hashes from a domain controller. Keyloggers being dropped, compiled and executed on compromised hosts. Every one of these actions leaves traces: process access patterns, network signatures and filesystem artifacts.

The obvious response is: if it's so detectable, why isn't it being detected?

Mostly because the detection methods that work here are hard to use at scale. You can write SIEM rules that flag LSASS access, alert on secretsdump's network signature or watch for unusual parent-child process relationships. Plenty of organisations have these rules. The problem is that they fire constantly. Legitimate tools touch LSASS. Backup agents query domain controllers. Monitoring scripts create weird process trees. In a large telco environment the volume is enormous and tuning rules to the point where a real Mimikatz execution surfaces above the noise of normal operations is a resource problem most security teams never fully solve.

This is where a different class of detection becomes interesting. Instead of trying to distinguish attacker credential theft from legitimate credential access in a sea of noise, you put credentials in the attacker's path that no legitimate process will ever use. Cached credentials that exist only as bait. Service accounts that aren't tied to real services. SSH keys that don't unlock anything real. Files in credential stores that no automation or admin has any reason to touch.

The thing about credential harvesting, as opposed to targeted credential theft, is that it's indiscriminate. When someone runs Mimikatz or secretsdump, they don't pick and choose. They dump everything. Every cached credential, every hash and every ticket. If some of those credentials only exist to be found by an attacker, they get swept up with the rest. And after you detect that credential being accessed you can also detect when the attacker tries to use it to move laterally, so you see not only where the attacker has been but where they're going. That's an unambiguous signal. A credential that has no legitimate purpose just got used for authentication.

This maps directly to Red Menshen's documented behaviour. At every stage, well-placed credential lures create detection opportunities that don't depend on distinguishing attacker activity from legitimate noise.

The same principle applies to the lateral movement itself. This group moves aggressively across platforms. Impacket tools pivoting from Linux to Windows AD. The BPFDoor controller reaching across internal networks to trigger implants on other Linux hosts. Movement between bare metal, virtualisation layers and containerised 5G workloads. Every one of those pivots involves touching hosts and services. Decoy hosts and honeypot services placed in the network segments these actors traverse create the same kind of unambiguous signal: a system that has no production purpose and no reason to receive connections just got probed or accessed. Unlike SIEM rules that have to distinguish malicious lateral movement from legitimate admin traffic, a connection to a host that shouldn't exist at all has exactly one explanation.

What this means for telco defenders

Red Menshen are highly capable but they aren't magic. Public reporting shows the group using common post-exploitation frameworks and credential theft tools. Before they become ghosts in the kernel, they need to get root on the right machine, and getting there looks like a regular intrusion. Commodity frameworks, credential theft and lateral movement through Windows AD and Linux-to-Linux pivoting with tools that every red team on the planet uses.

If you're a telco defender reading this, the immediate actions are straightforward: deploy Rapid7's scanning script and Trend Micro's detection signatures to check whether you're already compromised, and start auditing what cached credentials, service accounts and SSH keys actually exist across your Linux and AD estate. The harder but more valuable step is deploying deception across the paths this group uses. That means credential canaries like cached creds on hosts they'd target and service accounts in AD that aren't tied to real services, but also decoy services, honeypot hosts and tripwire files placed where lateral movement would encounter them. The goal is to create an environment where an attacker can't move, scan or harvest without touching something that exists only to detect them. Building and maintaining deception at scale across a telco environment isn't trivial. Open-source projects exist but come with operational overhead, scaling limitations and tuning challenges.

There are commercial deception platforms that solve this, and if this threat is in your risk register, it's worth evaluating them.

The BPFDoor research tells us what these actors become once they're bedded in. The question worth spending time on is whether your detection capability covers the window before they get there.