Red Menshen & BPFDoor

1. Executive Summary

Red Menshen is an APT group active since 2018 that primarily targets telecommunications companies, logistics infrastructure, and government institutions in the Middle East and Asia. Its principal targets are public-facing Linux and Unix servers.

The defining feature that separates Red Menshen from conventional APT groups is its custom backdoor, BPFDoor. Traditional malware establishes C2 communication by opening and listening on a system port; BPFDoor opens no port. Instead, it uses the Linux kernel’s packet-filtering architecture, cBPF, to create a raw socket (AF_PACKET).

This allows the malware to inspect network traffic directly at Layer 2 before it reaches host-based firewalls (iptables, nftables) or the network stack. BPFDoor does not appear as a listener in standard network-monitoring tools such as netstat or ss. After compromising a host, it remains passive and initiates C2 communication only when triggered by a specific “Magic Packet” sent by the attacker: a custom hexadecimal payload delivered over ICMP, TCP, or UDP. This architecture has allowed the group to maintain long-term persistence in target networks without detection.

2. Campaign Timeline

Red Menshen’s operations and the BPFDoor malware have evolved to evade EDR and SIEM detection mechanisms:

• 2018–2019 (Development and Early Traces): Early BPFDoor versions were deployed to vulnerable public-facing Linux routers and servers. During this period, the malware tested its ability to sniff network traffic through raw sockets.
• 2020–2021 (Persistence and Concealment): Active compromises of telecommunications companies. The malware masqueraded as legitimate system daemons such as dbus-daemon, systemd-journal, and kswapd0, and manipulated init.d scripts for persistence.
• May 2022 (Detection and Analysis): Technical reports published by PwC and Elastic Security Labs explained BPFDoor’s use of the cBPF architecture and shared indicators of compromise.
• After 2022 (Tactical Changes): After security vendors published YARA rules, the group modified the BPFDoor source code. Encryption algorithms and BPF filter structures were updated to evade static detection.

2.1. Notable Campaigns

Analysis of Red Menshen’s known operations indicates that the group focuses on cyber espionage and network-intelligence collection rather than financial gain.

Campaign 1: Telecommunications Intrusions in Asia and the Middle East (2018–2021)

• Target Profile: Major telecommunications companies in the Middle East and Asia.
• Attack Vector: Exploitation of vulnerable public-facing Linux and Solaris servers, including DNS servers, email gateways, and load balancers.
• Operational Details: Red Menshen deployed BPFDoor on endpoints carrying high volumes of network traffic so that the magic packet would blend into noisy network environments. After obtaining root privileges, the group took care not to disrupt normal server operations. It kept the backdoor in passive mode, using it only for periodic intelligence collection and as a lateral-movement pivot.

Campaign 2: Government and Logistics Infrastructure Operations (2021–2022)

• Target Profile: Government institutions and strategic logistics infrastructure.
• Attack Vector: Lateral movement from compromised edge devices to critical Linux servers on internal networks.
• Operational Details: The group placed greater emphasis on anti-forensics in this campaign. BPFDoor masqueraded under legitimate daemon names such as kswapd0 and udevd, allowing it to operate for months on high-uptime servers without detection. To minimize detection risk, the group avoided leaving files on disk and performed C2 communication entirely through ICMP/UDP magic packets rather than opening ports.

3. MITRE ATT&CK TTP Mapping

This section maps the specific techniques used by Red Menshen and BPFDoor on target systems to MITRE ATT&CK.

3.1. Process Name Spoofing

id: T1036.004
tactic: Defense Evasion
technique: Masquerading (Task Name/Process Spoofing)
platform: Linux

Technique Description

After establishing itself and starting execution, BPFDoor manipulates its process name to conceal its presence. It overwrites the argv[0] argument so that it appears to be a legitimate Linux daemon such as /sbin/udevd, dbus-daemon, systemd-journal, or kswapd0, reducing the likelihood of drawing attention from administrators and EDR products.

Execution and PoC

After calling fork(), the child process changes its own command-line argument.

//BPFDoor process spoofing örneği (C Pseudocode)
strncpy(argv[0], "/sbin/udevd -d", strlen(argv[0]));

