Malware analysis

Stantinko Trojan: What it is, how it works and how to prevent it | Malware spotlight

The number of threats attacking Linux systems have exploded in recent days. Within this context, a botnet that impacted several countries in the past, including Russia, Ukraine, Belarus and Kazakhstan has now again flown under the radar. The Stantinko Trojan, documented by ESET in a full whitepaper in 2017, is a recent variant (version: 2.17) of a Trojan that has been attacking Linux systems since 2012.

In this article, we will discuss this threat, provide in-depth reversing details and explore how to protect our assets against malware of this nature.

Introduction

According to the Intezer analysis which first documented this threat: “Stantinko group is known for targeting Windows operating systems with ongoing campaigns dating back to 2012. The group’s malware mainly consists of coin-miners and adware botnets”.

In 2017, ESET wrote about a Linux variant acting as a proxy behind the operations of the Stantinko group. In a recent campaign, Intezer researchers found a new variant of this proxy Trojan masqueraded as an httpd service. The sample’s version is 2.17, and the older version is 1.2.

Going into detail, we see that the sample was uploaded on November 7th, 2020 from Russia, one of Stantinko’s main target countries.

Figure 1: The sample’s detection report in VirusTotal (7d2a840048f32e487f8a61d7fc1a0c39)

At the first glance, the sample is an unstripped 64-bit ELF binary, probably built using the GCC compiler in a Red Hat environment.

Figure 2: Compilation details — Stantinko Trojan 2020

As observed from the PortEx diagram in Figure 3, the binary is not packed and is not protected against anti-reverse and anti-VM techniques — no packed regions were detected. Some strings can be identified inside the .rodata section, which contains static constants hardcoded in the binary.

Figure 3: PortEx diagram and strings present in the .rodata section of the Stantinko Trojan

How the Stantinko Trojan works

The malware is being used as a proxy agent and is activated through some clients (the bots) also installed on compromised web servers or users’ computers around the world.

Although specific details of this malware are explored below, we would like to focus on this diagram that presents the general workflow of how Stantinko works. In short, an infected client sends a POST or NOTIFY HTTP request to the proxy (1) that then parses the request and passes on a POST request to the attacker’s server (2). After that, the attacker’s server replies to the proxy and the proxy passes on the response to the client (3). Next, a non-infected machine sends a GET request to the proxy (4) and the proxy promptly replies with a 301 redirect to a preconfigured URL (5).

Figure 4: High-level diagram of the Stantinko Trojan

However, the malware has to go through some validation stages to run without restrictions and execute. All details of the analysis are depicted below.

Digging into the reversing details

The following diagram presents the general workflow of Stantinko malware. An interesting detail to observe is that a lot of verifications are executed when the malware is being started. If one of them return false, the malware terminates (the function highlighted in red color on the left side below).

Figure 5: Blocks of code from the main() function of Stantinko Trojan

In detail, all the mentioned verifications are performed based on the parsing of a configuration file probably implanted by crooks in the system along with the Trojan file. As shown in Figure 6 below, upon execution, the malware will validate the configuration file available on the /etc/pd.d/proxy.conf path (see line 10).

Figure 6: main() function and configuration file

After executing and the configuration file exists, an interesting function responsible for parsing the file is invoked inside the LoadConfigFromFile() call. This specific function — ParseConfigElement() — reveals in part the structure of the configuration file that is expected to have the following keys:

• proxy_ip
• port
• redirect_url
• localhost
• ip_header
• request_header_log_files

Figure 7: Function responsible for parsing the configuration file

After loading the configuration into the memory, the daemon starts, as presented in Figure 6 above (start_demon() function). A socket and a listener to accept new clients are created. Create socket (Figure 8) and listener function (Figure 9) are presented in the next images.

Figure 8: create_socket function()

Figure 9: listen_socket() function

Every time a new client is received, the “listen_socket()” function is called. A new thread is created by client (Figure 9 — line 33), and the code inside the “on_client_connect” function is executed. The Stantinko malicious code is here.

Figure 10: Source code of the “on_client_connect” function

This function checks, in the first place, if the request method is a GET, POST or NOTIFY as explained on the high-level diagram in Figure 4.

Figure 11: Malware detects if the request is a GET, POST or NOTIFY

If the request method is a GET, the program will reply with a 301 redirect HTTP response containing the redirect_url parameter from the configuration file. This means that if the C&C IP address is searched, for instance, using a web browser, the request could be redirected to an arbitrary website, leaving no trace or malicious artifacts.

On the other hand, if the request method is a POST or NOTIFY, the Trojan will build a POST request to send the C&C server based on the client’s HTTP request head and content, using the create_post_data() function (Figure 10, line 38).

After that, the malicious program will call the “mysql_server_do_request()” function, which is in charge of sending the POST request to the C&C server.

Figure 12: mysql_server_do_request() function.

The POST request is sent to one of the following paths on the C&C server:

• /kbdmai/index.php
• /kbdmai/dht/index.php
• /kbdmai/DRTIPROV/index.php
• /kbdmai/winsvc/index.php
• /kbdmai/anti_rstrui/index.php

Figure 13: C&C server details extracted from the malware source code

The path of the C&C server is selected in the detect_proxy_script() function, based on the data sent from the client. The C&C server IP address is a parameter loaded from the configuration file.

Figure 14: detect_proxy_script function

According to the Intezer analysis, “they believe that each path delivers a different payload as part of the campaign’s attack chain”.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

Final thoughts

Over the last months, several threads have been developed and improved to take advantage of Linux systems. In fact, Unix operating systems have an important role in infrastructures and businesses these days, and a great part of web-resources available online are running under Linux operating systems as the costs associated are cheaper than using a Windows environment.

In this way, Stantinko is the latest malware targeting Linux servers to fly under the radar, joining other threats such as RansomEXX.

In order to fight these kinds of threats, monitoring should be in place as a mandatory measure to trigger alarms or notify administrators on abnormal activity, such as connections to unknown or untrusted locations. Also, a large or uncommon volume of internet traffic can be detected using some network analyzing software.

Host monitoring is also a good way to detect uncommon traffic or suspicious listener active on Linux systems in an early stage.

Be proactive and start taking malware protection seriously!

 

Sources

Stantinko’s Proxy After Your Apache Server, Intezer

Stantinko Botnet Now Targeting Linux Servers to Hide Behind Proxies, The Hacker News

Stantinko: Teddy Bear Surfing Out of Sight, WeLiveSecurity