Tomcat Under Attack: Exploring Mirai Malware and Beyond

Analysis of Attacks Against Our Tomcat Honeypots

Over a course of two years, we witnessed more than 800 attacks against our Tomcat server honeypots. These attacks exploited a misconfiguration of weak user and password in order to drop a web shell that allowed remote code execution. We found 12 distinct web shells used in these attacks.

The initial access of these attacks is broadly covered below. The payload of these attacks can be divided into 3 types, as depicted in figure 1 below:

1. Mirai botnet: The carried-out impact is mainly consisted of Distributed Denial of Service (DDoS) and cryptomining campaigns.
2. Cryptominers: abusing computation power of the victim’s device to mine bitcoin cryptocurrency.
3. Chaos Malware: an upgraded version of a ransomware variant and lately discovered as a new DDoS malware variant too.

Figure 1: Investigated types of attacks based on detected web shells

Figure 2: Top threat actor IPs initiating the attack

As can be seen in figure 1 above, many of the attacks (~96%) are linked to the Mirai botnet, thus we decided to further analyze this campaign. We found that one of the attack types (152 attacks, ~20%) dropped a shell script called “neww”. A further analysis shows that these attacks originated from 24 unique IP addresses, and as illustrated in figure 2 below ~68% of the attacks originated from a single IP address.

data provided above led us to perform an in-depth analysis of the most common attacks against our Tomcat honeypots, specifically the Mirai campaign.

The Tomcat misconfiguration

First, Apache Tomcat, or Tomcat, is an efficient open-source Java program that functions as a servlet container. It processes and responds to client requests for web pages or data on a web server by passing the request to the appropriate servlet for processing.

After analyzing attacks in general against our honeypots’ environments we learned that threat actors are actively seeking misconfigurations on Tomcat servers. Specifically, misconfigurations in the Tomcat web application manager. The manager app provides the user with the basic functionality needed to manage the deployed web applications. The access to the manager app is restricted by a username and password. The list of authorized users who can access Tomcat resource is specified in the configuration file ‘tomcat_users.xml’ (as shown in figure 3). Threat actors are conducting brute force attacks on the manager app to guess the password.

Figure 3: An example for Tomcat’s configuration file – ‘tomcat_users.xml’

One of our Tomcat honeypots was set with the Apache Tomcat default credentials (tomcat:tomcat).

Attack flow

Figure 4: ‘neww’ campaign attack Flow

Below you can see figure 4, that depicts the Apache Tomcat attack.

Initial Access

Figure 5: Connection to Tomcat web application manager

The threat actor scanned for Tomcat servers and launched a brute force attack against it, attempting to gain access to the Tomcat web application manager by trying different combinations of credentials associated with it. These credentials were added to the request and encoded in base64, as seen in the Authorization field in figure 5. After a few unsuccessful attempts, the threat actor finally succeeded in gaining access to the web application manager on the third try by using the correct combination of credentials.

Once the threat actor gains access to the web application manager, they obtain complete control over the server, including the ability to deploy web applications on a Tomcat server. Tomcat’s web application manager allows users to deploy a directory or a WAR file, which is an archive file format that packages and deploys web applications on the Java platform. The WAR file contains all the necessary files to run a web application, such as HTML, CSS, servlets, and other classes, making it an efficient way to manage web application deployment on a Tomcat server.

Figure 6: VirusTotal scan of ‘cmd.jsp’ web shell

The threat actor utilizes this functionality to deploy a WAR file that contains a malicious web shell class named ‘cmd.jsp’. Using a legitimate action via the manager app (i.e., upload a WAR file) as an attack vector allows the threat actor to masquerade the attack, making it difficult to detect. As illustrated in Figure 6 below, the web shell ‘cmd.jsp’ has been flagged as malicious by 35 vendors on VirusTotal.

Figure 7: ‘cmd.jsp’ web shell

As illustrated in the Java file in figure 7 below, the web shell was designed to listen to requests and execute commands on the server. Thereby, enabling the threat actor to remotely execute code on the Apache Tomcat server.

Execution

