Hackers come hopping back.

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.

Ori David: So FritzFrog is a botnet that we have been tracking since 2020. Akamai originally discovered it and we were tracking it ever since. And a few months ago, when we inspected the code, we have noticed some very interesting additions, mainly the Log4Shell addition.

Dave Bittner: That's Ori David, a security researcher at Akamai. The research we're discussing today is titled "Frog4Shell -- FritzFrog Botnet Adds One-Days to Its Arsenal." [ Music ] Well, let's back up a little bit and talk about FritzFrog. What's the history of this particular botnet? How did it begin and who were they targeting over the years?

Ori David: So as I said before, we've seen FritzFrog since 2020 being active, and its traditional targets were vulnerable SSH servers. So SSH servers exposed to the internet with weak credentials that FritzFrog brute forced and took control over. So it didn't target any specific industry. It simply scanned the internet, identified SSH servers and attempted to brute force them.

Dave Bittner: And what was the FritzFrog botnet then used for? Who did they aim it at?

Ori David: Like I said before, it's not targeted, but rather their motivation is purely financial. They would compromise as many machines as possible and then they would use those machines to mine Monero. And there's actually an interesting feature for FritzFrog where they have an antivirus module. They know that the machines that they compromise very often have additional malware installed on it because, well, it's an SSH box with a weak password exposed to the internet. And because of that, they identify competing malware that consumes a lot of CPU and simply terminates them. And then they have all of the CPU for themselves.

Dave Bittner: It's a mixed blessing, I guess, right? It's an interesting approach. Well, let's dig into the updates that you all tracked here. I mean, they started using Log4Shell as an infection vector here. Before we dig into how FritzFrog is using that, can you give us just a quick reminder of what we're talking about with Log4Shell? So Log4Shell rocked the world two years ago at the end of 2021. It was a very high-profile vulnerability and for a good reason. It was a vulnerability in a Java library called Log4J. It is a logging library, which is very commonly used by Java applications. And what the vulnerability was, by getting the application to log a specific payload, attackers could get the Java application to download a malicious Java class and execute it. So in a very simple manner, they could get a code execution on all sorts of Java applications across the world. Like I said before, the library was very commonly used, and the exploitation was very, very simple. You simply need to get a line logged into a log file by the application, and that's it. You get code execution. So Log4Shell was a really big deal for another reason, and that is, it is really hard to patch. So let's say we have our traditional code execution vulnerability, let's say in Windows Server. It's pretty easy to determine if you're vulnerable. You'll check your Windows machines, and you'll see if your version is affected. With Log4Shell, because the vulnerability was in a Java library, it was not as trivial to know if an application is vulnerable, or even harder to tell if a machine is vulnerable. This made Log4Shell extremely hard to patch. And so, where does that leave us today? You mentioned that after Log4Shell, there was a real flurry of patching, but I suppose there's still plenty of systems that are left vulnerable?

Ori David: Yes. So the initial discovery of Log4Shell led to really a month-long or months-long frenzy of patching, where everyone was trying to identify where they are using Log4J, and what third-party applications that they use, use Log4J. And during this initial frenzy, some applications received more attention than others. So obviously, applications that were exposed to the internet were prioritized. So anything that was exposed to the internet and was vulnerable to Log4J, to Log4Shell, was either patched or compromised by now. So FritzFrog actually poses an additional risk to another type of asset, and that is internal assets. Like I said before, the traditional Log4Shell exploitation relied on access from the internet. But if you had a legacy Java application somewhere inside your network that didn't receive communication from the internet, it was safe because no one could reach it, so no one could exploit it. What FritzFrog does is that whenever it breaches any machine, it will scan the entire internal network of this machine. And now, let's say we have just a random SSH server, and that is not really important, but it was compromised by FritzFrog. And now this machine is scanning your entire network, and it will find the leftover, if you will, applications that were not patched. [ Music ]

Dave Bittner: We'll be right back. [ Music ] So machines that people perhaps had assumed were safe because they weren't facing the internet, FritzFrog has found a way to exploit them.

