Analyzing a malicious Raspberry Pi Bash script

Poison Dwarf

© Lead Image © Nelli Valova,

© Lead Image © Nelli Valova,

Article from Issue 224/2019

Analyze malware on hacked Raspberry Pis and create a signature to detect malware in log entries.

Raspberry Pis are being used more often by universities and scientific institutions, as well as for business computing. The small computers are often configured openly for easier usability, which means Rasp Pi users often execute every command with sudo without knowing the root password.

By default, the root has no password, but even if one were set, it does not have to be entered with sudo; therefore, the only difference between root and the pi user is that pi has to type sudo. In a learning environment for which the Raspberry Pi was designed, this is acceptable. In production use – especially when the computer can be accessed from the Internet – it is downright dangerous.

If you operate the Raspberry Pi without a monitor or keyboard (headless), you absolutely need SSH access. Although normally disabled, it is very easy to activate. If you do not change the default password of the pi user, then the computer is freely accessible over SSH. If it also turns out that the Raspberry Pi can be accessed through a firewall configuration that is too liberal or by way of port forwarding on the DSL router with an official IP address using port 22, you can expect someone to hack this computer. I had the opportunity to examine two such compromised Raspberry Pis.

Forensic Analysis

The microSD card (typically 16GB) used as the data carrier (hereafter called the "hard drive") is easy to save 1:1 as a zipped file via file sharing services for further analysis. In the two cases examined, the hackers had installed identical malware in the form of a shell script, which made the analysis relatively easy.

The aim was to find the indicators of compromise (see the "Indicators of Compromise" box), which are characteristics that can be used to determine whether another Raspberry Pi is infected. Additionally, it was essential to find a signature with which it should be possible to search logfiles for script activity.

Indicators of Compromise

I was able to identify the Raspberry Pi malware on the basis of a number of properties:

  • The /etc/hosts file contained an entry for
  • The /etc/rc.local file had the content
#!/bin/sh -e
    exit 0

where $NEWMYSELF was a random string of eight alphanumerical characters.

  • The /tmp/.s file contained a date.
  • The /opt/.r file contained one or multiple IP addresses.
  • The password hash for the pi user had the value:
  • The /root/.ssh/authorized_keys file contained the following public entry:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCl0kIN33IJISIufmqpqg54D6s4J0L7XV2kep0rNzgY1S1IdE8HDef7z1ipBVuGTygGsq+x4yVnxveGshVP48YmicQHJMCIljmn6Po0RMC48qihm/9ytoEYtkKkeiTR02c6DyIcDnX3QdlSmEqPqSNRQ/XDgM7qIB/VpYtAhK/7DoE8pqdoFNBU5+JlqeWYpsMO+qkHugKA5U22wEGs8xG2XyyDtrBcw10xz+M7U8Vpt0tEadeV973tXNNNpUgYGIFEsrDEAjbMkEsUw+iQmXg37EusEFjCVjBySGH3F+EQtwin3YmxbB9HRMzOIzNnXwCFaYU5JjTNnzylUBp/XB6B
  • The /tmp/public.pem keyfile had the content:
    MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/ihTe2DLmG9huBi9DsCJ90MJsglv7y530TWw2UqNtKjPPA1QXvNsWdiLpTzyvk8mv6ObWBF8hHzvyhJGCadl0v3HWrXneU1DK+7iLRnkI4PRYYbdfwp92nRza00JUR7P4pghG5SnRK+R/579vIiy+1oAFWRq+Z8HYMvPlgSRA3wIDAQAB    -----END PUBLIC KEY-----

When examining the infected Raspberry Pi hard drive, a Bash script in the /opt directory quickly caught my eye. An analysis of the script showed it was malware, basically structured as shown in Figure 1.

Figure 1: Schematic flow of the Rasp Pi malware shell script.

The script (Listing 1), which still contains rudimentary debug code (e.g., lines 4, 5, and 18), can be found on your own infected Raspberry Pi or on the Internet in various blog posts [1]. The production version redirects the output of the various print commands to /dev/null.

