Akamai Diversity

Akamai Security Intelligence & Threat Research

A Cryptomining SSH Worm

Recently, I noticed an interesting cryptomining script in my honeypot. It had all the usual checks for CPU and architecture type before downloading a binary. It even had the usual kill any processes that might be other cryptominers. However, what caught my eye was a one-line shell script that searched through .ssh/known_hosts and .ssh/id_pub.pub keys, in an attempt to infect other systems that might share SSH keys with the infected host. It's an interesting twist to cryptomining attacks because the pivoting attempted by this worm is the same process an attacker would use to navigate the network.  

In this post, I'll go through each phase of the script for those of you who may not be familiar with typical Linux OS malware tactics.

 

First, as I mentioned, the downloaded script checks the system's CPU type and architecture after overwriting resolv.conf with Google's 8.8.8.8 DNS server. Based on the architecture type, it downloads either binary x86/bash, arm/bash, or aarch64 bash, and sets the binaries' permissions for execution before executing them, and then executes it. After, it downloads three more scripts named 0, 1, 2 - in that order.

 

 

Script 0 is a cleaner script. It removes backdoor user accounts and kills a list of known cryptominer processes. It also adds an account named "0" with root privileges to the system.

 

 

 

 

Script 0 also adds null DNS routes in /etc/host for known cryptomining pools. 



Using the chattr command, the script will set the immutable bit to /etc/hosts in an attempt to thwart further changes.

 

Script 1 looks at the root's .ssh directory to go through the known_hosts files for other targets to attack while checking to see if any SSH keys are stored there as well.

 

 

If any SSH keys are found, the initial infection script i.sh is copied to the new target and executed. Script 2 is the same as above, but checks the .ssh directories in /home/*/.ssh instead of /root. This exploits any keys lacking passphrases the user might have.

 

The primary payload is the cryptomining software. Once executed, the software creates a directory in /root/.tmp00 to store its configuration files and a copy of itself along with the XMRig v2.14.1 binary.

 

 

The configuration is base64 encoded in an attempt to obscure the cryptominer's details. 

Decoded we have:

{ "algo": "cryptonight",

"autosave": false,

"background": false,

"colors": true,

"retries": 5,

"retry-pause": 5,

"syslog": false,

"print-time": 60,

"av": 0,

"safe": false,

"cpu-priority": null,

"cpu-affinity": null,

"donate-level": 0,

"threads": 1,

"pools": [

{

"url": "[REDACTED]",

"user": "[REDACTED]437c24b6ce44",

"pass": "x",

"keepalive": true,

"nicehash": false,

"variant": "r",

"tls": false,

"tls-fingerprint": null

}

],

"api": {

"port": 0,

"access-token": null,

"worker-id": null

}

While the malware is actively running, it ensures an entry for itself is in root's crontab:

Any attempt to edit or remove the entry will result in a new entry appearing at the top of the crontab. The only way to remove the crontab entry is to kill the running malware process first.

 

Conclusion

Criminals will use any means they can to spread malware. In this case, they're using well-known features of common command-line utilities. The malware targeting my honeypot relied on known passwords, similar to how Mirai takes from a list of documented default passwords rather than exploiting a vulnerability in the target server, in addition to targeting SSH keys with no passphrase. This attack propagates and survives on administrator error alone. Attacks like this are prevented by using strong passwords, two-factor authentication, and a user policy enforcing strong passwords on all SSH keys.

Leave a comment