Podcast Summary: CyberWire Daily – "A Tale of Two Botnets [Research Saturday]"

Episode Information

• Title: A Tale of Two Botnets [Research Saturday]
• Host/Author: N2K Networks
• Release Date: June 28, 2025
• Description: This episode delves into the intricacies of two distinct botnets exploiting a specific cybersecurity vulnerability. Hosted by Dave Bittner, the discussion features insights from Sam, a security expert from Akamai, as they dissect recent research and its implications for the cybersecurity landscape.

Introduction to Research Saturday

[01:31] Dave Bittner:
“Hello everyone and welcome to the Cyberwires Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems, and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us.”

Dave Bittner sets the stage for the episode, introducing the focus on recent research surrounding botnets and vulnerabilities in cybersecurity infrastructure.

Overview of Akamai’s Honeypot Research

[01:55] Sam:
“If you followed Akamai Sports Service publications before, you might know that we run a global network of honeypots that collect on a lot of different vulnerabilities that different kind of botnets are targeting. These tend to be IoT devices, but if you've been following Mirai botnets or botnets in general for a while, you might know that sometimes they do target vulnerabilities or machines that are not IoT like in this case.”

Sam explains Akamai's utilization of a global honeypot network to monitor and identify vulnerabilities targeted by various botnets, highlighting that while IoT devices are common targets, there are instances where non-IoT machines are exploited.

Introduction to the Study: "Two Botnets, One Flaw"

[02:20] Dave Bittner:
“That's Kyle Lefton, security researcher at Akamai. The research we're discussing today is titled Two Botnets, One Flaw. Mirai Spreads through WAZA Vulnerability.”

Dave introduces the central research study focusing on how two botnets exploit the same vulnerability within the WAZA cybersecurity platform.

Delving into the WAZA Vulnerability

[03:46] Dave Bittner:
“Well, let's talk about Wazoo itself. What is it and how is it typically used in enterprise environments?”

[03:55] Sam:
“Yeah, so very different to what we would usually report on. Wazoo is a cybersecurity platform, open source, XDR and SIEM. So again, it's not unheard of for something separate like that to be exploited by Botnet, but it's certainly uncommon. A lot of different enterprises use it. I know that the company itself claims, I believe 30 million downloads a month is what they, I think publicly claim, used by a bunch of Fortune 500 companies. So it's pretty wide. I know we found through census scans, maybe about 5,000 publicly accessible servers. So it is fairly widely used.”

Sam provides an overview of Wazoo, an open-source Extended Detection and Response (XDR) and Security Information and Event Management (SIEM) platform widely adopted by enterprises, including Fortune 500 companies. Despite its security focus, Wazoo has been identified as a target for botnets, albeit rarely.

Understanding the Critical Vulnerability: CVE-20002524016

[04:40] Dave Bittner:
“I see a lot of this centers around a particular CVE. This is CVE-20002524016. Take us through what is particularly interesting about that vulnerability.”

[04:55] Sam:
“Yeah, so basically what this CVE is, it's a remote code execution vulnerability in WAZA servers affecting versions 4.4.0 through 4.9.0, with 4.9.1 being the patched version. So it stems from an unsafe deserialization in IT through certain parameters, which we explain in a bit more depth in the article. I won't necessarily get into that here. So this can be exploited by threat actors, not just for botnets. Somebody else could use that, let's say, to execute arbitrary code on your WAZA server, if it is affected by this, to maybe establish backdoors or to do other nefarious things. So it's rated pretty, pretty highly, 9.9 critical as far as a CVSS score. So it is pretty severe if you are affected by it.”

Sam details the vulnerability CVE-20002524016, a critical (CVSS score 9.9) remote code execution flaw in WAZA servers, affecting versions 4.4.0 to 4.9.0. The vulnerability arises from unsafe deserialization, allowing attackers to execute arbitrary code, potentially establishing backdoors or facilitating other malicious activities.

Mechanism of Exploitation

[05:50] Dave Bittner:
“Well, walk me through how the vulnerability works here. What's the mechanism that allows for remote code execution here?”

[05:59] Sam:
“Yeah, absolutely. So basically there's a proof of Concept actually that was written on it back in February. So you can inject an unsanitized dictionary into the DAPI requests, which then can lead to evaluation of the arbitrary Python code. So you could trigger the RC using the run as endpoint, which enables the attacker to control the off context argument. There's a whole Burp Suite. You could actually run this using a Burp Suite as an example that was used in the proof of concept that was initially drafted up. So that's something that we see sometimes as well, is that's why we mention this is sometimes a double-edged sword is that it's likely that some of these threat actors will observe those proof of concepts and then adopt those to their own active exploitations.”

