BPFDoor and AVERAT at the Network Edge

What happened

Rapid7's October 2, 2026 research describes Linux malware adapted to the environments of mail-security and telecommunications appliances. Its analysis covers BPFDoor variants and a BPF-enabled Rekoobe build associated with South Korean targets, plus a dropper and six builds of an implant Rapid7 calls AVERAT associated with Taiwanese appliances.

The common defensive problem is contextual disguise. Process names resemble services that administrators expect to find on the affected platforms, while network activity exploits the fact that mail gateways legitimately handle SMTP. However, these are not interchangeable infection chains: BPFDoor and the analyzed Rekoobe build use packet-triggered access, whereas AVERAT initiates outbound command-and-control sessions.

The report provides malware analysis and infrastructure observations, not a new appliance vulnerability advisory. The findings below are attributed to Rapid7; the response priorities are CyberVOC's synthesis, supported by MITRE ATT&CK and Linux documentation.

Who is affected

The immediate audience is operators of Linux-based mail-security gateways, telecom infrastructure, and network-edge appliances. Rapid7 describes product-specific disguises associated with SpamSniper and assesses that a separate dropper was likely built for ShareTech appliances. These clues indicate adaptation to particular environments; they do not establish that every deployment of either product is vulnerable or compromised.

A second exposure category is consumer and small-business equipment repurposed as infrastructure. Rapid7 identifies NAS, embedded network equipment, and a video recorder as apparent third-party victim systems used as relays. Organizations can therefore be affected either as the principal target or as an unwitting intermediary.

The article does not establish a campaign-wide initial-access method, a complete affected-version matrix, a campaign-specific CVE or CVSS score, or a fixed firmware release. The analyzed dropper operates after access has already been obtained. Defenders should investigate how the appliance was first compromised rather than assume the malware itself explains entry.

Why it matters

An edge appliance often occupies a privileged network position but has less host telemetry than a managed workstation. A compromised gateway can provide opportunities for remote command execution, file access, traffic relay, and further access to reachable systems. The business impact depends on the appliance's permissions and network reach; these capabilities do not, by themselves, prove that data was stolen in every case.

Three familiar checks are insufficient on their own. A clean port scan cannot exclude a passive packet-triggered backdoor. A plausible daemon name does not establish executable integrity. And an allowed TCP/25 connection does not establish that the originating process is a mail service.

This is an argument for correlating host and network evidence, not for treating all BPF activity or SMTP traffic as malicious.

Technical details

Passive activation is different from outbound beaconing

The BPFDoor and BPF Rekoobe samples attach classic Berkeley Packet Filter filters to raw packet sockets. This lets them inspect selected traffic and remain relatively quiet until a matching trigger is received. MITRE documents this behavior as Traffic Signaling: Socket Filters, T1205.002.

Classic BPF socket filtering should not be conflated with a newly disclosed eBPF kernel vulnerability. The suspicious behavior is an unauthorized process using packet-capture capabilities for covert activation. Legitimate monitoring and network-security software can use similar mechanisms, so ownership, privileges, executable provenance, and subsequent connections must be assessed together.

Rapid7 also describes controller functionality that carries activation material inside web requests traversing an edge proxy. For defenders, the implication is that visibility at the TLS termination point and on the backend segment can matter. It does not establish that every proxy deployment or stateful firewall is bypassed; reachability and inspection depend on the actual topology and policy.

The analyzed Rekoobe build uses port-25-focused filtering and mail-platform process disguises. The fact that traffic uses a mail-associated port should not substitute for protocol or process validation.

AVERAT uses the appearance of mail traffic

AVERAT connects outward on TCP/25, begins with SMTP negotiation, and requests STARTTLS before continuing its encrypted control session. Rapid7 describes a fixed TLS ClientHello structure and callbacks initially spaced between 600 and 699 seconds, with the interval configurable by the operator.

These characteristics create investigation leads rather than permanent signatures. A fixed handshake fingerprint can change between builds, and a timing-only detector will miss modified intervals. Prefer a combination of connection destination, process attribution, protocol behavior, repeated timing, and the absence of corresponding legitimate mail activity.

Basic flow records may make these sessions resemble ordinary SMTP. That does not make the activity indistinguishable across all telemetry: mail transaction logs, approved relay configuration, TLS metadata where available, and endpoint socket ownership can provide additional context.

Rapid7 reports capabilities including host discovery, file transfer, interactive access, shared-module loading, proxying, and appliance reboot. These are capability findings; incident responders must determine which functions were actually used on an affected device.

Deleted filenames do not mean all evidence is gone

The reported dropper stages executables under service-like names, including ntpdate and udevds, starts them, and removes the staged paths roughly ten seconds later. A resident watchdog can recreate supporting artifacts. Original payload locations in the appliance's add-on directory remain relevant to the investigation.

Linux permits a process to continue after its executable pathname is unlinked. Its /proc/<pid>/exe link may then carry a '(deleted)' suffix. Importantly, the Linux manual documents that opening this link can still access the executable, subject to permissions and process state. Investigators should not assume the sample is unrecoverable merely because the original directory entry has disappeared.

This makes live acquisition valuable before termination or reboot. A deleted executable is not automatically malicious: legitimate software upgrades can produce the same condition. Correlate it with unexplained raw sockets, unusual parentage, transient staging, watchdog behavior, and network connections.

Rapid7 suggests that appliance package startup likely provides a relaunch mechanism. That is an assessment, not confirmed boot persistence for every affected device. Verify startup configuration and vendor package behavior during recovery.

