New linux Malware, dubbed Linux/Rakos is threatening devices and servers.The malware is written in the Go language and the binary is usually compressed with the standard  UPX tool.

Linux/Rakos performed via brute force attempts at SSH logins, in a similar way to that in which many Linux worms operate, including Linux/Moose (which spread by attacking Telnet logins)

ESET explains Linux/Rakos obvious aim of this trojan is to assemble a list of unsecured devices and to have an opportunity to create a botnet consisting of as many zombies as possible.

Most of the targeting Devices include both embedded devices and servers with an open SSH port and where a very weak password has been set. Not too extensive list of IP’s spread to targets .only low level of secured devices are most affected by Linux/Rakos,ESET said.

Most users forgot their device that had online service enabled and it was reverted to a default password after a factory reset .but the had reported when they had strong password enabled.In some cases,finally online exposure was enough for such a reset machine to end up compromised.

Threat Analysis method by ESET:

Since Author(s) used GO Language to create this malware binary has actually compromised with standard UPX TOOL.

Researcher’ Explained ,With the help of a script by RedNaga Security that maps symbols back to their respective function in the IDA Pro disassembling software, the whole analysis was simplified to reviewing the features that function names suggested, like main_loadConfig, main_startLocalHttp, main_Skaro_Upgrade, main_IPTarget_checkSSH etc.  There are strings like “Skaro” and “dalek” in the binary.

An example of Linux/Rakos configuration is available on ESET’s Github: https://github.com/eset/malware-ioc/tree/master/rakos.

The attack chain starts with the loading of a configuration file via standard input (stdin) in YAML format, the file contains information like lists of C&Cs, all the list of credentials to use in the brute force attacks against targets devices.

As the second step, the malware starts a local HTTP service available at http://127.0.0.1:61314.

“There are two reasons why this is installed: the first is as a cunning method for the future versions of the bot to kill the running instances regardless of their name by requesting http://127.0.0.1:61314/et; second, it tries to parse a URL query for parameters “ip”, “u”, “p” by requesting http://127.0.0.1:61314/ex. The purpose of this /ex HTTP resource is still unclear at the time of writing and it seems not to be referenced elsewhere in the code.” reads the analysis published by ESET.

The bot scans the SSH service on various IP addresses obtained from the C&C server. Malware researchers also noticed that previous versions of the Trojan also scanned for the SMTP service, a feature that is disabled in current versions.

Main Attack Explained by ESET:

“One of the username:password pairs from the configuration file results in a successful login to one of the target devices connection to target is successful, two commands are run on that newly-accessed victim (id, uname -m), and other checks are performed and their results reported”

“Finally the binary checks whether if it is possible to upload to the new victim and does so if the answer is affirmative”.

“We simulated an attack locally with two targets picked, 127.0.0.1 and 127.0.0.100 (originally, the attackers try 200 simultaneous targets every 10 seconds). Suppose the bot fails to connect to the first one which it then marks as FORGET, while the latter one is successful with the INSTALL notice (a SSH connection was established with the correct shipping:shipping login credentials; also note that the uploaded executable is deleted immediately after execution):”

Mitigation and cleanup:

The trojan isn’t able to maintain persistence after the system is rebooted. Instead, available devices may be compromised repeatedly.

The steps needed to clean up after a compromise are as follows:

• connect to your device using SSH/Telnet,
• look for a process named .javaxxx,
• run commands like netstat or lsof with -n switch to confirm that it is responsible for unwanted connections,
• (voluntarily) collect forensic evidence by dumping the memory space of the corresponding process (with gcore for example). One could also recover the deleted sample from /proc with cp /proc/{pid}/exe {output_file}
• the process with the -KILL

Needless to say that victims have to secure their SSH credentials and have to do that after every factory reset.