Linux Backdoors Impersonating Email Services Hit Telecom Networks in South Korea and Taiwan — Detection and Response Guide

Threat actors are deploying Linux-based unauthorized access mechanisms — persistent backdoors — against telecommunications providers and network appliances in South Korea and Taiwan, and they are using one of the oldest and most reliable defense-evasion techniques in the playbook: masquerading. According to recent reporting, these implants disguise both their on-host presence and their network traffic as legitimate email services, borrowing the names of real operating system binaries and blending command-and-control (C2) communications into what appears to be routine SMTP traffic.

This campaign matters beyond East Asia. Telecom infrastructure is a strategic intelligence target — it provides access to call metadata, signaling traffic, subscriber data, and a pivot point into enterprise and government networks. Any organization running Linux-based network appliances, mail gateways, or carrier-grade infrastructure should treat this as an active threat worth hunting for today, not a regional curiosity.

The techniques described — process masquerading and protocol impersonation — are catalogued in MITRE ATT&CK as T1036 (Masquerading) and T1071.003 (Application Layer Protocol: Mail Protocols). Neither is novel. Both are consistently effective because most environments have enormous blind spots around Linux process telemetry and east-west SMTP traffic. This post closes those gaps.

Technical Analysis

Affected Platforms and Targets

The reported campaign targets:

• Telecommunications infrastructure in South Korea and Taiwan, including Linux servers handling carrier workloads
• Network appliances — routers, gateways, and edge devices running embedded or hardened Linux, which frequently lack EDR coverage and forward little or no process telemetry
• Systems exposed to the internet or reachable from compromised upstream infrastructure

No CVE has been publicly associated with this campaign at the time of writing. That is itself a defensive signal: the access mechanism described does not depend on a single patched vulnerability. Implants like these are typically deployed after initial access — through compromised credentials, exposed management interfaces, or exploitation of edge appliances — which means patching alone will not evict an established foothold. You must hunt.

How the Evasion Works

1. Process masquerading (T1036 / T1036.005). The malicious binaries are named after legitimate operating system components or daemons — a technique as old as Unix rootkits. In this campaign, the naming convention favors email infrastructure: expect binaries and process names resembling sendmail, postfix, master, smtpd, exim, dovecot, or imapd. A process listing showing master or smtpd on a mail host raises no eyebrows. The differentiator is where the binary lives and how it was launched: a legitimate Postfix smtpd executes from /usr/libexec/postfix/ or /usr/sbin/ under a systemd unit. A masquerading implant typically executes from /tmp, /var/tmp, /dev/shm, a hidden directory under /var/lib, or a user home directory — often as a direct child of a shell or an orphaned process with no service unit.

2. Traffic impersonation (T1071.003). C2 traffic is crafted to look like legitimate email services. This can mean beaconing over TCP 25, 465, or 587 with SMTP-like protocol headers, or tunneling payloads inside syntactically plausible SMTP sessions. On a perimeter appliance or a host that legitimately handles mail, this traffic blends into the noise floor. On a host that has no business sending mail — an application server, a network appliance, a database node — outbound SMTP is an immediate anomaly.

3. Persistence. Linux implants of this class commonly persist via systemd service units with legitimate-sounding names (e.g., postfix-agent.service), cron entries, rc.local, or modified init scripts. Anything disguised as a mail subsystem restart is likely to survive casual review of systemctl list-units.

Exploitation Status

The activity is confirmed in the wild against telecom and network appliance targets in South Korea and Taiwan. There is no public CVE or CISA KEV entry tied to this campaign; it should be treated as an active intrusion set using post-compromise implants rather than a single exploitable vulnerability. The correct defensive posture is behavioral detection and compromise assessment, not patch-and-forget.

Detection & Response

The detections below are built around the two observable behaviors at the core of this campaign: mail-daemon process names executing from illegitimate locations, and SMTP-protocol traffic originating from hosts or processes that have no legitimate mail role. These are high-signal, low-noise hunts in most environments.