Relay infrastructure and attribution limits

Rapid7 assesses the recovered IP infrastructure as compromised third-party equipment rather than exclusively operator-owned servers. It also interprets matching PPTP service observations across disparate devices as possible operator-installed relay functionality.

The research compares this pattern with operational relay box, or ORB, networks, but explicitly reports no infrastructure or indicator overlap with the named networks it discusses. Shared device classes, software conventions, and regional targeting are not sufficient to assign a particular operator or government sponsor. Keep attribution separate from the evidence needed to contain a compromised appliance.

Detection priorities

• Investigate raw packet sockets and attached classic BPF filters belonging to processes without an approved capture or inspection role. On appliances that legitimately inspect traffic, compare against a vendor-supported baseline rather than alert on BPF presence alone.
• Validate process identity beyond the displayed name. Compare executable provenance, package ownership, parent process, privileges, open files, and sockets; daemon-looking labels can be rewritten.
• Correlate short-lived executable creation and deletion with continuing processes. Include the add-on package area and persistent storage in evidence collection, not only the staging directory.
• Review SMTP connections from non-mail processes and sessions that lack corresponding mail transactions. External destinations, repeated timing, and deviations from approved routing strengthen the signal; consumer broadband addressing alone is not proof of abuse.
• Review historical DNS and direct-IP connections. Rapid7 observed both domain-based and hardcoded-IP configurations, so DNS-only hunting leaves a coverage gap.
• Treat missing shell history as inconclusive. Centralized audit, network, and appliance logs are more useful than relying on an interactive history file to reconstruct activity.

Selected investigation artifacts

Rapid7 lists /addpkg/sbin/update and /addpkg/sbin/agetty as payload locations, /HDD/ms6x2xTo64/ as a supporting directory, and execProcEnd as a watchdog marker. It also lists /var/run/spamsniper.pid as a BPFDoor mutex artifact. Such names require contextual verification because they are intended to resemble legitimate software conventions.

AVERAT state-file paths vary by build: /var/lib/.db, /var/lib/.sencha, /var/lib/.us, and /var/lib/.a appear in the report. Do not restrict a hunt to one hidden filename or delete files solely because their names match.

Published network indicators include mx[.]zxopfds[.]com, spam[.]suwaccqi[.]com, mx1[.]wwstifsteel[.]com, 59.125.211[.]65, 122.116.138[.]33, and 1.34.200[.]85. These defanged indicators are for historical correlation and controlled defensive review, not browsing or active probing. Current ownership and availability have not been independently verified. Because the IPs may represent victim infrastructure or change ownership, record observation dates and assess collateral impact before blocking.

Use Rapid7's original indicator tables for complete sample hashes and updated context. Malware passwords, cryptographic secrets, activation bytes, and controller instructions are deliberately excluded here.

Recommended actions

Reduce exposure and improve visibility

1. Inventory edge appliances, firmware releases, support status, internet-facing management services, and ownership. Apply vendor-supported updates and replace end-of-life equipment. Updates reduce exposure to known weaknesses but do not establish that an already compromised device is clean.
2. Restrict management to approved administrative paths and segment appliances from unrelated internal systems. Review adjacent SMB or NFS access that could permit unauthorized writes to appliance storage.
3. Limit SMTP egress to systems with a documented mail role. Use approved relays where the architecture permits; where direct internet delivery is necessary, retain destination and transaction visibility rather than applying an indiscriminate port-25 block that disrupts mail.
4. Centralize appliance, management, DNS, firewall, and available process telemetry. Where endpoint agents are unsupported, combine vendor diagnostics with external sensors and an explicit evidence-collection procedure.
5. Validate unexpected VPN or relay services against approved configuration. Do not infer compromise from a port number alone, but investigate unexplained PPTP exposure and undocumented forwarding behavior.

Contain and recover

1. Coordinate containment with the network and messaging owners. Isolate or fail over affected services using a known-good alternative, balancing operational continuity against continued unauthorized access.
2. Preserve volatile evidence before routine reboot or process termination when operationally safe. Collect process metadata, socket ownership, file descriptors, memory mappings, recoverable executables, and relevant persistent files using approved forensic methods. Avoid interacting with the implant's command interface.
3. Scope the initial entry point, related appliances, management accounts, and subsequent connections. Investigate the possibility that the device is also forwarding activity for another operation.
4. Rebuild or reflash from trusted vendor media when integrity cannot be established. Verify add-on packages, startup configuration, and stored settings before restoration; do not automatically restore an unreviewed configuration backup. Replace unsupported hardware where trustworthy recovery is unavailable.
5. Rotate exposed administrative credentials and other secrets according to the incident scope, from a trusted system. Confirm management restrictions, clean service ownership, and expected egress before reconnecting the appliance.
6. Monitor for recurrence and follow vendor and Rapid7 updates. Blocking known destinations or deleting a staged binary is not sufficient evidence that the watchdog, persistence mechanism, or original access path has been removed.

The central lesson is to validate whether a process and connection belong on that particular appliance. Expected names and permitted protocols are useful context, but neither is proof of trust.

Sources

• Rapid7: SMTP is the key: BPFDoor and AVERAT hitting the network edge, October 2, 2026
• MITRE ATT&CK: Traffic Signaling: Socket Filters, T1205.002
• Linux man-pages: proc_pid_exe(5), executable links and unlinked pathnames

Source review date: October 7, 2026.