Listing 1

Malware Script


First Steps

The script first checks to see whether it is running with root privileges (line 7); if not, it copies itself under a random name to the /opt directory, configures this file to start automatically in /etc/rc.local (lines 9-13), and reboots the computer (line 15). With an openly configured sudo system, as on the Rasp Pi, creating a script that executes with root privileges at startup is no problem, proving once again that this configuration is unsuitable for computers accessible from the Internet.

The script then tries to stop any competitors (lines 20-35). The similarity to the Raspberry Pi-specific malware named Linux.MulDrop.14 [2], first described on the Dr.Web site in spring 2017, is apparent. The code of the malware discussed here [3] contains a miner for cryptocurrencies instead of the IRC backdoor.

The processes terminated by the script include mining (minerd) and DDoS software (kaiten, ktx-*), as well as regular programs (node, nodejs, zmap, perl). If you compare a fragment of this script with Linux.MulDrop.14, you will notice that lines 2--33 and 37-39 are identical in both scripts. What purpose the server serves is unclear. At the beginning of December 2018, the name belonged to an IP address in the Amazon Web Services EC2 area. However, this server did not have any obviously open ports.

The Backdoors

In line 41, the password of the pi user is changed with a SHA512 password hash, so no one can read the password in the source code. From this point on, the regular user is locked out because only the attacker knows the password for the pi account. This is the first backdoor that can be exploited as long as the computer remains accessible over the Internet.

The initial assumption is that this password hash is generated from the password raspberryraspberry993311 (see line 142). However, this assumption is wrong. With the small Python program in Listing 2, you can calculate the hash of a password for a given salt. The password hash for the assumed password with the salt from line 41 (Listing 1) would result in:

Listing 2

Computing the Password Hash



To determine the password for the hash from line 41, an analyst would need to launch a brute force attack on the SHA512 hash. Assuming an identical complexity as for the password raspberryraspberry993311, comprising 24 lowercase letters and digits (i.e., 36 possible characters), the password combinations to be searched would be:

With the password-cracking program Hashcat [4] and eight Tesla GPUs, 10^10 hashes per second are possible, calculated optimistically. For example, a system like the Sagitta Brutalis with eight Nvidia GTX 1080 Founders Edition GPUs achieved 8.4 x 10^9 SHA512 hashes per second [5]. In the worst case, this would take about 4.2 x 10^19 years to crack.

In Linux.MulDrop.14, you also find the line:

usermod -p \$6\$U1Nu9qCp\$FhPuo8s5PsQlH6lwUdTwFcAUPNzmr0pWCdNJj.p6l4Mzi8S867YLmc7BspmEH95POvxPQ3PzP029yT1L3yi6K1 pi

The effort needed to crack this hash is the same as that needed for the previous hash. However, a simple test with the Python program from Listing 2 shows that this is the SHA512 hash of the password raspberryraspberry993311. Assuming the author of the current malware did not crack this hash, he must have known it – an indication that both scripts were written by the same author.

The script then enters an additional SSH key in the file /root/.ssh/authorized_keys so that the virus author can log in as root via SSH at any time using certificate-based authentication (Listing 1, lines 43-44). This is a second backdoor the hacker can use if the legitimate user manages to reset the password for the pi account.

The script designates the Google server as its name server (line 46) and cleans up again (lines 47-49). Furthermore, a public RSA key is stored in /tmp/public.pem (lines 51-54). The IRC bot needs this key to verify signatures. The bot script then starts in line 123; all traces, including the script, are deleted immediately (lines 124-127). The script then only runs in the memory of the Raspberry Pi and creates the /tmp/bot.log logfile. The bot script would thus not survive a reboot, but because the script restarts on every boot, the bot script also runs every time.

An analysis of the /tmp/bot.log logfile showed no signs of successful bot communication on either of the Rasp Pis. The file contains only the output of line 77 of the bot script (i.e., the nickname and various error messages).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More