Sam explains the exploitation mechanism, where attackers inject unsanitized dictionaries into DAPI requests, leading to the evaluation of arbitrary Python code. The vulnerability leverages the "run as" endpoint, allowing attackers to execute remote code. The existence of a proof of concept facilitates rapid adoption and weaponization by threat actors.

Rapid Exploitation Post-Vulnerability Disclosure

[06:57] Dave Bittner:
“Now you all spotted this exploitation back in March of this year and that was just a few weeks after the vulnerability was disclosed. Why do you suppose the response window is so short in this case?”

[07:10] Sam:
“So it could be a variety of reasons. Sometimes like in the case of some of the previous publications like we reported on, I believe it was either the Edimax one or it might have been the it's not digit. I think it might have been the Edimax one where we had one, where there was two CVEs exploited, one disclosed in June or July of 2024 and the next in November. But we didn't see any exploitation until April. So sometimes there is a longer window. I think it definitely speeds things up. Like in the case of this one where there was a proof of exploit or proof of concept exploit that was published back in February. So it makes it pretty trivial to do. And a lot of these threat actors, you know, we've seen through, you know, looking at their, their Telegram chat sometimes that they pay attention to these security articles, they pay attention to these CVEs that get published if it's relevant to what they're trying to do. And so that's part of why they quickly adopt a lot of this. And the quicker as a botnet, the quicker you adopt these into your arsenal, the more effective it'll be. Because organizations, especially large ones, can take a while to do patching.”

Sam discusses the swift exploitation following vulnerability disclosure, attributing it to the availability of a public proof of concept. Threat actors actively monitor security disclosures, enabling rapid integration of vulnerabilities into their toolkits, thereby reducing the window for organizations to patch and mitigate threats.

Weaponization of Proof of Concept Exploits

[08:21] Dave Bittner:
“Well, you talk about how the attackers weaponized this proof of concept. Were there changes that you all tracked that when they converted it to be a tool for malware delivery?”

[08:33] Sam:
“Yeah, I mean a lot of it aligns pretty similarly to what the proof of concept is. A lot of it is pretty typical to how they're, how they're normally exploit or send the exploit code. So usually a lot of the the chain of exploitation with a lot of the Mirai exploits that we see is to execute the arbitrary code to download and execute a shell script, which then in turn downloads the main Mirai malware payload to execute on the target machine. So a lot of it is just repurposing the initial proof of concept to account for that kind of exploitation.”

Sam elaborates on how attackers adapt proof of concept exploits for malware delivery. Specifically, the Mirai botnet variants leverage the vulnerability to execute arbitrary code that downloads and runs shell scripts, subsequently deploying the main Mirai malware payload onto compromised systems.

Exploring the Two Botnet Campaigns: Mirai and Resbot

[09:15] Dave Bittner:
“I see. Well, your research talks about two botnets. Can we talk about those two campaigns? You've got Mirai and then there's one that you all are calling. I believe it's Resbot.”

[09:27] Sam:
“Yeah, well, so Resbot is just what we're calling that specific Mirai variant. It's all actually a Mirai variant. So the first one uses a variety of different ones. So it uses the wizard variant, which has been around for years and years. I think the first mentions I was finding that of Uizard Online was maybe back in 2018. So that's a source code that's been around. Foen ran there for quite a while. But they were using a variety of other stuff, like they were using something called V3G4 or we like to dub it as Vega. And then they had a, what might be a modified variant of Vega, a newer version Vega, something that we have seen before, and I believe we've reported on that before as well. As far as the malware itself, a lot of this is reused source code. A lot of these don't really change super significantly between each other, at least for the ones that we saw. So a lot of it is kind of just the distinction of it's different people operating some of these botnets because a lot of it is just reused code from people. So with Resbot they weren't using as many different variants. We just saw the one variant that we just dubbed as Resbot based on the strings and based on the C2 domains that they were using, that one was a little bit interesting in the sense that they had a bunch of C2 domains that were appearing to potentially target Italian speaking users, which is something that we haven't really seen much before. So we don't really know the exact motive behind that. We can maybe speculate on some of the reasons. One of my theories perhaps is that if they're targeting Italian speaking users, that the domains are perhaps made to look like some kind of legitimate Italian domain. So then if network defenders for machines that they're targeting go through to look at their network logs and they see this, maybe their alarm bells don't go off because they, they Might see that as as more legitimate perhaps is one of my theories, but it is unusual activity.”

Sam introduces the two botnets discussed in the research: Mirai and Resbot. Resbot is identified as a specific variant of the Mirai botnet, differentiated by unique command and control (C2) domains targeting Italian-speaking users. This targeting strategy is unusual and may be an attempt to blend malicious activities with legitimate-looking Italian domains to evade detection by network defenders.

