S1161: BPFDoor
BPFDoor is a Linux based passive long-term backdoor used by China-based threat actors. First seen in 2021, BPFDoor is named after its usage of Berkley Packet Filter (BPF) to execute single task instructions. BPFDoor supports multiple protocols for communicating with a C2 including TCP, UDP, and ICMP and can start local or reverse shells that bypass firewalls using iptables.[1][2]
Analyst context for executives and security teams
BPFDoor matters because it represents a Linux-focused, passive long-term backdoor that can wait for specific network traffic and then enable local or reverse shells. For leaders, the practical issue is not just malware detection; it is whether critical Linux systems have enough host, network, firewall, and shell telemetry to prove that stealthy access would be noticed.
Executive priority
Prioritize BPFDoor-related validation where Linux systems support business-critical services. The ATT&CK relationships point to stealth, persistence, command-and-control, and defense-impairment behaviors: socket filters, process masquerading, firewall modification, command-history suppression, file deletion, and timestamp manipulation. This makes it relevant to resilience planning, incident-response readiness, audit evidence for monitoring controls, and decisions about whether Linux visibility is mature enough for high-value servers.
Technical view
BPFDoor is listed for Linux and is described as using Berkeley Packet Filter behavior, TCP/UDP/ICMP communications, and local or reverse shells that may bypass firewalls using iptables. SOC and IR teams should validate coverage for the related ATT&CK behaviors: T1205.002 Socket Filters, T1059.004 Unix Shell, T1686 Disable or Modify System Firewall, T1036.009 Break Process Trees, T1036.011 Overwrite Process Arguments, T1070/T1070.004/T1070.006 Indicator Removal, T1690 Prevent Command History Logging, T1564.011 Ignore Process Interrupts, and T1480/T1480.002 Execution Guardrails. Because no official ATT&CK detection text is supplied, detection engineering should be based on local Linux telemetry, baselines, and confirmed logging depth rather than assumed tool coverage.
Likely telemetry
- Linux process execution and parent/child process lineage
- /proc-derived process names, command-line arguments, and argument changes where available
- Raw socket, packet capture, BPF/socket filter, or libpcap-related activity where collected
- Network telemetry for unusual TCP, UDP, and ICMP patterns to or from Linux hosts
- iptables or host firewall rule changes
Detection direction
- Confirm that Linux endpoint logging can see more than command lines; BPFDoor-related relationships include process tree breaking and overwritten process arguments, which can reduce confidence in simple process-name rules.
- Hunt for unusual socket filter or packet capture behavior on servers that do not normally perform network monitoring functions, while accounting for legitimate admin, observability, and security tools.
- Correlate unexpected TCP, UDP, or ICMP traffic with shell creation, long-running processes, and firewall rule changes rather than relying on a single indicator.
- Monitor iptables or host firewall changes, especially when followed by inbound or outbound connectivity that was previously blocked.
- Tune for stealth behaviors in combination: file deletion, timestamp anomalies, command-history suppression, abnormal parent process lineage, and process names that do not match executable paths or expected service behavior.
Mitigation priorities
- Establish priority coverage for critical Linux assets: endpoint telemetry, network visibility, firewall-change logging, and centralized log retention.
- Restrict and monitor privileges capable of opening raw sockets, attaching socket filters, modifying host firewalls, or spawning privileged shells.
- Baseline expected packet capture/BPF use, iptables changes, service processes, and administrative shell activity on important Linux servers.
- Use centralized and tamper-resistant logging where possible so file deletion, timestomping, and command-history suppression do not remove the only evidence.
- Prepare IR procedures for Linux backdoor investigations, including review of process lineage, firewall state, socket activity, shell history gaps, and file metadata anomalies.
Analyst notes and limits
The official object identifies BPFDoor as Linux-based malware and cites public research sources, with relationships to multiple stealth, execution, command-and-control, persistence, and defense-impairment techniques. The strongest defensive value is to use this object as a Linux visibility and response-readiness test case: can the organization explain what happened if a process hides its arguments, alters firewall behavior, waits on filtered network traffic, and cleans up traces?
ATT&CK provides no official detection guidance for this object, and the malware object itself has no explicit tactics listed. The take is therefore derived from the supplied description, external references, platform field, and stated technique relationships. Local baselines, asset criticality, and actual sensor capabilities are required before assessing exposure or detection coverage.
BPFDoor
BPFDoor is a Linux based passive long-term backdoor used by China-based threat actors. First seen in 2021, BPFDoor is named after its usage of Berkley Packet Filter (BPF) to execute single task instructions. BPFDoor supports multiple protocols for communicating with a C2 including TCP, UDP, and ICMP and can start local or reverse shells that bypass firewalls using iptables.[1][2]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1070 | Indicator Removal | BPFDoor clears the file location `/proc/ |
| Enterprise | T1480.002 | Mutual Exclusion Sub-technique | When executed, BPFDoor attempts to create and lock a runtime file, `/var/run/initd.lock`, and exits if it fails using the specified file, resulting in a makeshift mutex.CitationDeep Instinct BPFDoor 2023 |
| Enterprise | T1480 | Execution Guardrails | |
| Enterprise | T1036.011 | Overwrite Process Arguments Sub-technique | BPFDoor overwrites the `argv[0]` value used by the Linux `/proc` filesystem to determine the command line and command name to display for each process. BPFDoor selects a name from 10 hardcoded names that resemble Linux system daemons, such as; `/sbin/udevd -d`, `dbus-daemon --system`, `avahi-daemon: chroot helper`, `/sbin/auditd -n`, and `/usr/lib/systemd/systemd-journald`.CitationSandfly BPFDoor 2022 |
| Enterprise | T1205.002 | Socket Filters Sub-technique | BPFDoor uses BPF bytecode to attach a filter to a network socket to view ICMP, UDP, or TCP packets coming through ports 22 (ssh), 80 (http), and 443 (https). When BPFDoor finds a packet containing its “magic” bytes, it parses out two fields and forks itself. The parent process continues to monitor filtered traffic while the child process executes the instructions from the parsed fields.CitationSandfly BPFDoor 2022CitationDeep Instinct BPFDoor 2023 |
| Enterprise | T1564.011 | Ignore Process Interrupts Sub-technique | BPFDoor sets its process to ignore the following signals; `SIGHUP`, `SIGINT`, `SIGQUIT`, `SIGPIPE`, `SIGCHLD`, `SIGTTIN`, and `SIGTTOU`.CitationDeep Instinct BPFDoor 2023 |
| Enterprise | T1036.009 | Break Process Trees Sub-technique | After initial execution, BPFDoor forks itself and runs the fork with the `--init` flag, which allows it to execute secondary clean up operations. The parent process terminates leaving the forked process to be inherited by the legitimate process init.CitationSandfly BPFDoor 2022 |
| Enterprise | T1070.004 | File Deletion Sub-technique | After initial setup, BPFDoor's original execution process deletes the dropped binary and exits.CitationSandfly BPFDoor 2022 |
| Enterprise | T1070.006 | Timestomp Sub-technique | BPFDoor uses the `utimes()` function to change the executable's timestamp.CitationSandfly BPFDoor 2022 |
| Enterprise | T1059.004 | Unix Shell Sub-technique | BPFDoor can create a reverse shell and supports vt100 emulator formatting.CitationSandfly BPFDoor 2022 |
| Enterprise | T1686 | Disable or Modify System Firewall | BPFDoor starts a shell on a high TCP port starting at 42391 up to 43391, then changes the local `iptables` rules to redirect all packets from the attacker to the shell port.CitationSandfly BPFDoor 2022 |
| Enterprise | T1027 | Obfuscated Files or Information | BPFDoor can require a password to activate the backdoor and uses RC4 encryption or static library encryption `libtomcrypt`.CitationSandfly BPFDoor 2022 |
| Enterprise | T1690 | Prevent Command History Logging | BPFDoor sets the `MYSQL_HISTFILE` and `HISTFILE` to `/dev/null` preventing the shell and MySQL from logging history in `/proc/ |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 51e68d0de54b… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Sandfly BPFDoor 2022
The Sandfly Security Team. (2022, May 11). BPFDoor - An Evasive Linux Backdoor Technical Analysis. Retrieved September 29, 2023.
Open source URL -
[2]
Deep Instinct BPFDoor 2023
Shaul Vilkomir-Preisman and Eliran Nissan. (2023, May 10). BPFDoor Malware Evolves – Stealthy Sniffing Backdoor Ups Its Game. Retrieved September 19, 2024.
Open source URL -
[3]
Backdoor.Linux.BPFDOOR
(Citation: Merces BPFDOOR 2023)
-
[4]
Backdoor.Solaris.BPFDOOR.ZAJE
(Citation: Harries JustForFun 2022)
-
[5]
Harries JustForFun 2022
Jamie Harries. (2022, May 25). Hunting a Global Telecommunications Threat: DecisiveArchitect and Its Custom Implant JustForFun. Retrieved September 23, 2024.
Open source URL -
[6]
JustForFun
(Citation: Harries JustForFun 2022)
-
[7]
Merces BPFDOOR 2023
Fernando Merces. (2023, July 13). Detecting BPFDoor Backdoor Variants Abusing BPF Filters. Retrieved September 23, 2024.
Open source URL -
[8]
mitre-attack S1161Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.