Walkthrough Preview

This preview covers the initial reconnaissance and discovery of Bedside's research upload portal. The remaining walkthrough is being held back while the machine is active.

Environment & Scope

1. Host Discovery & Port Enumeration

I began with a full TCP port scan and service/version detection. The scan identified SSH and Apache, while TCP port 3000 appeared filtered from the attacking machine.

nmap -sCV -p- --min-rate 5000 -Pn \
  -oN nmapfirstScan.txt 10.129.248.191

PORT     STATE    SERVICE VERSION
22/tcp   open     ssh     OpenSSH 10.0p2 Debian 7+deb13u4
80/tcp   open     http    Apache httpd 2.4.68
3000/tcp filtered ppp

The web server redirected requests to bedside.htb, so I mapped the hostname to the target in /etc/hosts.

echo "10.129.248.191 bedside.htb" | sudo tee -a /etc/hosts
curl -i http://bedside.htb/

The main site was a mostly static clinic landing page. It did not expose an obvious login form or application workflow, so I continued with content and virtual-host enumeration.

2. Virtual Host Discovery

I used ffuf to vary the HTTP Host header while keeping the target IP fixed. This identified a second virtual host named research.bedside.htb.

ffuf -u http://10.129.248.191/ \
  -H "Host: FUZZ.bedside.htb" \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -ac -c -t 40 -rate 50 \
  -o vhosts.json -of json

research  [Status: 200, Size: 3152]

I added the discovered name locally and inspected the new application.

echo "10.129.248.191 research.bedside.htb" | sudo tee -a /etc/hosts
curl -i http://research.bedside.htb/

3. Research Portal & File Upload

The research virtual host exposed a multipart upload form. The file input was named uploadFile. The response also included X-Powered-By: pdfminer.six, which became an important lead.

<form method="post" enctype="multipart/form-data">
  <input type="file" name="uploadFile" required>
  <input type="submit" value="Upload File">
</form>

The portal listed image formats and PDF as accepted types, and its notice mentioned archive uploads. I tested harmless PNG, PDF, and ZIP files. All three uploads returned a success message. Gobuster also identified an /uploads/ directory. Directory listing returned HTTP 403, but files could be retrieved when their names were known.

gobuster dir \
  -u http://research.bedside.htb/ \
  -w /usr/share/wordlists/dirb/common.txt \
  -x php,txt,html,bak,old \
  -t 25 -o research-gobuster.txt

# Verify a known uploaded file
curl -i http://research.bedside.htb/uploads/probe.pdf

SHA-256 comparisons showed that the retrieved files were byte-for-byte identical to the originals. The ZIP was stored unchanged; the test archive's member was not found at the two obvious extraction paths, so extraction was not assumed.

← all walkthroughs