Malicious Infrastructure and Indicators of Compromise (IOCs)

[13:48] Dave Bittner:
“The research talks about some of the key indicators of compromise that you all were tracking here. Can you take us through that?”

[13:53] Sam:
“Yeah, absolutely. So a lot of the stuff we focus on as far as indicators of compromise, of course you have your IPs, your domains, your hashes. I like to do a lot of pivots off of IOCs. So I mentioned that with in Resbot, for example, you take one domain or you take another IP, that's whether it's a C2 or not. You could use various tools, some proprietary, some more open source like VirusTotal. Pivot off of those and see what overlaps as far as connections to that. So for example, with domain names, if you have the log data for it of, hey, you have these IP addresses that match two different domain names and these IP addresses are not, you know, like Cloudflare or something or some big hosting provider that hosts thousands of others, other websites on that same ip and they're all shifting to different domains that look suspicious all at the same time and the same dates. And then all of those domains are in turn popping up positive for, you know, the same Mirai malware basically, then that builds up a stronger case that these are all connected. So I like going through and building out the broader infrastructure through pivoting through a lot of those, the network based indicators there. And so that's a lot of how we got through to map out some of this infrastructure as well as then, of course, verifying through the malware itself and then through our own honey pots as well.”

Sam outlines the methodology for identifying Indicators of Compromise (IOCs), emphasizing the importance of IPs, domains, and hashes. By pivoting off these IOCs using tools like VirusTotal, researchers can uncover connections between seemingly disparate domains and IP addresses. This approach helps in mapping out the broader malicious infrastructure and verifying associations through malware analysis and honeypot data.

The Role of Experience in Threat Analysis

[15:25] Dave Bittner:
“I see. Can you tell us a little bit more about your own efforts there? I mean, is it the kind of thing where after a while you kind of have your own sense about it, you can kind of figure if you're on the right path and not going down a blind alley?”

[15:43] Sam:
“Yeah, sure. I mean, I've had plenty of times where I've gone down the wrong alley with something. So I think with going through this stuff, you start to pick up, you know, the more you do it, you start to learn what you would determine as, hey, high confidence as far as linking something if you're pivoting through something or if you're looking through, I don't know, honeypots. Like I've, I've gotten to recognize different kinds of strings or different kinds of, like URIs coming through as far as web requests as what we've seen or not seen. So I could look at something, I might not be able to remember off the top of my head, this specific CVE number for something, but I could say, hey, maybe this is a Huawei router exploit. Or at the very least say, hey, this is something that we've seen before and I can just filter that out to not get that kind of junk in there. Or maybe you're going through and analyzing a Mirai malware sample and you can determine, hey, well this a lot of the code in here, a lot of the ATT&CK commands are something that we've seen before, and it's not anything that particularly sticks out. And so once you get to that point, it definitely helps with investigations because it helps save a lot of time that could otherwise be spent going down this big rabbit hole and not yield much useful information.”

Sam emphasizes the importance of experience in threat analysis. Over time, analysts develop an intuitive understanding of patterns and indicators, allowing them to efficiently identify relevant threats and avoid unproductive investigative paths. This experiential knowledge enhances the accuracy and speed of threat detection and mitigation efforts.

The Limitations of AI in Security Analysis

[17:11] Dave Bittner:
“Yeah, I mean, it's, it's a really interesting insight and I guess it, you know, speaks to that notion that there's, there's no substitute for experience, right?”

[17:21] Sam:
“Yeah, absolutely. I know a lot of people, you know, a bit, a little bit of a separate topic, I suppose, but a lot of people have talked about AI and the advancement of that and how that would affect even, you know, in the security industry as far as replacing a lot of these tasks. And I think AI can be used a lot to assist in these places, but at the moment it doesn't usually have the kind of knowledge or context to go through and recognize and parse through all this stuff like an analyst would at this point.”

Sam discusses the current limitations of Artificial Intelligence in the realm of security analysis. While AI can assist in handling large volumes of data and automating certain tasks, it lacks the nuanced understanding and contextual awareness that experienced human analysts bring to threat detection and mitigation.

Defense and Mitigation Strategies

[18:05] Dave Bittner:
“Well, let's talk about defense and mitigation here. I mean, what are your recommendations for defenders out there if they think this is something that they should have their eye on?”

