Ebury SSH Rootkit - Frequently Asked Questions

Version 1.11 (2014-09-01)


You are probably visiting this website because you received notification from your ISP or hosting provider that a system you are responsible for has been found to be infected with the Ebury SSH rootkit/backdoor trojan. If that is the case, please read this FAQ carefully as it will provide you with details on the malware and how to verify your system is infected.

We are receiving lots of feedback from system administrators telling us they checked the systems we had reported to be infected with Ebury and found them to be clean, so our report must be a false alarm. However, after additional deeper analysis of the systems by the administrators all infections could be confirmed. So far we are not aware of any false positives.



In February 2013, CERT-Bund started analyzing Ebury in depth and was able to identify thousands of systems around the world infected with the malware. Subsequently, an international Working group was formed. In a joint research effort with ESET, the Swedish National Infrastructure for Computing and the European Organization for Nuclear Research (CERN), and with kind support from CERTs and hosting providers in several countries, many thousand additional systems infected with Ebury could be identified.
Since February 2013, hosting providers and national CERTs in more than 60 countries have been notified of infected machines hosted on networks within their responsibility.
About one-third of the systems that were found to be infected are hosted in the US, another ten percent in Germany. Other countries with large numbers of infections include France, Italy, Great Britain, Netherlands, Russian Federation, Ukraine, Mexico and Canada.

What is Ebury?

Ebury is a SSH rootkit/backdoor trojan for Linux and Unix-style operating systems (like FreeBSD or Solaris). It is installed by attackers on root-level compromised hosts by either replacing SSH related binaries (ssh, sshd, ssh-add, etc.) or modifying a shared library used by SSH (libkeyutils).

On infected hosts, Ebury steals SSH login credentials (username/password) from incoming and outgoing SSH connections. The harvested credentials are sent to dropzone servers controlled by the attackers using specially crafted DNS-like packets. Additionally, SSH private keys stored on the compromised system for use with outgoing SSH connections are stolen by the attackers.

Ebury provides a backdoor the attackers can use to get a remote root shell on infected hosts even if passwords for user accounts are changed on a regular basis.

Why do you think my system is infected with Ebury?

Login credentials harvested by Ebury from SSH connections from/to your system were seen being sent to a dropzone server for the malware. Corresponding timestamps have been included in our reports to ISPs, hosting providers and national CERTs.

What do the attackers use compromised systems like mine for?

The compromised systems are used for various criminal activities, such as sending massive amounts of spam, redirecting visitors of compromised websites to drive-by-exploits or running nameservers for malicious domains. See [3] for details.

Equipped with root-level privileges, the attackers can take full control of your machine and are able to access, delete or alter any kind of data processed or stored on the system. For example, if the compromised system is running a web shop the attackers might gain access to sensitive information like personal customer data or credit card numbers.

How can I verify my system is infected with Ebury?

This section provides indicators of compromise (IOCs) for different versions of the Ebury malware.

Ebury versions < 1.5

Ebury versions prior to 1.5 use shared memory segments (SHMs) for interprocess communication. A list of currently existing SHMs can be obtained by running the command 'ipcs -m' as root. Prior to version 1.3.5, the malicious segments have a size of at least 3 megabytes and broad permissions (666) set. Example:

# ipcs -m
------ Shared Memory Segments --------
key        shmid      owner     perms      bytes      nattch
0x000006e0 65538      root      666        3283128    0

Please note that the SHMs are only created on the first event of data exfiltration – so immediately after a reboot of the system, the malicious SHMs will probably not show up in the output of 'ipcs -m'.

There are of course also legitimate applications making use of SHMs, so the presence of a SHM like shown above on any system must not necessarily mean it is infected. However, if you received notification from your ISP or hosting provider that your system has been found to be infected, the SHM most likely has been created by Ebury. If in doubt, we recommend looking for the malicious libkeyutils file or inspecting your network traffic to double-check (see below).

With Ebury version 1.3.5, the malware authors changed the permissions of the SHM to be more strict (600). Also, the size of the segment is significantly smaller. Example:

# ipcs -m
------ Shared Memory Segments --------
key        shmid      owner     perms      bytes      nattch
0x0000091a     0      root      600        463084     0

So starting with version 1.3.5, the SHMs created by Ebury are no longer easy to spot.

Replacement of the shared library 'libkeyutils' can be identified by looking at the file size. Legitimate versions of the library usually are less than 15 kilobytes in size, while the malicious ones are larger than 25 kilobytes. To check the file size, run the following command:

# find /lib* -type f -name libkeyutils.so* -exec ls -la {} \;

Depending on how the attackers installed the malicious library, you will see one or more files in the output. If any file is larger than 25 kilobytes in size, it is most probably a malicious version of the library. Example:

-rwxr-xr-x 1 root root 35136 Jun 22  2012 /lib64/libkeyutils.so.1.3

For the SSH binaries, identifying malicious replacements based on file sizes is not easily possible as file sizes vary strongly with different Linux distributions and other operating systems.

Ebury version 1.5

