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.”
^[1]

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.”

^{[2][3][4][5][6]}