Cryptojacking Attacks Continue To Target SSH Servers

TL;DR

Cryptojacking trend continues to motivate attackers -- hijacking systems for mining. Weak authentication SSH attacks are used to gain unauthorised access to systems. Once inside, cryptojacking attacks typically start with reconnaissance to determine suitability for cryptomining. Malicious code is then deployed to mine without consent. Or, for existing mining systems, redirect mined coins to the attacker by altering wallet configurations.

Contents

• Intro
• Credentials
• Shell Commands
• Malware
• Key Takeaways

Intro

Coming up in today's blog post: I'll be exploring recent cyber attacks targeting my SSH honeypots.

Just over 1 month ago I deployed my new SSH honeypots (built in Python, containerised in Docker, see: Secure Honey v2.0 has been launched!). Since then, my honeypots have received 129,122 unauthorised logins (username:password credentials) from 3,780 unique IP addresses. 132,479 (77,214 unique) shell commands have been executed, and 91,927 (64,156 unique) files have been uploaded to the honeypot -- of which 23,874 (53 unique) were malicious.

Excellent, my honeypot's being attacked! So where am I going with all this? Well, since 2018/19, we've known that SSH servers around the world have been targeted by cryptocurrency mining operations (see: Cryptocurrency Mining Operations Take Aim at SSH Servers by eWeek, Miner Bot Targets Devices With Running SSH Service by Trend Micro, and Cryptocurrency-Mining Botnet Spreads via ADB, SSH by Trend Micro).

So I'm curious to analyse my SSH honeypot logs to understand A) if threat actors are still motivated by cryptocurrency, and B) what techniques are used by threat actors.

Let's crack on and explore the data!

Credentials

We start by exploring the credentials (username:password) used by attackers to gain access to my honeypots.

The 5 most frequent passwords are:

The 5 most frequent usernames are:

One of my first observations is that weak passwords are still being used in brute-force authentication attacks. This may suggest that (at least some) target devices are using weak passwords. If, theoretically, we stopped using weak passwords, would attacks change their approach?

