Linux Backdoors Email Security Gateways Korea Taiwan

Linux Backdoors Hide in Email Gateways in Korea and Taiwan

Linux Backdoors Hide in Email Gateways in Korea and Taiwan

Linux backdoors were found on email security gateways in South Korea and Taiwan, named and packaged to look like the software already running on them. In Korea that was the SpamSniper anti-spam suite; in Taiwan, ShareTech appliances.

A new implant, AVERAT, talks to its operators over SMTP on port 25, so its traffic looks like ordinary mail. It deletes its own files after starting, and its traffic was routed through hijacked NAS units and CCTV recorders in Taiwan.

There is no patch to apply, and nobody yet knows how the attackers got in. Finding these implants means hunting for them, mainly for processes running from deleted files and for anything other than the mail service talking on port 25.

What happened

New research describes three Linux implants found on mail security and network appliances: a new variant of the passive backdoor BPFDoor, a packet-filtering build of the Rekoobe backdoor, and AVERAT, a modular remote access tool not reported before.

What ties them together is where they were placed. Mail security gateways send and receive email all day, are trusted by the rest of the network, and are rarely inspected closely. Extra mail traffic from a mail gateway gives a defender very little to notice.

Implant families
3
BPFDoor, Rekoobe, AVERAT
C2 port
25 SMTP
blends with mail traffic
Hijacked relays
3 devices
NAS, SMB appliance, CCTV
Files on disk
0 binaries
deleted 10 s after launch

Campaign at a glance

AttributeDetail
Targets SpamSniper mail gateways in South Korea, ShareTech appliances in Taiwan, telecom-style Linux hosts
Associated cluster BPFDoor is associated with Red Menshen (also Earth Bluecrow, DecisiveArchitect, Red Dev 18), China-nexus, active against telecoms since at least 2021
Initial access Not established
Command and control SMTP on TCP 25, via compromised consumer and small-business devices in Taiwan
Remediation path Hunting and monitoring; no patchable flaw implicated

Why target email security gateways?

Most security monitoring looks for unusual behaviour. An email gateway opening mail connections to servers around the internet is normal, so a backdoor that hides its traffic inside those connections is hard to pick out in network logs.

Firewall rules add to the problem. Mail relays are often allowed traffic from port 25 to port 25, and a crafted packet that fits that rule can reach the device before deeper inspection. One of the implants listens for packets of that shape.

This has happened before. In 2023, a different China-nexus group exploited CVE-2023-2868 and later CVE-2023-7102 in Barracuda's Email Security Gateway and kept long-term access to victims. Mail appliances handle sensitive traffic, and most of them cannot run endpoint security agents.

BPFDoor on Korean mail gateways

BPFDoor uses Berkeley Packet Filter, a standard Linux feature for inspecting traffic, to read incoming packets. It does not open a listening port, so a port scan will not find it. It acts only when it receives a specific "magic" packet, in this case one carrying the values 0x6693 (UDP), 0x4274 (TCP) and 0x7820 (ICMP).

The Korean variant's hidden strings decode to /var/run/spamsniper.pid, a file named after the SpamSniper product, and to a list of ten process names it rotates through, such as /usr/sbin/chronyd, /usr/sbin/rsyslogd -n and [watchdogd].

How the wake-up signal gets through the proxy

The updated controller can send its trigger inside a normal HTTPS request

  1. Encrypted wake-up The operator sends a normal-looking HTTPS request towards the target's web-facing edge. HTTPS
  2. The proxy decrypts it An edge proxy or web application firewall terminates TLS and forwards the request inward as plain HTTP. SSL offloading
  3. The backdoor sees the trigger BPFDoor, reading traffic on the internal server, recognises the trigger in the decrypted request. BPF filter match
  4. Direct shell back The implant opens a connection back to the operator that does not pass through the proxy. reverse shell
The proxy's TLS decryption is what lets the backdoor read the trigger. Diagram redrawn by TechOwl from the published description.

Another sample names itself ora_ppmond, which resembles the Oracle database background processes used on telecom subscriber platforms. A fourth uses paths under /sniper/, the Korean mail product's install directory. Both give the operator a Tiny Shell session with a command shell, upload and download.

A disguise that only reads as legitimate on hosts actually running that class of infrastructure.

Primary research report, on the ora_ppmond process name

A Rekoobe build that listens on port 25

Rekoobe is a long-standing Linux backdoor derived from Tiny Shell. This build adds a 26-instruction packet filter that watches TCP, UDP and SCTP over IPv4, and UDP over IPv6, where both the source and destination port are 25, the same pattern the mail-relay firewall rule allows. Its process names copy those of the mail product's own components:

  • /sniper/bin/crond -n and /sniper/bin/earsd --start
  • /sniper/apache/bin/httpd -k start and /sniper/snipe/bin/snipe-smtpd
  • /usr/lib/polkit-1/polkitd --no-debug, a standard Linux process name

