Possible Vulnerability in Vesta and Treatment for Trojan.DDoS_XOR
This post outlines a vulnerability affecting the Vesta control panel and provides steps to treat the Trojan.DDoS_XOR malware in compromised servers.
Possible Vulnerability in Vesta and Treatment for Trojan.DDoS_XOR
In recent days, there have been reports of server breaches where the Vesta control panel is installed. Below, we will describe how to check your server, how to protect it, and what to do if your VDS or dedicated server is compromised.
As of the writing of this note, the main source of information and discussion is the VestaCP forum. We recommend referring to the original source for updates.
What is known at the moment?
Automated breaches have been occurring since the end of March, affecting various operating systems (CentOS, Debian, Ubuntu of different versions). After gaining access to the operating system, the malicious complex Trojan.DDoS_XOR was loaded and executed. For details on this malware family, see the CheckPoint document. The breaches are not related to your passwords, CMS, or configurations—breaches have been recorded on virtual servers where no websites were hosted, only the Vesta control panel was installed in its standard configuration.
In brief, this malware complex is used for DDoS attacks on remote nodes. Upon command from the command and control center (C&C), the attack (SYN flood, UDP flood, etc.) is directed at the IP address obtained from the management center. Since all available resources are utilized during such an attack, the sender’s IP address (the infected server or VDS) can be easily and often automatically identified and blocked by either the service provider or the telecommunications operator.
Thus, if your server or VDS has been inaccessible for some time (or has generated unusually high traffic) in the past 2-3 days and you are using Vesta, it is highly likely that your system is infected. We strongly recommend all users of Vesta check their operating systems.
How to determine if the system has been compromised?
Log in via SSH and execute the command:
find /etc -name gcc.sh -print
If the result of the command returns /etc/cron.hourly/gcc.sh, then you have a trojan code loaded on your server or VDS. There’s no need to panic—removing the trojan is quite simple. You can do it yourself or contact your provider’s support or your system administrator.
The most important thing is to take your time, stay calm, and make a backup of your data and settings. The backup should be kept separate from your websites—on another VDS, on a network storage, on Dropbox, Google Drive, etc.
Steps to Remove the Trojan
-
Block
gcc.sh:chmod 0 /etc/cron.hourly/gcc.sh; chattr +ia /etc/cron.hourly/gcc.sh; chattr +i /etc/crontab -
Find the trojan running in memory. Use the following to identify the first variant:
lsof -n | grep /tmp/update -
If you see a process ID, stop it:
kill -STOP [Process_ID] -
Remove the file:
rm /tmp/update -
Now kill the process:
kill -9 [Process_ID] -
Check with lsof to ensure that no malicious code remains.
-
Remove other identified malicious files:
rm /etc/init.d/update rm /lib/libudev.so -
Check for suspicious files in
/usr/bin:ls -lt /usr/bin | head -20 -
If similar files are found, use a script to stop and remove them based on size:
kill -STOP \`lsof -n | egrep "625622|625633" | grep -v deleted | awk '{print $2}' | uniq\`Followed by:
kill -9 \`lsof -n | egrep "625622|625633" | awk '{print $2}' | uniq\` -
Finally, run a scan with ClamAV:
clamscan -r -i /Pay attention to the Infected Files count.
How to protect against such situations
- Update your software regularly.
- Restrict access to the control panel and service applications (FTP, webmail) to trusted IPs only.
- Use a VPN for access from various locations.
- Always maintain backups.
Need Help?
Our support team is available 24/7 to assist you with any questions or issues.
Contact Support