HoneyMex Lab Logo
HoneyMex Lab

AryStinger — The Botnet Turning Decade-Old Routers Into Covert Reconnaissance Infrastructure for Attackers

AryStinger — The Botnet Turning Decade-Old Routers Into Covert Reconnaissance Infrastructure for Attackers

Publication date: June 25, 2026 Category: Information Security · IoT Security · Threat Intelligence

XLab’s Findings: A Botnet That Neither Encrypts nor Mines

On June 17, 2026, QiAnXin’s XLab team published its analysis of AryStinger, a malware family that has compromised at least 4,300 routers globally — a count the researchers warn is still rising. The stated motivation for the report was a May 20, 2026 publication by China’s Ministry of State Security about outdated routers as an entry point for espionage; XLab explicitly clarifies that the AryStinger campaign has no direct relationship to what that agency described.

What sets AryStinger apart is not what it does but what it deliberately does not do: it does not encrypt files, it does not mine cryptocurrency, and it does not build a conventional DDoS botnet. Its purpose is to operate in the stage that precedes the break-in. Infected devices scan the internet, fingerprint exposed services, enumerate subdomains, tunnel traffic, and execute commands on demand, returning the results to the operator. Each compromised router simultaneously becomes a footprinting node and a relay that hides the attacker’s real location.

XLab named the family AryStinger based on a hint in the source code path indicating the internal project name is Ary-Attack. The 4,300 count covers only RTL819X devices; the scale of NAS infections is not yet measurable.

Old Hardware, Older Bugs

The campaign targets routers built on Realtek RTL819X chips, hardware whose peak deployment ran from 2012 to 2015. XLab first detected the activity on March 12, 2026, spreading from a single IP address, 107.150.106.14, which distributed a C-written Linux ELF with zero detections on VirusTotal.

The initial access vector is two vulnerabilities from another era:

The infection pool is dominated by D-Link hardware, with the DIR-850L accounting for roughly 75% and the DIR-818LW a further 13%. Both devices have been in end-of-life (EOL) status for years: the manufacturer permanently ceased firmware development, so the vulnerabilities AryStinger exploits will never receive a fix. By geography, the distribution concentrates in South Korea (48.45%) and China (31.82%), followed by Sweden (6.40%), Malaysia (3.50%), and Singapore (2.50%).

A second strain appeared on April 26, 2026, aimed at QNAP NAS devices through CVE-2025-11837, a code injection flaw in QNAP’s Malware Remover component. The detail relevant to the timeline: that vulnerability was demonstrated at Pwn2Own Ireland 2025 and patched in November 2025 — months before this strain began exploiting it. The way in is, ironically, the appliance’s own malware-removal tool.

Distributed Architecture: The Executor/C2 Model

AryStinger is a bot that communicates with its C2 server over HTTP/HTTPS. Network traffic is encoded with Protobuf and obfuscated with a simple XOR using the hardcoded key sh_#@!_2024_secret (the Go-based Standard strain adds Gzip compression). The “2024” component of the key may indicate the operation began before the March 2026 detection, though XLab cannot confirm it. If so, the reconnaissance data already collected would be substantial.

Each node running AryStinger is called an Executor. The centerpiece of the operational design is task sharding: the attacker splits a massive scan into multiple subtasks and distributes them across different Executors for parallel execution. This distributed-style scheme efficiently completes the early footprinting stage, providing coverage assurance for subsequent intrusion operations.

The bot’s workflow is structured around a set of services:

  1. AUTH (authentication): sends the device fingerprint — MAC address, name, public and internal addresses, OS version, CPU architecture, and timestamp — to the C2’s /auth endpoint. After validating that the request comes from a real device, the C2 assigns a unique Executor ID that serves as the credential for subsequent task dispatch.
  2. HB (heartbeat and configuration): reports heartbeat and receives configuration updates via /heartbeat and /config.
  3. Watchdog (deployment): downloads dropbear from the distribution server and deploys it on port 2332.
  4. Upgrade (self-update): maintains the implant’s update capability. Since March 12, XLab has captured 32 distinct version samples of the RTL819X variant — a numbering that evidences active development.
  5. TASK / WORKER (pulling and execution): obtains probing tasks from the /cmd endpoint, identifying itself via the X-Executor-ID HTTP header.
  6. TUNNEL (tunneling): traffic proxy or forwarding function, added after V2.0.27 and supported by two additional C2s (sdkv1.dataexplore.cc and sdkv1.dataexplore.co).