Sigma Rules

The first rule fires on processes using mail daemon names from non-standard filesystem locations — the heart of the masquerading behavior. The second catches outbound SMTP connections from processes that are not legitimate mail transfer agents. The third covers systemd-based persistence masquerading as mail services.

---
title: Linux Mail Daemon Masquerading From Non-Standard Path
id: 4f2b8c91-7d3a-4e5b-9c6d-1a2b3c4d5e6f
status: experimental
description: Detects processes named after legitimate mail daemons (postfix, sendmail, exim, dovecot, smtpd, master) executing from non-standard filesystem locations such as /tmp, /var/tmp, /dev/shm, or user directories. Observed in Linux backdoor campaigns targeting telecom infrastructure in South Korea and Taiwan.
references:
  - https://thehackernews.com/2026/10/linux-backdoors-impersonate-email.html
  - https://attack.mitre.org/techniques/T1036/005/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.defense_evasion
  - attack.t1036.005
logsource:
  category: process_creation
  product: linux
detection:
  selection_names:
    Image|endswith:
      - '/postfix'
      - '/sendmail'
      - '/smtpd'
      - '/exim'
      - '/exim4'
      - '/dovecot'
      - '/imapd'
      - '/master'
  selection_suspicious_paths:
    Image|contains:
      - '/tmp/'
      - '/var/tmp/'
      - '/dev/shm/'
      - '/home/'
      - '/var/lib/.'
      - '/run/user/'
  condition: all of selection_*
falsepositives:
  - Custom mail relay builds installed under non-standard prefixes (verify against package manager records)
level: high
---
title: Outbound SMTP Connection From Non-Mail Process
id: 8c1d5e72-3a9f-4b6c-8d2e-5f6a7b8c9d0e
status: experimental
description: Detects outbound connections to SMTP ports (25, 465, 587) initiated by processes that are not recognized mail transfer agents. Backdoors impersonating email services use these ports to blend C2 traffic into legitimate mail flows.
references:
  - https://thehackernews.com/2026/10/linux-backdoors-impersonate-email.html
  - https://attack.mitre.org/techniques/T1071/003/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.command_and_control
  - attack.t1071.003
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort:
      - 25
      - 465
      - 587
  filter_known_mta:
    Image|endswith:
      - '/postfix'
      - '/sendmail'
      - '/smtpd'
      - '/exim'
      - '/exim4'
      - '/master'
      - '/smtp'
      - '/proxymap'
      - '/cleanup'
  condition: selection and not filter_known_mta
falsepositives:
  - Monitoring or alerting scripts sending mail via SMTP
  - Application servers with legitimate mail-notification functions (allowlist by host role)
level: medium
---
title: Systemd Service Persistence Referencing Suspicious Path
id: 2e7a9d14-6b8c-4f1a-9e3b-7c8d9e0f1a2b
status: experimental
description: Detects systemd service enablement or daemon-reload activity where the service unit or executed binary references world-writable or user-writable paths, a common persistence mechanism for Linux implants disguising themselves as mail or system services.
references:
  - https://thehackernews.com/2026/10/linux-backdoors-impersonate-email.html
  - https://attack.mitre.org/techniques/T1543/002/
author: Security Arsenal
date: 2026/10/15
tags:
  - attack.persistence
  - attack.t1543.002
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith: '/systemctl'
    CommandLine|contains:
      - 'enable'
      - 'daemon-reload'
      - 'start'
  selection_suspicious:
    CommandLine|contains:
      - 'postfix'
      - 'sendmail'
      - 'smtp'
      - 'mail'
      - 'dovecot'
  condition: all of selection_*
falsepositives:
  - Legitimate mail server administration (tune with change-window context or host allowlists)
level: low

A note on the third rule: it is intentionally low-severity and best used as a correlation signal alongside the first two, not as a standalone alert.

KQL — Microsoft Sentinel / Defender