[18:05] Sam:
“Yeah, so I mean aside from the obvious, which is patch your systems, I think that's the most important. Always will stress that I would say with this too is make sure, you know, if your systems, if you're running WAZA or Wazoo, don't have your servers publicly accessible on the Internet unless there's some other kind of filters to it or good reason, a lot of this will affect the API. So make sure API is locked down. There's, I know we identified, I think, yeah, 5,000 or over 5,000 servers that were publicly accessible, that were running WAZA through just census queries. So if you don't have any reasonable need to be publicly accessible on the Internet, it's best to just cordon that off. And then of course, in lieu of that, pasture systems as well.”

Sam provides actionable recommendations for defenders:

1. Patch Systems: Ensure all systems are updated to the latest versions to mitigate known vulnerabilities.
2. Restrict Public Access: Servers running WAZA should not be publicly accessible unless absolutely necessary. Implement stringent access controls and filtering mechanisms.
3. Secure APIs: Lock down APIs to prevent unauthorized access and exploitation.
4. Network Segmentation: Implement network segmentation to limit the potential spread of malware.
5. Ongoing Monitoring: Continuously monitor systems for unusual activities and potential breaches.

Balancing Transparency and Weaponization in Security Research

[19:04] Dave Bittner:
“I'm curious from your perspective, balancing the need for transparency through things like public proof of concepts, but then on the flip side of that, you have the risk of rapid weaponization which we kind of saw here. How do you balance those two needs of the security community?”

[19:26] Sam:
“I think that's a great question. I think that's a tricky one because. Yeah, I mean we've detailed that a bit in our article that it's a little bit of a double-edged sword. It helps people identify and analyze the vulnerability in their own configurations, in their own organization to try to mitigate things better and be more aware of it. But then yeah, as you say, it can allow for rapid weaponization and adoption. I suppose you could have other alternatives such as having organizations be part of some trusted partnership group and distribute things like exploit code for proof of concepts within those trusted circles rather than having those publicly accessible on the Internet. I suppose you could make an argument for that which would provide a lot of the same purpose but help mitigate that. Of course the issue you would have with that is, you know, maybe certain smaller organizations can't get access to that and then it would become, you know, this inside club, so to speak. So that was, that's just kind of an idea, I suppose. I think overall the whole CVE program does more good than harm and I think it's necessary to have at this point. But yeah, there's definitely some downsides to it and there could be a discussion as far as with proof of concepts. How necessary are they or should they be as public as they are? I don't really know the answer to that myself. So it's definitely a trend that's been going on and I expect that trend to continue.”

Sam addresses the complex balance between transparency and the potential for rapid weaponization of vulnerabilities. While public proof of concepts facilitate widespread awareness and prompt mitigation, they also enable threat actors to quickly exploit these vulnerabilities. Sam suggests possible alternatives, such as distributing exploit code within trusted circles, though this approach has its own drawbacks, including exclusivity and accessibility issues for smaller organizations. Ultimately, the CVE program's benefits outweigh its drawbacks, despite inherent challenges in managing proof of concept disclosures.

Conclusion and Acknowledgments

[21:15] Dave Bittner:
“Our thanks to Kyle Lefton from Akamai for joining us. The research is titled Two Botnets, One Flaw, Mirai Spreads Through WAZA Vulnerability. We'll have a link in the show notes. And that's Research Saturday, brought to you by N2K CyberWire. We'd love to hear from you. We're conducting our annual audience survey to learn more about our listeners, collecting your insights through the end of this summer. There's a link in the show notes. Please do check it out. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher and I'm Dave Bittner. Thanks for listening. We'll see you back here next time.”

Dave wraps up the episode by thanking the guest, Kyle Lefton from Akamai, highlighting the research discussed, and providing information about the show’s production team. He also invites listeners to participate in an annual audience survey to enhance future content.

[22:02] Sam:
“Sam.”

Sam signs off, concluding the discussion.

Key Takeaways:

• WAZA Vulnerability (CVE-20002524016): A critical remote code execution flaw affecting WAZA servers, exploited by two botnets, Mirai and Resbot.
• Botnet Variants: Mirai continues to evolve with multiple variants, while Resbot is a Mirai derivative targeting Italian-speaking domains, indicating sophisticated targeting strategies.
• Indicators of Compromise: Effective utilization of IOCs through IPs, domains, and hashes helps in mapping malicious infrastructure.
• Defense Strategies: Emphasize patching, restricting public access to critical servers, securing APIs, and continuous monitoring.
• Transparency vs. Weaponization: While public disclosures aid in defense, they also facilitate rapid exploitation by adversaries, posing a continual challenge for the cybersecurity community.

This episode of CyberWire Daily offers a comprehensive analysis of the recent botnet activities exploiting a critical vulnerability in the WAZA platform. Through detailed discussions and expert insights, listeners gain a deeper understanding of the dynamics between vulnerability disclosures, threat actor behaviors, and effective defense mechanisms in the ever-evolving cybersecurity landscape.