MalwareSecurity

Mirai-based NoaBot botnet deploys cryptominer on Linux servers

However, SSH dictionary attacks — where the attacker will test predefined pairs of usernames and passwords — are nothing new and are also easy to defend against by following best security practices like using SSH key-based authentication and disabling password authentication. This means that the servers compromised by NoaBot are likely low-hanging fruit from a security perspective and it wouldn’t be surprising if they’re already infected with other malware.

The NoaBot SSH scanner does have a clear signature because when a SSH connection is accepted by an IP address the botnet client sends the message “hi.” This is not a valid SSH command and there is no practical reason to send it, so it can be used to create a firewall signature.

Other modifications made to NoaBot involve changing the compiler from GCC to uClib to make its binary code significantly different from Mirai and therefore evade existing Mirai detection signatures, and adding command line arguments that enable different functionalities. For example, the bot can add an attacker-controlled key in the SSH authorized keys to ensure persistence even if password-based authentication is disabled, it acts as a backdoor by downloading and installing additional binaries and adds a crontab entry to ensure it starts after reboot.

The command line flag for this persistence mechanism is called “noa”, inspiring the name of the botnet. However, the researchers found detection signatures in antivirus engines for the prefix “noa-” which suggests it could be common.

Cryptominer modifications and P2PInfect connection

The cryptomining component is XMRig, an open-source and widely used cryptocurrency mining program that has legitimate uses but is also popular with attackers. According to the Akamai researchers, the NoaBot creators made advanced modifications to the XMRig code as well to hide and encrypt its configuration, particularly the IP address that serves as the mining pool where attackers collect the generated cryptocurrency.

“We believe that the threat actors chose to run their own private pool instead of a public one, thereby eliminating the need to specify a wallet (their pool, their rules!),” the researchers said. “However, in our samples, we observed that miner’s domains were not resolving with Google’s DNS, so we can’t really prove our theory or gather more data from the pool, since the domains we have are no longer resolvable. We haven’t seen any recent incident that drops the miner, so it could also be that the threat actors decided to depart for greener pastures.”

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button