The target IP is not directly accessible through a browser, so we create SSH tunneling so that we can access the internal services running on the target machine.

target ip → 154.57.164.71:31282 username → htb-stdnt password → 4c4demy_Studen7

To create SSH tunneling, we use this command:

This allows us to:

• access the internal web app on http://127.0.0.1:1337
• let target access our local server on port 8000
• Receive a reverse shell on port 9001

First, I check whether I can access the app or not by opening:

http://127.0.0.1:1337

It shows:

which confirms the app is running.

Then I started testing endpoints and found the /workflows endpoint. I tested for SSRF using:

And I confirmed that the server is requesting my machine, so SSRF is working.

After that, I tried to get RCE using the Torch workflow archiver:

This created a pwn.war file, but this file alone does not give RCE.

While testing, I noticed the server tries to access:

This means the application is trying to load a Java plugin using SPI (Service Provider Interface).

so the real vulnerability is:

ssrf → remote Java plugin loading → rce

Then I created a Java payload implementing ScriptEngineFactory:

package exploit;

Then I compiled it:

Then I created the required directory structure:

Then I created the final payload archive:

jar -cvf pwn.war META-INF exploit

Then I started a server:

python3 -m http.server 8000

Due to SSH tunneling, the target can access this via 127.0.0.1:8000.

Then I started listening:

nc -lvn 9001

Then I triggered an exploit:

After sending the request, the target loads our Java class and executes the constructor.

Because of reverse port forwarding, the connection comes back to our machine.

Then I got shell in nc and ran:

and got the flag.

This lab shows that this is not just a simple SSRF, but a combination of:

ssrf → remote plugin loading → code execution

Thanks for reading. This lab was a great example of chaining SSRF with Java plugin loading to achieve RCE.