Detailed analysis of the Linux / Ebury backdoor
Recently, our researchers performed an OpenSSH backdoor and Linux / Ebury password stealer analysis. This analysis is the result of the joint work of ESET with the German CERT-Bund , the Swedish center SNIC and the European organization CERN , as well as other organizations that are members of the international working group (Working Group). Linux / Ebury is a complex backdoor used by attackers to steal OpenSSH authentication data, as well as gain access to a compromised server (backdoor).
According to previous reports , this backdoor is already active for at least two years. Linux / Ebury can be distributed in two different forms: a malicious library and a patch to the OpenSSH binary files. The malicious library is a modification of the libkeyutils.so file. This library is shared by the OpenSSH components and is loaded by its executable files, such as ssh, sshd and ssh-agent. The analysis will publish information about how the malicious code carries out the theft of the authentication data of the accounts and how system administrators can detect the infected system.
')
The malicious Linux / Ebury code is interesting for some reason. Before, we saw malicious libraries under Windows and this is the first time that we see a similar module for POSIX systems. He also uses special techniques to intercept functions, to inject his code into the address space of the process, which loads the library and in a special way modifies the code during execution. We believe that before using the external library method to gain access to the OpenSSH process, the author of Linux / Ebury used a special patch to modify the OpenSSH source code, thereby adding “new features” to this software. The first variants of the malicious code looked exactly like this, since we found modified OpenSSH binary files on the disk of one of the compromised servers: ssh, sshd and ssh-add. We also observed the use of rpm commands to remove signatures from the original OpenSSH software package (openssh-server and openssh-clients), as well as modifying the RPM database to update file hashes for their modified malware counterparts. Such a modification allows you to prevent the detection of modification of files by checking their hashes using the rpm --verify openssh-servers command. At the same time, the rpm -qi openssh-servers command will show their absence.
Later versions of Linux / Ebury do not directly modify OpenSSH files. Instead, they use their own version of the library, libkeyutils.so, which is connected to all OpenSSH executable files. The changes that are made on the original library are similar to those used to modify OpenSSH binary files, which we mentioned above, except that some functions are intercepted, and they are also patched in the process of execution (runtime patching). Usually this file is 10 KB in size. Malicious code adds about 20 KB of its code to this file, after which the file size is already 30 KB.
Below are two examples of how a backdoor is installed on a system. The first one shows an infected Linux / Ebury file, which follows the clean libkeyutils.so file. The symbolic link is modified and points to the malicious version.
The following screenshot shows the scenario in which the library libkeyutils.so is overwritten by a malicious version.
Although the practice of placing malicious code inside libraries has already been observed previously, this is the first time that we have discovered it in Linux to change the behavior of OpenSSH.
To implement various functions of malicious code, it uses a special constructor function , which is added to libkeyutils.so. This function will be called by the loader when loading a binary file. It determines from which file it was launched, after which it modifies the executable code and intercepts the functions of the import table.
In the most recently discovered Linux / Ebury variants, the attackers encrypted the malicious code strings using a simple XOR and a static key. After unpacking its code, the malware gets the addresses of the functions necessary for it using the dlsym call. After that, it receives the address in the memory of the binary file itself via dlopen (NULL, RTLD_NOW) and passes this address (descriptor) to the dlinfo function (handle, RTLD_DI_LINKMAP, ...) . This method will work even if the ASLR is active in the system. Calling these functions allows Linux / Ebury to analyze the import table of the executable ELF file and replace its imports in memory (interception). As a result, when one of the sssh, sshd, or ssh-add programs calls one of the intercepted functions, the execution thread will be redirected to the malicious function implementation from libkeyutils.so. The code snippet below demonstrates calls to dlopen and dlinfo to find the module address in memory, followed by analysis of the ELF header information.
The malicious code intercepts various functions (when the malicious modification of libkeyutils.so is loaded into the sshd process):
These functions are inherently related to logging functions, that is, they can be used to record the activity of a program. If the backdoor is present in the system, these functions will be intercepted and replaced by malicious counterparts, which prevents them from performing their direct duties. Malicious code intercepts other functions, for example, pam_start , crypt and connect, which are used, for example, to steal passwords. The last function is intercepted for further control over Xbnd (see below), while the call of the socket binding function (bind) is performed before the call to the real connect .
In the case where the interception of functions using the import table is not possible, Linux / Ebury directly modifies the code in a specific section of the binary file, redirecting certain branches of the code to its implementation. The figure below shows an example of such an interception, the ssh program calls the key_parse_private_pem function and the execution thread is redirected to the malicious code. The address highlighted in red goes outside the executable ssh image and indicates a malicious modification of libkeyutils.so. This interception will then call the original function, memorize the private key in memory and then transfer it to the operators of the malicious program.
Before modifying instructions in the code segment, the program installs a special handler to catch exceptions (faults) related to segmentation. Such a handler will be called when a process receives SIGSEGV or SIGBUS signals . In the event of a signal, Linux / Ebury will simply interrupt its task and allow OpenSSH to execute its code. Before starting to execute functions that can lead to the collapse of the process, it calls the sigsetjmp function to save the current state of the environment (snapshot). If, subsequently, any exception occurs , siglongjmp will be used to restore the state of the environment to its original state.
This code modification technique is limited, since code offsets that are to be corrected are tightly wired in the body of libkeyutils.so. Thus, its effectiveness is limited by the binary file to which these modifications are directed. In practice, each modification of libkeyutils.so will work on three or five different versions of OpenSSH and will depend on the Linux distribution.
The backdoor itself is activated by sending specially crafted data within the string, which identifies the protocol version used by the SSH client. The following is a portion of the SSH specification that indicates the use of a protocol version.
This is the “ssh-protocolmajor.protocolminor-version”, where the protocolmajor and protocolminor are specified. version is server side; it may not be interpreted as useful for debugging.
www.openssh.com/txt/ssh-rfc-v1.5.txt - T. Ylonen
A part can actually be anything and should not be interpreted in any way by an SSH server. In the case of the Linux / Ebury backdoor, the field contains a string of hexadecimal characters with a length of 22 or more characters. It contains 11 characters of the system access password, which is encrypted using the value of the client IP address, and then encoded as a hexadecimal string; The password can also be followed by four optional bytes of the command, which is also encrypted.
Please note that the version of the protocol used is sent before the client and the server agree on encryption, which allows detecting the behavior of the malicious program in network traffic.
An example of the version of the SSH protocol used, the next time the root shell is started, it looks like this:
SSH-2.0-fb54c28ba102cd73c1fe43
After the backdoor has verified the password, the sshd process will allow you to use any characters as a password for subsequent successful authentication. If the configuration of the PermitRootLogin , PasswordAuthentication or PermitEmptyPassword options is disabled, the malicious code will enable them. It will also disable any logging operations for successful creation of a new session, so that it was impossible to track the activity of intruders. In versions 1.3.1 and later, the SHA-1 password hash is stored in a binary file, and not in 11 characters of the protocol version string as specified above. This practice makes it impossible to guess the password in case you do not have a network packet capture tool to track logon operations by operators. In addition, the password is different in different modifications of malicious code. Most likely, malware operators have a database of infected servers with corresponding passwords to access backdoors, so that they can activate each of them separately.
The primary purpose of Linux / Ebury is to steal credentials that are used for authentication. The stolen account data was most likely used to infect more servers. The malicious code itself does not contain opportunities for self-propagation, most likely it is distributed by the attackers themselves or installed through special scripts. Account data is intercepted in several places when it is recruited or used by the victim.
Regardless of the type of credentials, Linux / Ebury will save all the necessary information (username, destination IP address and OpenSSH port) for malware operators who can use them later.
When Linux / Ebury intercepts the required password, it is sent to the remote server through a specially crafted DNS query. He creates a request for an A record (regular A record request), which will be sent to UDP port number 53. The requested domain name field contains the encrypted data in hexadecimal, as well as the IP address. The data has the following format:
<encrypted_data_hexadecimal_presentation>. <ip address>
The first field contains data from one of the accounts listed above. They are encrypted using XOR and 4-byte static key 0x000d5345, and then encoded in hexadecimal representation.
This IP address specified in the request depends on the type of credentials stolen. If the credentials are for an infected server, the source IP address is used; otherwise, the remote IP address that is used to connect from the infected server. We believe that the method of sending stolen data chosen by the authors of the malware is used to disguise as legitimate DNS requests that are sent through port 53 in order to avoid their blocking by firewalls.
There are two methods by which Linux / Ebury can select a server to send DNS packets there. First, it can be explicitly set by the operator when using the Xver command. The second method is to use the DGA domain name generation algorithm. In this case, the domain name will be checked for existence and belonging to its operators using the records of the query A and TXT.
Below are three commands that allow operators (evil movers) to facilitate the management of a compromised server. The command is added to the backdoor password string (see above) before encrypting this string. When the backdoor identifies a command, it recognizes it and performs the necessary actions.
Linux / Ebury authors use the practice of embedding a version number in a binary file of malicious code. This allows operators to be aware of which version of their malware is installed on a compromised system. On the other hand, it helps the supervisors to understand the chronology of the release events and correctly sort the samples.
For example, starting from version 1.3.2, Linux / Ebury will not send any information to a remote server if the network interface for accepting packets is in promiscuous mode. This interface mode is used, for example, when tools like tcpdump capture network traffic from the network. It is possible that the authors of the malware added this feature in response to an article from cPanel about Linux / Ebury, in which it is proposed to run the tcpdump tool to track DNS requests and record attempts to steal confidential account data (an indicator of system compromise).
There are two ways to check the presence of the Linux / Ebury SSH backdoor in two ways. The easiest way is to check the SSH binary files for the presence of malicious code there. A more complex way is to study shared memory segments that are used by malware.
The ssh –G command has different behavior on a clean system and a system infected with Linux / Ebury. On an uninfected server, the output (in stderr) will be:
ssh: illegal option - G
On the infected server, a “usage” message will be displayed on the rules for using the application. The following command can be used to detect the fact of compromise:
$ ssh -G 2> & 1 | grep -e illegal -e unknown> / dev / null && echo "System clean" || echo "System infected"
Linux / Ebury relies on POSIX shared memory segments that are used for inter-process communication (IPC). The current version of the malware uses large segments larger than 3 MB of memory with extensive rights to access them, which allow you to write data there and read it from there (R / W). Other legitimate processes can also create their shared memory segments with read and write permissions. When checking for the presence of a backdoor using this method, make sure that the segment was created by the sshd process (shown below).
You can find a large segment of shared memory with broad rights to access it by running the following command as root:
# ipcs -m
- Shared Memory Segments - key shmid owner perms by nattch
0x00000000 0 root 644 80 2
0x00000000 32769 root 644 16384 2
0x00000000 65538 root 644 280 2
0x000010e0 465272836 root 666 3282312 0
To verify the sshd process:
# ps aux | grep root 11531 0.0 0.0 103284 828 pts / 0 S + 16:40 0:00 grep 15029
root 15029 0.0 0.0 66300 1204? Ss Jan26 0:00 / usr / sbin / sshd
It can be seen that the sshd process uses shared memory segments that are larger than 3 MB (3,145,728 bytes) with broad access rights (666). Such an indicator indicates infection of the system.
Below are some small snort rules so that you can easily determine the activity of this malicious program on large networks. The first rule is used to detect the SSH client protocol (SSH Client Protocol) field, which is used by operators when connecting to the backdoor. Any host that tries to connect to the backdoor on the SSH port will be detected by this rule.
alert tcp $ EXTERNAL_NET any -> $ HOME_NET $ SSH_PORTS (msg: “Linux / Ebury SSH backdoor activty”; content: “SSH-2.0”; isdataat: 20, relative; pcre: "/ ^ SSH-2 \ .0- [ 0-9a-f] {22,46} / sm "; reference: url, http: //www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/; classtype: trojan-activity; sid: 1000001; rev: 1;)
The following Snort rule can be used to detect the infected server through which the stolen data is sent, see CERT-Bund .
alert udp $ HOME_NET any -> $ EXTERNAL_NET 53 (msg: "Linux / Ebury SSH backdoor data exfiltration"; content: "| 12 0b 01 00 00 01 |"; depth: 6; pcre: "/ ^ \ x12 \ x0b \ x01 \ x00 \ x00 \ x01 [\ x00] {6}. [a-f0-9] {6,} (([[x01 | \ x02 | \ x03] \ d {1,3}) {4} | \ x03 :: 1) \ x00 \ x00 \ x01 / Bs "; reference: url, http: //www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/; reference : url, https: //www.cert-bund.de/ebury-faq; classtype: trojan-activity; sid: 1000002; rev: 1;)
Conclusion
The Linux / Ebury malware certainly represents a complex threat with many interesting features, such as intercepting various functions of an executable file, using POSIX exception handlers and various methods to disguise its presence in the system. Based on the data we received, it can be stated that, at present, thousands of systems are infected with this malicious code. Linux / Ebury is distributed by attackers using stolen credentials that were available to the operators. Having such data on hand eliminates any need to use any 0day vulnerabilities in software or OS for remote installation of this malicious program. Although it is not completely clear where the attackers got the initial account data of the systems from which the initial infection began.
According to previous reports , this backdoor is already active for at least two years. Linux / Ebury can be distributed in two different forms: a malicious library and a patch to the OpenSSH binary files. The malicious library is a modification of the libkeyutils.so file. This library is shared by the OpenSSH components and is loaded by its executable files, such as ssh, sshd and ssh-agent. The analysis will publish information about how the malicious code carries out the theft of the authentication data of the accounts and how system administrators can detect the infected system.
')
The malicious Linux / Ebury code is interesting for some reason. Before, we saw malicious libraries under Windows and this is the first time that we see a similar module for POSIX systems. He also uses special techniques to intercept functions, to inject his code into the address space of the process, which loads the library and in a special way modifies the code during execution. We believe that before using the external library method to gain access to the OpenSSH process, the author of Linux / Ebury used a special patch to modify the OpenSSH source code, thereby adding “new features” to this software. The first variants of the malicious code looked exactly like this, since we found modified OpenSSH binary files on the disk of one of the compromised servers: ssh, sshd and ssh-add. We also observed the use of rpm commands to remove signatures from the original OpenSSH software package (openssh-server and openssh-clients), as well as modifying the RPM database to update file hashes for their modified malware counterparts. Such a modification allows you to prevent the detection of modification of files by checking their hashes using the rpm --verify openssh-servers command. At the same time, the rpm -qi openssh-servers command will show their absence.
Later versions of Linux / Ebury do not directly modify OpenSSH files. Instead, they use their own version of the library, libkeyutils.so, which is connected to all OpenSSH executable files. The changes that are made on the original library are similar to those used to modify OpenSSH binary files, which we mentioned above, except that some functions are intercepted, and they are also patched in the process of execution (runtime patching). Usually this file is 10 KB in size. Malicious code adds about 20 KB of its code to this file, after which the file size is already 30 KB.
Below are two examples of how a backdoor is installed on a system. The first one shows an infected Linux / Ebury file, which follows the clean libkeyutils.so file. The symbolic link is modified and points to the malicious version.
The following screenshot shows the scenario in which the library libkeyutils.so is overwritten by a malicious version.
Although the practice of placing malicious code inside libraries has already been observed previously, this is the first time that we have discovered it in Linux to change the behavior of OpenSSH.
To implement various functions of malicious code, it uses a special constructor function , which is added to libkeyutils.so. This function will be called by the loader when loading a binary file. It determines from which file it was launched, after which it modifies the executable code and intercepts the functions of the import table.
In the most recently discovered Linux / Ebury variants, the attackers encrypted the malicious code strings using a simple XOR and a static key. After unpacking its code, the malware gets the addresses of the functions necessary for it using the dlsym call. After that, it receives the address in the memory of the binary file itself via dlopen (NULL, RTLD_NOW) and passes this address (descriptor) to the dlinfo function (handle, RTLD_DI_LINKMAP, ...) . This method will work even if the ASLR is active in the system. Calling these functions allows Linux / Ebury to analyze the import table of the executable ELF file and replace its imports in memory (interception). As a result, when one of the sssh, sshd, or ssh-add programs calls one of the intercepted functions, the execution thread will be redirected to the malicious function implementation from libkeyutils.so. The code snippet below demonstrates calls to dlopen and dlinfo to find the module address in memory, followed by analysis of the ELF header information.
The malicious code intercepts various functions (when the malicious modification of libkeyutils.so is loaded into the sshd process):
- audit_log_user_message
- audit_log_acct_message
- hosts_access
- connect
- __syslog_chk
- write
- syslog
- popen
- hosts_access
- crypt
- pam_start
These functions are inherently related to logging functions, that is, they can be used to record the activity of a program. If the backdoor is present in the system, these functions will be intercepted and replaced by malicious counterparts, which prevents them from performing their direct duties. Malicious code intercepts other functions, for example, pam_start , crypt and connect, which are used, for example, to steal passwords. The last function is intercepted for further control over Xbnd (see below), while the call of the socket binding function (bind) is performed before the call to the real connect .
In the case where the interception of functions using the import table is not possible, Linux / Ebury directly modifies the code in a specific section of the binary file, redirecting certain branches of the code to its implementation. The figure below shows an example of such an interception, the ssh program calls the key_parse_private_pem function and the execution thread is redirected to the malicious code. The address highlighted in red goes outside the executable ssh image and indicates a malicious modification of libkeyutils.so. This interception will then call the original function, memorize the private key in memory and then transfer it to the operators of the malicious program.
Before modifying instructions in the code segment, the program installs a special handler to catch exceptions (faults) related to segmentation. Such a handler will be called when a process receives SIGSEGV or SIGBUS signals . In the event of a signal, Linux / Ebury will simply interrupt its task and allow OpenSSH to execute its code. Before starting to execute functions that can lead to the collapse of the process, it calls the sigsetjmp function to save the current state of the environment (snapshot). If, subsequently, any exception occurs , siglongjmp will be used to restore the state of the environment to its original state.
This code modification technique is limited, since code offsets that are to be corrected are tightly wired in the body of libkeyutils.so. Thus, its effectiveness is limited by the binary file to which these modifications are directed. In practice, each modification of libkeyutils.so will work on three or five different versions of OpenSSH and will depend on the Linux distribution.
The backdoor itself is activated by sending specially crafted data within the string, which identifies the protocol version used by the SSH client. The following is a portion of the SSH specification that indicates the use of a protocol version.
This is the “ssh-protocolmajor.protocolminor-version”, where the protocolmajor and protocolminor are specified. version is server side; it may not be interpreted as useful for debugging.
www.openssh.com/txt/ssh-rfc-v1.5.txt - T. Ylonen
A part can actually be anything and should not be interpreted in any way by an SSH server. In the case of the Linux / Ebury backdoor, the field contains a string of hexadecimal characters with a length of 22 or more characters. It contains 11 characters of the system access password, which is encrypted using the value of the client IP address, and then encoded as a hexadecimal string; The password can also be followed by four optional bytes of the command, which is also encrypted.
Please note that the version of the protocol used is sent before the client and the server agree on encryption, which allows detecting the behavior of the malicious program in network traffic.
An example of the version of the SSH protocol used, the next time the root shell is started, it looks like this:
SSH-2.0-fb54c28ba102cd73c1fe43
After the backdoor has verified the password, the sshd process will allow you to use any characters as a password for subsequent successful authentication. If the configuration of the PermitRootLogin , PasswordAuthentication or PermitEmptyPassword options is disabled, the malicious code will enable them. It will also disable any logging operations for successful creation of a new session, so that it was impossible to track the activity of intruders. In versions 1.3.1 and later, the SHA-1 password hash is stored in a binary file, and not in 11 characters of the protocol version string as specified above. This practice makes it impossible to guess the password in case you do not have a network packet capture tool to track logon operations by operators. In addition, the password is different in different modifications of malicious code. Most likely, malware operators have a database of infected servers with corresponding passwords to access backdoors, so that they can activate each of them separately.
The primary purpose of Linux / Ebury is to steal credentials that are used for authentication. The stolen account data was most likely used to infect more servers. The malicious code itself does not contain opportunities for self-propagation, most likely it is distributed by the attackers themselves or installed through special scripts. Account data is intercepted in several places when it is recruited or used by the victim.
- Password from successful login to the infected server . Whenever someone logs on to a Linux / Ebury infected system, the sshd daemon saves this password and sends it to the attacker's server (exfiltration).
- Any password entered to log in to the infected server . Even if the attempt to log in to the server was unsuccessful, the username and password entered will be sent to the attacker's server.
- Password from successful login from the infected server . When someone uses the ssh client on an infected server, the malicious code will intercept this operation and send the entered password to the attacker's server.
- Secret passphrase . When an SSH client on an infected server requests a private key passphrase from the user for successful login, it will be sent to the remote server.
- Unencrypted secret key . When someone uses a secret key to authenticate to a remote server, its unencrypted version is intercepted by malicious code. Unlike the password case, this key will not be sent to the remote server; instead, it will be stored in memory. In doing so, Linux / Ebury will wait for the operator’s command to transfer the key using the xcat command.
- Secret keys added to OpenSSH using ssh-add . The keys (the unencrypted version of the key and the secret phrase) added to the OpenSSH agent are also intercepted by malware.
Regardless of the type of credentials, Linux / Ebury will save all the necessary information (username, destination IP address and OpenSSH port) for malware operators who can use them later.
When Linux / Ebury intercepts the required password, it is sent to the remote server through a specially crafted DNS query. He creates a request for an A record (regular A record request), which will be sent to UDP port number 53. The requested domain name field contains the encrypted data in hexadecimal, as well as the IP address. The data has the following format:
<encrypted_data_hexadecimal_presentation>. <ip address>
The first field contains data from one of the accounts listed above. They are encrypted using XOR and 4-byte static key 0x000d5345, and then encoded in hexadecimal representation.
This IP address specified in the request depends on the type of credentials stolen. If the credentials are for an infected server, the source IP address is used; otherwise, the remote IP address that is used to connect from the infected server. We believe that the method of sending stolen data chosen by the authors of the malware is used to disguise as legitimate DNS requests that are sent through port 53 in order to avoid their blocking by firewalls.
There are two methods by which Linux / Ebury can select a server to send DNS packets there. First, it can be explicitly set by the operator when using the Xver command. The second method is to use the DGA domain name generation algorithm. In this case, the domain name will be checked for existence and belonging to its operators using the records of the query A and TXT.
Below are three commands that allow operators (evil movers) to facilitate the management of a compromised server. The command is added to the backdoor password string (see above) before encrypting this string. When the backdoor identifies a command, it recognizes it and performs the necessary actions.
- Xcat : print all passwords, secret phrases and keys stored in the backdoor's memory and exit.
- Xver : print the version of the malware and exit. The command also accepts optional four bytes as an argument. If this argument is present, it is interpreted as the IP address of the remote server to which the stolen data should be transferred (exfiltration server).
- Xbnd : takes a four-byte argument — the IP address that is used for the bind operation of the client socket to this address when creating the tunnel connection.
Linux / Ebury authors use the practice of embedding a version number in a binary file of malicious code. This allows operators to be aware of which version of their malware is installed on a compromised system. On the other hand, it helps the supervisors to understand the chronology of the release events and correctly sort the samples.
For example, starting from version 1.3.2, Linux / Ebury will not send any information to a remote server if the network interface for accepting packets is in promiscuous mode. This interface mode is used, for example, when tools like tcpdump capture network traffic from the network. It is possible that the authors of the malware added this feature in response to an article from cPanel about Linux / Ebury, in which it is proposed to run the tcpdump tool to track DNS requests and record attempts to steal confidential account data (an indicator of system compromise).
There are two ways to check the presence of the Linux / Ebury SSH backdoor in two ways. The easiest way is to check the SSH binary files for the presence of malicious code there. A more complex way is to study shared memory segments that are used by malware.
The ssh –G command has different behavior on a clean system and a system infected with Linux / Ebury. On an uninfected server, the output (in stderr) will be:
ssh: illegal option - G
On the infected server, a “usage” message will be displayed on the rules for using the application. The following command can be used to detect the fact of compromise:
$ ssh -G 2> & 1 | grep -e illegal -e unknown> / dev / null && echo "System clean" || echo "System infected"
Linux / Ebury relies on POSIX shared memory segments that are used for inter-process communication (IPC). The current version of the malware uses large segments larger than 3 MB of memory with extensive rights to access them, which allow you to write data there and read it from there (R / W). Other legitimate processes can also create their shared memory segments with read and write permissions. When checking for the presence of a backdoor using this method, make sure that the segment was created by the sshd process (shown below).
You can find a large segment of shared memory with broad rights to access it by running the following command as root:
# ipcs -m
- Shared Memory Segments - key shmid owner perms by nattch
0x00000000 0 root 644 80 2
0x00000000 32769 root 644 16384 2
0x00000000 65538 root 644 280 2
0x000010e0 465272836 root 666 3282312 0
To verify the sshd process:
# ps aux | grep root 11531 0.0 0.0 103284 828 pts / 0 S + 16:40 0:00 grep 15029
root 15029 0.0 0.0 66300 1204? Ss Jan26 0:00 / usr / sbin / sshd
It can be seen that the sshd process uses shared memory segments that are larger than 3 MB (3,145,728 bytes) with broad access rights (666). Such an indicator indicates infection of the system.
Below are some small snort rules so that you can easily determine the activity of this malicious program on large networks. The first rule is used to detect the SSH client protocol (SSH Client Protocol) field, which is used by operators when connecting to the backdoor. Any host that tries to connect to the backdoor on the SSH port will be detected by this rule.
alert tcp $ EXTERNAL_NET any -> $ HOME_NET $ SSH_PORTS (msg: “Linux / Ebury SSH backdoor activty”; content: “SSH-2.0”; isdataat: 20, relative; pcre: "/ ^ SSH-2 \ .0- [ 0-9a-f] {22,46} / sm "; reference: url, http: //www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/; classtype: trojan-activity; sid: 1000001; rev: 1;)
The following Snort rule can be used to detect the infected server through which the stolen data is sent, see CERT-Bund .
alert udp $ HOME_NET any -> $ EXTERNAL_NET 53 (msg: "Linux / Ebury SSH backdoor data exfiltration"; content: "| 12 0b 01 00 00 01 |"; depth: 6; pcre: "/ ^ \ x12 \ x0b \ x01 \ x00 \ x00 \ x01 [\ x00] {6}. [a-f0-9] {6,} (([[x01 | \ x02 | \ x03] \ d {1,3}) {4} | \ x03 :: 1) \ x00 \ x00 \ x01 / Bs "; reference: url, http: //www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/; reference : url, https: //www.cert-bund.de/ebury-faq; classtype: trojan-activity; sid: 1000002; rev: 1;)
Conclusion
The Linux / Ebury malware certainly represents a complex threat with many interesting features, such as intercepting various functions of an executable file, using POSIX exception handlers and various methods to disguise its presence in the system. Based on the data we received, it can be stated that, at present, thousands of systems are infected with this malicious code. Linux / Ebury is distributed by attackers using stolen credentials that were available to the operators. Having such data on hand eliminates any need to use any 0day vulnerabilities in software or OS for remote installation of this malicious program. Although it is not completely clear where the attackers got the initial account data of the systems from which the initial infection began.
Source: https://habr.com/ru/post/214733/
All Articles