{
	"id": "14f14205-8472-4468-80b7-11b6c64d9e3f",
	"created_at": "2026-04-06T00:16:46.091725Z",
	"updated_at": "2026-04-10T03:33:12.092081Z",
	"deleted_at": null,
	"sha1_hash": "2ba8e179f577da0ee8a2ec75e09aab98bdafa51a",
	"title": "A peek behind the BPFDoor",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2232221,
	"plain_text": "A peek behind the BPFDoor\r\nBy Jake King, Colson Wilhoit\r\nPublished: 2022-07-13 · Archived: 2026-04-02 11:53:03 UTC\r\nPreamble\r\nBPFDoor is a backdoor payload specifically crafted for Linux. Its purpose is for long-term persistence in order to\r\ngain re-entry into a previously or actively compromised target environment. It notably utilizes BPF along with a\r\nnumber of other techniques to achieve this goal, taking great care to be as efficient and stealthy as possible. PWC\r\nresearchers discovered this very interesting piece of malware in 2021. PWC attributes this back door to a specific\r\ngroup from China, Red Menshen, and detailed a number of interesting components in a high-level threat research\r\npost released last week.\r\nPWC’s findings indicated that Red Menshen had focused their efforts on targeting specific Telecommunications,\r\nGovernment, Logistics, and Education groups across the Middle East and Asia. This activity has been across a\r\nMonday-to-Friday working period, between 01:00 UTC and 10:00 UTC, indicating that the operators of the malware\r\nwere consistent in their attacks, and operation during a working week.\r\nPerhaps most concerningly, the payload itself has been observed across the last 5 years in various phases of\r\ndevelopment and complexity, indicating that the threat actor responsible for operating the malware has been at it for\r\nsome time, undetected in many environments.\r\nBPFDoor Tools\r\nThe Elastic Security Team has created a few tools that will aid researchers in analyzing the BPFDoor\r\nmalware.\r\nThe BPFDoor scanner will allow you to scan for hosts infected with the BPFDoor malware and the\r\nBPFDoor configuration extractor will allow you to extrapolate the malware’s configuration or hardcoded\r\nvalues which can lead to additional observations you can use for further analysis, developing additional\r\nsignatures or connecting to the backdoor utilizing our client.\r\nBPFDoor scanner\r\nBPFDoor configuration extractor\r\nAttack Lifecycle\r\nThis inherently passive backdoor payload is built to be a form of persistence – a method to regain access if the first\r\nor second stage payloads are lost. It is built for and intended to be installed on high-uptime servers or appliances,\r\nIoT/SCADA, or cloud systems with access to the Internet. The backdoor usually sits in temporary storage so if a\r\nserver were to be rebooted or shut down, the backdoor would be lost.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 1 of 20\n\nIt should be assumed that if this malware is found on a system the initial-access (1st stage) or post-exploitation (2nd\r\nstage) payloads are still most likely present and possibly active elsewhere in the environment. This backdoor excels\r\nat stealth, taking every opportunity to blend in and remain undetected.\r\nIn the below steps, we will break BPFDoor’s actions down according to the vast majority of the samples available.\r\n1. When executed the binary copies itself into /dev/shm/. A temporary filesystem /dev/shm stands for shared\r\nmemory and is a temporary file storage facility serving as an efficient means of inter-process communication\r\n2. Renames its process to kdmtmpflush, a hardcoded process name\r\n3. Initializes itself with the -init flag and forks itself. Forking in Linux means creating a new process by\r\nduplicating the calling process\r\n4. Deletes itself by removing the original binary invoked. The forked process continues to run\r\n5. Alters the forked processes’ creation and modification time values, also known as timestomping\r\n6. Creates a new process environment for itself and removes the old one setting (spoofing) a new process name.\r\nIt changes the way it appears on the system akin to wearing a mask. The process is still kdmtmpflush but if\r\nyou were to run a ps you would see whatever value it set\r\n7. Creates a process ID (PID) file in /var/run. PID files are text files containing the process of the associated\r\nprogram meant for preventing multiple starts, marking residency, and used by the program to stop itself. This\r\nfile resides in /var/run, another temporary file storage facility\r\n8. Creates a raw network socket. On Linux, a socket is an endpoint for network communication that allows you\r\nto specify in detail every section of a packet allowing a user to implement their own transport layer protocol\r\nabove the internet (IP) level\r\n9. Sets BPF filters on the raw socket. BPF allows a user-space program to attach a filter onto any socket and\r\nallow or disallow certain types of data to come through the socket\r\n10. Observes incoming packets\r\n11. If a packet is observed that matches the BPF filters and contains the required data it is passed to the backdoor\r\nfor processing\r\n12. It forks the current process again\r\n13. Changes the forked processes working directory to /\r\n14. Changes (spoofs) the name of the forked process to a hardcoded value\r\n15. Based on the password or existence of a password sent in the “magic packet” the backdoor provides a reverse\r\nshell, establishes a bind shell, or sends back a ping\r\nAtypical BPFDoor sample\r\nOf note there is one sample we have come across that does not seem to exhibit steps 1 - 4. It doesn’t alter\r\nits initial name to a hardcoded value and simply executes from its placed location, otherwise, it models the\r\nsame behavior.\r\nBelow you can see visual representations of the BPFDoor process tree, utilizing Elastic’s Analyzer View. The first\r\nimage displays the tree prior to active use of the backdoor (i.e reverse shell, bind shell, or pingback) and the second\r\nimage after a reverse shell has connected and performed post-exploitation activities.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 2 of 20\n\nElastic Analyzer View of the BPFDoor initial invocation process tree\r\nElastic Analyzer View of BPFDoor following a reverse shell connection and post exploitation actions\r\nDefense Evasion Insights\r\nBPFDoor is interesting given the anti-forensics, and obfuscation tactics used. Astute readers will observe slight\r\ndifferences in the PID tree visible when running a ps ajxf on an infected host when compared to executed data within\r\nthe Analyzer View inside of Elastic. This is due to the process name spoofing mentioned in step 6 (above) of the\r\nattack lifecycle above. The image below is taken from a system running BPFDoor with an active reverse shell\r\nconnection established:\r\nAn observed running process created by the BPFDoor reverse shell\r\nThe difference lies in the fact that kdmtmpflush and sh are run prior to spoofing, and are captured at runtime by\r\nElastic Endpoint. This is an accurate representation of the processes active on the host, further confirming the\r\nimportance of appropriate observation software for Linux hosts - you can’t always trust what you see on the local\r\nsystem:\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 3 of 20\n\nElastic Analyzer View of BPFDoor demonstrating real process capture.\r\nBPFDoor also holds in its repertoire the ability to subvert the traditional Linux socket client - server architecture in\r\norder to hide its malicious traffic. The methods which it utilizes to achieve this are both unusual and intriguing.\r\nThe sockets interface is almost synonmous with TCP/IP communication. This simple interface has endured for over\r\n40 years - predating both Linux and Windows implementations.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 4 of 20\n\nExample of how TCP/IP and socket interfaces function\r\nBPFDoor uses a raw socket (as opposed to ‘cooked’ ones that handle IP/TCP/UDP headers transparently) to observe\r\nevery packet arriving at the machine, ethernet frame headers and all. While this might sound like a stealthy way to\r\nintercept traffic, it’s actually not – on any machine with a significant amount of network traffic the CPU usage will\r\nbe consistently high.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 5 of 20\n\nThat’s where BPF comes in - an extremely efficient, kernel-level packet filter is the perfect tool to allow the implant\r\nto ignore 99% of network traffic and only become activated when a special pattern is encountered. This implant\r\nlooks for a so-called magic packet in every TCP, UDP and ICMP packet received on the system.\r\nOnce activated, a typical reverse shell - which this back door also supports - creates an outbound connection to a\r\nlistener set up by the attacker. This has the advantage of bypassing firewalls watching inbound traffic only. This\r\nmethod is well-understood by defenders, however. The sneakiest way to get a shell connected would be to reuse an\r\nexisting packet flow, redirected to a separate process.\r\nIn this attack, the initial TCP handshake is done between the attacker and a completely legitimate process – for\r\nexample nginx or sshd. These handshake packets happen to be also delivered to the backdoor (like every packet on\r\nthe system) but are filtered out by BPF. Once the connection is established, however, BPFDoor sends a magic packet\r\nto the legitimate service. The implant receives it and makes a note of the originating IP and port the attacker is using,\r\nand it opens a new listening socket on an inconspicuous port (42391 - 43391).\r\nThe implant then reconfigures the firewall to temporarily redirect all traffic from the attacker’s IP/port combination\r\nto the new listening socket. The attacker initiates a second TCP handshake on the same legitimate port as before,\r\nonly now iptables forwards those packets to the listening socket owned by the implant. . This establishes the\r\ncommunication channel between attacker and implant that will be used for command and control. The implant then\r\ncovers its tracks by removing the iptables firewall rules that redirected the traffic.\r\nDespite the firewall rule being removed, traffic on the legitimate port will continue to be forwarded to the implant\r\ndue to how Linux statefully tracks connections. No visible traffic will be addressed to the implant port (although it\r\nwill be delivered there).\r\nA diagram representing the aforementioned network flows\r\nBPF Filters\r\nAs stated in step 9 (above), BPF or Berkeley Packet Filters is a technology from the early ’90s that allows a user-space program to attach a network filter onto any socket and allow or disallow certain types of data to come through\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 6 of 20\n\nthe socket. These filters are made up of bytecode that runs on an abstract virtual machine in the Linux kernel. The\r\nBPF virtual machine has functionality to inspect all parts of incoming packets and make an allow/drop decision\r\nbased on what it sees. . You can see in the image example below what this looks like within the BPFDoor source\r\ncode:\r\nBPFDoor source code BPF Filters\r\nWe took this BPF code, converted it, and wrote it up as pseudo code in an effort to aid our research and craft packets\r\nable to successfully get through these filters in order to activate the backdoor.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 7 of 20\n\nBPFDoor source code BPF Filter Pseudocode\r\nThe above capabilities allow BPFDoor to attach a filter onto any socket and allow or disallow certain types of data\r\nto come through the socket - used carefully by the adversary to invoke a series of different functions within the\r\npayload.\r\nHistorical Analysis\r\nWe wanted to see over time, between BPFDoor payloads, what, if anything, the threat actors modified. A number of\r\nsamples were detonated and analyzed ranging from the uploaded source code to a sample uploaded last month. We\r\nfound that the behavior over time did not change a great deal. It maintained the same relative attack lifecycle with a\r\nfew variations with the hardcoded values such as passwords, process names, and files - this is not uncommon when\r\ncompared to other malware samples that look to evade detection or leverage payloads across a variety of victims.\r\nWe posture that the threat group would change passwords and update process or file names in an effort to improve\r\noperational security and remain hidden. It also makes sense that the general functionality of the backdoor would not\r\nchange in any great way. As the saying goes “If it’s not broken, don’t fix it”. Our malware analysis and reverse\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 8 of 20\n\nengineering team compared the source code (uploaded to VirusTotal and found on Pastebin) to a recently uploaded\r\nsample highlighting some of the notable changes within the main function of the malware in the images below.\r\nA side by side comparison of the main functions for the Pastebin source code and a sample uploaded\r\nto VT last month focusing on the hardcoded string values for the passwords, process names and file\r\nname\r\nAs we mentioned earlier, one recent sample we have come across that does not seem to exhibit some of the tactics of\r\nprior payloads has been observed - It doesn’t alter its initial name to a hardcoded value and simply executes from its\r\nplaced location, otherwise, it models relatively the same behavior.\r\nLinux Malware Sophistication\r\nA trend we have had the privilege of observing at Elastic, is the threat landscape of Linux targeted attacks - these\r\nbeing focused often on cloud workloads, or systems that typically have less observational technology configured in\r\nmany of the environments we see. The trend of complex, well-designed payloads is something that is often simply\r\noverlooked, and specifically in the case of BPFDoor, remained hidden for years.\r\nIt is important to consider these workloads a critical component of your security posture: A lack of visibility within\r\ncloud workloads will eventually lead to large gaps in security controls - adversarial groups are further growing to\r\nunderstand these trends, and act accordingly. Best practices state that endpoint defenses should be consistent across\r\nthe fleet of systems under management, and conform to a least privilege architecture.\r\nDetection of BPFDoor\r\nAfter researching this malware it became apparent as to why the backdoor remained in use and hidden for so long. If\r\nyou aren’t intimately familiar with Linux process abnormalities or weren’t looking for it you would generally not\r\ndetect it. Even though it takes advantage of Linux capabilities in a stealthy manner to evade detection, there are still\r\nopportunities for both behavioral and signature-based detections.\r\nThe first area of opportunity we witnessed while testing was the behavior we observed during the initial execution of\r\nthe malware, specifically its working directory, in a shared memory location /dev/shm. This is a native temporary\r\nfilesystem location in Linux that uses RAM for storage, and a binary executing from it let alone generating network\r\nconnections is fairly uncommon in practice.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 9 of 20\n\nDuring execution, BPFDoor removes existing files from /dev/shm and copies itself there prior to initialization. A\r\ndetection for this would be any execution of a binary from this directory as root (you have to be root to write to and\r\nread from this directory).\r\nThis was verified by detonating the binary in a VM while our Elastic Agent was installed and observing the\r\nsequence of events. You can see an image of this detection on the Kibana Security Alerts page below. This rule is\r\npublicly available as an Elastic SIEM detection rule - Binary Executed from Shared Memory Directory:\r\nElastic Alert in Kibana - Binary Executed from Shared Memory Directory\r\nThe second opportunity we noticed, for detection, was a specific PID file being created in /var/run. We noticed the\r\ndropped PID file was completely empty while doing a quick query via the Osquery integration to the /var/run\r\ndirectory. While this is not inherently malicious, it is unusual for the file size of a PID to be 0 or above 10 bytes and\r\nthus we created an additional rule centered around detecting this unusual behavior.\r\nOur Abnormal Process ID or Lock File Created rule identifies the creation of a PID file in the main directory of\r\n/var/run with no subdirectory, ignoring common PID files to be expected:\r\nElastic Alert in Kibana - Abnormal Process ID or Lock File Created\r\nThe third area we wanted to look at was the network connections tied to two of the three capabilities (reverse shell\r\nand bind shell) the backdoor possesses. We wanted to see if there were any suspicious network connections tied to\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 10 of 20\n\nprocess or user abnormalities we could sequence together based off of the way BPFDoor handles establishing a\r\nreverse or bind shell.\r\nThe reverse shell was the first capability focused on. Taking a deep look at the process tree in and around the reverse\r\nshell establishment allowed us to key in on what would be considered a strange or even abnormal sequence of events\r\nleading to and involving an outbound network connection.\r\nWe developed a hunt rule sequence that identifies an outbound network connection attempt followed by a session id\r\nchange as the root user by the same process entity. The reason we developed these network focused hunt rules is due\r\nto possible performance issues caused if running these continually.\r\nThe bind shell was the last capability we honed in on. Identifying an abnormal sequence of events surrounding the\r\nbind shell connection was difficult due to the way it forks then accepts the connection and kills the accepting process\r\npost established connection. Therefore we had to focus on the sequence of events within the process entity id\r\ndirectly involving the network connection and subsequent killing of the accepting process.\r\nAfter developing the 2 detection rules along with the 2 hunt rules listed below and in addition to the 6 YARA\r\nsignatures deployed we were able to detect BPFDoor in a myriad of different ways and within different stages of its\r\nlife cycle. As stated earlier though, if you detect this malware in your environment it should be the least of your\r\nconcerns given the threat actor will most likely have already successfully compromised your network via other\r\nmeans.\r\nElastic Detection Summary of complete BPFDoor attack lifecycle\r\nExisting Detection Rules\r\nThe following Elastic Detection Rules will identify BPFDoor activity:\r\nAbnormal Process ID or Lock File Created\r\nBinary Executed from Shared Memory Directory\r\nHunting Queries\r\nThis EQL rule can be used to successfully identify BPFDoor reverse shell connections having been established\r\nwithin your environment:\r\nEQL BPFDoor reverse shell hunt query\r\nsequence by process.entity_id with maxspan=1m\r\n[network where event.type == \"start\" and event.action == \"connection_attempted\" and user.id == \"0\" and not process\r\n[process where event.action == \"session_id_change\" and user.id == \"0\"]\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 11 of 20\n\nElastic Alert in Kibana - Suspicious Network Connection Attempt by Root\r\nThe hunt rule we created here identifies a sequence of events beginning with a session id change, followed by a\r\nnetwork connection accepted, in correlation with ptmx file creation and a deletion of the process responsible for\r\naccepting the network connection. This EQL rule can be used to successfully identify BPFDoor bind shell\r\nconnections within your environment:\r\nEQL BPFDoor bind shell hunt query\r\nsequence by process.entity_id with maxspan=1m\r\n[process where event.type == \"change\" and event.action == \"session_id_change\" and user.id == 0 and not process.exe\r\n[network where event.type == \"start\" and event.action == \"connection_accepted\" and user.id == 0]\r\n[file where event.action == \"creation\" and user.id == 0 and file.path == \"/dev/ptmx\"]\r\n[process where event.action == \"end\" and user.id == 0 and not process.executable : (\"/bin/ssh\", \"/sbin/ssh\", \"/usr\r\nElastic Alert in Kibana - Suspicious Network Connection Accept by Root\r\nYARA Rules\r\nIn addition to behavioral detection rules in the Elastic Endpoint, we are releasing a set of BPFDoor Yara signatures\r\nfor the community.\r\nBPFDoor YARA rule\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 12 of 20\n\nrule Linux_Trojan_BPFDoor_1 {\r\n meta:\r\n Author = \"Elastic Security\"\r\n creation_date = \"2022-05-10\"\r\n last_modified = \"2022-05-10\"\r\n os = \"Linux\"\r\n arch = \"x86\"\r\n category_type = \"Trojan\"\r\n family = \"BPFDoor\"\r\n threat_name = \"Linux.Trojan.BPFDoor\"\r\n description = \"Detects BPFDoor malware.\"\r\n reference_sample = \"144526d30ae747982079d5d340d1ff116a7963aba2e3ed589e7ebc297ba0c1b3\"\r\n strings:\r\n $a1 = \"hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event\" ascii fullword\r\n $a2 = \"/sbin/iptables -t nat -D PREROUTING -p tcp -s %s --dport %d -j REDIRECT --to-ports %d\" ascii fullwo\r\n $a3 = \"avahi-daemon: chroot helper\" ascii fullword\r\n $a4 = \"/sbin/mingetty /dev/tty6\" ascii fullword\r\n $a5 = \"ttcompat\" ascii fullword\r\n condition:\r\n all of them\r\n}\r\nrule Linux_Trojan_BPFDoor_2 {\r\n meta:\r\n Author = \"Elastic Security\"\r\n creation_date = \"2022-05-10\"\r\n last_modified = \"2022-05-10\"\r\n os = \"Linux\"\r\n arch = \"x86\"\r\n category_type = \"Trojan\"\r\n family = \"BPFDoor\"\r\n threat_name = \"Linux.Trojan.BPFDoor\"\r\n description = \"Detects BPFDoor malware.\"\r\n reference_sample = \"3a1b174f0c19c28f71e1babde01982c56d38d3672ea14d47c35ae3062e49b155\"\r\n strings:\r\n $a1 = \"hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event\" ascii fullword\r\n $a2 = \"/sbin/mingetty /dev/tty7\" ascii fullword\r\n $a3 = \"pickup -l -t fifo -u\" ascii fullword\r\n $a4 = \"kdmtmpflush\" ascii fullword\r\n $a5 = \"avahi-daemon: chroot helper\" ascii fullword\r\n $a6 = \"/sbin/auditd -n\" ascii fullword\r\n condition:\r\n all of them\r\n}\r\nrule Linux_Trojan_BPFDoor_3 {\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 13 of 20\n\nmeta:\r\n Author = \"Elastic Security\"\r\n creation_date = \"2022-05-10\"\r\n last_modified = \"2022-05-10\"\r\n os = \"Linux\"\r\n arch = \"x86\"\r\n category_type = \"Trojan\"\r\n family = \"BPFDoor\"\r\n threat_name = \"Linux.Trojan.BPFDoor\"\r\n description = \"Detects BPFDoor malware.\"\r\n reference_sample = \"591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78\"\r\n strings:\r\n $a1 = \"[-] Spawn shell failed.\" ascii fullword\r\n $a2 = \"[+] Packet Successfuly Sending %d Size.\" ascii fullword\r\n $a3 = \"[+] Monitor packet send.\" ascii fullword\r\n $a4 = \"[+] Using port %d\"\r\n $a5 = \"decrypt_ctx\" ascii fullword\r\n $a6 = \"getshell\" ascii fullword\r\n $a7 = \"getpassw\" ascii fullword\r\n $a8 = \"export %s=%s\" ascii fullword\r\n condition:\r\n all of them\r\n}\r\nrule Linux_Trojan_BPFDoor_4 {\r\n meta:\r\n Author = \"Elastic Security\"\r\n creation_date = \"2022-05-10\"\r\n last_modified = \"2022-05-10\"\r\n os = \"Linux\"\r\n arch = \"x86\"\r\n category_type = \"Trojan\"\r\n family = \"BPFDoor\"\r\n threat_name = \"Linux.Trojan.BPFDoor\"\r\n description = \"Detects BPFDoor malware.\"\r\n reference_sample = \"591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78\"\r\n strings:\r\n $a1 = { 45 D8 0F B6 10 0F B6 45 FF 48 03 45 F0 0F B6 00 8D 04 02 00 }\r\n condition:\r\n all of them\r\n}\r\nrule Linux_Trojan_BPFDoor_5 {\r\n meta:\r\n Author = \"Elastic Security\"\r\n creation_date = \"2022-05-10\"\r\n last_modified = \"2022-05-10\"\r\n os = \"Linux\"\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 14 of 20\n\narch = \"x86\"\r\n category_type = \"Trojan\"\r\n family = \"BPFDoor\"\r\n threat_name = \"Linux.Trojan.BPFDoor\"\r\n description = \"Detects BPFDoor malware.\"\r\n reference_sample = \"76bf736b25d5c9aaf6a84edd4e615796fffc338a893b49c120c0b4941ce37925\"\r\n strings:\r\n $a1 = \"getshell\" ascii fullword\r\n $a2 = \"/sbin/agetty --noclear tty1 linux\" ascii fullword\r\n $a3 = \"packet_loop\" ascii fullword\r\n $a4 = \"godpid\" ascii fullword\r\n $a5 = \"ttcompat\" ascii fullword\r\n $a6 = \"decrypt_ctx\" ascii fullword\r\n $a7 = \"rc4_init\" ascii fullword\r\n $b1 = { D0 48 89 45 F8 48 8B 45 F8 0F B6 40 0C C0 E8 04 0F B6 C0 C1 }\r\n condition:\r\n all of ($a*) or 1 of ($b*)\r\n}\r\nrule Linux_Trojan_BPFDoor_6 {\r\n meta:\r\n Author = \"Elastic Security\"\r\n creation_date = \"2022-05-10\"\r\n last_modified = \"2022-05-10\"\r\n os = \"Linux\"\r\n arch = \"x86\"\r\n category_type = \"Trojan\"\r\n family = \"BPFDoor\"\r\n threat_name = \"Linux.Trojan.BPFDoor\"\r\n description = \"Detects BPFDoor malware.\"\r\n reference_sample = \"dc8346bf443b7b453f062740d8ae8d8d7ce879672810f4296158f90359dcae3a\"\r\n strings:\r\n $a1 = \"getpassw\" ascii fullword\r\n $a2 = \"(udp[8:2]=0x7255) or (icmp[8:2]=0x7255) or (tcp[((tcp[12]\u00260xf0)\u003e\u003e2):2]=0x5293)\" ascii fullword\r\n $a3 = \"/var/run/haldrund.pid\" ascii fullword\r\n $a4 = \"Couldn't install filter %s: %s\" ascii fullword\r\n $a5 = \"godpid\" ascii fullword\r\n condition:\r\n all of them\r\n}\r\nInteracting with BPFDoor\r\nThe Elastic Security Team has released several tools that can aid in further research regarding BPFDoor to include a\r\nnetwork scanner used to identify infected hosts, a BPFDoor malware configuration extractor, and a BPFDoor client\r\nbinary that can be used to actively interact with a sample.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 15 of 20\n\nBPFDoor Scanner\r\nThe Elastic Security Team has released a Python script that can identify if you have BPFDoor infected hosts.\r\nThe scanner sends a packet to a defined IP address using the default target port (68/UDP)and default interface. It\r\nlistens to return traffic on port 53/UDP.\r\nBPFDoor scanner tool\r\nBPFDoor Configuration Extractor\r\nThis tool will allow you to extract configurations from any BPFDoor malware you may have collected. This will\r\nallow you to develop additional signatures and further analysis of the malware as well as your environment.\r\nThe BPFDoor configuration extractor can be downloaded here.\r\nBPFDoor configuration extractor\r\nBPFDoor Client POC\r\nQuickly after beginning our research into this malware we realized we would also need to actively interact with\r\nBPFDoor in order to observe the full extent of the capabilities that it possesses and monitor what these capabilities\r\nwould look like from a host and SIEM level.\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 16 of 20\n\nIn order to do this, we had to break down the BPF filters in the BPFDoor source code so we could craft packets for\r\nthe different protocols. To do this, we used Scapy, a packet manipulation program, to ensure we could pass the filters\r\nfor the purpose of activating the backdoor. Once we ensured we could pass the filters, Rhys Rustad-Elliott, an\r\nengineer at Elastic built a BPFDoor client that accepts a password, IP address, and port allowing you to connect to a\r\nBPFDoor sample and interact if you possess the sample’s hardcoded passwords.\r\nDepending on the password or lack of password provided, BPFDoor will behave exactly the same way it would in\r\nthe wild. You can invoke a reverse shell, establish a bind shell, or connect to it with no supplied password to receive\r\na ping-back confirming its installation.\r\nA preview of the BPFDoor Client developed by Elastic Security to assist in research\r\nResearchers looking to use BPFDoor can reach out to Elastic Security for access to the BPFDoor client POC. Please\r\nnote that these tools will be shared at our discretion with those in the trusted security community looking to improve\r\nthe detection of this vulnerability.\r\nImpact\r\nThe following MITRE ATT\u0026CK Tactic, Techniques, and Sub-techniques have been observed with the BPFDoor\r\nmalware.\r\nTactics\r\nTactics represent the “why” of an ATT\u0026CK technique or sub-technique. It is the adversary’s tactical goal: the reason\r\nfor performing an action.\r\nExecution\r\nTechniques (sub-techniques)\r\nTechniques (and sub-techniques) represent ‘how’ an adversary achieves a tactical goal by performing an action.\r\nNative API\r\nExternal Remote Services\r\nHide Artifacts\r\nIndicator Removal on Host\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 17 of 20\n\nNon-Application Layer Protocol\r\nCommand and Scripting Interpreter: Unix Shell\r\nAbuse Elevation Control Mechanism: Setuid and Setgid\r\nSource Pseudocode\r\nTo clearly articulate the details of this malware, we’ve created two diagrams that outline the specific pseudocode for\r\nBPFDoor based on the source code uploaded to VT and found on Pastebin. While this contains a lot of detail, it is\r\nsimple to understand if researchers choose to further this research.\r\nSummary\r\nWhile threat groups continue to increase in maturity, we expect this kind of mature, well designed and hidden threat\r\nwill continue to be found within Linux environments. These kinds of findings reiterate the importance of\r\ncomprehensive security controls across the entirety of a fleet, rather than simply focusing on user endpoints.\r\nBPFDoor demonstrates a perfect example of how important monitoring workloads within Linux environments can\r\nbe. Payloads such as this are near-on impossible to observe and detect without sufficient controls, and should be\r\nconsidered a moving trend within the general adversarial landscape.\r\nObservables\r\nObservable Type Reference Note\r\n/dev/shm/kdmtmpflush\r\nprocess\r\nname\r\nBPFDoor\r\nprocess\r\nname\r\nObserved\r\nprocess\r\nname of\r\nBPFDoor\r\n/var/run/haldrund.pid\r\nfile\r\nname\r\nBPFDoor\r\nfile name\r\nObserved\r\nBPFDoor\r\nPID file\r\n/var/run/kdevrund.pid\r\nfile\r\nname\r\nBPFDoor\r\nfile name\r\nObserved\r\nBPFDoor\r\nPID file\r\n/var/run/xinetd.lock\r\nfile\r\nname\r\nBPFDoor\r\nfile name\r\nObserved\r\nBPFDoor\r\nlock file\r\n74ef6cc38f5a1a80148752b63c117e6846984debd2af806c65887195a8eccc56\r\nSHA-256BPFDoor\r\nmalware\r\n07ecb1f2d9ffbd20a46cd36cd06b022db3cc8e45b1ecab62cd11f9ca7a26ab6d\r\nSHA-256BPFDoor\r\nmalware\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 18 of 20\n\nObservable Type Reference Note\r\n76bf736b25d5c9aaf6a84edd4e615796fffc338a893b49c120c0b4941ce37925\r\nSHA-256BPFDoor\r\nmalware\r\n93f4262fce8c6b4f8e239c35a0679fbbbb722141b95a5f2af53a2bcafe4edd1c\r\nSHA-256BPFDoor\r\nmalware\r\n96e906128095dead57fdc9ce8688bb889166b67c9a1b8fdb93d7cff7f3836bb9\r\nSHA-256BPFDoor\r\nmalware\r\n599ae527f10ddb4625687748b7d3734ee51673b664f2e5d0346e64f85e185683\r\nSHA-256BPFDoor\r\nmalware\r\n2e0aa3da45a0360d051359e1a038beff8551b957698f21756cfc6ed5539e4bdb\r\nSHA-256BPFDoor\r\nmalware\r\nf47de978da1dbfc5e0f195745e3368d3ceef034e964817c66ba01396a1953d72\r\nSHA-256BPFDoor\r\nmalware\r\nfd1b20ee5bd429046d3c04e9c675c41e9095bea70e0329bd32d7edd17ebaf68a\r\nSHA-256BPFDoor\r\nmalware\r\n5faab159397964e630c4156f8852bcc6ee46df1cdd8be2a8d3f3d8e5980f3bb3\r\nSHA-256BPFDoor\r\nmalware\r\nf8a5e735d6e79eb587954a371515a82a15883cf2eda9d7ddb8938b86e714ea27\r\nSHA-256BPFDoor\r\nmalware\r\n5b2a079690efb5f4e0944353dd883303ffd6bab4aad1f0c88b49a76ddcb28ee9\r\nSHA-256BPFDoor\r\nmalware\r\n97a546c7d08ad34dfab74c9c8a96986c54768c592a8dae521ddcf612a84fb8cc\r\nSHA-256BPFDoor\r\nmalware\r\nc80bd1c4a796b4d3944a097e96f384c85687daeedcdcf05cc885c8c9b279b09c\r\nSHA-256BPFDoor\r\nmalware\r\n4c5cf8f977fc7c368a8e095700a44be36c8332462c0b1e41bff03238b2bf2a2d\r\nSHA-256BPFDoor\r\nmalware\r\nReferences\r\nhttps://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896\r\nhttps://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/cyber-year-in-retrospect/yir-cyber-threats-report-download.pdf\r\nhttps://www.pangulab.cn/en/post/the_bvp47_a_top-tier_backdoor_of_us_nsa_equation_group\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 19 of 20\n\nArtifacts\r\nArtifacts are also available for download in both ECS and STIX format in a combined zip bundle.\r\nSource: https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nhttps://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor"
	],
	"report_names": [
		"a-peek-behind-the-bpfdoor"
	],
	"threat_actors": [
		{
			"id": "b740943a-da51-4133-855b-df29822531ea",
			"created_at": "2022-10-25T15:50:23.604126Z",
			"updated_at": "2026-04-10T02:00:05.259593Z",
			"deleted_at": null,
			"main_name": "Equation",
			"aliases": [
				"Equation"
			],
			"source_name": "MITRE:Equation",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "08623296-52be-4977-8622-50efda44e9cc",
			"created_at": "2023-01-06T13:46:38.549387Z",
			"updated_at": "2026-04-10T02:00:03.020003Z",
			"deleted_at": null,
			"main_name": "Equation Group",
			"aliases": [
				"Tilded Team",
				"EQGRP",
				"G0020"
			],
			"source_name": "MISPGALAXY:Equation Group",
			"tools": [
				"TripleFantasy",
				"GrayFish",
				"EquationLaser",
				"EquationDrug",
				"DoubleFantasy"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "2d9fbbd7-e4c3-40e5-b751-27af27c8610b",
			"created_at": "2024-05-01T02:03:08.144214Z",
			"updated_at": "2026-04-10T02:00:03.674763Z",
			"deleted_at": null,
			"main_name": "PLATINUM COLONY",
			"aliases": [
				"Equation Group "
			],
			"source_name": "Secureworks:PLATINUM COLONY",
			"tools": [
				"DoubleFantasy",
				"EquationDrug",
				"EquationLaser",
				"Fanny",
				"GrayFish",
				"TripleFantasy"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "e0fed6e6-a593-4041-80ef-694261825937",
			"created_at": "2022-10-25T16:07:23.593572Z",
			"updated_at": "2026-04-10T02:00:04.680752Z",
			"deleted_at": null,
			"main_name": "Equation Group",
			"aliases": [
				"APT-C-40",
				"G0020",
				"Platinum Colony",
				"Tilded Team"
			],
			"source_name": "ETDA:Equation Group",
			"tools": [
				"Bvp47",
				"DEMENTIAWHEEL",
				"DOUBLEFANTASY",
				"DanderSpritz",
				"DarkPulsar",
				"DoubleFantasy",
				"DoubleFeature",
				"DoublePulsar",
				"Duqu",
				"EQUATIONDRUG",
				"EQUATIONLASER",
				"EQUESTRE",
				"Flamer",
				"GRAYFISH",
				"GROK",
				"OddJob",
				"Plexor",
				"Prax",
				"Regin",
				"Skywiper",
				"TRIPLEFANTASY",
				"Tilded",
				"UNITEDRAKE",
				"WarriorPride",
				"sKyWIper"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "9c8a7541-1ce3-450a-9e41-494bc7af11a4",
			"created_at": "2023-01-06T13:46:39.358343Z",
			"updated_at": "2026-04-10T02:00:03.300601Z",
			"deleted_at": null,
			"main_name": "Red Menshen",
			"aliases": [
				"Earth Bluecrow",
				"Red Dev 18"
			],
			"source_name": "MISPGALAXY:Red Menshen",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434606,
	"ts_updated_at": 1775791992,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2ba8e179f577da0ee8a2ec75e09aab98bdafa51a.pdf",
		"text": "https://archive.orkl.eu/2ba8e179f577da0ee8a2ec75e09aab98bdafa51a.txt",
		"img": "https://archive.orkl.eu/2ba8e179f577da0ee8a2ec75e09aab98bdafa51a.jpg"
	}
}