The following query hunts Linux Syslog and CEF-ingested telemetry in Sentinel for mail-daemon masquerading and anomalous SMTP egress. It assumes Linux process and network events are forwarded via the Syslog/CEF connector or AMA.

// Hunt 1: Mail daemon process names executing from suspicious paths
Syslog
| where TimeGenerated > ago(7d)
| where Facility =~ "authpriv" or SyslogMessage has_any ("postfix", "sendmail", "smtpd", "exim", "dovecot", "/master")
| extend SuspiciousPath = SyslogMessage has_any ("/tmp/", "/var/tmp/", "/dev/shm/", "/home/", "/run/user/")
| where SuspiciousPath == true
| project TimeGenerated, Computer, ProcessName, ProcessID, SyslogMessage
| order by TimeGenerated desc;

// Hunt 2: Outbound SMTP (25/465/587) from hosts not designated as mail gateways
// Replace the dynamic list with your actual mail gateway hostnames
let MailGateways = dynamic(["mailgw01", "mailgw02", "smtp-relay01"]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort in (25, 465, 587)
| where DeviceAction !~ "deny"
| where SourceHostName !in~ (MailGateways)
| summarize ConnectionCount = count(), DistinctDestinations = dcount(DestinationIP), Destinations = make_set(DestinationIP, 20) by SourceHostName, SourceIP, DestinationPort
| order by ConnectionCount desc;

If you have Defender for Endpoint on Linux servers, use DeviceNetworkEvents and DeviceProcessEvents with the same logic — join process names against egress ports 25/465/587 and exclude your known MTAs. The key analytic is the host role: SMTP egress from a non-mail host is the anomaly, regardless of what the process calls itself.

Velociraptor VQL

For DFIR teams doing fleet-wide triage, this artifact correlates mail-daemon process names against their on-disk paths and active network connections:

-- Hunt for mail-daemon masquerading: legitimate names, illegitimate paths, SMTP connections
LET mail_names = '(?i)(postfix|sendmail|smtpd|exim4?|dovecot|imapd|/master)$'
LET legit_paths = '(?i)^/usr/(s?bin|libexec|lib)/'
LET procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       netstat() AS Connections
FROM pslist()
WHERE Name =~ mail_names AND NOT Exe =~ legit_paths

SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       Connections.Family AS ConnFamily,
       Connections.Status AS ConnStatus,
       Connections.Raddr.IP AS RemoteIP,
       Connections.Raddr.Port AS RemotePort
FROM procs

Complement this with a glob hunt for recently created service units referencing mail-sounding names:

-- Enumerate systemd units referencing mail services created/modified recently
SELECT FullPath, Mtime, Size,
       read_file(filename=FullPath, length=4096) AS UnitContent
FROM glob(globs=['/etc/systemd/system/*.service', '/usr/lib/systemd/system/*.service',
                 '/etc/cron.d/*', '/var/spool/cron/*'])
WHERE Mtime > now() - 60*60*24*30
  AND (FullPath =~ '(?i)(postfix|sendmail|smtp|mail|dovecot)'
       OR read_file(filename=FullPath, length=4096) =~ '(?i)(/tmp/|/var/tmp/|/dev/shm/)')

Triage and Hardening Script

Run the following Bash script via your configuration management or EDR remote shell to sweep Linux hosts for the indicators above. It performs read-only checks — it does not remediate automatically, because killing a masquerading process before forensic capture can destroy volatile evidence.

#!/bin/bash
# Security Arsenal - Linux mail-daemon masquerading triage sweep
# Read-only. Collect findings, capture volatile data, escalate to IR before containment.

REPORT="/root/masq_triage_$(hostname)_$(date +%Y%m%d_%H%M%S).txt"
{
echo "=== [1] Mail-daemon processes running from non-standard paths ==="
ps -eo pid,ppid,user,comm,args --no-headers | grep -Ei '(postfix|sendmail|smtpd|exim|dovecot|imapd| master)' \
  | grep -Ev '/usr/(sbin|libexec|lib)/' || echo "None found"

echo ""
echo "=== [2] Executables in world-writable/temp dirs (common implant staging) ==="
find /tmp /var/tmp /dev/shm /run/user -type f -executable 2>/dev/null || echo "None found"

echo ""
echo "=== [3] Outbound connections to SMTP ports (25/465/587) ==="
ss -tnp 2>/dev/null | grep -E ':(25|465|587)\b' || echo "None found"

echo ""
echo "=== [4] Systemd units referencing mail services (check ExecStart paths) ==="
grep -rslEi 'postfix|sendmail|smtp|dovecot' /etc/systemd/system/ /usr/lib/systemd/system/ 2>/dev/null \
  | while read -r f; do echo "--- $f"; grep -E 'ExecStart|WorkingDirectory' "$f"; done

echo ""
echo "=== [5] Cron persistence referencing temp paths or mail names ==="
grep -rEn '/tmp/|/var/tmp/|/dev/shm/|postfix|sendmail' /etc/cron* /var/spool/cron/ 2>/dev/null || echo "None found"

echo ""
echo "=== [6] Recently modified binaries matching mail daemon names ==="
find / -xdev -type f \( -name 'postfix' -o -name 'sendmail' -o -name 'smtpd' -o -name 'exim*' -o -name 'dovecot' \) \
  -mtime -60 2>/dev/null | while read -r b; do echo "$b  $(sha256sum "$b" 2>/dev/null | cut -d' ' -f1)"; done
} | tee "$REPORT"
echo "Report written to $REPORT — preserve memory and disk images before any containment action."

Remediation and Hardening

Because this campaign is implant-driven rather than CVE-driven, remediation centers on compromise assessment, eviction, and closing the access paths that made the foothold possible:

1. Hunt before you contain. Run the detections above across all Linux servers, mail gateways, and network appliances — especially any host with telecom or carrier-network roles. If a masquerading process is found, capture memory and a disk image before killing anything. Implants in this class frequently include watchdog and re-infection logic.

2. Enforce egress filtering on SMTP. No host should initiate outbound TCP 25/465/587 except designated mail gateways. This single control converts an invisible C2 channel into an immediate, high-fidelity alert. Audit your firewall and security group rules today — this is the highest-leverage fix for this specific threat.

3. Baseline your mail daemons. Inventory legitimate mail binaries via your package manager (rpm -qf / dpkg -S) and record their expected paths and hashes. Any postfix/sendmail/dovecot binary not owned by a package is anomalous by definition.

4. Deploy telemetry to Linux and network appliances. These implants thrive where there is no process logging. Deploy auditd or eBPF-based process telemetry, forward Syslog/auth logs to your SIEM, and ensure network appliances send NetFlow and connection logs. A backdoor impersonating a mail daemon is only invisible if nobody is watching process lineage.

5. Restrict execution from temp paths. Mount /tmp, /var/tmp, and /dev/shm with noexec,nosuid,nodev where operationally feasible, and alert on any execution from these locations. This directly breaks the staging pattern described above.

6. Review persistence surfaces. Audit systemd units, cron, rc.local, and init scripts across the fleet. Validate that mail-related service units point to package-owned binaries. Rotate credentials on any host where suspicious activity is confirmed — implants of this class are commonly paired with credential theft for lateral movement.

7. Verify initial access vectors. Since no CVE is associated, assume the implant arrived via compromised credentials, an exposed management interface, or a vulnerable edge appliance. Review VPN, SSH, and management-plane authentication logs for the 90 days preceding any confirmed implant activity, and enforce MFA and key-only SSH on all internet-facing Linux infrastructure.

Telecom and network infrastructure is being actively targeted, and the operators behind this campaign are betting that your Linux fleet is quieter and less instrumented than your Windows estate. In most environments, they are right. Close that gap.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub