Red Menshen's BPFDoor: Hunting for eBPF Rootkits in Telecom Infrastructure
Saw the report on Red Menshen (Earth Bluecrow) leveraging BPFDoor for telecom espionage. It's a sophisticated case of "living off the land" but entirely within the kernel. The implant hooks into the XDP (eXpress Data Path) or socket filters to stay invisible to standard user-space monitoring tools and firewalls.
If you're securing Linux edge servers or routers in this sector, you can't rely on standard process monitoring. You need to inspect the kernel for unexpected attachments.
Here is a quick command to list loaded BPF programs. If you see unknown attachments or programs attached to xdp or socket_filter that you didn't authorize, investigate immediately.
sudo bpftool prog show
You should also check for binaries with the capability to load BPF programs, as this is often required for the initial dropper:
getcap -r / 2>/dev/null | grep cap_sys_admin
The article mentions they are positioning themselves in telecoms to pivot to government networks. This implies deep lateral movement inside the ISP. Is anyone enforcing strict eBPF lockdowns or signature verification in production, or is the performance trade-off too high for your environment?
Great post. We’ve been using Falco for runtime security, but detecting eBPF loading events specifically requires some tuning. You'll want to monitor the bpf syscall.
Here is a basic Falco rule to catch program loading if you aren't already using it:
- rule: Load BPF Program
desc: Detect attempts to load eBPF programs
condition: >
syscall.type=bpf and
evt.dir=
BPF program loaded (user=%user.name command=%proc.cmdline)
priority: WARNING
However, be aware that once the loader is done and the program is attached, the syscall won't fire again. Kernel integrity checks are vital.
From a defensive architecture standpoint, relying purely on detection is a losing battle against kernel-level implants. If Red Menshen has cap_sys_admin, it's game over for that host.
We've started enforcing Kernel Lockdown Mode (integrity or confidentiality) on our exposed DMZ nodes. It prevents unsigned modules and eBPF programs from loading entirely.
# Check lockdown status
cat /sys/kernel/security/lockdown
# To enable (via kernel parameter or mokutil if using UEFI)
It's aggressive and breaks some monitoring agents, but for telecom edge nodes, it might be the only way to stop BPFDoor variants.
I've analyzed samples of BPFDoor before. What's scary is how it parses raw packets directly from the socket buffer, bypassing the standard network stack entirely. It doesn't show up in netstat or ss because the socket isn't created in userspace.
One thing I look for during IR is memory scraping for 'magic byte' sequences associated with the C2 heartbeat, or checking for specific file artifacts often dropped in /lib or /dev/shm. The persistence mechanism usually involves a cron job or a systemd service that looks benign. Don't just look at the network; hunt the droppers.
To complement runtime monitoring, we schedule periodic audits of loaded BPF programs. Since standard tools miss XDP attachments, we specifically check interface hooks using:
sudo bpftool net show
Additionally, ensure unprivileged BPF loading is disabled in your hardening guides via kernel.unprivileged_bpf_disabled=1 to restrict non-root access.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access