Linux Under Attack

There is no such thing as software without vulnerabilities, so it follows that Linux, while in some ways more secure than alternatives like windows, is nonetheless vulnerable to attack. Until recently Linux was to some degree protected by “Security Through Obscurity”, which is to say that as a fringe OS it was not worth investing much effort into attacking it. But things have changed. Linux is winning the data center, the Cloud, and the Desktop. Consider the data:

So, there is no longer anything obscure about Linux, and we should expect to see attacks against it and vulnerabilities being exploited, and indeed we do.

There’s still a dangerous assumption among many that malware is only a problem for Windows. That might have been more believable a decade or two ago. But the reality is that any computer system that builds up significant market share or plays host to valuable data will now be a target. Linux is increasingly the foundation of many different business systems and vast parts of the cloud. While there are still relatively few threats targeting Linux, there’s no reason why that should remain the case.

The most serious attacks are against Linux servers, of course, because Linux is so dominant in the Cloud. Here are some of the recent malware attacks on Linux.


SSH stands for Secure Shell, and it is the more secure replacement for the terribly insecure telnet. It is a way for computers to talk to each other, and we discussed it previously in SSH Introduction and following. Open SSH is the open source implementation of this protocol, and is the de facto standard on all Linux distros. The ability to breach SSH gives you access to the server, and potentially to anything on the server. That makes Open SSH a prime candidate for attacks.

One of the early attacks was discovered by researchers at ESET. They helped to disrupt a botnet of 25,000 servers that were infected with an OpenSSH-based backdoor and credential stealer named Ebury In March, 2017, Maxim Senakh, a Russian, pled guilty for his role in the creation of the Ebury malware and for maintaining its infamous botnet, though he was just one member of the group. This malware included a rootkit to persist through reboots and a backdoor to give the criminals access. And once they got in, they started stealing credentials, and then used the botnet for things like traffic redirects and email spam. Then Donald Austin from Florida installed the malware on the servers.

One result of this is that ESET researchers started to systematically look for OpenSSH vulnerabilities, and when they looked, they found more. One of the first clues that they would find things is that the Ebury software would do a check for other SSH malware installs before it installed itself. Their search revealed an entire ecosystem that included 12 new families of malware not previously documented. For a more detailed look at all of these vulnerabilities, take a look at a Research White Paper from ESET called The Dark Side of the ForSSHe.

Interestingly, there are some common features to all of the malware that they studied, despite the fact that each one was on a different code base. They all had hard-coded credentials to enable backdoor access, and mechanisms to steal credentials. And when the credentials were stolen, they were always stored locally in a file. If that were all, the criminals would have to then log in using their backdoor credentials and exfiltrate the file in some way. But some of the malware had provisions to push the file out through the network:

“Interestingly, those backdoors were also the most complex ones; not one was based on publicly-available source code,” the researchers found. “Exfiltration techniques for stolen SSH credentials are creative and include SMTP (mail sent to malicious operator), HTTP, DNS, and even custom protocols using TCP and UDP.”

Finally, the best protection against these attacks is to not rely on passwords to authenticate SSH logins. Things like Two-Factor Authentication and Encryption Keys provide much higher security. And you should always disable SSH logins for the root account. Instead, create a user with admin privileges whose user name is not easily guessed by an attacker.


This software appears to be the work of the Russian hacker group APT28, a group operating from the Russian GRU. It is a multi-component piece of malware targeting Linux systems

Drovorub is a Linux malware toolset consisting of an implant coupled with a kernel module rootkit, a file transfer and port forwarding tool, and a command and control (C2) server. When deployed on a victim machine, Drovorub provides the capability for direct communications with actor-controlled C2 infrastructure; file download and upload capabilities; execution of arbitrary commands; port forwarding of network traffic to other hosts on the network; and implements hiding techniques to evade detection.

The rootkit capabilities allow it to not only evade detection, but to survive through system restarts and many anti-malware measures. We know it is from this Russian source because they reused a Command and Control server identified in previous APT28 operations. The precise target is not known right now, but could be anything from industrial espionage to election interference. But there is detailed guidance on remediation measures in a PDF from the NSA and FBI.

“Drovorub is a ‘swiss-army knife’ of capabilities that allows the attacker to perform many different functions, such as stealing files and remote controlling the victim’s computer,” McAfee CTO, Steve Grobman, told ZDNet in an email today.

“In addition to Drovorub’s multiple capabilities, it is designed for stealth by utilizing advanced ‘rootkit’ technologies that make detection difficult,” the McAfee exec added. “The element of stealth allows the operatives to implant the malware in many different types of targets, enabling an attack at any time.”

Lucifer DDoS

This malware is a cryptojacking and DDoS attack that originally attacked vulnerabilities in software such as Rejetto HTTP File Server, Jenkins, Oracle Weblogic, Drupal, Apache Struts, Laravel, and Windows. The list of targets is fairly long, but now we can add Linux to that list.

“The fact that it can run on Linux-based systems means that it can potentially compromise and make use of high-performance, high-bandwidth servers in internet data centers (IDCs), with each node packing a larger punch in terms of DDoS attack capacity than is typical of most bots running on Windows or IoT-based Linux devices,” the NETSCOUT researchers explained.

Lemon Duck

Lemon Duck is another ssh attack malware. It scans the Internet for machines listening to port 22 for logins, then launches a brute force attack using the username “root” (see above), then uses a list of passwords to try. If it gets in to a system, it employs all of the usual tricks, such as running cron jobs to aid persistence and scanning for other Linux systems by taking login data from the /.ssh/known_hosts file.


FritzFrog is still another ssh attacker, with the wrinkle that it is based on a peer-to-peer network, rather than a Command and Control server network. It is basically a combination of a botnet and a cryptominer. It looks for ports 22 and 2222, and if it gets in it adds its own ssh public key to the authorized_keys file.

Bottom Line

Does this mean Linux is not more secure? Not exactly. Linux certainly can be more secure because the code is open and can be fixed by anyone. The idea that trying to keep code secret breeds security has been thoroughly disproven by the many attacks on proprietary systems. The bad guys will find the vulnerabilities, it is only the researchers that are hampered. But in reading the accounts of many of these attacks I was struck by often I heard something like “This vulnerability was patched, but…” or “This attacks older versions of…” It does no good to create patches if sysadmins don’t apply them. I personally apply all patches as soon as I get them on my home network. There is a chance that a patch might cause a problem (though I cannot think of an occasion where that happened to me), but not applying the patches makes me subject to a known vulnerability. In a corporate data center the appropriate procedure would be to install the patches on a test server right away and run the appropriate tests with an aim of installing the patches as soon as possible on your production servers.

Next, we mentioned not giving the root account ssh login capabilities. This is only one case of the general principle of disabling default logins. Particularly in this time when so many devices are network-connected (even when there is no compelling reason to be), you don’t want to have the default “admin” account enabled. There are actually botnets of lightbulbs now because of hardcoded login accounts. This one change reduces your attack surface, and while it may not guarantee you won’t be attacked, it reduces your chances. Many of these malware attacks are just looking for easy pickings, and if your machine is not the easy one, they will just move on to other machines.

Finally, a lot of these attacks leverage problems with ssh. If you are a sysadmin, learn how to use ssh safely. I will recommend a book by a friend of mine, Michael W. Lucas, who just released the second edition of his SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys. I think this is the best book out there.

Listen to the audio version of this post on Hacker Public Radio!

 Save as PDF