As a result, commands such as ps aux or top display the spoofed daemon name instead of the malware’s actual name.

Detection Methods

Process-name manipulation can be detected through inconsistencies in /proc. Although the cmdline value of a spoofed process changes, the exe symbolic link that points to the underlying binary continues to reveal the malware’s original path.

• Auditd / Telemetry: A /proc/[pid]/exe link pointing outside standard system directories such as /usr/sbin/ or /lib/systemd/—for example, to /tmp or /dev/shm—is suspicious.
• YARA: Search unexpected memory regions for BPFDoor signatures during memory scanning.

Defense

• Collect process-execution logs with EDR tooling such as Sysmon for Linux and alert on process command-line changes.

3.2. Magic Packet & Raw Socket Listening

id: T1205
tactic: Defense Evasion, Command and Control
technique: Traffic Signaling (Magic Packet)
platform: Linux

Technique Description

Conventional backdoors bind to and listen on a specific TCP or UDP port for C2 communication. BPFDoor instead captures packets directly at Layer 2 through an AF_PACKET socket. Its embedded cBPF filter accepts only packets containing a specific attacker-controlled magic-packet hexadecimal pattern. All other traffic continues into the operating system’s normal network stack without being dropped.

Execution and PoC

The malware creates a raw socket to avoid opening a port and applies its filter in the kernel with SO_ATTACH_FILTER.

//AF_PACKET ile raw socket açılması
int sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

//Kernel'a cBPF filtresinin uygulanması
setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &bpf_filter_struct, sizeof(bpf_filter_struct));

When the magic packet reaches the system, the BPF filter captures it before iptables rules take effect and executes the backdoor commands.

Detection Methods

• Auditd Rule: Log socket system calls that create AF_PACKET sockets, especially when initiated by root or nonstandard daemons.
• Network Telemetry: Look for unnecessary or irregularly sized hexadecimal data in payloads when ICMP pings or arbitrary TCP packets are sent to the target server.
• BPF Tool: List and inspect active, unauthorized BPF filters with bpftool prog show.

Defense

• Opening a raw socket requires CAP_NET_RAW; restrict this capability for unauthorized processes.

3.3. Boot Script Manipulation

id: T1037.004
tactic: Persistence
technique: Boot or Logon Initialization Scripts: rc.common
platform: Linux

Technique Description

BPFDoor targets system startup scripts so that it can become active in memory again after a reboot. Rather than creating a new and suspicious service file, it inserts its execution command into existing, trusted init.d scripts such as those for iptables, rsyslog, or sshd.

Execution and PoC

The attacker typically downloads the malware to a temporary filesystem such as /dev/shm or /tmp and appends its execution command to a legitimate shell script.

#Yasal bir init.d script'ine zararlı payload'un eklenmesi
echo "/dev/shm/kswapd0 &" >> /etc/rc.d/init.d/rsyslog

When the system starts the rsyslog service during boot, it also launches the BPFDoor binary in the background, which then opens its raw socket.

Detection Methods

File Integrity Monitoring can detect unauthorized changes to system startup files.

• Auditd: Log write and append syscall activity targeting files in /etc/init.d/, /etc/rc.d/, and /etc/systemd/system/.
• Stat Analysis: Identify anomalous mtime values on critical startup files.

Defense

• Apply strict, read-only file permissions to configuration files in critical directories such as /etc/init.d/, and monitor changes in real time with FIM tooling such as Wazuh or Tripwire.

3.4. Binary Deletion & Environment Wiping

id: T1070.004
tactic: Defense Evasion
technique: Indicator Removal on Host: File Deletion
platform: Linux

Technique Description

Immediately after beginning execution in memory, the malware deletes its own binary from the filesystem to hinder static analysis and avoid leaving artifacts on disk. The process continues to run, but the file can no longer be accessed from disk. It also clears environment variables to remove variable traces created during execution.

Execution and PoC

After fork(), BPFDoor deletes its file path through the unlink() syscall and clears the environ pointer.

//Binary'nin diskten silinmesi ve environment temizliği
unlink(argv[0]);
clearenv();

