Ebury

command : curl -s https://ssp.cpanel.net/ssp | perl

cPanel support team update : It appears that your server has been root-level compromised with the following high-level security issue, and there is a significant chance that the compromise is related to why WHM and upcp are failing: [17:06:29 hybrid9 root@8346023 ~]cPs# stat /lib64/tls/libkeyutils.so.1{,.5} File: `/lib64/tls/libkeyutils.so.1' -> `libkeyutils.so.1.5' Size: 18 Blocks: 0 IO Block: 4096 symbolic link Device: fd00h/64768d Inode: 2230071 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-03-30 23:51:01.623913293 +0100 Modify: 2014-10-15 12:08:05.000000000 +0100 Change: 2016-01-11 22:43:58.710918033 +0000 File: `/lib64/tls/libkeyutils.so.1.5' Size: 40960 Blocks: 80 IO Block: 4096 regular file Device: fd00h/64768d Inode: 2242430 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-03-31 03:53:01.129997084 +0100 Modify: 2014-10-15 12:08:05.000000000 +0100 Change: 2016-05-26 03:44:41.112998325 +0100 [17:06:43 hybrid9 root@8346023 ~]cPs# sha256sum /lib64/tls/libkeyutils.so.1.5 01a16bcdff7e577cee4e2977f013e74db40addb6ac8479caf87b532669db44d7 /lib64/tls/libkeyutils.so.1.5 The SHA-256 value above matches the following VirusTotal scan which confirms the presence of the Ebury malware: https://virustotal.com/en/file/01a16bcdff7e577cee4e2977f013e74db40addb6ac8479caf87b532669db44d7/analysis/ There are some security discussions online that can provide checks we've used to determine your machine has been exploited: http://go.cpanel.net/checkyourserver https://www.cert-bund.de/ebury-faq http://reverse.put.as/2014/02/05/linuxhackingteamrdorks-a-a-new-and-improved-version-of-linuxcdorked-a/ Additionally, a detailed write up can be found here: http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.pdf The only actions that can be considered to reasonably address a root compromised server are to either perform a fresh Operating System and WHM/cPanel installation, or to migrate the accounts to a known clean server that hasn't been previously root compromised. For more information about why a server cannot be "cleaned" please review our documentation located here: http://go.cpanel.net/cantcleanhackedserver Because this server has been confirmed root compromised, we essentially can no longer trust the integrity of the server. Even if the identified symptom(s) have been removed from the server, this isn't enough to be confident in the server again. There could be modified binaries, back-doors, or a multitude of other actions taken with the server that make it dangerous to work on. Commands that are otherwise innocent may turn out to cause damage to the server up to and including data loss. Until the server can be brought into a state in which we're confident in the integrity of the server, our scope of support will be limited to assisting with questions and guidance that does not require us to login to the server. As mentioned, we view anybody at all logging into a compromised server as a risk to server health and integrity that's only worth risking if attempting to reload/migrate the server. After we are able to confirm that a fresh installation or migration of accounts to another server has been completed, then we feel reasonable action has been taken to address the root compromise and we can resume normal support to the server. If you would like cPanel staff to perform the server migration for you, please let us know so that we can get you started with one of our Migration Specialists. To migrate for you, we request that you set up a second server with at least a base CentOS/RHEL installation and sufficient server resources to accommodate your current server's accounts and usage. We will perform the cPanel install as well as migrate all accounts for you to the new, clean server. Given the nature of the payload involved in this compromise, it is important to understand that, at a minimum, all root authentication information has been compromised. If your server's root password, wheel user password, and/or SSH keys are in use on any other system you should change them immediately. Those passwords and keys should be considered unusable and no longer set for any future logins. Do *not* use them on the new server to which you migrate. All user account login details are also at risk and should be changed once migrated or restored from backups. Additionally, please do not SSH, SCP or perform any actions on the source machine to log into or copy files to the destination machine. The method used for this type of compromise allows any activity from the source to the destination that is based on SSH activity to infect the new destination server. All actions to copy files or otherwise should be performed from the destination machine only. If you have any questions on this portion, please let us know and we would be happy to explain further.