BPFDoor is backdoor malware associated with the Chinese APT – Red Menshen. It is a highly evasive malware that targets Linux and Solaris-based systems. It is said to have been unnoticed for up to 5 years before its discovery. This malware uses a Berkeley Packet Filter (BPF) sniffer which makes it capable of sniffing all network traffic and bypassing existing firewall rules. It can be used for remote code execution without opening any new network ports.
BPFDoor does not have any form of inbuilt persistence because it does not survive a system reboot. It is therefore assumed that the attacker immediately performs post-exploitation activities after infecting an endpoint. Cronjobs and startup scripts might be used by the attacker for persistence.
When BPFDoor infects an endpoint, It performs the following actions:
1. It copies itself to the
/dev/shm directory as
2. It makes itself executable, timestomps
/dev/shm/kdmtmpflush, and runs with the
--init tag. This creates a forked version of the malware.
3. It starts a packet capture loop to inspect network traffic.
4. It creates one of the following droppers:
/var/run/syslogd.reboot . These are used to mark residency and prevent multiple starts of the executable.
5. The timestomped executable gets deleted but the forked version keeps running in memory.
6. The forked version listens for a magic packet with a password. If the magic packet contains a password that matches the ones hardcoded in the malware source code, a remote shell is created.
1. An installed Wazuh manager (version 4.3.6).
2. An installed and enrolled Wazuh agent on the Linux/Unix endpoints to be monitored.
Wazuh can be configured in multiple ways to detect BPFDoor infection on an endpoint. You can select your desired method of detection. The different detection methods are:
- Using VirusTotal Integration to scan file hashes
- Using Security Configuration Assessment (SCA)
- Using Auditd
Using VirusTotal Integration to scan file hashes
VirusTotal is an online platform that analyzes suspicious files and URLs using multiple antivirus engines and website scanners. It offers an API service that can be queried by using URLs, IP addresses, domain names, or file hashes. Wazuh provides an out-of-box VirusTotal integration which can be combined with the Wazuh FIM module to detect malicious file hashes on an endpoint.
We configured the Virustotal integration on the Wazuh manager and FIM on the Wazuh agent to monitor the
Downloads directory using this guide. Other directories can be added to be monitored by FIM. When BPFDoor samples are downloaded to the monitored directory, alerts are generated on the Wazuh dashboard as shown below:
It is not recommended to detect malware by using only file hashes because the malware can easily be modified and its file hash will change.
Security Configuration Assessment (SCA)
The Wazuh SCA module is used for testing system hardening. It is also used for testing policies and finding misconfigurations on endpoints. To detect BPFDoor activity on the endpoint, we created an SCA policy to check for files created after a BPFDoor infection. These files are
On the Wazuh manager
1. First, we create a new policy file at
policy: id: "bpfdoor_check" file: "bpfdoor_check.yml" name: "BPFDoor backdoor malware check" description: "Checking BPFDoor malware infection for Unix/Linux based systems." requirements: title: "Checking for BPFDoor observables on Unix/Linux based systems." description: "Check that system is Unix/Linux based." condition: any rules: - 'f:/etc/passwd' checks: - id: 10000 title: "Check for BPFDoor malware observables in the \"/var/run/\" directory" description: "Check for BPFdoor artifacts on Unix/Linux based systems." condition: none rules: - 'c:find /var/run/ -name "haldrund.pid" -> r:/var/run/haldrund.pid$' - 'c:find /var/run/ -name "kdevrund.pid" -> r:/var/run/kdevrund.pid$' - 'c:find /var/run/ -name "xinetd.lock" -> r:/var/run/xinetd.lock$' - 'c:find /var/run/ -name "syslogd.reboot" -> r:/var/run/syslogd.reboot$'
Please be aware that, depending on the monitored endpoint, the
find command can be CPU intensive.
2. This SCA policy will get shared with a group of agents, which are the ones that will run the checks. In our case, we are sharing the policy with the
default group, hence the
3. Once the SCA policy file is created, we modify the owner and group so that it can be used by Wazuh:
chown wazuh:wazuh /var/ossec/etc/shared/default/bpfdoor_check.yml
4. Next, we add the SCA block to
/var/ossec/etc/shared/default/agent.conf to enable the new policy on the Wazuh agents that belong to the
<agent_config> <sca> <enabled>yes</enabled> <scan_on_start>yes</scan_on_start> <interval>12h</interval> <skip_nfs>yes</skip_nfs> <policies> <policy>/var/ossec/etc/shared/bpfdoor_check.yml</policy> </policies> </sca> </agent_config>
On the Linux/Unix endpoint
1. We make a change to the Wazuh agent
/var/ossec/etc/local_internal_options.conf file. This is done directly on the endpoints that are being monitored, as there is no way to push this setting from the Wazuh manager. The purpose of this modification is to enable the execution of commands in the SCA policies that are received from the Wazuh manager. Remote commands are disabled by default for security reasons and have to be explicitly enabled by users. This modification is not necessary when the SCA policies are local to the agent:
echo "sca.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf
2. Restart the Wazuh agent to apply the changes:
systemctl restart wazuh-agent
When the SCA scan runs subsequently, we can see the results for an endpoint infected with BPFDoor malware:
Auditd is a native Linux/Unix utility that is used for access monitoring and accounting. It can be used for monitoring system calls, file/directory access, etc.
We wrote Auditd rules to watch for the malicious files that BPFDoor creates on an infected endpoint.
On the Linux/Unix endpoint
1. Install Auditd if it is not already installed on the endpoint:
sudo apt -y install auditd
sudo yum -y install auditd
2. The following rules were added to the
-w /dev/shm/kdmtmpflush -p wa -k possible_bpfdoor_infection -w /var/run/haldrund.pid -p wa -k possible_bpfdoor_infection -w /var/run/kdevrund.pid -p wa -k possible_bpfdoor_infection -w /var/run/xinetd.lock -p wa -k possible_bpfdoor_infection -w /var/run/syslogd.reboot -p wa -k possible_bpfdoor_infection
3. We reload the rules to apply the changes:
auditctl -R /etc/audit/rules.d/audit.rules auditctl -l
4. To set up Auditd log collection, add this block to the agent
<localfile> <log_format>syslog</log_format> <location>/var/log/audit/audit.log</location> </localfile>
5. Restart the Wazuh agent for changes to apply:
systemctl restart wazuh-agent
On the Wazuh manager
1. We create the rule below in
/var/ossec/etc/rules/local_rules.xml file to detect BPFDoor behavior on Linux/Unix endpoints:
<group name="bpfdoor"> <rule id="200402" level="12"> <if_sid>80700</if_sid> <field name="audit.key">possible_bpfdoor_infection</field> <description>Possible BPFDoor infection - Auditd.</description> <mitre> <id>T1204.002</id> </mitre> </rule> </group>
2. Restart Wazuh manager for changes to apply:
systemctl restart wazuh-manager
This screenshot shows alerts that will be displayed if BPFDoor malware infects an endpoint:
BPFDoor is a highly evasive malware that has gone undetected for years. It is associated with Red Menshen and uses BPF to sniff network traffic efficiently. The C2 server can reach the malware implant on already opened network ports, blending with legitimate network traffic.
Wazuh provides multiple methods of detecting this malware: VirusTotal integration, SCA, and ruleset.