The malware remains active in memory, but incident-response teams cannot find its file on disk to calculate its hash or perform static analysis.

Detection Methods

A process whose source file has been deleted while it continues to execute is one of the strongest Linux memory-analysis indicators.

• Procfs Analysis: Search /proc for running processes whose binary links are marked (deleted).

ls -l /proc/*/exe | grep "deleted"

• Auditd Rule: Detect files executed from /tmp, /var/tmp, or /dev/shm that call unlink or unlinkat on themselves.

Defense

• noexec Mount Flag: Mount temporary filesystem paths such as /tmp, /var/tmp, and /dev/shm with noexec to prevent malware from executing directly from these directories.

4. Malware Anatomy: BPFDoor and ZayoELF Analysis

Static-analysis tools and dynamic behavioral monitoring reveal characteristics that distinguish BPFDoor from conventional backdoors. This section profiles the malware and its runtime anatomy using ZayoELF Analyzer for static analysis.

4.1. Static Analysis Profile

Analysis of the BPFDoor binary with ZayoELF produced the following findings:

• Packer / Anti-Analysis Detection: ZayoELF found that the Section Headers table had been removed entirely. Combined with the UPX! markers visible in the string preview, this strongly indicates that the malware was packed to impede static analysis. Manual unpacking recovered the original file structure, exposed the hidden .dynsym and .plt tables, and measured the entropy of the .text section containing the core malware code at a normal value of 5.153.

Figure 1: Entropy analysis

• Symbol Table and Suspicious Imports: The malware is commonly compiled as a stripped binary to hinder analysis. In variants that retain symbols, ZayoELF’s “Noteworthy Imported Functions” module directly identifies calls to socket, setsockopt, fork, unlink, and clearenv. This combination is characteristic of malware that uses raw sockets and deletes itself from disk.

Figure 2: Variant without retained symbols

Figure 3: Variant with retained symbols

• String Preview: ZayoELF’s string results contained no cleartext C2 IP address or domain. The recovered strings primarily referenced the malware’s original source file (bpfdoor.c) and critical system calls (socket, fork, setsockopt, clearenv, unlink). The presence of clearenv and unlink in particular provides strong static evidence that the malware implements concealment mechanisms.

Figure 4: String analysis

4.2. Dynamic Analysis and cBPF Integration

At runtime, BPFDoor’s primary function is to inspect and filter network traffic at Layer 2. It uses classic BPF (cBPF) rather than modern eBPF, providing backward compatibility and support for a broader range of Linux kernels.

1. Raw Socket Initialization: The malware calls socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) to begin listening on every network interface available to the device.
2. Filter Attachment: The compiled cBPF bytecode in the C source—a struct sock_fprog structure—is attached to the raw socket through setsockopt with SO_ATTACH_FILTER.
3. Network Stack Bypass: The cBPF filter runs before the operating system’s iptables or firewalld rules. The malware receives only packets containing the magic packet pattern. Nonmatching traffic is not dropped and continues through the operating system’s normal network stack.

5. Campaign Execution Flow & Architecture

The typical BPFDoor attack chain used by Red Menshen and the malware’s position in the network architecture are described below.

5.1. BPFDoor Network Architecture

The following diagram shows how BPFDoor captures an incoming network packet before it encounters the operating system’s firewall rules.

[Attacker (C2)]
      │
      ▼ (Magic Packet - TCP/UDP/ICMP)
[Public-Facing Linux Server]
      │
      ▼
[Network Interface Card (NIC)]
      │
      ▼ (L2 Data Link Layer)
+---------------------------------------------------+
| Linux Kernel                                      |
|                                                   |
|  [cBPF Filter] <─────────────── (AF_PACKET) ────┐ |
|        │ (Match? YES)                           │ |
|        ▼                                        │ |
|  [BPFDoor Process] ─────────────────────────────┘ |
|  (Executes bind shell or reverse shell)           |
|                                                   |
|        │ (Match? NO)                              |
|        ▼                                          |
|  [Standard Network Stack (TCP/IP)]                |
|        │                                          |
|        ▼                                          |
|  [Host Firewall (iptables / nftables)]            |
+---------------------------------------------------+

5.2. Operational Lifecycle

1. Initial Access: The attacker typically exploits vulnerabilities in public-facing web, VPN, or router systems, or obtains initial access through brute force.
2. Execution & Masquerading: The BPFDoor payload is downloaded to a directory such as /dev/shm or /tmp. On execution, it calls fork() and changes the child process name (argv[0]) to /sbin/udevd or kswapd0, concealing itself as a legitimate daemon.
3. Persistence: The malware’s execution command is injected into a legitimate /etc/init.d/ script, such as an rsyslog or iptables startup file.
4. Defense Evasion (Cleanup): The malware deletes its own executable from disk with unlink() and clears its environment variables with clearenv(), removing static artifacts from forensic examination.
5. Signaling: The malware begins passive listening through a raw socket and remains silent until the attacker sends a magic packet.
6. Action on Objectives: After detecting the magic packet, BPFDoor either opens a bind shell or connects a reverse shell to the attacker’s IP address. When the connection closes, it returns to passive listening mode.

6. Indicators of Compromise (IoC)

Because BPFDoor’s stealth architecture allows static hashes to change rapidly, detection should focus on behavioral and host-based anomalies.

Host-Based Indicators

7. Threat Hunting Notes

The following threat-hunting hypotheses can help identify BPFDoor variants that evade signature-based detection:

Hunt 1: Detecting Processes That Open Raw Sockets (AF_PACKET)

• Hypothesis: BPFDoor uses AF_PACKET to inspect Layer 2 traffic directly instead of opening a TCP or UDP port.
• Data Source: Linux Auditd, Sysmon for Linux.
• Logic: Detect processes other than network-analysis tools such as tcpdump or Wireshark that call socket with the AF_PACKET or SOCK_RAW parameter.
• Example Auditd Rule:

-a always,exit -F arch=b64 -S socket -F a0=17 -k raw_socket_creation
#a0=17 (AF_PACKET)

Hunt 2: Analyzing “Deleted” Binaries Running in Memory

• Hypothesis: The malware deletes itself from disk with unlink() immediately after execution.
• Data Source: Procfs (/proc).
• Logic: List processes that continue to run in memory after their original executable has been deleted from disk.
• Bash Detection:

ls -al /proc/*/exe | grep "deleted"

