Exploiting the JMX Console (A slightly different path to compromise)

by | Jul 19, 2022 | cybersecurity, penetration testing

Print PDF

Submit your email address to access the PDF of this post.

  • This field is for validation purposes and should be left unchanged.

On a recent engagement, the client I was assessing had a relatively strong security posture. None of the old standby attacks were working. The client had disabled LLMNR and WPAD based on a previous security assessment, and all the client’s Windows machines were patched, so there was no easy avenue to compromise the network through something like EternalBlue or BlueKeep. In short, I had to get creative to gain a foothold on their network.

I then used a tool called EyeWitness to manually enumerate webservers on the client’s network. When automated scanning yields few results, this is often a way to determine further avenues of attack. Through using EyeWitness , I found an unsecured Java JMX console. In Nessus, this vulnerability is flagged as “JBoss JMX Console Unrestricted Access” and the console in question looks like this:

JBOSS JMX Console Access

I searched to try to find a way to take advantage of this console and found this blog by Tony Lee and Chris Lee. Using the instructions in their blog, I was able to successfully gain a privileged shell on the host. However, I ran into a few wrinkles that differed from their process. The goal of this blog is to document the process that I used from start to finish.

I first tried to exploit this vulnerability using Metasploit. The relevant modules are exploit/multi/http/jboss_maindeployerand exploit/multi/http/jboss_invoke_deploy. However, in the case of this client, neither of them worked. I got this response from the “jboss_maindeployer “ module.

JBOSS Invoke Deploy

The client was kind enough to provide proof that their antivirus was catching my attempts at using this exploit.

Exploit Antivirus Alert

First, to exploit the JMX console, you need to download the code for the shell. The Lees’ recommended a shell from the Redteam Pentesting group, which I downloaded using wget https://www.redteam-pentesting.de/files/redteam-jboss.tar.gz. At this point, I unzipped the file. Several tools are included in it, but we are concerned with the shell.jsp file for this exploit. In order to deploy it on the JMX server, we need to package it in a WAR file format that the JMX agent can run. We do this by using this command : jar cvf fs.war shell.jsp WEB-INF/

Packaging the shell as a WAR file

Now, we need to find a way for the JMX client to find and run our payload. I did this by starting an Apache webserver on the Kali instance I was using to attack the client and hosting the WAR file on it. Once the web server is started, place the fs.jar file in the /var/www/html directory.

 At first, I had issues with the file being available until I changed both the directory and the file to be world writable by using the chmod command.

Chmod War file

Please note that this is NOT a safe configuration for a regular webserver. I strongly recommend stopping the webserver immediately after deploying the payload as there is the potential to create a backdoor into the attacking host with this configuration.

Now, we are ready to deploy the payload to the vulnerable JMX client. Navigate to the console site and look for the “service=MainDeployer” link.

Payload Deployment

On the page that loads, paste or type the URL for the fs.war payload file and click Invoke.  This will make a GET request to download the malicious code from the attacker machine and host it on the Java webserver.

Malicious Code Get Request

If the payload is successful, we will be notified by a success message. Now we are ready to start exploiting however we would like. Start by going to the shell page (“ip.address.of.host:8080/fs/shell.jsp?pass=secret”). The top box can be used as a privileged Windows shell by typing the command we’d like to use and clicking Run.

Successful Payload

One way that I like to exploit is by creating a local administrator on the host and then using crackmapexec to obtain password hashes from running memory on the host:

net user username password /add 

net localgroup administrators username /add

Local Admin Creation

Finally, we need to clean up our exploit to avoid detection and to protect the client for other attacks. This is done by destroying the shell running on the JMX console. We can do this by finding the process running on the console. After clicking that link, click the “Invoke” button under the “void destroy()” function, as shown below.

Exploit Cleanup