On Linux-based systems, an additional shared library file 'libns2.so' is installed and the existing libkeyutils file is patched to link against this library instead of libc6. The malicious 'libns2.so' file can be located by running the following command, which should not return any results on clean systems.

# find /lib* -type f -name libns2.so

Ebury now uses Unix domain sockets instead of shared memory segments for interprocess communication. The malicious socket can be located using 'netstat' as follows. Again, this command should not return any results on clean systems.

# netstat -nap | grep "@/proc/udevd"
unix  2      [ ACC ]     STREAM     LISTENING     5597     2529/atd     @/proc/udevd

Replacing the SSH binaries or modifying the shared library requires root privileges. How did the attackers initially obtain root privileges on my system?

There are several scenarios that have been identified so far:

  • Login credentials for a user account with root privileges on the affected system were stolen when administrators logged in using SSH from a machine already infected with Ebury. The login credentials were then harvested from the outgoing SSH connection on the infected machine.
  • Login credentials for a user account with root privileges were stolen on Windows machines infected with an infostealer/keylogger malware when administrators logged in to the affected system using tools like PuTTY.
  • The network of cPanel Inc.'s support department was compromised and machines used for connecting to customers' servers were found to be infected with Ebury [4].
  • Some affected systems analyzed had been compromised by exploiting vulnerabilities in outdated software packages which led to the attackers gaining root privileges.

Do antivirus products or other security tools detect Ebury?

Some antivirus products are capable of detecting Ebury, usually as 'SSHDoor' or 'Sshdkit'. However, ClamAV or tools like chkrootkit or rkhunter currently do not detect Ebury.

Can I use tools like debsums or rpm to verify the integrity of the SSH related files on my system?

No, this is not reliable!

Depending on the version of Ebury and the way the attackers installed the malware, tools like debsums or rpm will not be able to detect the malicious files.

How does the backdoor work?

The backdoor can be used to obtain a remote root shell on the infected system. It is triggered by connecting to the trojanized SSH daemon in a specific way. There are no processes listening on additional network ports.

Please note that the backdoor connections do not show up in any logfiles!

Ok, my system is infected with Ebury. What do you recommend me to do now?

If your system is infected with Ebury, it has been root-level compromised and can no longer be trusted. The attackers have probably changed security-related system settings or installed additional malware. Therefore we highly recommend re-installing the operating system instead of trying to clean it up.

All login credentials used with SSH connections from or to an infected machine as well as private SSH keys stored on the host must be considered compromised. Please note that your system probably has been infected with Ebury for many weeks or even months.

If there are other systems you are responsible for, we recommend checking those for infections with Ebury as well. When re-installing compromised hosts, use new strong passwords for all user accounts and replace all SSH keys used for key-based authentication.

Never log in to re-installed hosts using SSH from a system still infected with Ebury or the new login credentials for the re-installed machine will be harvested from the outgoing SSH connection again!

I have a lot of additional machines on my network. Is there a way to identify systems infected with Ebury by inspecting the network traffic?

Ebury uses specially crafted DNS-like packets for exfiltrating harvested login credentials to dropzone servers. Systems infected with Ebury can be identified by inspecting the network traffic as follows:

Legitimate IP packets for DNS queries from a client to a DNS server usually look like this (tcpdump output format):

10:53:21.377449 IP [Client].20374 > [DNS server].53:
                36027+ A? www.google.com. (32)

IP packets sent by Ebury infected systems look like a DNS query for a hexadecimal string followed by an IP address:

21:44:24.506801 IP [Ebury infected system].42177 > [IP address].53:
                4619+ A? 5742e5e76c1ab8c01b1defa5.[IP address]. (56)

If you spot any packet similar to this in your network traffic, the system that sent the packet is most likely infected with Ebury.

When running tcpdump for network traffic inspection on the infected machine itself, make sure to start tcpdump with option '-p'. This will prevent tcpdump from setting the network interface to promiscuous mode. Recent versions of Ebury will not send harvested credentials to a dropzone server while the network interface is in promiscuous mode.

Is there a Snort IDS rule for detecting infected machines on my network?

The following Snort-compatible IDS rule can be used to detect infected machines sending harvested login credentials to a dropzone server:

alert udp $HOME_NET any -> $EXTERNAL_NET 53 \
(msg:"Ebury SSH Rootkit data exfiltration";\
content:"|12 0b 01 00 00 01|"; depth:6;\
classtype:trojan-activity; sid:9000001; rev:1;)

Please let us know if you encounter any false alarms with this rule.


[1] BSI: Zahlreiche deutsche Server mit Ebury-Rootkit infiziert (2014-02-13)

[2] ESET: An In-depth Analysis of Linux/Ebury (2014-02-21)

[3] ESET: Operation Windigo (2014-03-18)

[4] cPanel: Determine Your System's Status (2013-02-25)

[5] ISC Diary: SSHD rootkit in the wild (2013-02-22)

Please note that the information provided in [4] and [5] on how to identify an infection with Ebury is outdated as the attackers have deployed newer versions of the malware since then.

CERT-Bund bietet personalisierte Warn- und Informationsdienste an.
Bitte registrieren Sie sich, um diese Angebote nutzen zu können.