(Note: Some services may enter this state during normal system updates. Results pointing to /dev/shm or /tmp can be treated as critical.)

Hunt 3: Process Execution Spoofing (argv vs. exe Mismatch)

• Hypothesis: BPFDoor overwrites argv[0] to appear as udevd, while the process’s underlying source path—the exe link—remains different.
• Data Source: EDR telemetry or Procfs.
• Logic: Detect cases where /proc/[PID]/cmdline and /proc/[PID]/exe do not correspond semantically.
• Bash Detection:

for pid in $(ls /proc | grep -E '^[0-9]+$'); do 
  exe_path=$(readlink -f /proc/$pid/exe 2>/dev/null); 
  cmdline=$(tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null); 
  #Analiz için bu ikiliyi karşılaştır
done

8. MITRE ATT&CK Matrix Summary

9. Conclusion

BPFDoor demonstrates the limitations of conventional network-based detection. Its portless architecture, use of classic BPF filters, and behavior-driven concealment techniques make signature-only approaches insufficient. Behavioral analysis, system-call monitoring, and threat-hunting operations are therefore critical in modern Linux environments.

10. References

• PwC Threat Intelligence: “Red Menshen: A telecom-focused threat actor” (May 2022)
• Elastic Security Labs: “A Peek Behind the BPFDoor” - In-depth eBPF/cBPF malware analysis (May 2022)
• Sandfly Security: “BPFDoor - Stealthy Linux Malware Bypasses Firewalls” (Technical deep-dive on AF_PACKET and execution flow)
• Kevin Beaumont (DoublePulsar): “BPFDoor - A stealthy Linux backdoor” (Threat intelligence & IOCs)
• MITRE ATT&CK Framework: Enterprise Linux Matrix (Tactic and Technique definitions)