Two Builds for One Job

XLab identified two functionally equivalent variants tailored to different environments.

The RTL819X variant is written in C and deliberately stripped down, because the old hardware cannot run more. The analyzed sample (V2.0.27) is a 32-bit MIPS ELF, statically linked and stripped. It is limited to mass DNS scanning (massdns-style) and traffic tunneling, and establishes persistence by downloading the lightweight SSH server Dropbear on port 2332, configuring iptables to allow the traffic — thereby establishing a persistent login backdoor that survives reboots.

The Standard variant is written in Go, packed with UPX, and targets the more capable NAS devices. It is significantly fuller: in addition to IP, DNS, and HTTP Alive scanning, it integrates open-source pentesting tools such as fscan, ksubdomain, httpx, and Tlsx for intranet reconnaissance. It builds its persistent control channel by deploying gs-netcat rather than Dropbear. Its functional correspondence to the RTL819X variant is direct: each Loop in the Go version (authLoop, cmdLoop, heartLoop, etc.) maps to a service in the C version, with the addition of an exclusive intranetScanLoop.

The Standard variant’s most notable capability is the ScriptWork task, which executes shell commands and source-level payloads in three languages: Go, Java, and Python. This removes the need to compile per-platform binaries: the operator ships source code that is executed dynamically regardless of the target’s architecture, reducing both the cost and the time window of the attack.

XLab notes, however, that this design carries a defensively relevant cost: execution depends on interpreters present on the host (Python, Java, Go), the source code must be written to disk in plaintext, and the interpreter process’s command line is recorded in the system’s audit logs. Compared with fileless, in-memory binary payloads, ScriptWork’s exposure surface is greater — making it more capturable by EDR and HIDS. It is a deliberate trade of stealth for flexibility.

One additional detail: the nat_tunnel-linux-x86_64 binary, used by the Standard strain for traffic forwarding, is suspected to be AI-assisted in its generation, per XLab’s assessment.

Where AryStinger Fits: ORB Networks and the End-of-Life Pattern

AryStinger’s shape is recognizable. In May 2025, the FBI and the U.S. Department of Justice dismantled the 5socks and Anyproxy services, which had turned old Linksys and Cisco routers infected with TheMoon malware into residential proxies sold by monthly subscription. AryStinger replicates the model, but oriented toward espionage and reconnaissance rather than proxy resale.

The most direct parallel is the ORB (Operational Relay Box) networks Mandiant has tracked: meshes of compromised end-of-life routers and IoT that state actors use to scan and relay while remaining hard to attribute. Recent SOHO router botnets like LapDogs farm devices through n-days exactly as AryStinger does. The same affected D-Link models were flagged in a March 2026 FBI FLASH notice about AVrecon, another botnet that hijacked the same hardware.

XLab has not attributed AryStinger to any known actor and states that the investigation is ongoing. What is clear is the structural pattern: forgotten hardware, ancient CVEs, turned into quiet infrastructure for the opening moves of an intrusion. A box that stopped getting patches in 2016 is not going to start now.

The Underlying Problem: The Edge Device as Unmanaged Risk

AryStinger’s danger does not lie in a novel technical capability but in the economics of the target. Compromised routers and NAS continue to operate normally: the router keeps routing, the NAS keeps serving files. There is no obvious performance degradation, no alert, no popup. Because both the sample and its C2s have a near-zero detection rate in mainstream engines, no signal prompts the user to investigate.

