March 5, 2014 at 14:02Detailed analysis of the Linux / Ebury backdoor
Recently, our researchers performed an analysis of the OpenSSH backdoor and password thief Linux / Ebury . This analysis is the result of ESET working together with the German CERT-Bund , the Swedish SNIC and the European organization CERN , as well as other organizations that are members of the international Working Group. Linux / Ebury is a complex backdoor used by cybercriminals to steal OpenSSH authentication data, as well as gain access to a compromised server (backdoor).
According to previous reports, this backdoor has been active for at least two years. Linux / Ebury can be distributed in two different forms: a malicious library and a patch for OpenSSH binaries. The malicious library is a modification of the libkeyutils.so file. This library is common to OpenSSH components and is loaded with its executable files, such as ssh, sshd and ssh-agent. The analysis will publish information on how malicious code steals account authentication data and how system administrators can detect an infected system.
Linux / Ebury malware is interesting for some reason. Before, we saw malicious libraries under Windows and this is the first time that we observe 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 specially modifies the code at runtime. 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, because we found modified OpenSSH binary files on the disk of one of the compromised servers: ssh, sshd and ssh-add. We have also observed the use of rpm commandsto remove signatures from the original OpenSSH software package (openssh-server and openssh-clients), as well as modifying the RPM database to update file hashes to their malicious modified counterparts. This modification allows you to prevent detection of file modifications 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 modify OpenSSH files directly. Instead, they use their version of the libkeyutils.so library, which is connected by all OpenSSH executables. The changes made to the original library are similar to those used to modify the OpenSSH binary files that we mentioned above, except that some functions are intercepted and patched during execution (runtime patching). Usually this file is 10 KB in size. The 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 in the system. The first shows the infected Linux / Ebury file, which follows the clean libkeyutils.so file. The symbolic link is modified and indicates a malicious version.
The following screenshot shows a scenario in which the libkeyutils.so library 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 we discovered it in Linux to modify the behavior of OpenSSH.
To implement various functions of malicious code, it uses a special constructor function ( constructor function), which is added to libkeyutils.so. This function will be called by the bootloader 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 recent Linux / Ebury variants, attackers encrypted lines of malicious code using a simple XOR and a static key. After unpacking its code, the malicious program obtains 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 (handle) to the dlinfo function (handle, RTLD_DI_LINKMAP, ...) . This method will work even if ASLR is active.in 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 implementation of the function from libkeyutils.so. The code snippet below shows the dlopen and dlinfo calls to find the module address in memory, and then parse the ELF header information.
Malicious code intercepts various functions (when the malicious modification of libkeyutils.so is loaded into the sshd process):
These functions relate in essence to logging functions, that is, they can be used to record the activity of the program. If a backdoor is present in the system, these functions will be intercepted and replaced by malicious counterparts, which impedes the performance of their direct duties. Malicious code intercepts other functions, for example, pam_start , crypt and connect, which are used, for example, to steal entered passwords. The last function is intercepted for further control over Xbnd (see below), and the call to the bind function of the socket (bind) is performed before the call to this connect .
In the event that it is not possible to intercept functions using the import table, Linux / Ebury directly modifies the code in a specific section of the binary file, redirecting certain branches of 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 malicious code. The address highlighted in red goes beyond the ssh executable image and indicates a malicious modification to libkeyutils.so. This interception will then call the original function, store the private key in memory and then pass it to the malware operators.
Before modifying the instructions in the code segment, the program installs a special handler to catch the exceptions (fault) associated with segmentation. Such a handler will be called when the 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 could lead to a process crash, it calls the sigsetjmp function to save the current state of the environment (snapshot). If, in the future, any exception occurs , siglongjmp will be used to restore the environment to its original state.
This technique for modifying the code is limited because the code offsets that need to be fixed are hard wired into 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 generated data inside a line that identifies the protocol version used by the SSH client. The following is part of the SSH specification, which indicates the use of a protocol version.
After the socket is opened, the server sends an identification string, which is of the form "SSH-protocolmajor.protocolminor-version", where protocolmajor and protocolminor are integers and specify the protocol version number (not software distribution version). version is server side software version string (max 40 characters); it is not interpreted by the remote side but may be useful for debugging.
www.openssh.com/txt/ssh-rfc-v1.5.txt - T. Ylonen
The part can actually be anything and should not be interpreted in any way by the 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 client IP address value 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 used version of the protocol is sent before the client and 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 launched, 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 option is PermitRootLogin , PasswordAuthentication or PermitEmptyPasswordprohibited, malicious code will enable them. It will also disable any logging operations for successfully creating a new session so that it is impossible to track the activity of attackers. In versions 1.3.1 and later, the SHA-1 hash of the password is stored in a binary file, and not in 11 characters of the protocol version string as indicated above. This practice makes it impossible to guess the password if you do not have a network packet capture tool to track login operations by operators. In addition, the password differs in different modifications of the malicious code. Most likely, the malware operators have a database of infected servers with the corresponding passwords for access to the backdoors, so that they could activate each of them individually.
The main purpose of Linux / Ebury is to steal the 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 self-propagation capabilities, most likely it is distributed by the attackers themselves or installed through special scripts. Account data is intercepted in several places when it is collected 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 in the future.
When Linux / Ebury intercepts the required password, it is sent to the remote server through a specially crafted DNS query. It creates an A record request (regular A record request), which will be sent to UDP port number 53. The requested domain name field contains the encrypted data in hexadecimal form, as well as the IP address. The data has the following format:
<encrypted_data_in_hexadecimal_representation>.
The first field contains the data for one of the accounts listed above. They are encrypted using XOR and a 4-byte static key 0x000d5345, and then encoded in hexadecimal representation.
This IP address specified in the request depends on the type of stolen credentials. If the credentials refer to the infected server, the source IP address is used; otherwise, the remote IP address is used to connect from the infected server. We believe that the method of sending the stolen data chosen by the authors of the malicious program is used to mask as legitimate DNS queries that are sent through port 53 to avoid being blocked by firewalls.
There are two methods by which Linux / Ebury can select a server to send DNS packets to. 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 query records A and TXT.
The following are three commands that allow operators (attackers) to facilitate the management of a compromised server. The command is added to the backdoor password line (see above) before the encryption operation of this line. When a backdoor identifies a team, it recognizes it and performs the necessary actions.
Linux / Ebury authors use the practice of embedding version numbers 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 receivers to understand the chronology of events on the release of versions and correctly sort the samples.
For example, starting with 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. A similar interface mode is used, for example, when tools like tcpdump capture network traffic from the network. It is possible that the authors of the malicious program added this feature in response to an article from cPanel about Linux / Ebury, which suggested launching the tcpdump tool to track DNS queries and recording attempts to steal sensitive account data (system compromise indicator).
There are two ways to verify the presence of the Linux / Ebury SSH backdoor system. The easiest way is to check the SSH binary files for malicious code. A more complex way is to study the shared memory segments that are used by the 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 look like:
ssh: illegal option - G
On the infected server, a “usage” message will be displayed about the rules for using the application. The following command can be used to detect a fact of compromise:
$ ssh -G 2> & 1 | grep -e illegal -e unknown> / dev / null && echo "System clean" || echo "System infected"
Linux / Ebury relies on shared POSIX memory segments that are used for inter-process communication (IPC). The current version of the malicious program uses large segments larger than 3 MB of memory with wide access rights to them, which allow you to write data there and read them from there (R / W). Other legitimate processes can also create their own shared memory segments with read and write permissions. When checking the presence of a backdoor using this method, make sure that the segment was created by the sshd process (shown below).
You can detect a large segment of shared memory with wide permissions to access it by running the following command from root:
- Shared Memory Segments - key shmid owner perms bytes 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 check 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 larger than 3 MB (3,145,728 bytes) with wide access rights (666). A similar indicator indicates a system infection.
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 field, which is used by operators when connecting to the backdoor. Any host that tries to connect to the backdoor via 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 an infected server through which stolen data is sent, see.
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 is certainly a complex threat with many interesting features, such as intercepting various functions of an executable file, using POSIX exception handlers, and various methods to mask its presence on the system. Based on the data that we obtained, it can be ascertained that thousands of systems are currently infected with this malicious code. Linux / Ebury is being distributed by cybercriminals using stolen credentials held by operators. Having such data on hand, there is no need to use any 0day vulnerabilities in software or OS for remote installation of this malicious program. Although it’s not clear where the attackers came from the initial data of the system accounts,
According to previous reports, this backdoor has been active for at least two years. Linux / Ebury can be distributed in two different forms: a malicious library and a patch for OpenSSH binaries. The malicious library is a modification of the libkeyutils.so file. This library is common to OpenSSH components and is loaded with its executable files, such as ssh, sshd and ssh-agent. The analysis will publish information on how malicious code steals account authentication data and how system administrators can detect an infected system.
Linux / Ebury malware is interesting for some reason. Before, we saw malicious libraries under Windows and this is the first time that we observe 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 specially modifies the code at runtime. 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, because we found modified OpenSSH binary files on the disk of one of the compromised servers: ssh, sshd and ssh-add. We have also observed the use of rpm commandsto remove signatures from the original OpenSSH software package (openssh-server and openssh-clients), as well as modifying the RPM database to update file hashes to their malicious modified counterparts. This modification allows you to prevent detection of file modifications 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 modify OpenSSH files directly. Instead, they use their version of the libkeyutils.so library, which is connected by all OpenSSH executables. The changes made to the original library are similar to those used to modify the OpenSSH binary files that we mentioned above, except that some functions are intercepted and patched during execution (runtime patching). Usually this file is 10 KB in size. The 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 in the system. The first shows the infected Linux / Ebury file, which follows the clean libkeyutils.so file. The symbolic link is modified and indicates a malicious version.
The following screenshot shows a scenario in which the libkeyutils.so library 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 we discovered it in Linux to modify the behavior of OpenSSH.
To implement various functions of malicious code, it uses a special constructor function ( constructor function), which is added to libkeyutils.so. This function will be called by the bootloader 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 recent Linux / Ebury variants, attackers encrypted lines of malicious code using a simple XOR and a static key. After unpacking its code, the malicious program obtains 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 (handle) to the dlinfo function (handle, RTLD_DI_LINKMAP, ...) . This method will work even if ASLR is active.in 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 implementation of the function from libkeyutils.so. The code snippet below shows the dlopen and dlinfo calls to find the module address in memory, and then parse the ELF header information.
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 relate in essence to logging functions, that is, they can be used to record the activity of the program. If a backdoor is present in the system, these functions will be intercepted and replaced by malicious counterparts, which impedes the performance of their direct duties. Malicious code intercepts other functions, for example, pam_start , crypt and connect, which are used, for example, to steal entered passwords. The last function is intercepted for further control over Xbnd (see below), and the call to the bind function of the socket (bind) is performed before the call to this connect .
In the event that it is not possible to intercept functions using the import table, Linux / Ebury directly modifies the code in a specific section of the binary file, redirecting certain branches of 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 malicious code. The address highlighted in red goes beyond the ssh executable image and indicates a malicious modification to libkeyutils.so. This interception will then call the original function, store the private key in memory and then pass it to the malware operators.
Before modifying the instructions in the code segment, the program installs a special handler to catch the exceptions (fault) associated with segmentation. Such a handler will be called when the 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 could lead to a process crash, it calls the sigsetjmp function to save the current state of the environment (snapshot). If, in the future, any exception occurs , siglongjmp will be used to restore the environment to its original state.
This technique for modifying the code is limited because the code offsets that need to be fixed are hard wired into 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 generated data inside a line that identifies the protocol version used by the SSH client. The following is part of the SSH specification, which indicates the use of a protocol version.
After the socket is opened, the server sends an identification string, which is of the form "SSH-protocolmajor.protocolminor-version", where protocolmajor and protocolminor are integers and specify the protocol version number (not software distribution version). version is server side software version string (max 40 characters); it is not interpreted by the remote side but may be useful for debugging.
www.openssh.com/txt/ssh-rfc-v1.5.txt - T. Ylonen
The part can actually be anything and should not be interpreted in any way by the 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 client IP address value 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 used version of the protocol is sent before the client and 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 launched, 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 option is PermitRootLogin , PasswordAuthentication or PermitEmptyPasswordprohibited, malicious code will enable them. It will also disable any logging operations for successfully creating a new session so that it is impossible to track the activity of attackers. In versions 1.3.1 and later, the SHA-1 hash of the password is stored in a binary file, and not in 11 characters of the protocol version string as indicated above. This practice makes it impossible to guess the password if you do not have a network packet capture tool to track login operations by operators. In addition, the password differs in different modifications of the malicious code. Most likely, the malware operators have a database of infected servers with the corresponding passwords for access to the backdoors, so that they could activate each of them individually.
The main purpose of Linux / Ebury is to steal the 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 self-propagation capabilities, most likely it is distributed by the attackers themselves or installed through special scripts. Account data is intercepted in several places when it is collected or used by the victim.
- Password for a successful login operation to the infected server . Whenever someone logs on to a Linux / Ebury infected system, the sshd daemon will save this password and send it to the exfiltration server.
- Any password entered for the operation of entering the infected server . Even if the attempt to enter the server was unsuccessful, the entered username and password will be sent to the attacker server.
- Password for a successful login operation from an 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 attackers server.
- Secret passphrase . When the SSH client on the infected server asks the user for a passphrase (private key passphrase) for successful login, it will be sent to the remote server.
- Unencrypted secret key . When someone uses a secret key for authentication on a remote server, its unencrypted version is intercepted by malicious code. Unlike the case with passwords, this key will not be sent to the remote server; instead, it will be stored in memory. In this case, Linux / Ebury will wait for the operator to transmit the key using the xcat command.
- Secret keys added to OpenSSH using ssh-add . Keys (an unencrypted version of the key and a secret phrase) added to the OpenSSH agent are also intercepted by the malicious program.
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 in the future.
When Linux / Ebury intercepts the required password, it is sent to the remote server through a specially crafted DNS query. It creates an A record request (regular A record request), which will be sent to UDP port number 53. The requested domain name field contains the encrypted data in hexadecimal form, as well as the IP address. The data has the following format:
<encrypted_data_in_hexadecimal_representation>.
The first field contains the data for one of the accounts listed above. They are encrypted using XOR and a 4-byte static key 0x000d5345, and then encoded in hexadecimal representation.
This IP address specified in the request depends on the type of stolen credentials. If the credentials refer to the infected server, the source IP address is used; otherwise, the remote IP address is used to connect from the infected server. We believe that the method of sending the stolen data chosen by the authors of the malicious program is used to mask as legitimate DNS queries that are sent through port 53 to avoid being blocked by firewalls.
There are two methods by which Linux / Ebury can select a server to send DNS packets to. 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 query records A and TXT.
The following are three commands that allow operators (attackers) to facilitate the management of a compromised server. The command is added to the backdoor password line (see above) before the encryption operation of this line. When a backdoor identifies a team, 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 malware version and exit. The command also takes an optional four bytes as an argument. If this argument is present, it is treated as the IP address of the remote server to which the stolen data should be transmitted (exfiltration server).
- Xbnd : accepts a four-byte argument - the IP address that is used for the bind operation of the client socket with this address when creating a tunnel connection.
Linux / Ebury authors use the practice of embedding version numbers 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 receivers to understand the chronology of events on the release of versions and correctly sort the samples.
For example, starting with 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. A similar interface mode is used, for example, when tools like tcpdump capture network traffic from the network. It is possible that the authors of the malicious program added this feature in response to an article from cPanel about Linux / Ebury, which suggested launching the tcpdump tool to track DNS queries and recording attempts to steal sensitive account data (system compromise indicator).
There are two ways to verify the presence of the Linux / Ebury SSH backdoor system. The easiest way is to check the SSH binary files for malicious code. A more complex way is to study the shared memory segments that are used by the 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 look like:
ssh: illegal option - G
On the infected server, a “usage” message will be displayed about the rules for using the application. The following command can be used to detect a fact of compromise:
$ ssh -G 2> & 1 | grep -e illegal -e unknown> / dev / null && echo "System clean" || echo "System infected"
Linux / Ebury relies on shared POSIX memory segments that are used for inter-process communication (IPC). The current version of the malicious program uses large segments larger than 3 MB of memory with wide access rights to them, which allow you to write data there and read them from there (R / W). Other legitimate processes can also create their own shared memory segments with read and write permissions. When checking the presence of a backdoor using this method, make sure that the segment was created by the sshd process (shown below).
You can detect a large segment of shared memory with wide permissions to access it by running the following command from root:
- Shared Memory Segments - key shmid owner perms bytes 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 check 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 larger than 3 MB (3,145,728 bytes) with wide access rights (666). A similar indicator indicates a system infection.
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 field, which is used by operators when connecting to the backdoor. Any host that tries to connect to the backdoor via 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 an infected server through which stolen data is sent, see.
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 is certainly a complex threat with many interesting features, such as intercepting various functions of an executable file, using POSIX exception handlers, and various methods to mask its presence on the system. Based on the data that we obtained, it can be ascertained that thousands of systems are currently infected with this malicious code. Linux / Ebury is being distributed by cybercriminals using stolen credentials held by operators. Having such data on hand, there is no need to use any 0day vulnerabilities in software or OS for remote installation of this malicious program. Although it’s not clear where the attackers came from the initial data of the system accounts,
