A New Fileless P2P Botnet Malware Targeting SSH Servers Worldwide

Cybersecurity researchers today took the wraps off a sophisticated, multi-functional peer-to-peer (P2P) botnet written in Golang that has been actively targeting SSH servers since January 2020.

Called "FritzFrog," the modular, multi-threaded and file-less botnet has breached more than 500 servers to date, infecting well-known universities in the US and Europe, and a railway company, according to a report released by Guardicore Labs today.

"With its decentralized infrastructure, it distributes control among all its nodes," Guardicore's Ophir Harpaz said. "In this network with no single point-of-failure, peers constantly communicate with each other to keep the network alive, resilient and up-to-date."

In addition to implementing a proprietary P2P protocol that's been written from scratch, the communications are done over an encrypted channel, with the malware capable of creating a backdoor on victim systems that grants continued access for the attackers.

A Fileless P2P Botnet

Although GoLang based botnets have been observed before, such as Gandalf and GoBrut, FritzFrog appears to share some similarities with Rakos, another Golang-based Linux backdoor that was previously found to infiltrate target systems via brute force attempts at SSH logins.

But what makes FritzFrog unique is that it's fileless, meaning it assembles and executes payloads in-memory, and is more aggressive in carrying out brute-force attacks, while also being efficient by distributing the targets evenly within the botnet.

Once a target machine is identified, the malware performs a series of tasks involving brute-forcing it, infecting the machine with malicious payloads upon a successful breach, and adding the victim to the P2P network.

To slip under the radar, the malware runs as ifconfig and NGINX, and begins listening on port 1234 to receive further commands for execution, including those for syncing the victim with the database of network peers and brute-force targets.

The commands themselves are transmitted to the malware through a series of hoops designed to avoid detection. The attacker node in the botnet first latches onto a specific victim over SSH and then uses the NETCAT utility to establish a connection with a remote server.

What's more, the payload files are exchanged between nodes in BitTorrent-style, employing a segmented file transfer approach to send blobs of data.

"When a node A wishes to receive a file from its peer, node B, it can query node B which blobs it owns using the command getblobstats," Harpaz said. "Then, node A can get a specific blob by its hash, either by the P2P command getbin or over HTTP, with the URL 'https://node_IP:1234/blob_hash.' When node A has all the needed blobs, it assembles the file using a special module named Assemble and runs it."

Aside from encrypting and encoding the command responses, the malware runs a separate process, named "libexec," to mine Monero coins and leaves a backdoor for future access to the victim by adding a public key to the SSH's "authorized_keys" file so that logins can be authenticated without having to rely on the password again.

13,000 Attacks Spotted Since January

The campaign began on January 9, according to the cybersecurity firm, before reaching a cumulative of 13,000 attacks since its first appearance spanning across 20 different versions of the malware binary.

Aside from targeting educational institutions, FritzFrog has been found to brute-force millions of IP addresses belonging to governmental organizations, medical centers, banks, and telecom companies.

Guardicore Labs has also made available a detection script that checks if a server has been infected by FritzFrog, along with sharing the other indicators of compromise (IoCs).

"Weak passwords are the immediate enabler of FritzFrog's attacks," Harpaz concluded. "We recommend choosing strong passwords and using public key authentication, which is much safer. Routers and IoT devices often expose SSH and are thus vulnerable to FritzFrog — consider changing their SSH port or completely disabling SSH access to them if the service is not in use."