Ori David: Yeah. So in many cases, internal machines were patched as well, but because the external machines received most of the attention, we believe that the malware developers chose to target, believed that they could target internal machines that might have been neglected.

Dave Bittner: Well, can you walk us through the process here of how FritzFrog attacks a system and finds its way in and then makes its way through?

Ori David: An interesting fact about FritzFrog is that it operates entirely in a peer-to-peer manner. So there is no C2 server, but rather all of the different bots communicate with each other in a peer-to-peer network. And this is relevant for the exploitation as well. So the payload is also delivered through this network to newly compromised machines. So FritzFrog has two ways of propagations currently, and that is SSH brute force and Log4Shell exploitation. So FritzFrog will identify targets. It will do that by parsing certain system configuration files. And for example, it will identify your known SSH host from the compromised machine and will then attempt to connect over SSH to these servers. So if the compromised machine previously connected to an SSH server, FritzFrog will attempt to do the same thing. And besides these more targeted targets, FritzFrog will also just randomize IP addresses into the internet and scan them. And that's for the SSH brute force. As for the Log4J exploitation, so again, FritzFrog will generate targets randomly and from the internal network. So it will start by enumerating the internal network. It will scan ports that often host applications that are known to be vulnerable to Log4Shell. And it will then just blast them with a massive payload that attempts to exploit Log4Shell. I would say a brute force approach that contains a lot of different possibilities, hoping that at least one of them triggers the Log4Shell vulnerability. Once the vulnerability is triggered, interestingly, the newly compromised machine will connect back to the bot, which hosts its own LDAP server. And it will fetch the payload from the bot. So like I said before, the botnet is entirely peer-to-peer. And this is also true for the Log4Shell exploitation. The machine will connect back to the bot over LDAP. And so, this is also a pretty unique thing for FritzFrog regarding the Log4Shell exploitation.

Dave Bittner: It strikes me that you're being configured as a peer-to-peer thing. And as you said, downloading large files, that strikes me as being potentially noisy here. So how does it avoid detection?

Ori David: Yeah, so FritzFrog does a few noisy things, but at the same time it attempts to avoid detection. The main thing would be that it tries its best to not touch disk and operate only inside the memory, the volatile memory. It utilizes two mechanisms of the Linux operating systems to do that. Yeah, when possible, given the right permissions, it will not write any files to disk and will only work inside the RAM.

Dave Bittner: So what are your recommendations for folks to best protect themselves against this?

Ori David: So first, I would say the most important thing to protect from FritzFrog, but other botnets and automated scanners as well, would be to identify your internet exposed applications. Because a lot of times there are these SSH servers that no one knows about, and this is how FritzFrog gets in. So first you need to identify the servers and then harden them. Specifically for FritzFrog, SSH passwords should be not used if possible. SSH keys would be better, and if you use a password, it should be strong. Obviously, you should patch for Log4Shell if you're still vulnerable somehow. That is for the initial entry for FritzFrog. I would also say that network segmentation can really help prevent lateral movement of such a worm-like botnet. If you have a flat network, FritzFrog will simply scan everything and exploit it, if possible. So really, I think that a good firewall policy and good segmentation can help contain such a breach in a really significant way.

Dave Bittner: You know, Ori, I think you and I have both demonstrated tremendous discipline here in resisting the urge to use frog puns throughout our conversation here. And I just want to say that when it comes to patching your Log4Shell, you should really hop to it.

Ori David: Yeah, definitely. [ Music ]

Dave Bittner: Our thanks to Ori David from Akamai for joining us. The research is titled "Frog4Shell -- FritzFrog Botnet Adds One-Days To Its Arsenal." We'll have a link in the show notes. [ Music ] The CyberWire Research Saturday podcast is a production of N2K Networks. N2K's strategic workforce intelligence optimizes the value of your biggest investment, your people. We make you smarter about your team while making your team smarter. Learn more at n2k.com. This episode was produced by Liz Stokes. Our mixer is Elliott Pelzman. Our executive producers are Jennifer Eiben and Brandon Karp. Our executive editor is Peter Kilpe. And I'm Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]