Linux devices are under attack by a never before seen worm

Enlarge Getty Images reader comments 4 For the past year, previously unknown self replicating malware has been compromising Linux devices around the world and installing cryptomining malware that takes unusual steps to conceal its inner workings, researchers said. Further Reading Record breaking DDoS reportedly delivered by >145k hacked cameras The worm is a customized version of Mirai, the botnet malware that infects Linux based servers, routers, Web cameras, and other so called Internet of things devices.

Mirai came to light in 2016 when it was used to deliver record setting distributed denial of service attacks that paralyzed key parts of the Internet that year. The creators soon released the underlying source code, a move that allowed a wide array of crime groups from around the world to incorporate Mirai into their own attack campaigns.

Once taking hold of a Linux device, Mirai uses it as a platform to infect other vulnerable devices, a design that makes it a worm, meaning it self replicates. Dime a dozen malware with a twist Traditionally, Mirai and its many variants have spread when one infected device scans the Internet looking for other devices that accept Telnet connections .

The infected devices then attempt to crack the telnet password by guessing default and commonly used credential pairs. When successful, the newly infected devices target additional devices, using the same technique. Mirai has primarily been used to wage DDoSes. Given the large amounts of bandwidth available to many such devices, the floods of junk traffic are often huge, giving the botnet as a whole tremendous power.

On Wednesday, researchers from network security and reliability firm Akamai revealed that a previously unknown Mirai based network they dubbed NoaBot has been targeting Linux devices since at least last January. Instead of targeting weak telnet passwords, the NoaBot targets weak passwords connecting SSH connections.

Another twist: Rather than performing DDoSes, the new botnet installs cryptocurrency mining software, which allows the attackers to generate digital coins using victims’ computing resources, electricity, and bandwidth. The cryptominer is a modified version of XMRig, another piece of open source malware.

More recently, NoaBot has been used to also deliver P2PInfect, a separate worm researchers from Palo Alto Networks revealed last July . Advertisement Akamai has been monitoring NoaBot for the past 12 months in a honeypot that mimics real Linux devices to track various attacks circulating in the wild.

To date, attacks have originated from 849 distinct IP addresses, almost all of which are likely hosting a device that’s already infected. The following figure tracks the number of attacks delivered to the honeypot over the past year. Enlarge / Noabot malware activity over time. “On the surface, NoaBot isn’t a very sophisticated campaign—it’s ‘just’ a Mirai variant and an XMRig cryptominer, and they’re a dime a dozen nowadays,” Akamai Senior Security Researcher Stiv Kupchik wrote in a report Wednesday .

“However, the obfuscations added to the malware and the additions to the original source code paint a vastly different picture of the threat actors’ capabilities.” The most advanced capability is the way NoaBot goes about installing the XMRig variant. Typically, when cryptominers are installed, the wallets funds are distributed to are specified in configuration settings delivered in a command line issued to the infected device.

This approach has long posed a risk to threat actors because it allows researchers to track where the wallets are hosted and how much money has flowed into them. NoaBot uses a novel technique to prevent such detection. Instead of delivering the configuration settings through a command line, the botnet stores the settings in encrypted or obfuscated form and decrypts them only after XMRig is loaded into memory.

The botnet then replaces the internal variable that normally would hold the command line configuration settings and passes control to the XMRig source code. Kupchik offered a more technical and detailed description: In the XMRig open source code, miners can accept configurations in one of two ways — either via the command line or via environment variables.

In our case, the threat actors chose not to modify the XMRig original code and instead added parts before the main function. To circumvent the need for command line arguments (which can be an indicator of compromise IOC and alert defenders), the threat actors had the miner replace its own command line (in technical terms, replacing argv) with more “meaningful” arguments before passing control to the XMRig code.

The botnet runs the miner with (at most) one argument that tells it to print its logs. Before replacing its command line, however, the miner has to build its configuration. First, it copies basic arguments that are stored plaintext— the rig id flag, which identifies the miner with three random letters, the threads flags, and a placeholder for the pool’s IP address (Figure 7).

Curiously, because the configurations are loaded via the xmm registers, IDA actually misses the first two loaded arguments, which are the binary name and the pool IP placeholder. Enlarge / NoaBot code that copies miner configurations Akamai Next, the miner decrypts the pool’s domain name. The domain name is stored, encrypted, in a few data blocks that are decrypted via XOR operations.

Although XMRig can work with a domain name, the attackers decided to go the extra step, and implemented their own DNS resolution function. They communicate directly with Google’s DNS server (8.8.8.8) and parse its response to resolve the domain name to an IP address. The last part of the configuration is also encrypted in a similar way, and it is the passkey for the miner to connect to the pool.

All in all, the total configuration of the miner looks something like this: o rig id threads –pass espana*tea Notice anything missing? Yep, no wallet address. 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!).

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.