What it is
BPFDoor is a hidden backdoor for Linux servers and appliances that stay running for long stretches, notably in telephone and mobile networks. It doesn't open a normal network port. Instead it attaches a packet filter inside the kernel, the core of the operating system, and waits quietly to be contacted. It disguises its process with the names of real system programs, deletes its own program file after it starts and changes file timestamps, which is why a server with BPFDoor can't be trusted to check itself.
How it gets in
Researchers describe it as something attackers install after they have already broken in another way, so the first way in isn't known from these reports. Treat the rest of your network as possibly affected too.
Close the door: Watch for executables running from /dev/shm or /var/run, unusually sized PID files directly under /var/run, and processes holding raw packet sockets with attached filters (the Trend Micro report shows listing them with the ss tool). Do not trust the process name alone.
How to tell if you have it
Signs published for this threat. One sign alone proves little: names get reused, and newer versions change them. Look for several together.
| Kind | Sign |
|---|---|
| File location | /dev/shm/kdmtmpflush |
| File location | /var/run/haldrund.pid |
| File location | /var/run/kdevrund.pid |
| File location | /var/run/xinetd.lock |
| File location | /var/run/cma.lock |
| File location | /var/run/user/0 |
| File name | kdmtmpflush |
| Process name | kdmtmpflush |
| Process name | hpasmlited |
| Process name | cmathreshd |
| Process name | hald-addon-acpi |
These commands only look. They change nothing.
Look for the known file locations:
sudo ls -la /dev/shm/kdmtmpflush /var/run/cma.lock /var/run/haldrund.pid /var/run/kdevrund.pid /var/run/user/0 /var/run/xinetd.lock 2>/dev/nullSearch for the known file names (slow on big disks):
sudo find / -xdev \( -name 'kdmtmpflush' \) 2>/dev/nullLook for the known process names, and where each one runs from:
for p in $(pgrep -f 'kdmtmpflush|hpasmlited|cmathreshd|hald\-addon\-acpi'); do echo "$p $(sudo readlink /proc/$p/exe)"; doneList running programs that live in a temporary folder (real software almost never does):
sudo ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E '/(tmp|var/tmp|dev/shm)/'Fingerprint a suspect file and compare it with the list below:
sudo sha256sum /path/to/suspect-fileKnown file fingerprints (SHA-256). A match identifies that exact file; newer builds differ.
How sure these signs are: BPFDoor changes its process name, deletes its own program file and alters timestamps, so a check run on the infected server can miss it, and finding nothing does not prove the server is clean. /dev/shm/kdmtmpflush may already be gone on a running server. Several names belong to real software: xinetd, cma.lock, cmathreshd (part of HPE server management, which one version imitates, as it does with hpasmlited) and hald-addon-acpi, so check where a process runs from, not its name. /var/run/user/0 is a normal folder; only an unexpected program inside it is a sign. A stronger sign is a program running from /dev/shm or /var/run, or one holding a raw packet filter that you can't explain. These signs come from reports from 2022 to 2026, and newer versions change names and locations.
How to deal with it
Removing it in place isn't safe. Here is what to do instead, in order:
- Don't try to clean it in place. Plan to rebuild the server from a fresh install.
- Cut the server off from the internet, but keep a way to log in, such as your hosting provider's web console. Save evidence before you restart anything, because it usually lives in temporary storage that is cleared on restart: the process list and memory, the PID and lock files in /var/run such as haldrund.pid, kdevrund.pid, xinetd.lock and cma.lock, and the list of programs holding packet filters.
- Copy off your data: databases, website files and documents. Don't copy programs, scripts or startup entries; any of those could bring it back.
- Reinstall from a fresh image, install all updates, then restore only the data you copied and checked.
- From a clean computer, change every password and key that was on the server, and cancel the old ones. Check your other servers for the same signs, because the attackers got in some other way first and may still have that access.
- Before you reconnect, find out how the attackers first reached the server and close that route. Keep watching for programs running from /dev/shm or /var/run, unusually sized PID files directly in /var/run, and programs holding raw packet filters. Don't trust a process name on its own.
What Minaki Scan does about it
Minaki Scan looks for this threat and reports it only when at least two signs agree. It never tries to remove it: it tells you to back up your data and rebuild.
Minaki Scan checks your server every day for this and the other threats in this wiki. $1 per server a month. Downloads open soon.
Sources
This page is written by MinakiLabs in our own words. The facts above come from this published research; credit and thanks to its authors.
- SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, NIST (2013-07)
- A peek behind the BPFDoor, Elastic Security Labs (2022-07-13)
- Stealthy BPFDoor Variants are a Needle That Looks Like Hay, Rapid7 (2026-04-02)
- Detecting BPFDoor Backdoor Variants Abusing BPF Filters, Trend Micro (2023-07-13)