China-linked hackers target Southeast Asian edge routers with custom Linux implant

A China-linked threat cluster is targeting edge routers in Southeast Asia with a custom Linux implant that can monitor, redirect, and manipulate traffic moving through compromised networks. The campaign is dangerous because attackers are going after routers at the network perimeter, not just individual endpoints.

A technical analysis published on Qiita describes the primary router payload as router.elf, a custom Linux x86-64 implant that communicates with attacker infrastructure over HTTPS. The same operation also uses a secondary router backdoor and a Windows Cobalt Strike Beacon inside affected environments.

By compromising the router, the attackers gain a powerful position. They can observe traffic from many downstream devices, redirect DNS requests, interfere with software update flows, and support deeper access into Windows systems on the same network.

Why targeting edge routers matters

Edge routers sit between internal networks and the internet. When attackers control them, they can affect traffic from many users and devices at once. That makes a router compromise more damaging than a single infected workstation in many cases.

The campaign uses router.elf as the main Linux implant and client_rc_start as a backup backdoor. This gives the attackers a way to maintain access even if defenders remove the first payload.

The router implant also creates malicious iptables rules and uses an ipset list called evil_fix. These rules can redirect DNS traffic from devices behind the router to attacker-controlled resolvers, giving the threat actor a way to manipulate where users are sent online.

Component	Role in the campaign
router.elf	Main Linux implant deployed on compromised edge routers
client_rc_start	Secondary router backdoor used for persistence
evil_fix	Malicious ipset list used for targeted traffic redirection
version.dll	Windows DLL sideloading payload linked to Cobalt Strike Beacon
/api/v1/get and /api/v1/post	Command-and-control URI patterns used by the operation

The implant hides DNS lookups inside HTTPS traffic

The router implant communicates with command servers over port 443, which helps the traffic blend in with normal encrypted web activity. It also uses DNS over HTTPS for domain lookups, making the activity harder to catch with older DNS monitoring setups.

Cloudflare’s DNS over HTTPS documentation explains that DoH wraps DNS queries inside regular HTTPS requests and uses port 443. That privacy feature can help legitimate users, but attackers can also abuse it to reduce visibility for defenders.

In this campaign, the implant reportedly routes DNS lookups through Cloudflare’s DoH service while maintaining its own command-and-control channel. This means defenders need to inspect router behavior, firewall rules, and unusual HTTPS destinations, not only plain DNS logs.

DNS redirection creates downstream risk

The most concerning router-level behavior is DNS manipulation. By altering iptables rules, the implant can redirect DNS queries from internal devices to attacker-controlled servers.

That gives attackers several options. They can send users to phishing pages, interfere with update requests, or selectively target certain destinations while leaving other traffic untouched. This selective behavior can help the campaign remain quiet for longer.

The technique also weakens endpoint-only detection. A user’s laptop may look clean while the router silently changes how that system resolves domains.

• Audit iptables NAT rules on edge routers and gateways.
• Check for unauthorized DNS redirection to unfamiliar IP addresses.
• Search for ipset entries named evil_fix or similar suspicious lists.
• Review outbound HTTPS traffic from routers to unknown domains.
• Inspect router file systems for router.elf and client_rc_start.

Windows systems were also targeted

The campaign did not stop at the router layer. The same reporting links the router compromise to Cobalt Strike Beacon activity on Windows systems inside the same networks.

The Windows activity uses DLL sideloading, a known technique in which a legitimate executable loads a malicious DLL from a location controlled by the attacker. MITRE ATT&CK describes this class of execution hijacking as a way for adversaries to run their own payloads through trusted programs.

In this case, the malicious DLL is named version.dll and is placed near CrashReport.exe. When the legitimate process runs, it loads the attacker’s DLL and starts the Beacon payload.

Windows indicator	What defenders should check
version.dll	Unexpected DLL near CrashReport.exe
CrashReport.exe	Processes running from unusual AllUsers profile paths
specialclouds.com	Potential Cobalt Strike command-and-control domain
/api/v1/get	Polling path shared across campaign infrastructure
/api/v1/post	Upload or exfiltration path used in the C2 profile

Shared infrastructure links the router and Windows activity

The router implant and the Windows Beacon share several infrastructure patterns. These include the same URI paths, similar cookie markers, HTTPS command traffic, and a roughly 50-second check-in interval.

