AhnLab SEcurity intelligence Center (ASEC) is using a Linux SSH honeypot to monitor attacks against unspecified Linux systems. Threat actors install malware by launching brute force and dictionary attacks against Linux systems that are poorly managed, such as using default settings or having a simple password.
While there is a variety of attack cases including those where worms, CoinMiners, and DDoS bots are installed, this post will cover attack cases where backdoor accounts are created instead of malware. Such attacks have been persisting for a long time and many attack logs are still being identified like cases where malware strains are installed.
Attackers may employ various attack methods including adding new accounts, changing the password of the existing root account, and registering an SSH key to log in without entering a password. Accordingly, they can log in to the tampered account later on and control the infected system, ultimately installing various malware strains such as ransomware, CoinMiners, and DDoS bots.
1. Backdoor Account
Maintaining persistence is a technique that allows threat actors to continuously sustain control over the infected system even after the initial attack. Malware strains typically register themselves to the Run key in the registry, Task Scheduler, or a service, maintaining persistence by allowing themselves to be run even after a system reboot. Besides such malware-related techniques, adding a backdoor account is also employed to maintain persistence.
For example, while the Kimsuky threat group uses RATs to control the infected system when attacking Windows systems, it also uses RDP to remotely control the target system in a GUI environment. Accordingly, the Kimsuky threat group installs RDP Wrapper or activates the RDP service in the infected system, then patches the RDP service afterward to allow multiple RDP sessions. Then it adds and conceals a new account so that the account can be used to control the target system thereon [1].
Figure 1. Commands for adding and concealing a user accountThis attack technique of adding a new account in Windows systems is the same for Linux systems as well. Like in attacks against Windows systems, the method of creating a new account is also used in attacks against Linux environments. Of course, threat actors can also change the password of a pre-existing account with a high privilege level like the root account.
For security, instead of using a password. Linux administrators register an SSH key in the SSH server and use the generated key to log in from the client to the server later. In this way, password is not required, and it is possible to log in to the server only from the client that has the key. By using this method, threat actors register a self-generated SSH key in the compromised account and allow themselves to log into the infected system using the key, without needing a password.
2. Attacks Against Linux SSH Servers
Threat actors need to obtain information on the attack target (IP address and SSH account credentials). To do so, they perform IP scanning, searching for servers with the SSH service (port 22) open. Afterward, they attempt to log in by launching brute force or dictionary attacks to find out the ID and password. After successful login, the threat actors execute various commands (described later in this post) to add a backdoor account in the infected system.
| User | Password | Attacker |
| admin1 | admin | 180.151.19[.]85 |
| root | 1234!@#$ | 180.151.19[.]85 |
| svn | svn | 180.151.19[.]85 |
| root | tttttt | 124.221.81[.]81 |
| root | 1QZ2WX3EC | 124.221.81[.]81 |
| 345gs5662d34 | 345gs5662d34 | 124.221.81[.]81 |
3. Analysis of Attack Cases
3.1. Adding a User Account
Threat actors used the commands below to add a new account after successful login. The added account will be used to allow the threat actor to log in to the infected system in the future to install a malware strain or perform various malicious actions.
| Attacker | Added Account | Command |
| 218.75.72[.]82 | tomer | # echo -e “tomer\nsIeI5BHxSX3y\nsIeI5BHxSX3y”|passwd|bash |
| 106.55.28[.]159 | 123456 | # echo -e “123456\nBaPSCgtzh27G\nBaPSCgtzh27G”|passwd|bash |
| 115.219.2[.]97 | username123456 | # echo -e “username123456\nm9qMsqItsEr4\nm9qMsqItsEr4″|passwd|bash |
Such attack logs were identified in multiple attack sources with the account and password differing each time. It seems that there is an automated script that includes commands for adding an account after a successful login. For example, the case where a scanner malware was installed in a compromised Linux system was once covered in the ASEC Blog [2]. If the threat actor had additionally installed a script that adds a backdoor account in systems where login was successful, it would have been possible to automate the attacks.
3.2. Changing the Root Account Password
Multiple cases were identified where the method of changing the pre-existing root account’s password was used, instead of adding a new user account. Root accounts are generally present in Linux systems and have sufficient privileges for controlling the system, so it frequently becomes a main attack target. The threat actor used the following commands to change the root account’s password. As many logs that use these commands are found, it appears that the threat actor installed a script that executes these commands in the target system alongside a scanner malware strain.
| Attacker | Command |
| 106.13.198[.]93 | # echo “root:Kx1ZUAdwqxj4″|chpasswd|bash |
| 175.178.80[.]251 | # echo “root:U356mjT31Wga”|chpasswd|bash |
| 117.50.187[.]121 | # echo “root:gK18riPfcCjG”|chpasswd|bash |
| 47.103.63[.]1 | # echo “root:Mo0ai05lV75A”|chpasswd|bash |
Contrary to this attack type that only executes commands for changing the root account password after logging in, there is also the following case where commands for outputting various information such as the infected system’s OS, hardware, and user information are used. After converting the root account into a backdoor account that only they can access, threat actors would install additional malware strains or sell the credentials on the dark web based on the obtained information.
| # cat /proc/cpuinfo | grep name | wc -l # echo “root:jeEQGchP0tzc”|chpasswd|bash # rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh; pkill -9 secure.sh; pkill -9 auth.sh; echo > /etc/hosts.deny; pkill -9 sleep; # ls -lh $(which ls) # which ls # crontab -l # w # uname -m # cat /proc/cpuinfo | grep model | grep name | wc -l # top # uname # uname -a # whoami # lscpu | grep Model # df -h | head -n 2 | awk ‘FNR == 2 {print $2;}’ |
3.3. Registering an SSH Key
Until now, this post covered attack cases where a user account was added or the password of a pre-existing root account was changed to a format familiar to that of the threat actor. However, there are also multiple cases where an SSH key was created in the compromised system (Linux servers).
While it is possible to use a password when logging into a Linux server using SSH, using an SSH key allows users to log in without entering a password. An SSH key pair (public/private keys) is created for this purpose, and the public SSH key must be installed in the Linux server to log in. Once the public key is installed in the Linux server, the generated private key can be used afterward to log in from the client to the server without needing a password.
Threat actors take advantage of this process to delete the pre-existing SSH public key (“authorized_keys”) file after logging in, then write the newly created public key to the same “authorized_keys” file. Afterward, the threat actor would be able to use the private key created alongside the public key to log into the compromised system.
The following attack is similar to the attack covered above involving a backdoor account being added, but it has an additional process of inserting a public SSH key. By doing so, the threat actor can log into the account they logged into during the attack process using an SSH key or log in using the newly created “student2123” account.
| # cd ~; chattr -ia .ssh; lockr -ia .ssh # cd ~ && rm -rf .ssh && mkdir .ssh && echo “ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr”>>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~ # cat /proc/cpuinfo | grep name | wc -l # echo -e “student2123\nEI8sqWc0mQk3\nEI8sqWc0mQk3″|passwd|bash # ls -lh $(which ls) # which ls # crontab -l # w # uname -m # cat /proc/cpuinfo | grep model | grep name | wc -l # top # uname # uname -a # whoami # lscpu | grep Model # df -h | head -n 2 | awk ‘FNR == 2 {print $2;}’ |
Figure 2. Newly installed public SSH key3.4. Cases of Malware Attacks
A. KONO DIO DA CoinMiner Attack Case
Although the behaviors of creating a backdoor account or SSH key may be used as independent methods of attack, these are sometimes employed together in some attacks. In a past case of KONO DIO DA attacks launched against poorly managed Linux SSH servers, an SSH key file was added simultaneously with the installation of the XMRig CoinMiner [3]. The following compressed file contains a “key” file including the public SSH key, and the malicious Bash script “init0” installs this key. The script first removes the pre-existing “~/.ssh/authorized_keys” key before copying the “key” file into the same path.
Figure 3. Malware strains inside the compressed file used in past attacksThe threat actor can also use the usermod command to add an account called “cheeki”. If the infected system has accounts called “root”, “dolphinscheduler”, “admin”, “es”, or “hadoop”, then the password is changed by the threat actor.
Figure 4. Routine used to maintain persistenceB. DDoS Bot Attack Case (Tsunami and ShellBot)
The behavior of creating an SSH key file was not only detected in cases of attacks where XMRig was installed but also those involving the installation of Tsunami and ShellBot [4]. After successful login, the threat actor downloaded and executed a Bash script. This contains routines to install a CoinMiner, DDoS bot, and log cleaner malware as well as a routine for creating an SSH key file.
Figure 5. Bash script that creates an SSH key file alongside various malware strains4. Conclusion
Attack campaigns where a backdoor account is added to poorly managed Linux SSH servers have been continuously discovered since the past. Threat actors will be able to use the added backdoor accounts to later install malware strains such as ransomware, CoinMiners, and DDoS bots in the compromised system, or sell the credentials collected from the infected systems on the dark web.
Accordingly, administrators must enhance security policies for SSH servers. First, they must use passwords that cannot be easily guessed and change them periodically to protect the Linux servers from brute force and dictionary attacks. Also, for SSH security, SSH key-based authentication must be used instead of passwords. Alternatively, they can deactivate SSH login of the root account and limit SSH access to allowed IP addresses only.
Additionally, to restrict access by attackers, security programs such as firewalls must be used for servers accessible from outside. Finally, to block malware infection in advance, caution must be practiced by updating V3 to the latest version.
ASEC is using a Linux SSH honeypot to collect these attack source IPs in real-time. Confirmed IPs are provided in AhnLab TIP.
Figure 6. Threat IOCs page of AhnLab TIPIOC
Attack Source
– 180.151.19[.]85
– 124.221.81[.]81
– 218.75.72[.]82
– 106.55.28[.]159
– 115.219.2[.]97
– 106.13.198[.]93
– 175.178.80[.]251
– 117.50.187[.]121
– 47.103.63[.]1
Subscribe to AhnLab’s next-generation threat intelligence platform ‘AhnLab TIP’ to check related IOC and detailed analysis information.
The post Threat Actors Installing Linux Backdoor Accounts appeared first on ASEC BLOG.
Article Link: Threat Actors Installing Linux Backdoor Accounts - ASEC BLOG