Lately, our support staff has been seeing a large amount of servers compromised at the root level by a very sneaky and dastardly SSH Rootkit. Throughout the past two years, various hosting companies, security researchers, and other concerned parties have been steadily compiling more and more information about the rootkit and its related tools. As more research has been done, the full scope of the infections has turned out to be quite large. The SSH Rootkit has allowed its operators to essentially run multiple spam and other cyber-criminal operations virtually undetected.
Security researchers have dubbed the rootkit â€˜Eburyâ€™, and security group ESET (proud makers of our Windows antivirus of choice, NOD32) have recently published a blog article and full white paper on Ebury and its related tools, which they have dubbed â€˜Operation Windigoâ€™, an apt name, as it is taken from from an Algonquin legend of a half-demonic beast that can â€˜infectâ€™ and transform humans into other Windigos through cannibalism.
The white paper is a good read as it is literally a full analysis of the rootkit and all tools dependent on it. The most surprising thing to us is how it spreads. Since the rootkit infects the SSH server and client, any time someone logs into another server from the infected one, either the password or the key is transmitted to a remote exfiltration server, and then twice a day, the logins are tried. If they work, the rootkit and its tools are immediately deployed.
The easiest way to check for the detection is due to how the infected SSH rootkit works. The infected SSH client binary has an additional flag (-G) the attackers can pass to collect info from the rootkit, like passwords for example or command history. On a clean server, that flag is not valid, and running the command would return a normal usage statement. If you donâ€™t get any output from the -G flag, this means the server is infected.
What should you do if your server or VM is infected?
- DO backup everything immediately
- DONâ€™T login to other linux servers, especially with root credentials or a user with sudo access
- DO request an OS reload when your backup is finished and you are ready to restore. If you have server management, our techs can assist you with backup/restore if needed.