Investigating the resurgence of the Mexals campaign

In this campaign we saw improved obfuscation, more inconspicuous file names, and custom mining pool proxies that weren’t present in the previous iteration. The attack chain begins with SSH credential brute forcing. Then comes a long chain of obfuscated payloads, which eventually drops an XMRig cryptominer. One of the dropped payloads is a wormable module that we think has been active in this resurgence.

We also believe that their own attack servers are hosted in a Netherlands-based VPS, and their victims are spread across the globe. We estimate the attackers have managed to mine more than US$10,000 in XMR coins.

Fig. 2: A summary of the different payloads employed by the attackers

We can rely on glibc’s source code to understand what the entry point looks like. The actual main function is the function loaded into rdi. Looking into it, we can find a pretty specific error string: E: neither argv[0] nor $_ works., which we can search on the web. This leads us to shc. Unfortunately, there is no decompiler easily available. Instead of reverse engineering it and creating a decryptor, which would be too much of a hassle, we can debug the payload and pause execution after a second. The decrypted shell script will reside in the malware’s memory, which we can then dump and analyze.

Each payload chains together relatively plainly, with various methods of setting up the next link. For example, killing competitor miners or CPU-heavy processes, cleaning bash history or installing persistence, and then downloading and executing the next payload (Figure 5).

The first webhook is from a function called toDiscord, and it relegates the results of the various profiling commands run on the target machine. The next two are called from the functions toAPIlogs and toDisc, and both relegate the same information — the target’s IP and the user and password that can authenticate to it.

Finally, if the victim was running OpenWrt, another function is called toMirai, and sends the same information to yet another webhook. There is some redundancy here, which we assume is for the attackers to track different metrics more easily, or it may serve as a separation for different parts of their attack campaign (Mirai as a botnet/IAB vs. the regular use of Mirai as a cryptominer).

Although it is “just” a compiled bash script, payload is interesting because it is riddled with comments and progress messages, which can teach us about the thought processes of the malware operators.

The comments and progress messages are in Romanian, which reinforces the supposition that the attackers are Romanian (the malware’s command and control/download domain literally translates to “hacker’s archive”).

The script also checks for the presence of other known cryptominers, and kills their processes — among them dhpcd and ksmdx. This shows that the attackers are aware of their ecosystem and aren’t just trying their luck in the cryptomining world.

After killing competitors and other CPU-heavy processes, the script checks how many CPU cores the machine has — if it has less than four, it just installs History and Update and a cron job for them. (The two executables are responsible for downloading the aliases payload and are scheduled to run on a reboot of the victim machine.) If there are four or more cores, the script also downloads and executes .diicot, a compiled bash script that downloads and executes an XMRig cryptominer.

Finally, if there are eight or more CPU cores, then the script downloads and executes retea, the LAN spreader.

The LAN spreader module presents a new capability in the attackers’ chain. It’s another compiled shell script, which extracts all users configured on the system, and creates a file called .usrs. The file is used for an SSH dictionary attack and is populated using the extracted users and a hardcoded default password list. It then downloads and executes a network scanner on the LAN network, which detects machines with open SSH ports and writes the output to a file. Next, it downloads and executes Network, which is a lesser version of aliases, with less capabilities. Instead of installing a malicious payload or reporting to a Discord webhook, it just saves the output of the breached machines to a file, which can be later picked up by the attackers.

Since the attackers have a wormable payload, it makes it hard to distinguish which source IP caught in our threat sensors is attacker infrastructure - and which is a victim. In this section, we'll try to dissect the attacker's infrastructure and find actual victims. 

We pulled all the attacking IPs we detected (50 unique IP addresses) and geomapped them to their geographical location in the world. In addition to the attacking IPs, we also found evidence of infection at some of Akamai's customers, so they were also entered into our victim list. The geographical distribution of victims/infrastructure is shown in Figure 7.

Fig. 9: Top attacking IPs, which we assume are attacker’s infrastructure, not just victims

Prior to the release of this blog post, we reached out to affected Akamai customers with information about the attacks, as well as to the abused emails registered for each attacking IP address.

Summary

The payload chain employed by the threat actors is certainly impressive, and tells of a pretty sophisticated threat actor. We also usually don’t see such a long chain of payloads, and we believe there are a few reasons why the attackers chose to use so many payloads.

• Obfuscation - the more moving parts in the system, the harder it is to analyze and keep track of it. The fact that the binaries are obfuscated only strengthens this hypothesis.

• There are multiple people behind the threat group. Although we have no actual information on the threat actors behind the campaign, we’ve seen striking code differences among different samples of the same scripts, which we can only attribute to them having been developed by different people.

• The malware campaign is built to evolve over time. We see evidence of that in the new capabilities and further obfuscation that have been added, as well in some of the redundancies in the code that were created as a groundwork for future usage.

Improvements and additions from their previous operation

• UPX packing and stripping the UPX header.

• Automatic update feature moved from inside the payload to outside scripts (History and Update.)

• More inconspicuous file names (Chrome, Opera — mimicking browsers)

• Additional malware reportings over Discord

• OpenWRT specific behavior (and probably more to come)

• Usage of custom mining pool proxies instead of public pools

Defender’s archive

The malware doesn’t have any novel or sophisticated technique to distribute itself. It simply uses a dictionary attack on SSH. As such, only machines that are open to SSH from the internet are at risk. Blocking SSH at the network’s perimeter, or moving it behind a VPN, can greatly reduce the risks such attacks pose.

In addition, using non default credentials or complicated passwords greatly reduces the risk of a dictionary attack like the one employed by this malware. We also recommend using SSH keys for authentication as those are even more secure than passwords (they are impossible to guess, and the “secret” is never transmitted over the connection).

Finally, we also need to consider the LAN spreader module. Since it is also using SSH for lateral movement, segmenting your network can safely mitigate that risk. If we consider servers that are open to the internet as the demilitarized zone (DMZ), then preventing SSH traffic (and generally other traffic that can be used for lateral movement, like RDP, MS-RPC, or WinRM) from the DMZ to the rest of the network is the logical thing to do. If, for some reason, you do need one of those servers to have SSH access to the internal network (because it serves as a jumpbox, for example), then moving it outside of the DMZ and under the VPN should be the preferred method. Just don’t expose servers to the internet and allow attackers to jump from them internally — reduce the blast radius and propagation paths.

We’ve created a GitHub repository for tools that can assist you with detecting infections from this malicious campaign. There you'll find a bash script, a full list of IOCs and osquery queries that Akamai Guardicore Segmentation customers can use. You can also find the detection script and a partial list of IOCs at the end of this post.

In addition to those tools, we would also like to recommend a general way of detecting cryptominers that might be applied in this case — detecting outgoing traffic to mining pools by looking at the destination port. The default ports for mining pools are sometimes pretty unique, so keeping an eye out for them might prove beneficial. For example:

• TCP port 4242 is the default port for this pool implementation

• TCP ports 3333, 5555, 7777, 9000 are the default ports in the nodejs pool implementation

Of course, miners can also communicate with their pool over HTTP and HTTPS, in which case detection would be a lot harder. Still, it’s worth looking out for these ports.

Indicators of compromise

This is a partial list of IOCs. The full list is available on our GitHub repository.