My second observation is the username "user" and password "1". These are the default credentials for Hive OS (as stated on their install guide). This suggests that some attacks may be targetting existing cryptocurrency mining platforms (I recently wrote a blog post about Hive OS malware that targetted my honeypots, but we'll get to that).

The 5 most frequent username:password pairs are:

The credentials nproc:nproc stand out here. The command "nproc" basically displays the number of available processing units. It may be that automated attacks are simply spraying the "nproc" command at SSH servers without supplying credentials (hence why it appears in the credentials logs). Either way, it's another sign that threat actors may be motivated by cryptocurrency mining attacks.

This is just a quick and simple analysis of the most common passwords used by attackers to gain access to my honeypots. In a future blog post I might analyse credentials in more detail to explore aspects such as what devices/organisations are being targeted, etc.

The main takeaway from the credentials analysis is that attackers are using weak passwords to brute-force systems via SSH. Therefore, strong passwords are essential to protect against these attacks. Even better, disable passwords altogether and use public key authentication instead.

Shell commands

Now let's explore what attackers do once they're inside my SSH honeypots. From here, an attacker has entered a correct username:password -- I'm pretty lax; I'll accept any username:password. Once inside, the attackers start executing commands...

The top 5 shell commands I've observed on my SSH honeypots are:

Looking through these commands, we see more signs to suggest attackers are motivated by cryptocurrency mining. The commands probe for system resource information (CPU, RAM, cron jobs, etc) -- useful to determine how much mining the system could handle (i.e. its power potential).

Command 'cpuinfo'

Let's explore the most common command:

cat /proc/cpuinfo | grep name | wc -l

Essentially, this command tells the attacker how many CPU (central processing units) the system has. Let's break the command down. /proc/cpuinfo is a short, read-only, plain text file that contains information about the CPUs. cat (short for "concatenate") is a commonly-used Unix utility that displays the contents of a file in the terminal. So cat /proc/cpuinfo displays the contents of /proc/cpuinfo to the attacker.

Next, the command grep is a utility for searching plain text files that match a regular expression. So, grep name searches for the string "name". The vertical bar | is called a pipe. It basically tells the shell that we want the output of the command on the left to be used as input for the command on the right. So cat /proc/cpuinfo | grep name will search the text file /proc/cpuinfo for the string "name". This might output something similar to the following:

model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz
model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz
model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz
model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz

Finally, the command wc (word count) is called with the parameter -l, which prints the number of newline counts (again, everything to the left of pipe | wc -l is used as input for the word count). There are 4 lines in the above output. Therefore, the command cat /proc/cpuinfo | grep name | wc -l prints 4 to terminal (i.e. 4 CPUs).

The attacker now has some useful information about the processing power of our "compromised" system. But the number of CPU units on its own can be meaningless if those CPUs are not very powerful. So, let's look at the second most-frequent command used by attackers:

cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'

This command gives the attacker more specific information about the CPU. We see that the first part of the command is similar to what we saw earlier: cat /proc/cpuinfo | grep name. It might output something like:

model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz
model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz
model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz
model name      : Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz

But this time, the attacker calls head, a utility to display the beginning of a text file or piped data. The parameter -n prints the first n lines. So head -n 1 prints the first line. Finally, the command awk is a bit like grep in that it filters text (see Awk - A Tutorial and Introduction - by Bruce Barnett). The numbers ($4, $5, etc) refer to fields (i.e. columns) of the input line. So the command awk '{print $4,$5,$6,$7,$8,$9;}' will output the 4th, 5th, 6th, 7th, 8th, and 9th columns from cat /proc/cpuinfo | grep name | head -n 1. Which gives us:

Intel(R) Core(TM) i3 CPU M 380

By executing these 2 commands, the attacker knows our CPU model and how many CPU units we have. Excellent reconnaissance for a potential cryptocurrency mining attack. But a system's CPU might be irrelevant if it doesn't have enough memory (or RAM) to handle mining. So let's explore the third most-frequent shell command used by attackers.

Command 'free'

The full shell code is:

free -m | grep Mem | awk '{print $2 ,$3, $4, $5, $6, $7}'

The command free provides information about the total amount of physical and swap memory available, as well as the free and used memory. The parameter -m displays the output in mebibytes (MiB, see: What is mebibyte (MiB)?). The output from free -m might be:

              total        used        free      shared  buff/cache   available
Mem:           3745         863         599          30        2282        2616
Swap:          1949         284        1665

The shell command filters by string "Mem" and prints the 2nd, 3rd, 4th, 5th, 6th, and 7th columns: free -m | grep Mem | awk '{print $2 ,$3, $4, $5, $6, $7}'. Which prints the following to terminal:

3745 863 599 30 2282 2616

In other words, the attacker has discovered that my system has 3,745 MiB total ram and that 2,616 MiB is available.

The attacker's reconnaissance now includes key CPU and memory information. Useful for deciding if the target system would make for a good miner.

Malware

Now we get to the juicy stuff! Let's explore what sort of malicious files have been uploaded to the honeypot. I won't dissect malware in this blog post -- since it's a lengthy process which needs its own write-up. I'll save that for another time. So for this, I use VirusTotal's API for Malware analysis. I've provided links for all the VirusTotal scans below so you can explore them.

First, let's explore the most frequently uploaded malicious files by unique IP addresses:

We're seeing some malicious coin miners here. Some of these files were first detected by VirusTotal in March 2021. Now, lets order the same data but this time by number of total uploads:

* The same IP address uploaded both malicious files: fe794147d4c68b9e36e744a98fdeb704dec88a8258a41102a96c4b5dfecb1174 and fd7151c8373889941f304f160d352aa20bf8e8ee7b58c449f879884b9131354d.

An interesting observation, when sorting by total number of uploads, is how repeated attempts to upload malware to my honeypot can sometimes come from a small number of IPs. For example, the malware in the first row of the table was uploaded to my honeypot 12,855 times between 30th June and 11th July 2021 -- all from a single IP address.

We see many instances of the MiraiA malware. First discovered in 2016, MiraiA malware turns networked devices running Linux into remotely controlled bots that form a botnet. The MiraiA botnets have been used to carry out large scale distributed denial-of-service (DDoS) attacks (see Mirai Botnet). Devices infected with MiraiA continuously scan the web for Internet of Things (IoT) devices, using common credentials to gain access. MiraiA has since evolved to carry out cryptomining attacks (see Next-gen Mirai botnet targets cryptocurrency mining operations).

Some of these malware files also appear to be variants of a Goland worm that runs XMRig Miner (a popular, open-source miner software) at a large scale (see Early Bird Catches the Worm: New Golang Worm Drops XMRig Miner on Servers).

I also recently discovered malware that targets existing cryptocurrency miners running Hive OS (a popular mining management platform). The malware changes the wallet configuration of Hive OS so the attacker receives all mined coins. Changing the config file back doesn't stop the attack, since the malware regularly updates the file (see: Sneaky Malware Reconfigures Hive OS Wallet for Profit).

We see the trend of cryptocurrency mining continue in the types of malware uploaded to my honeypot. Suggesting that, after reconnaissance (using shell commands we saw in the previous section) threat actors infect their chosen victims with lucrative cryptojacking malware. Filling the attacker's cryptocurrency wallets to the brim.

Key Takeaways

So, what have we learnt today? Threat actors continue to attack SSH servers, motivated by cryptocurrency riches. Attack techniques start with brute-force SSH authentication, typically relying on weak credentials. Once inside, threat actors carry out reconnaissance to determine suitability for cryptomining. Finally, attackers leverage a seemingly endless arsenal of malware; to carry out cryptojacking and other cyber attacks.

Strong passwords are essential to protect against these weak authentication SSH attacks. For increased security, disable password authentication altogether on SSH servers, and use public key authentication instead.

With the volatile nature of cryptocurrency, SSH-targeted cryptojacking may, eventually, fizzle out. But, for now at least, this trend continues to thrive.

Main image credit: A Bitcoin covered in black crystals. by Executium.

About the author

Simon Bell is an award-winning Cyber Security Researcher, Software Engineer, and Web Security Specialist. Simon's research papers have been published internationally, and his findings have featured in Ars Technica, The Hacker News, PC World, among others. He founded Secure Honey, an open-source honeypot and threat intelligence project, in 2013. He has a PhD in Cyber Security from Royal Holloway's world-leading Information Security Group.

Follow Simon on Twitter: @SimonByte