A Linux backdoor can disappear from a mail-security appliance’s directory while continuing to run—and then talk to its operator using the same protocol the appliance handles all day. Rapid7’s October 2 research connects those two disguises: short-lived executable files and command traffic that looks like ordinary outbound email.
The report examines new BPFDoor variants, a BPF-enabled Rekoobe backdoor used against South Korean targets, and six builds of an implant Rapid7 calls AVERAT, found on Taiwanese appliances. The useful distinction is how they maintain access: some wait quietly for a special packet; AVERAT calls out over SMTP. This is network-edge malware research, not evidence that receiving an email infects a Windows PC.
The files vanish; the processes stay
In the Taiwanese chain, a local installer uses the name of appliance vendor ShareTech to derive its decryption key. It checks for an existing /tmp/flag, then writes a shell script to /HDD/ms6x2xTo64/updIptable.php. The extension says PHP, but the file begins with a shell-script header. The installer already requires access to the device; the report does not establish the initial intrusion route.
The script copies two binaries from an add-on package directory into /sbin, naming them ntpdate and udevds. It starts each and deletes its directory entry ten seconds later. On Linux, removing that entry does not stop a running executable. Its /proc/{pid}/exe link can show (deleted) while the process remains alive. A search for the two filenames in /sbin can therefore miss the access that matters.
The first binary is the installer running again as a watchdog. Because its script now exists, it takes a different branch, checking every two seconds and recreating the script or its execProcEnd marker if either disappears. The second binary is AVERAT. Rapid7 considers the appliance’s package-startup behavior a likely route to relaunch the installer at boot; that is an assessment, not a demonstrated universal persistence method.
AVERAT borrows the appliance’s normal language
AVERAT opens an outbound connection on TCP port 25, sends EHLO, requests STARTTLS, and proceeds to its encrypted control session. A mail gateway is expected to make SMTP connections, so a flow record containing the right port and encryption is a weak reason to trust this one. The more useful questions are which process opened it and what kind of device sits at the destination.
The analyzed implant checks in every 600–699 seconds, reporting details including the hostname, user, operating system and network interfaces. It stores adjustable timing state in /var/lib/.db. Its commands support file transfer, interactive shells, extra modules and proxy channels. The problem is continuing remote access to a device positioned in the mail path, rather than a suspicious email attachment that a recipient can simply discard.
BPFDoor waits for a trigger instead
The South Korean samples take a quieter route. BPFDoor attaches a classic Berkeley Packet Filter to a raw packet socket, watching for an authenticated trigger before opening access. Related Rekoobe code inspects traffic associated with port 25 and imitates services belonging to the SpamSniper mail-security environment. Familiar service names fit the camouflage; they are not evidence that the genuine software is malicious.
Rapid7 also reconstructed controller behavior that puts a BPFDoor trigger inside an HTTPS POST request. When an edge proxy terminates encryption and forwards HTTP, the implant can locate its payload despite rewritten headers. A padded 9999 marker and the end of the HTTP headers provide reference points. This describes control of an already compromised server, not a claim that an ordinary login request compromises a healthy one.
The other end can be someone else’s recorder
Rapid7 traced three AVERAT configuration addresses to Taiwanese consumer or small-business equipment: a fuel retailer’s NAS, an old network appliance and a CCTV recorder. The researchers assessed these as compromised third-party relays. Their matching PPTP service fingerprints supported an assessment of operator-installed VPN access, making the devices useful as both relays and possible footholds into their own networks.
This resembles the broader pattern of turning neglected equipment into attack infrastructure, also seen in the separate LeakySensey router-proxy case. Rapid7 did not find indicator or infrastructure overlap proving AVERAT belonged to a particular named relay network. A shared device type cannot supply that missing attribution.
What to investigate before erasing evidence
For operators of Linux mail gateways and edge appliances, Rapid7’s findings favor process and network evidence over a filename-only sweep:
- Correlate running executables marked
(deleted)with process arguments, open descriptors and socket ownership. Legitimate software updates can also leave a deleted executable running; the suffix is a lead, not a verdict. - Look for the unusual script path, shell content under a
.phpextension,execProcEnd, and the launch/delete sequence aroundntpdateandudevds. A generic daemon name alone is insufficient. - Investigate port-25 callbacks from processes that are not mail services, especially when their destination resolves to broadband equipment. Review raw packet sockets and classic BPF use where packet capture has no expected role.
- Preserve volatile process and connection evidence before rebooting or removing artifacts. Restrict exposed management interfaces and review support status and adjacent writable mounts. The separate MikroTrick investigation also explains why updating an edge device and checking for existing intrusion are separate tasks.
The revealing failure is misplaced trust in appearances: a missing binary, a routine daemon name or normal-looking SMTP does not establish that a mail appliance is clean. In this case, the running process and the destination of its connection tell the more useful story.
References
- Rapid7 Intelligence. SMTP is the key: BPFDoor and AVERAT hitting the network edge. Rapid7, October 2, 2026.
- Linux man-pages project. proc_pid_exe(5): link to the executable. Accessed October 4, 2026.
