From N-Days to Multiple Arch: Inside RondoDox’s Delivery Pipeline

RondoDox doesn’t “pick a CVE.” It sprays the internet with exploit attempts, cycling through dozens of known vulnerabilities until something sticks. It then pivots quickly when new high-impact bugs emerge. By late 2025, this meant incorporating enterprise-facing targets, such as the XWiki RCE and the React2Shell flaw, while continuing to run large-scale IoT enrollment waves in parallel.

Anish Bogati

Security Researcher

Jane

Security Researcher

The RondoDox Shift

RondoDox is a Linux botnet family first identified by FortiGuard Labs in September 2024 and documented more broadly through 2025. Early activity focused on exploiting internet-exposed DVRs and routers to recruit devices into a DDoS-capable botnet.

What’s changed is that the campaign increasingly behaves like an exploitation and delivery pipeline: compromise widely, fingerprint hosts quickly, then deploy whatever payload best matches the operator’s goals.

What makes it stand out is scale and adaptability:

• Operational phasing: CloudSEK describes a progression from reconnaissance/testing → automated exploitation → broad IoT botnet deployment across 2025.
• Exploit “shotgun” model: Trend Micro/ZDI observed RondoDox exploiting 50+ vulnerabilities across 30+ vendors, reflecting a volume-first strategy rather than a single vulnerability propagation chain.
• Scaled further in v2: Later reporting on RondoDox v2 describes 75+ distinct exploit payloads fired in rapid succession, showing that exploit coverage keeps expanding over time.
• Rapid adoption of new server-side CVEs: reporting links activity to XWiki RCE (CVE-2025-24893) in November and React2Shell (CVE-2025-55182) exploitation against Next.js servers in December.

RondoDox is best understood as a scalable exploitation framework, not just “a botnet with a couple of bugs.” The advantage is operational: keep probing, keep enrolling, keep refreshing exploit coverage, then opportunistically jump to whichever enterprise CVE is drawing the most exploitation activity.

That kind of volume-first model only works if the backend can keep up. When you’re firing dozens of exploits across many targets, you need infrastructure that can scan at scale, host staging content, and rotate delivery endpoints quickly when they get burned.

The infrastructure layer that makes the "pipeline" durable

That pipeline depends on more than exploit coverage; it also depends on churn-friendly infrastructure. Mapping tied to the broader RondoDox delivery ecosystem suggests a constellation pattern: an enabling transit/backbone layer with multiple downstream abuse-tolerant hosting lanes used for scanning, staging, and distribution, plus parallel capacity that helps operations survive takedowns and blocklists.

The practical takeaway is simple: RondoDox can lose nodes and still keep operating, because staging and delivery endpoints are designed to rotate. That’s why IOC-only defense tends to decay quickly here; detection improves when you combine IOCs with behavioral signals (scanning bursts, repeated staging patterns, short-lived nodes) and contextual enrichment (infra clustering by ASN/provider patterns). Importantly, an ASN is not proof of “RondoDox infrastructure” on its own. These networks are better treated as reusable hosting lanes that operators can rent and repurpose to stand up, move, and rebuild staging and delivery endpoints quickly.

Representative infrastructure artifacts

• Transit/backbone overlap (enabler): AS401110 (Sovy Cloud Services)
• Core hosting cluster (recent activity): AS401120 (Cheapy-Host / cheapy.host)
  • Representative /24s: 196.251.70.0/24, 196.251.71.0/24, 196.251.72.0/24
• Additional lanes observed in the same constellation: AS401116 (Nybula), AS401115 (EKABI), AS401109 (Zhongguancun)
• Parallel spillover capacity (outside core): AS270824 (ENX, Brazil), AS208220 (Offerhost, Seychelles), AS210848 (Telkom Internet, Seychelles)

With infrastructure optimized for churn, the first stage must be equally disposable. That’s where RondoDox’s lightweight shell-based loader fits: it bridges initial access into a portable delivery step that can quickly fetch the “right” payload for the host’s CPU architecture.

• Parallel spillover capacity (outside core): AS270824 (ENX, Brazil), AS208220 (Offerhost, Seychelles), AS210848 (Telkom Internet, Seychelles)

With infrastructure built for churn, the next piece fits naturally: a lightweight first-stage that’s easy to redeploy and designed to bridge initial access into whatever payload is most profitable.

Infection chain

The “shell loader” is the workhorse

RondoDox typically relies on a lightweight shell-based loader as the main delivery mechanism. While infrastructure keeps the operation resilient, the shell loader makes the infection portable and scalable across Linux environments.

Key Behaviors Observed

• Environment preparation and CPU architecture detection
  Identifies the host architecture and retrieves the correct ELF payload variant.
• Competitive displacement
  Terminates and/or removes other malware or botnet processes to reduce contention.
• Persistence enforcement and host “hygiene”
  Uses aggressive process-killing and recurring checks in some chains to maintain control and stability.
• Multi-architecture payload staging and execution
  Stages the appropriate payload, executes it, and may perform cleanup to reduce artifacts.

The loader first approach is what enables scale: keep the initial intrusion disposable, then swap payloads based on what the operator wants to achieve on that host.

Main Payload — What the Bot Can Do

Static analysis indicates the RondoDox main payload is a Linux backdoor/bot agent designed for flexible capability delivery, C2-controlled operations, and long-term persistence.

Notable Capability Themes

1) Modular design

• Uses a plug-in style structure rather than a single linear program flow.
• Core functions are connected through function-pointer registries and dispatch tables, making analysis harder and allowing features to be swapped/extended.
• CloudSEK’s reporting around React2Shell also points to multi-stage components (loader/health-checker).

2) C2-driven tasking with extensible handlers

• Performs periodic C2 check-ins to receive instructions.
• Uses a task routing model:
  receive task → map to handler/capability → execute → return output
• Handler-based structure suggests the bot can support new command types with minimal changes.

3) Persistence and stealth primitives

• Built for durability and reduced visibility.
• Includes multiple persistence options and masquerading behaviors (e.g., deceptive process/service naming).
• Uses encoded/obfuscated strings to hinder static detection and reverse engineering.

The key risk isn’t a single vulnerability but patch lags combined with exposure. Threats like RondoDox treat new vulnerability disclosures as immediate fuel, and the loader-based delivery model means a compromise can be repurposed for different outcomes (botnet node, proxy, miner, or a staging point) depending on what’s most profitable.

Conclusion

RondoDox is less a single botnet and more an operational pipeline: high-volume exploitation up front, a flexible loader layer in the middle, and modular payloads that can shift from IoT enrollment to enterprise-facing intrusion as soon as new CVEs become viable. That combination with scale, speed, and payload flexibility is what makes it durable.

This blog only scratches the surface. The full report includes:

• In-Depth Background, Ecosystem, and Future Outlook for RondoDox
• Infrastructure breakdown
• Infection Chain
• Technical analysis
• Full IOC set
• Detection and Response guidance
• Mitigation and Best Practices