I recently completed the Silver Platter room on TryHackMe, and while it’s tagged as “Easy,” it definitely had its moments. What started out as routine enumeration turned into a lesson in logic flaws, persistence, and the value of reading CVEs carefully.
Initial Recon
Running rustscan gave me a few open ports :
rustscan -a 10.10.137.83 -r 1-65535
.----. .-. .-. .----..---. .----. .---. .--. .-. .-.
| {} }| { } |{ {__ {_ _}{ {__ / ___} / {} \ | `| |
| .-. \| {_} |.-._} } | | .-._} }\ }/ /\ \| |\ |
`-' `-'`-----'`----' `-' `----' `---' `-' `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: https://discord.gg/GFrQsGy :
: https://github.com/RustScan/RustScan :
--------------------------------------
Please contribute more quotes to our GitHub https://github.com/rustscan/rustscan
[~] The config file is expected to be at "/home/kali/.rustscan.toml"
[!] File limit is lower than default batch size. Consider upping with --ulimit. May cause harm to sensitive servers
[!] Your file limit is very small, which negatively impacts RustScan's speed. Use the Docker image, or up the Ulimit with '--ulimit 5000'.
Open 10.10.137.83:22
Open 10.10.137.83:80
Open 10.10.137.83:8080
[~] Starting Script(s)
[>] Script to be run Some("nmap -vvv -p {{port}} {{ip}}")
[~] Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-07-14 23:22 IST
Initiating Ping Scan at 23:22
Scanning 10.10.137.83 [4 ports]
Completed Ping Scan at 23:22, 0.26s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 23:22
Completed Parallel DNS resolution of 1 host. at 23:22, 1.03s elapsed
DNS resolution of 1 IPs took 1.04s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating SYN Stealth Scan at 23:22
Scanning 10.10.137.83 [3 ports]
Discovered open port 8080/tcp on 10.10.137.83
Discovered open port 22/tcp on 10.10.137.83
Discovered open port 80/tcp on 10.10.137.83
Completed SYN Stealth Scan at 23:22, 0.28s elapsed (3 total ports)
Nmap scan report for 10.10.137.83
Host is up, received reset ttl 60 (0.21s latency).
Scanned at 2025-07-14 23:22:55 IST for 0s
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack ttl 60
80/tcp open http syn-ack ttl 60
8080/tcp open http-proxy syn-ack ttl 59
Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.81 seconds
Raw packets sent: 7 (284B) | Rcvd: 4 (172B)- 22 (SSH)
- 80 (HTTP)
- 8080 (HTTP Proxy)
A classic start. I dove into port 80 first, hoping to find something useful.
Exploring Port 80: Mostly Static, Some Hints
Using gobuster and dirbuster, I found the usual suspects like /assets/, /images/, and an index.html. Nothing fancy.
dirbuster
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
Starting OWASP DirBuster 1.0-RC1
Starting dir/file list based brute forcing
Dir found: / - 200
Dir found: /images/ - 403
Dir found: /assets/ - 403
Dir found: /assets/js/ - 403
File found: /assets/js/jquery.min.js - 200
File found: /assets/js/browser.min.js - 200
File found: /assets/js/breakpoints.min.js - 200
File found: /assets/js/main.js - 200
File found: /assets/js/util.js - 200gobuster dir -u http://10.10.137.83 -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -t 60
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.10.137.83
[+] Method: GET
[+] Threads: 60
[+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/assets (Status: 301) [Size: 178] [--> http://10.10.137.83/assets/]
/images (Status: 301) [Size: 178] [--> http://10.10.137.83/images/]
/index.html (Status: 200) [Size: 14124]
Progress: 4734 / 4735 (99.98%)
===============================================================
Finished
===============================================================Here’s what we’ve found till now….
| Finding | Insight |
|---|---|
/contact | Contains clue about a user: scr1ptkiddy |
| Mention of Silverpeas | Potential target application; user enumeration or misconfig could lead to RCE |
| Form doesn’t submit anywhere | Likely static or dummy |
| POST not allowed | Confirms nothing handled server-side at root |
| No dynamic JS / fetch | No JS-based submission |
| Gobuster output | Only /images/ and /assets/ — no auth, login, or dynamic dirs |
But then I stumbled on a subtle clue inside the /contact page: a username, scr1ptkiddy.
No login form or dynamic interaction here, everything seemed static. Even POST requests were being rejected. Looked like a dead end
Digging Deeper: Silverpeas
After exhausting directory scans, I focused on port 8080, which turned out to be hosting the Silverpeas application.
gobuster dir -u http://10.10.137.83:8080/ -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -t 60
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.10.137.83:8080/
[+] Method: GET
[+] Threads: 60
[+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/console (Status: 302) [Size: 0] [--> /noredirect.html]
/console/base/config.json (Status: 302) [Size: 0] [--> /noredirect.html]
/console/payments/config.json (Status: 302) [Size: 0] [--> /noredirect.html]
/website (Status: 302) [Size: 0] [--> http://10.10.137.83:8080/website/]
Progress: 4734 / 4735 (99.98%)
===============================================================
Finished
===============================================================What we found till now is summarized here →
| Path | Response | Notes |
|---|---|---|
/console | 302 → /noredirect.html | Likely protected |
/console/base/config.json | 302 → /noredirect.html | Sensitive path |
/website/ | 403 Forbidden | Exists but access restricted |
| Port 8080 | Serves app with auth/redirection control | |
| No access via headers or host manipulation | ✅ Tried all relevant tricks | |
| whatweb | Not much info (probably custom or Java-based) |
Testing for SilverPeas
| URL Tested | Result | Notes |
|---|---|---|
/silverpeas | 302 Found | Redirects to /silverpeas/ – good indicator! ✅ |
/services, /RssService, /website/login, etc. | 404 Not Found | Not available, might not be deployed or renamed |
/website/modules/jsp/preview_jsp.jsp | 404 Not Found | Endpoint doesn’t exist, might be a different structure |
Scanning for any SilverPeas directory….
gobuster revealed the /silverpeas/ directory, which redirected me to a login page.
http://10.10.137.83:8080/silverpeas/ → http://10.10.137.83:8080/silverpeas/defaultLogin.jsp
Perfect – finally something dynamic!!!
I hit it with hydra and several password lists (rockyou, xato, etc.), but nothing worked. Stuck again.
This is where I cheated a bit. I checked out a write-up, and learned the app was vulnerable to CVE-2024-36042, a logic flaw where removing the password parameter entirely from a POST request allows a user to log in.
Yep, you read that right. No brute-force needed. Just drop the password field.
Logged in as scr1ptkiddy, grabbed the API token, and explored the app further.
From scr1ptkiddy’s token, I pivoted to other users within the app, testing the same login bypass technique. It worked again…..even for users with higher privileges like Manager and Tyler.
tim@silver-platter:/var/log$ grep -iR tyler
Using these creds to login as Tyler and then escalating to root
Silver Platter might be labeled “easy,” but it was a great reminder of how simple logic bugs can have massive security implications. Forget brute-forcing and fuzzing for a second, sometimes, it’s about understanding how a web app handles (or mishandles) its inputs.
Key takeaway: Always read CVEs. Sometimes the smallest clue can save you hours of rabbit holes.
Feel free to follow along or reach out if you want to try some other room together like this room too!
If you’re as passionate about Cyber-Security as I am, feel free to follow me on Twitter – @shrisec for the latest updates and connect with me on LinkedIn – Aditya Narayan to stay in the loop with my posts and insights in the upcoming projects and CTF writeups.
Let’s continue this fascinating journey together!