For an organization, this means a forgotten edge device can become an unmanaged security risk sitting inside the network perimeter. The three damage vectors XLab enumerates are: silent traffic theft (credentials, session tokens, financial information), DNS hijacking to redirect to phishing or malware sites, and use of the device as a springboard for scanning, penetration, DDoS, or malware propagation against third parties — with the true origin hard to trace.

The scale factor compounds the problem. These devices are typically always on, frequently exposed directly to the internet, and many are EOL. When a large volume of obsolete hardware is aggregated into a covert botnet, the result is a persistent, hard-to-trace threat to personal privacy, corporate security, and critical network infrastructure.

Blue Team Perspective: Detection and Remediation

AryStinger poses a classic edge-device detection challenge: these devices lack native EDR support and their telemetry is limited. Defense must rely on network monitoring, device filesystem inspection, and attack surface reduction through EOL hardware retirement.

Immediate self-check (per XLab)

  1. Network: verify outbound communications to AryStinger’s C2 and download domains — including opi7.com, the hosts under ajb8.com (eixfi, dybic, xook), dataexplore.cc/.co, and the downloaders hgodpcx.ajb8.com / hgodpcx.auq8.com.
  2. Files: log in to the device and inspect the /tmp/bin directory for binaries not installed by the administrator — it is the implant’s working directory and where the Standard variant stores its toolset and scan results.
  3. Processes: look for processes named syswapd0h or syswapd0w.

Network controls

Structural remediation

The underlying recommendation is the one the industry repeats endlessly: retire or isolate end-of-life routers and NAS that no longer receive firmware, and disable remote administration on any exposed device. Where vendor patches exist — as in QNAP’s case for CVE-2025-11837 — apply them without delay. For the affected RTL819X hardware, no patch is possible: the fix is device replacement. EOL devices must be treated as known-risk assets, not as trusted infrastructure by inertia.

Incident Timeline

Date Event
2012–2015 Peak deployment period of Realtek RTL819X chips
2013 / 2016 Disclosure of CVE-2013-3307 (Linksys) and CVE-2016-5681 (D-Link)
2024? Possible start of operations (inferred from the sh_#@!_2024_secret key; unconfirmed)
November 2025 QNAP patches CVE-2025-11837 (demonstrated at Pwn2Own Ireland 2025)
March 12, 2026 XLab detects RTL819X variant propagation from IP 107.150.106.14
March 2026 FBI FLASH warns about AVrecon on the same D-Link models
April 26, 2026 Standard (Go) variant appears against QNAP NAS via CVE-2025-11837
May 20, 2026 China’s Ministry of State Security publishes on outdated routers and espionage
June 17, 2026 XLab publishes the full technical analysis of AryStinger; 4,300+ infections confirmed

Wrapping Up…

AryStinger introduces no novel exploitation technique; it introduces an uncomfortable reminder about the security debt accumulated at the network edge. The combination of vendor-abandoned hardware, vulnerabilities public for over a decade, and a distributed architecture designed for silent footprinting produces exactly the kind of infrastructure advanced actors need for the early phases of an intrusion: reconnaissance capability at scale and a relay layer that dissolves attribution.

Three structural conclusions emerge. First: the value of these devices to the attacker lies not in what they contain but in their position — always on, exposed, EDR-free, and unpatched — as disposable compute and masking nodes. Second: the sharded task model and the multilingual ScriptWork task demonstrate an operational maturity oriented toward minimizing cost and friction, with a conscious trade of stealth for flexibility. Third: the pattern is continuous with prior campaigns — TheMoon, AVrecon, LapDogs, Mandiant’s ORB networks — and confirms that an edge device’s security lifecycle does not end when the vendor stops supporting it, but when it stops being connected.

For security teams, the operational question is not only whether there is an implant on a specific router, but how many EOL devices remain connected at the perimeter, operating as trusted assets when they are in fact unmanaged risk. XLab’s report provides the IOCs and the self-check methodology to begin answering it.

Sources consulted: