Skip to content
stellvia.dev

Externally Exposed Services

Initial investigation from outside should identify the next branch to explore, rather than merely list port numbers. Focus here on exposed ports, name-based routing, and Web input surfaces.

Use the evidence labels from the Linux overview. After obtaining a shell, inspect internal services under Network and IPC.

All ports and name-based routing

Section titled “All ports and name-based routing”

Additional check examples:

Terminal window
nmap -sS -A -p- --min-rate 10000 <TARGET_IP>
curl -i http://<HOSTNAME>/
ffuf -u http://<HOSTNAME>/ -H "Host: FUZZ.<DOMAIN>" -w <WORDLIST> -ac
  • Purpose: Identify externally exposed services, HTTP redirects, virtual hosts, and whether SSH is present.
  • Prerequisites: The target must be authorized, such as an HTB machine. -p- adds load and should not be used outside a lab.
  • What to inspect: Nonstandard ports such as 8080, 8888, 9100, and 3000 as well as 22/tcp, 80/tcp, and 443/tcp; HTTP page titles, Server headers, and redirect destinations.
  • Expected output: Did not follow redirect to http://name.htb/, HTTP 401/403, or status codes or response sizes that vary by virtual host.
  • Interpretation: A redirect hostname is a candidate for /etc/hosts and further checks. A virtual host can indicate a separate application on the same IP. Recheck externally filtered ports locally after gaining access.
  • If a check fails: Check DNS and hosts, VPN IP, HTTP versus HTTPS, Host headers, incorrect -ac calibration, and filtering caused by common responses.
  • Alternative commands: rustscan, masscan, curl -H 'Host: ...', feroxbuster --dont-filter.
  • State change: None in principle. Large scans and fuzzing generate logs and load.

If redirect destinations or Host headers change response status or size, names may route to different sites. Add the redirect hostname to /etc/hosts and investigate using that name.

File shares and mail

Section titled “File shares and mail”

Exposed shares such as NFS and mail can provide clues to other hostnames, accounts, or application locations. Record URLs and account names found in shares alongside Web input surfaces. If you changed a file on a share, record its contents too.

Web input surfaces

Section titled “Web input surfaces”

Additional check examples:

Terminal window
feroxbuster -u http://<HOSTNAME>/ -w <WORDLIST> -d 1
curl -i http://<HOSTNAME>/<PATH>
grep -RniE 'fetch|ajax|nonce|upload|api|token|encrypt|decrypt|action' <DOWNLOADED_JS_DIR>
  • Purpose: Find authentication, uploads, admin UIs, APIs, and configuration exposed to the frontend.
  • Prerequisites: Do not confuse where a downloaded file was saved with its path on the target.
  • What to inspect: Nonces, encryption keys, API operations, file uploads, admin bots, machine-learning model registration, and archive processing.
  • Expected output: admin-ajax.php, nonce, ENCRYPTION_KEY, /predict, /upload_*, or /api/... in JavaScript.
  • Interpretation: A value in frontend code cannot be treated as a secret. Check whether it leads to a process running with other privileges, such as stored XSS or model loading.
  • If a check fails: Inspect SPA bundles, source maps, different virtual hosts, the presence of cookies, and HTTP versus HTTPS.
  • Alternative commands: httpx, katana, subjs, browser devtools.
  • State change: Primarily GET requests make no changes in principle. Record anything created by POST or upload tests for cleanup.

Trace which process receives an input as a data flow under Trust Boundaries in Custom Code.