The reverse shell runs as /sniper/autorun/rblsmtpd --start -n 9, the name of a real mail-filtering daemon, and connects to the operator on port 25. It sets HISTFILE=/dev/null and related variables so the operator's commands are not saved in shell or editor history.

The ShareTech dropper

On Taiwanese appliances, the installer is a small x86-64 program with no networking code. It is a local installer, run after the attacker already had access. It sits in /addpkg/sbin/, the appliance's own add-on package directory, and decrypts its payload with an AES key taken from the SHA-1 hash of the string "ShareTech", the vendor's name.

Install chain on a ShareTech appliance

From gate check to boot persistence

  1. Gate check The dropper runs only if a marker file already exists, a precondition set by the operator. /tmp/flag
  2. Write the script A shell script is written to the appliance's storage volume, despite its .php extension. /HDD/ms6x2xTo64/updIptable.php
  3. Copy, run, delete The dropper and AVERAT are copied into /sbin under system-tool names, started, and deleted ten seconds later. /sbin/ntpdate · /sbin/udevds
  4. Watchdog The relaunched dropper recreates its marker file and script every two seconds if either disappears. execProcEnd
  5. Survive reboot There is no persistence code. The firmware likely relaunches add-on packages at boot. /addpkg/sbin/
Both programs keep running after their files are deleted. Searching /sbin afterwards turns up nothing to hash or submit.

AVERAT, the new implant

AVERAT connects out to port 25 and starts like a mail client: it sends EHLO, requests STARTTLS, then switches to its own encrypted session. The TLS layer is hand-built around a fixed ClientHello template with a 40-entry cipher list, so every connection should present the same TLS fingerprint. That is our inference from the design; it has not been confirmed on live traffic.

The implant checks in every 600 to 699 seconds, reporting hostname, user, operating system, network interfaces and logged-in users. Its only disk artefact is a small hidden state file, /var/lib/.db by default.

  • Files: browse, upload, download with resume, and recursive deletion.
  • Processes: list with command lines, and terminate.
  • Shells: up to ten simultaneous interactive sessions.
  • Network: proxy and port-forward channels through the appliance, and runtime changes to its C2 address.
  • Extension: load and unload modules at runtime, and reboot the device.

If it receives a command it does not recognise, it shuts itself down, so probing a live implant ends the session. Six samples were analysed. Their configurations fall into two builds, and all six use the same authentication keys, which makes them good material for detection signatures.

The relay devices

The three hardcoded C2 addresses belong to compromised third-party devices on a large Taiwanese broadband network (AS3462), in three different cities: a Synology NAS belonging to a small business, an obsolete ADSL/FTTH business appliance, and a Dahua CCTV recorder. All three are old or unpatched, and probably nobody is watching them.

Each one also runs a PPTP VPN service on port 1723, and all three return the same banner byte for byte. CCTV recorders do not come with a VPN server, so the operator probably installed it. If so, each device works as a relay for implant traffic and also as a way into its owner's local network.

CISA, NCSC-UK and partner agencies described this kind of device in joint advisory AA26-113A (April 2026) as typical of China-nexus covert relay networks, also called operational relay box (ORB) networks. These relays have not been linked to any specific named ORB network.

What we observed on 7 October

We looked up the published domains in public WHOIS, DNS, certificate transparency and scan data. We did not connect to any of the infrastructure.

C2 hostnameParent registeredSubdomain first seenResolves to (7 Oct)
spam.suwaccqi[.]com Apr 2024 23 Dec 2025 AS2828, United States
mx.zxopfds[.]com Feb 2025 21 Dec 2025 AS4134, China
mx1.wwstifsteel[.]com Dec 2024 5 Oct 2026 AS702, Germany

What we found. All three domains were registered at the same registrar, and each has a mail-style subdomain. Two of those subdomains were first seen two days apart, eight to twenty months after the parent domains were registered. All three now resolve to addresses that were not in the original research. None of those addresses has reverse DNS or other domains hosted on it, and none has been seen scanning the internet.

Our assessment

The domains were likely left unused on purpose so they would not be caught by filters for newly registered domains (moderate confidence).

The late-December dates likely show when these C2 servers were switched on (low confidence, based on two data points).

The new addresses are roughly as likely to be new relays as reassigned addresses. Two are in business IP ranges, which fits the relay pattern without proving it (low confidence).

Attribution

BPFDoor and its variants are associated with Red Menshen, a China-nexus group that has targeted telecom providers in the Middle East and Asia since at least 2021. The Korean-language disguises, the telecom-platform process names and the Taiwanese relays are consistent with what is known about that group.

Other explanations are possible. BPFDoor source code has been public since 2022, and other China-nexus groups, including Liminal Panda, UNC3886 and Velvet Ant, also use Tiny Shell. Using the same tools does not make two groups the same group. Red Menshen is a reasonable attribution, but it is based on the malware and the targets, not on infrastructure unique to that group.

Indicators of compromise

Network indicators are defanged. The IP addresses below belong to compromised third-party devices.

IndicatorTypeContext
mx.zxopfds[.]com Domain AVERAT C2, TCP 25
spam.suwaccqi[.]com Domain AVERAT C2, TCP 25
mx1.wwstifsteel[.]com Domain AVERAT C2, TCP 25
59.125.211[.]65 IPv4 C2 relay, compromised NAS
122.116.138[.]33 IPv4 C2 relay, compromised SMB appliance
1.34.200[.]85 IPv4 C2 relay, compromised CCTV recorder
/var/run/spamsniper.pid Path BPFDoor product-spoofing artefact
/var/lib/.db, .sencha, .us, .a Path AVERAT state files
/HDD/ms6x2xTo64/updIptable.php Path ShareTech dropper script
/addpkg/sbin/update, /addpkg/sbin/agetty Path Dropper and AVERAT staging
ora_ppmond, /sniper/autorun/rblsmtpd Process name BPFDoor and Rekoobe disguises

Current resolutions observed by TechOwl

Seen on 7 October 2026. These have not been confirmed as malicious; we suggest monitoring them rather than blocking.

IndicatorTypeContext
118.250.171[.]118 IPv4 A record of mx.zxopfds[.]com, AS4134
216.105.6[.]40 IPv4 A record of spam.suwaccqi[.]com, AS2828
195.126.224[.]88 IPv4 A record of mx1.wwstifsteel[.]com, AS702

SHA-256 hashes

HashContext
2bedc26d4b29b435c21962beed7db21188a0219a0d28334bba8b4fb1656d7b15 ShareTech dropper
bf8135f46ecedfe5bd06fcecbb2e721c2367ff765b18f4aa3f868e6597f49e47 AVERAT
4925bcca085ec504f51191645da278d8e96698d91f3c6df44146336c697b4de8 AVERAT
a4379e115d3c4420f5d4b92561022d6e0897990e7297be65c033d47de68e6a6a AVERAT
925c041807d4fb9dfe2ad84f963c2a4c60ea1289f6a0bdccbfb944478ffc2cf2 AVERAT
2fe2dd402ee6f9c578fce6dd4b36daaa407e99133e5dd502f2afca80feb60150 AVERAT
a65048eb30661e27f8edc2dd8d8c77ec87faec1f1750f6e04e7ecaf069a32858 AVERAT
a37ea9897221d4495b538de72b74f2aa1d2ff09b7b6dcedd395aee58931adbf3 BPFDoor, SpamSniper disguise
7e667ba5f9df912e02275d3cfe3809d16f822fe776f4035c84b118ebd925b1b5 BPFDoor, SpamSniper disguise
4435fcd6862921092614dbeaa880e4192352984686ebcd98f0ba13ee8e226ef9 BPFDoor, data-plane variant
a6f3b7f932761fb1fd5e74123f2482e36c65dd13e769af2ce08c65da195bfa7a BPFDoor, data-plane variant
652508a9cf40bee883dc0e5e219dfeba71fe7dac591d01c89f74c21f73b4963f BPF Rekoobe

Detection and response

Because the files delete themselves after launch, scanning the appliance's disk is unlikely to find anything. Look at behaviour instead.

  • Hunt for processes running from deleted files. On Linux, /proc/<pid>/exe ending in (deleted) means the program file has been deleted. There are very few legitimate reasons for this on an appliance.
  • Look for packet sniffing where none is expected. Find out why any host that has no reason to capture traffic has raw packet sockets or BPF filters attached. Check /proc/net/packet and ss -0 -p.
  • Check process names against the files behind them. A process calling itself chronyd, rsyslogd or a mail-product daemon should map to that binary.
  • Watch outbound port 25 per process. Outbound SMTP from anything other than the mail service is suspicious. Where TLS metadata is visible, look for one repeated ClientHello fingerprint after STARTTLS.
  • Tighten the "port 25 to port 25" firewall rule to known mail peers where possible.
  • Restrict management access to edge devices such as routers, NAS units and CCTV recorders, and replace end-of-life hardware. Devices like these, including ones on your own network, are what relay networks are built from.
  • Collect evidence before rebooting. These implants run in memory, so capture process lists, memory and network connections first.

Verdict

Is there a patch to apply? No. The research does not point to a vulnerability; these tools were installed after the attackers already had access.
Who should act now? Operators of SpamSniper and ShareTech appliances, and telecoms running Linux infrastructure in the region.
Will file scanning find it? Unlikely. The binaries delete themselves after launch.
Best single detection? Processes whose executable shows as (deleted) on appliances.
Is the C2 still live? All three domains still resolve as of 7 October 2026, to new addresses.
What should change? Include mail gateways and other security appliances in threat hunting, not only servers and laptops.

The implants were tailored to particular products in particular countries, so the attackers knew what software their targets were running before they deployed anything. Teams that run SpamSniper, ShareTech or similar mail appliances should hunt on those devices now rather than wait for indicators to match.

Sources

  1. CISA, NCSC-UK and partner agencies, joint advisory AA26-113A on China-nexus covert network infrastructure, Apr 2026.