A tale of two botnets.

[ Music ]

Dave Bittner: Hello everyone and welcome to the CyberWire's "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 a rapidly-evolving cyberspace. Thanks for joining us. [ Music ]

 

Kyle Lefton: If you followed Akamai 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.

 

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 Wazuh vulnerability".

 

Kyle Lefton: As part one of the things that we do in our day-to-day job is go through our honeypot network and try to identify anything that stands out. Because we get hundreds of thousands, if not millions of requests coming in all the time. So, it's a lot of junk to sift through sometimes. So we have certain ways to try to look through and identify things that haven't been seen before, whether or not that's a zero day or it could be something like in this case, it was previously reported, but it was not reported as being actively exploited. Nobody had written about it. And so it wasn't in CISA's Known Exploited Vulnerabilities Catalog. And so in those cases, it's worthwhile to bring up like, Hey, we're not only just seeing one botnet exploit this, we're seeing two different botnets exploit this. So that's how it becomes relevant. So we have a lot of times where we identify something that we think is maybe interesting in there, and then we start to dive down the rabbit hole a bit on it and then determine, Oh, well, this is not actually very interesting to report on because maybe somebody else has already reported on it or maybe it was an erroneous piece of data that we're looking at.

 

Dave Bittner: Well, let's talk about, let's start off with Wazuh itself. What is it and how is it typically used in enterprise environments?

 

Kyle Lefton: Yeah, so very different to what we would usually report on. Wazuh is a security, cybersecurity platform, open source, XDR and SIEM. So it's not, again, it's not unheard of for something separate like that to be exploited by a 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 Wazuh servers. So it is fairly widely used.

 

Dave Bittner: I see. A lot of this centers around a particular CVE. This is CVE 2025-24016. Take us through what is particularly interesting about that vulnerability.

 

Kyle Lefton: Yeah, so basically what this CVE is, it's a remote code execution vulnerability in Wazuh 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 the bit more in-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 Wazuh server if it is affected by this, to maybe establish backdoors or to do other nefarious things. So it's rated pretty highly, 9.9 critical as far as a CPSS score. So it is pretty severe if you are affected by it.

 

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

 

Kyle Lefton: 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 can trigger the RCE using the run0as 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, and that's why we, you know, mention this as 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.

 

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?

 

Kyle Lefton: 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 digitized yet, 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, 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 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 awhile to do patching.

 

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

 

Kyle Lefton: Yeah, I mean, a lot of its, aligns pretty similarly to what the proof of concept is. A lot of it is pretty typical to how they normally exploit or send the exploit code. So usually a lot of 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.

 

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?

 

Kyle Lefton: Yeah, well, so Resbot is, I'll get into both. Resbot is just what we're calling that specific Mirai variant. It's all actually Mirai variants. 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 Wizard online was maybe back in 2018. So that's a source code that's been around, floating around there for quite a while. But they're using a variety of other stuff like they're 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 is 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 like 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 that if network defenders for machines that they're targeting go through to look at their network logs and they see this, maybe, you know, their alarm bells don't go off because they might see that as more legitimate perhaps, is one of my theories. But it is unusual activity. [ Music ]

 

Dave Bittner: We'll be right back. [ Music ] Let's talk about the malicious infrastructure. The research talks about some of the key indicators of compromise that you all were tracking here. Can you take us through that?

 

Kyle Lefton: Yeah, absolutely. So a lot of the stuff we focus on as far as indicators of compromise, you know, 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 know, you take one domain or you take another IP, that's, whether it's a C2 or not. You could use various tools, you know, 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 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.

 

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 a your own sense about it where you can kind of figure if you're on the right path and not, you know, going down a blind alley?

 

Kyle Lefton: 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 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 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 attack 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.

 

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

 

Kyle Lefton: Yeah, absolutely. I know a lot of people, 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.

 

Dave Bittner: Yeah. 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?

 

Kyle Lefton: 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 Wazuh, or Wazuh, don't have your servers publicly accessible on the internet unless there's some other kind of filters to it or a 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 5,000 or over 5,000 servers that were publicly accessible that were running Wazuh 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, you know, in lieu of that, you know, patch your systems as well.

 

Dave Bittner: I'm curious, you know, 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?

 

Kyle Lefton: I think that's, I mean, 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, 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'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. [ Music ]

 

Dave Bittner: Our thanks to Kyle Lefton from Akamai for joining us. The research is titled, "Two Botnets, One Flaw: Mirai spreads through Wazuh 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. We're 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 Elliott Peltzman and Tre Hester. Our executive producer is Jennifer Eiben. Peter Kilpe is our publisher. And I'm Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]