You Had Me at Hi — Mirai-Based NoaBot Makes an Appearance

The botnet

The NoaBot botnet has most of the capabilities of the original Mirai botnet (such as a scanner module and an attacker module, hiding its process name, etc.), but we can also see many differences from Mirai’s original source code. First and foremost, the malware’s spreader is based in SSH, not based in Telnet like Mirai.

The SSH scanner seems to be custom made, and quite peculiar — once a connection is established, the botnet simply sends the string “hi” and terminates the connection (Figure 2). Quick termination makes sense in the context of a scanner, since it doesn’t need to keep the connection open, just to verify it exists. Why does it bother sending “hi,” though? That’s a mystery.

Another quirkiness of the malware is the embedded song lyrics. Earlier samples of the botnet had lyrics from the song “Who's Ready for Tomorrow” by Rat Boy and IBDY (Figure 3). As far as we can tell, those lyrics served no purpose. Later samples did not have them.

Other changes from Mirai is that he botnet uses a different credential dictionary for its SSH scanner, and includes a lot of postbreach capabilities, such as installing a new SSH authorized key as a backdoor to download and execute additional binaries or spread itself to new victims (Figure 4).

The malware also comes statically compiled and stripped of any symbols. This, alongside with being a nonstandard compilation, made reverse engineering the malware much more frustrating.

Newer samples of the botnet also had their string obfuscated instead of saved as plaintext. This made it harder to extract details from the binary or navigate parts of the disassembly but the encoding itself was unsophisticated and simple to reverse engineer. 

We’ve also seen the addition of command line arguments over time. The most interesting one is the “noa” flag, which made the botnet install a persistence method in the form of a crontab entry to run after a reboot.

Coincidentally, it seems this flag was heavily used in the wild, as some of the antivirus detections for botnet samples had the prefix “Noa-”.

The postbreach operations, which we showed in Figure 4, are another evolution. Those were not present in the earlier samples that we’ve investigated.

The miner — and why we couldn't find its wallet address

The miner itself is a lot less complicated. It is the standard XMRig miner, although it was also self-compiled, and the threat actors added some code before the miner’s execution to extract the mining configuration instead of supplying it via command line or saving it inside the binary as plaintext (Figure 6).

We can see there are some other function calls before the function call to build the XMRig configuration. If it fails, the miner terminates, but otherwise it goes to the standard XMRig miner logic. (You can compare the decompilation above to the actual XMRig source code.) Why do we as researchers care about the XMRig configuration? Usually, it contains details about the mining pool it connects to, as well as the wallet address to receive mining payments. By getting the wallet address and tracking the payments to it (which are usually tracked by public pools), we can estimate how profitable the cryptomining gig is.

This time, however, the attackers were ahead of us. So, let’s do a deeper dive into building the configuration. 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.

Mirai is too old and developed some Rust

The most recent incidents we’ve seen also had samples of P2PInfect — a peer-to-peer self-replicating worm written in Rust. While P2PInfect was first seen in July 2023, we’ve seen NoaBot activity since January 2023, which means it predates P2PInfect by a bit. Why switch from Mirai to something else? Something that might even be custom? We have no clear answer, but a few guesses.

First, custom code is more difficult to reverse engineer than repurposed code because it is modified. Second, the threat actors seem quite tech-savvy, so it could be that they’re trying their hand at malware development out of curiosity or boredom (or both). Finally, given that P2PInfect targets Redis servers, it could simply be a case of different tools for different purposes.

How do we know that it’s the same threat actors, not just some sort of collaboration? We aren’t 100% certain, but we’re close. It all boils down to the technical professionalism in the malware, coupled with a teenager’s maturity level in terms of inside jokes, including inserting profanities in the miner’s name, embedding gaming pop song lyrics in malware binaries, and sending “hi” while scanning for open ports. 

P2PInfect carries on that tradition. It seems like a sophisticated tool, but it uses a Unix socket and names it “NunzombiE” (Figure 8). And while NunzombiE is obfuscated and decoded during run time, the worm also has embedded strings for “fast_vuln_file” and “slow_vuln_file” — perfectly legit strings to contain in an executable, no red flags here.