After successfully deploying the web shell as part of the WAR file, it remains on the server, allowing the threat actor to send remote commands. As their first command, the threat actor downloads the ‘neww’ shell script, which is designed to execute malware on any architecture it runs on. This script then proceeds to perform the following actions:

1. Change the current directory to the /tmp directory.
2. Use the ‘wget’ or ‘curl’ command to download the malware from the remote server, which is the same server used to download the ‘neww’ shell script.
3. Grant the file execution permissions by using the ‘chmod +x’ command.
4. Execute the malware.
5. Remove the file from the directory using the ‘rm -rf’ command, which is considered a powerful command in Linux, as it forcefully deletes the file regardless of its permissions.

The script contains links to download 12 binary files, and each file is suitable for a specific architecture according to the system that has been attacked by the threat actor.

The file ‘l4sd4sx64′ was downloaded and executed on our honeypot, as it is compatible with our machine’s hardware configuration.

Defense evasion

To conceal their actions and avoid being detected, the threat actor attempts to remove the file that stores the command history of the last 500 commands entered by the logged-in user in Linux. This file is critical as it allows tracking of the user’s actions later. The threat actor is attempting to erase any evidence of their activities during the attack.

Figure 8: Clear command history

Impact

The malware known as ‘l4sd4sx64’ is specifically designed to run on x86-64 systems, which is the type of system we use as our honeypot. This malware is a variant of the infamous Mirai botnet series, which is known to infect devices and execute commands on behalf of a remote controller. In our case, the host was infected with this malware, and based on our analysis of previous attacks and research, it appears that the threat actor intends to use this malware as a base for further attacks. These attacks could range from relatively low-impact campaigns like cryptomining to more severe DDoS attacks.

It is important to note that this campaign is still ongoing, and the attacks are continuously evolving and changing to avoid detection. This is evident in the naming convention of the shell script responsible for downloading the Mirai malware, as well as the varied and different variants of the Mirai malware downloaded onto compromised machines.

Detecting compromised workloads in runtime

The well-known phrase, “An open door invites the thief,” appears to be an appropriate analogy for our attack, with the open door serving as a metaphor for the misconfiguration and the thief being represented by the threat actor. The threat actor scans internet connected environments to find initial access and execute their malicious activities. If such an opportunity exists, it will expose you to immediate risk.

Our investigation involved monitoring the malicious activities of the threat actor on our compromised servers. We first detected new script dropped during runtime. A closer inspection reveals that this is the WAR file which contained the web shell that granted the threat actor remote code execution and further access to the host. We typically don’t expect to see web shells hidden in WAR files uploaded to Tomcat servers and thus this behavior in runtime is suspicious. Next, we observed how the threat actor utilized the web shell to drop and execute a shell script, followed by dropping and executing an executable file, which was identified as the Mirai malware.

Figure 9: CNDR attack flow

Those events were detected by Aqua’s Cloud Native Detection and Response (CNDR) tool, which leverages eBPF technology to detect malicious events in the Linux kernel level.

Guidelines for protecting your environments

In this blog we showed how the Mirai botnet exploits Tomcat servers in the wild. Once the threat actor gained access to the web application manager using valid credentials, they leveraged the platform to upload a web shell disguised in a WAR file. Next, the threat actor executed commands remotely and launched the attack.

Our investigation emphasizes the importance of properly configuring and monitoring runtime environments. We observed how a misconfiguration exposed the server to attacks, potentially resulting in the infection of additional hosts within the same network.

To protect against these kinds of attacks, we recommend following these guidelines:

1. Properly configure your environments – avoid using default settings, and make sure the passwords are aligned with best practice. Regularly rotate secrets and passwords to further secure your environments.
2. Scan your environments for unknown threats – threat actors are becoming more sophisticated, concealing their activity under the impression of legitimate activity, making it challenging to detect their activity. Therefore, runtime detection and response solutions can help to identify anomalies and alert about malicious activity.
3. Equipped your developers, DevOps, and security teams with tools that were designed to scan for vulnerabilities and misconfigurations in cloud native environments.