FritzFrog: P2P Botnet Hops Back on the Scene
Executive summary
FritzFrog is a peer-to-peer botnet campaign uncovered by Guardicore Labs (now Akamai Threat Labs) in August 2020
The decentralized botnet targets any device that exposes an SSH server — cloud instances, data center servers, routers, etc. — and is capable of running any malicious payload on infected nodes
Its peer-to-peer architecture and proprietary code demonstrate a high level of sophistication
It has recently resurfaced and displayed 10x growth in its infection rate within a month, compromising servers in the healthcare, education, and government sectors
1,500 distinct hosts have been infected since the reappearance of the botnet, most of which are in China
The Golang malware being spread adds new functionality to the botnet, including the usage of a proxy network and the targeting of WordPress servers
The recent round of attacks provides more evidence as to the origins of FritzFrog, indicating a possible link to an actor operating in China, or one masquerading as Chinese
Akamai Threat Labs has updated the FritzFrog detection tool to handle the newest version of the malware
FritzFrog at a glance
FritzFrog v1 — a quick recap
FritzFrog is a peer-to-peer botnet, which means its command and control server is not limited to a single, centralized machine, but rather can be done from every machine in its distributed network. In other words, every host running the malware process becomes part of the network, and is capable of sending, receiving, and executing the commands to control machines in the network.
FritzFrog propagates over SSH. Once it finds a server’s credentials using a simple (yet aggressive) brute force technique, it establishes an SSH session with the new victim and drops the malware executable on the host. The malware then starts listening and waiting for commands. These commands include exchanging targets, sharing the details of compromised machines, and transferring files, as well as running scripts and binary payloads. The full list of commands is available in our previous blog post.
We consider FritzFrog to be a “next generation” botnet due to a combination of properties that make it unique in the threat landscape:
Constantly updating — Databases of targets and breached machines are exchanged seamlessly
Aggressive — Brute force is based on an extensive dictionary; by comparison, DDG, another recently discovered P2P botnet, used only the username “root”
Efficient — Targets are evenly distributed among nodes
Proprietary — The P2P protocol is completely proprietary, relying on no known P2P protocols such as μTP
FritzFrog v2 — the resurface
Right after publishing the details about FritzFrog in August 2020, the Guardicore Labs team (now Akamai Threat Labs) noticed a drop in the number of attack incidents. However, in early December 2021, we started seeing an uptick in attacks toward our global sensor network.
A FritzFrog attack starts with an SSH brute force, and continues with a file being dropped and executed. This file immediately starts listening on port 1234 and scanning thousands of internet IP addresses over ports 22 and 2222.
One difference between the old FritzFrog attacks and new attacks is the name of the malicious process. In the first round of attacks, the malicious process was named ifconfig or nginx; this time the FritzFrog operators chose the name apache2.
We started monitoring the new variant and saw a surprising rise in the number of FritzFrog attacks, peaking at 500 incidents per day.
Number of FritzFrog attack incidents seen by our sensors since the its first appearance
Victim analysis
As part of our investigation into FritzFrog’s first campaign, we developed a tool called Frogger. Frogger allows us to gather information on infected hosts, including their uptime, hashrate, peers, and hasrate, if a cryptominer is running. This program takes an infected node’s IP address and queries the host over an encrypted communication channel in order to receive information on its status. By doing this, we can find out more about the node, and other nodes it is connected to. This process leverages the botnet's infrastructure to do so.
Our victim analysis was based on two sources: the IP addresses of the machines that attacked our sensors, and information obtained by Frogger. Namely, we started with the list of attacker IPs seen by our sensors, and then expanded that list by querying each one for its peers, using Frogger, recursively.
The graphs below show the daily number of IP addresses that attacked our sensors and the difference in the number of attackers between consecutive days. The rise in the number of attacking nodes — victim machines running the malware — is disturbing.
Number of attacking nodes per day as captured by our threat sensors
Graph showing the difference in number of attacking nodes between consecutive days
During the time span of the second campaign, FritzFrog managed to infect more than 1,500 distinct hosts. These were server machines belonging to organizations of various sizes and sectors, including healthcare, higher education, and government. We found infected machines in a European television channel network, a Russian manufacturer of healthcare equipment, and multiple universities in East Asia. As the map shows, a large concentration of victim machines was found in China.
Most of the victims are north of the equator, with high attraction to China
New malware capabilities
The FritzFrog binary is written in Golang and can be compiled to run on many different architectures. It is packed using UPX and is usually executed under one of four process names: ifconfig, nginx, apache2, or php-fpm. We have provided a thorough analysis of the malware in our previous publication, and will therefore focus on the new samples and the additions they make.
FritzFrog is updated daily — sometimes multiple times a day. Most new releases involve bug fixes, but some versions add new capabilities to the malware.
Preparation for WordPress targeting
FritzFrog released a new version that implements the infrastructure for tracking WordPress servers. It contains functions responsible for adding and removing entries from lists titled Wordpress and WordpressTargetsTTL. The snippet of disassembled code below shows the implementation of a new P2P command, put wordpress, which adds a new entry to the WordPress target list. At the time this report was written, these lists — which are saved on all infected nodes — are still empty.
The malware does not contain any module capable of cracking or identifying WordPress targets. Based on this, we assume the code is a preparation for new versions, which will be capable of compromising those targets and using them for purposes other than mining, such as information leaks, ransomware, etc.
Tor proxy chain
FritzFrog can proxy outgoing SSH connections using the Tor proxy chain by setting the proxy for SSH connections to local port 9050. The Tor proxy chain is a network of nodes that provides its users with better privacy and masking by creating an encapsulation-based path from source to destination; each node is only aware of its direct neighbor nodes.
By proxying requests to local port 9050, FritzFrog uses the Tor proxy chain to connect to owned SSH devices. An owned device would see the incoming request as coming from the last node in the proxy chain. This can be used to conceal the address of current infected nodes. As of today, while the functionality exists, we have not yet seen this capability being used by the malware.
SCP
FritzFrog now uses SCP to copy itself to a remote compromised server. This is different from the first version, where the malware executable was dropped on a new victim using the cat command over an established SSH session. The new implementation uses a public SCP library written in Golang in GitHub. We could not determine any meaningful advantage for one method over the other. It is, however, notable that the writers of the SCP library are located in China.
Blocklist
FritzFrog’s early version implemented a blocklist, to exclude specific machines from being breached by the cracker (brute force) module. While a special P2P command, putblentry, allows for dynamic insertion of entries to this list, the new versions hard-code several entries in advance.
Some of these entries specify a Unix name, and some of them an IP address — but never both.
Blocklist entries hard-coded into the new FritzFrog samples
[
{"Address": "",
"Uname_match": "[redacted]dddz.me 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017"},
{"Address": "",
"Uname_match": "[redacted]-1 4.4.0-151-generic #178-Ubuntu SMP Tue Jun 11 08: 30: 22 UTC 2019"},
{"Address": "",
"Uname_match": "[redacted].amzn2.x86_64 #1 SMP Mon Jun 18 22: 33: 07 UTC 2018 x86_64 GNU/Linux"},
{"Address": "",
"Uname_match": "[redacted]-generic #113-Ubuntu SMP Thu Jul 9 23: 41: 39 UTC 2020"},
{"Address": "",
"Uname_match": "[redacted] raspberrypi 4.4.32-v7+ #924 SMP Tue Nov 15 18: 11: 28 GMT 2016 armv7l GNU/Linux"},
{"Address": "",
"Uname_match": [redacted] 3.10.0-123.4.4.el7.x86_64 #1 SMP Fri Jul 25 05: 07: 12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux"},
{"Address": "",
"Uname_match": [redacted] 4.18.0-193.28.1.el8_2.x86_64 #1 SMP Thu Oct 22 00: 20: 22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux"},
{"Address": "[redacted].24: 22",
"Uname_match": ""},
{"Address": "[redacted].88: 22",
"Uname_match": ""},
{"Address": "[redacted].26: 22",
"Uname_match": ""}]
The entries suggest the operators are seeking to avoid infecting low-end systems with low resources, such as Raspberry Pi devices or low-resource EC2 images on AWS.
One IP in the blocklist is from Russia. It has multiple open ports and a long list of unpatched vulnerabilities, so it may be a honeypot. Additionally, a second entry points to an open-source botnet sinkhole. These two entries suggest that the operators are attempting to evade detection and analysis.
Two of the IP addresses are geo-based in the United States. One entry blocks the University of Maryland, for reasons that are not clear, and the second displays a practical joke, or warning when browsed to, seemingly aware of potential investigation into the malware.
Warning displayed says "curiosity killed the cat"
Origins and attribution
Recent changes and additions to this campaign have allowed us to examine the possible origins of this malware. While we cannot be certain of its true origin, we believe that sharing this information can be valuable.
The first piece of evidence comes from one of the newly added libraries compiled into the FritzFrog malware named scp, which implements the Secure Copy Protocol for file transfers over SSH. The library is written in Go and its code is shared on GitHub, in a repository by a user located in Shanghai. One fork exists in this repository, which was done by a second individual in Shanghai.
Another piece of evidence linking to China comes from FritzFrog’s cryptomining activity. Our research team has managed to find new wallet addresses as well as new mining pools used in the cryptomining process. One of the newly observed wallets addresses (given below) was also used as part of the Mozi botnet campaign, whose authors were recently arrested in China.
FritzFrog Monero wallet address connected to Mozi
47BD6QNfkWf8ZMQSdqp2tY1AdG8ofsEPf4mcDp1YB4AX32hUjoLjuDaNrYzXk7cQcoPBzAuQrmQTgNgpo6XPqSBLCnfsjaV
These points of evidence, while not damning, lead us to believe a possible link exists to an actor operating in China, or an actor masquerading as Chinese.Lastly, monitoring attack data has demonstrated a high level of activity in and around China throughout the lifetime of the campaign. As of now, approximately 37% of infected nodes seem to be located in China.
Prevention and mitigation
FritzFrog detection tool
Akamai provides a FritzFrog detection script to run on SSH servers. It looks for the following FritzFrog indicators:
Running processes named nginx, ifconfig, php-fpm, apache2, or libexec, whose executable file no longer exists on the file system (as seen below)
Listening port 1234
In addition, TCP traffic over port 5555 can indicate network traffic to the Monero pool.
Recommendations
Always Keep systems updated and patched
Implement passwordless login using strong key management and rotation system
Enable system login auditing with alerting
Monitor the authorized_hosts file on Linux
Configure explicit allow list of SSH login
Disable root SSH access
Enable Akamai cloud-based DNS protection with threats and unrelated business applications such as coin mining set to block