The technical analysis on Qiita also points to Mandarin strings, a zh-CN language setting, and a cracked Cobalt Strike profile as reasons for the China-nexus assessment. Those clues support attribution, but they do not publicly identify a named threat group.

This combined Linux and Windows activity suggests a coordinated espionage campaign. The router gives the attacker visibility and traffic control, while the Windows Beacon gives hands-on access to endpoints behind the perimeter.

Why normal endpoint defenses may miss the campaign

Many security tools focus on laptops, servers, and cloud workloads. Routers, firewalls, and gateways often receive less monitoring, fewer forensic logs, and slower patch cycles.

That gap benefits attackers. If a router compromise redirects DNS traffic or proxies command activity, endpoint tools may not see the original cause. They may only see the downstream effects.

Cloudflare’s DNS over HTTPS documentation also highlights why encrypted DNS traffic can look similar to normal HTTPS. Defenders need DNS visibility policies that account for DoH and router-originated encrypted traffic.

• Monitor DNS behavior from routers, not only endpoints.
• Alert on router-originated HTTPS traffic to newly seen domains.
• Keep router configuration backups for comparison.
• Review firewall and NAT changes outside approved maintenance windows.
• Collect router logs centrally before attackers can erase local evidence.

How defenders should respond

Organizations with exposed edge routers in Southeast Asia should check for the listed files, hashes, domains, IP addresses, and iptables changes. Routers should not contain unknown ELF files, unexplained persistence scripts, or DNS redirection rules that point to unfamiliar infrastructure.

CISA’s guidance for network edge devices urges organizations to protect routers, firewalls, VPN gateways, and other perimeter appliances because they are frequent targets for advanced attackers.

Security teams should also inspect Windows endpoints for DLL sideloading patterns. MITRE ATT&CK notes that attackers can place a malicious DLL where a legitimate program will load it, which matches the reported version.dll and CrashReport.exe pattern.

Priority	Action
1	Audit edge routers for router.elf, client_rc_start, evil_fix, and unauthorized iptables rules
2	Block known C2 domains and IP addresses at the perimeter where possible
3	Check Windows hosts for version.dll near CrashReport.exe
4	Review DNS traffic and detect unexpected DoH use from network devices
5	Rotate credentials used through compromised network segments

Indicators of compromise

The reported indicators include router payloads, Windows payloads, command-and-control domains, rogue DNS resolvers, and URI patterns. Defenders should validate these indicators against internal logs and avoid relying on a single signal.

Type	Indicator	Description
File	router.elf	Main Linux router implant
SHA-256	6a43de021fa79dc3eb5f6ed509b605ef617f56af7de8b136698e5dd86c7775ae	router.elf hash
File	client_rc_start	Secondary router backdoor
File	version.dll	Windows DLL sideloading payload
Domain	contextlayerrun.com	Router implant command-and-control domain
Domain	specialclouds.com	Reported Cobalt Strike Beacon domain
Domain	specialclouds.top	Reported Cobalt Strike Beacon domain
Domain	namefilecode.com	Reported command-and-control domain
IP address	8.211.130.16	Reported C2 server on port 443
IP address	8.213.217.130	Reported rogue DNS resolver on port 8090
IP address	47.81.37.109	Reported backup rogue DNS resolver on port 8090

Longer-term hardening steps

Organizations should manage routers and gateways as critical systems. That means strong access controls, configuration monitoring, firmware integrity checks, central logging, and change alerts for routing, firewall, DNS, and NAT settings.

Teams should also restrict management interfaces to trusted networks and require multi-factor authentication where supported. If a router cannot support modern logging, firmware integrity controls, or secure management, it may no longer be suitable for high-risk environments.

CISA’s guidance for network edge devices recommends stronger visibility and hardening for perimeter appliances. This campaign shows why that work matters, especially in regions and sectors likely to face espionage activity.

Bottom line

This campaign shows how edge routers can become high-value surveillance and control points. The attackers are not only trying to infect a machine. They are trying to control the network path used by many machines.

Defenders should respond by auditing router configurations, blocking known infrastructure, hunting for Windows DLL sideloading, and improving monitoring around DNS and encrypted traffic from network devices.

Any organization that finds router.elf, client_rc_start, evil_fix, suspicious iptables rules, or the linked Windows payload should treat the finding as a serious network intrusion and begin incident response immediately.

FAQ