Tomcat Under Attack: Exploring Mirai Malware and Beyond

A recent Java Developer Productivity Report  showed that almost 50% of developers are using Apache Tomcat, indicating its widespread usage in the cloud, big data and website development. We will begin by presenting statistics and examples from recent attacks. Afterward, we will delve into a detailed analysis of a single attack directed at one of our Apache Tomcat honeypots.

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.
Investigated types of attacks based on detected web shells 

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

Top threat actor IPs initiating the attack 

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.

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

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

‘neww’ campaign attack Flow

Figure 4: ‘neww’ campaign attack Flow

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

Initial Access

Connection to Tomcat web application manager

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.

 VirusTotal scan of 'cmd.jsp' web shell

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.

 'cmd.jsp' web shell

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(a) figure8(b)

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.

CNDR attack flow

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.

Indications of Compromise (IOCs)

Attacker IP Malware host
104.248.157.218 198.50.135.105
Files
Name Type SHA256
cmd.jsp Text file 0515cd2ba84a5da10c63cadae06f04d778d66c054b9184edb57be6ea95a1095b
neww Shell script 997f303c3696788923e41d35a26fc2c79a11ec34389028d81a6fb43f8c11aecf
l4sd4sx64 Binary 0df529cbb87b51c91f4b98bfe4600627a8fce66ec12b8a3bad59fccf6779f679
l4sd4s86 Binary 489ac3fdefac8d07e198c0c6346c9c9ae7c141a86ef3ec1720f61d171862a87a
l4sd4sm4 Binary 8ada5545b85c18d24a914e4b46f3275fca2d360ca5bfb91bf3ee4e7fde667065
l4sd4s8k Binary 9d4963fa1b4d2bb576ac801c4a1efa5a0758d615aaa7d9cc5ae27f7955f67dee
l4sd4sm6 Binary 35bb6ca1389fd3f4343090135ff11a69bc4315b1e46bd789301d675da813028d
l4sd4sspc Binary 2ee307971d8529b2a882b194b30d7e439db3d0b51ccbf5bf5fedb5deb1116606
l4sd4ssl Binary ce718bf0fefb061bafd115639f6942b11ef3ac96e74a6b4fc19710e9e03a083a
l4sd4sm5 Binary 5ee119fe3ce335200a2f029625bf9fa3ec495b8322093b59528029e1d6c9b69f
l4sd4sm7 Binary a0fcc70704a49c38f1e7b9bbdc5fddd83ebd23da748b796d46e8211b86c5c3d6
l4sd4spc Binary bcc98241024fa6c1d0d1f2b48b9d4b9b8558de07621dcf109eaf9d18815018b8
l4sd4sps Binary b0731816f2363f9afbfc05797ced85ce137b9fa7d8d92f423edd4ff32feeda2d
l4sd4sh4 Binary 696d3c58966d2e742cb02f34866d456413920fb83d3cb5ee49d285998167f6ff
.jsp files detected in the wild
Name Type SHA256
nmapunix.jsp Text file 690f7d22545b0c59fe638082bac2bc5fd35214008d5065bf773ea57f0bfd1789
sc.jsp Text file c086430aed0607ee6291402d16969a10ba8aaab81421aa5fae5085e3b5dd56bb
6888.jsp Text file d0ad85e652e2c6091af6f347aef9e918c954580609f715e376226edd12b5bc15
index.jsp Text file 5407cc0b19573b6c807b7fcb188aa3af3e762cf9c65379cd8f70d815f89283dc
7.jsp Text file 7b108418d450682e2c7f1acbef0e546a622bb73e829682fdbcc0dc8fc3e4876f
win.jsp Text file 4c2969c6f81043985c73547096498df064ca2d8e77c5d9ec8a47925a77ce776b
cmd.jsp Text file 99b96d232693a7de6899e47b0da66af59a7eb7cbc3b9fadd8b88039e714e23f1
test03.jsp Text file 6eadfab5438dc777b4abff3bee5d6d8d0043ea2cfade18af1e71eae16f3b0bd2
_sysrv_int.jsp Text file 11bcad6663b6ba025c4d9b6e80dbc5d5f103c5b9977ff8f138ca1c8486b7e0a7
_bd.jsp Text file 519dd6c3d0e5e022c63ad7b892f5ac51e6dc9d047c03e91510b4bcbabea24d58

Source: https://blog.aquasec.com/tomcat-under-attack-investigating-the-mirai-malware