I85PREP
⌘ K
OSCP study materials
OSCP study resources

Four Services, One Scope Entry: Deciding What Deserves the Minutes

OSCP · Put your knowledge to work in context.

All case studies

Four Services, One Scope Entry: Deciding What Deserves the Minutes

You have a single in-scope host, 10.10.10.45, no credentials, and a hard stop in six hours. A full TCP scan returns 22/tcp OpenSSH 8.2p1 (Ubuntu), 80/tcp Apache 2.4.41 serving the stock "It works" page, 8080/tcp Apache Tomcat 9.0.31 returning 401 on /manager/html, and 8443/tcp presenting a self-signed certificate with CN=internal.corp and a Tomcat-style error page. robots.txt on port 80 lists only /backup/, which returns 403. Directory brute forcing on port 80 with a 4,600-word list produces nothing beyond /index.html and /backup/. Default credentials tomcat:tomcat and admin:admin both fail against 8080. The AJP port 8009 is not in your scan output because you only scanned TCP top-1000 plus a handful of common ports.

1. Rank the four services by expected return per minute and state the single piece of evidence that would make you abandon each lead.

Read the worked answer

Priority order: 8443, then 80 with Host headers, then 8080, then 22.

8443 first. A self-signed certificate with CN=internal.corp is the only artefact on the box that names something you have not tried. It tells you a name-based site probably exists, and the Tomcat error page tells you it is not just a TLS wrapper around a static site. Evidence to abandon: after adding internal.corp to /etc/hosts, the response body, headers and error page are byte-identical to the bare-IP request, and openssl s_client shows the same certificate whether or not SNI is sent.

80 with Host headers second. The stock page plus a 403 /backup/ is a classic vhost-fallback signature: the default vhost answers, the real site waits on a name. Evidence to abandon: every candidate name returns the same Content-Length and the same ETag as the IP request.

8080 third. A 401 on /manager/html is a credential problem, not an exploit, unless the version is vulnerable. Evidence to abandon: version is patched for known manager CVEs, AJP is closed, and the small credential set derived from the certificate name fails.

22 last. No usernames yet, and SSH is rarely the entry point on these boxes. Revisit only after a name or credential appears.

2. Without a wordlist, how do you determine whether 8443 hosts a distinct application from the one on port 80?

Read the worked answer

Compare behaviour, not ports.

  1. Request the same paths (/, /manager/html, a deliberately invalid path) on both ports and diff status code, Server, Content-Length, ETag and body length. Identical ETags or identical 404 bodies mean one backend behind two connectors.
  2. Send Host: internal.corp to port 80 and to port 8443. If port 80 suddenly stops returning the stock page, the default vhost is masking a name-based site and 8443 is likely the same site with TLS.
  3. Check the certificate on both ports with openssl s_client -connect 10.10.10.45:8443 -servername internal.corp. If SNI changes the certificate, there are multiple TLS sites sharing the port.
  4. Look for a redirect: a plain-HTTP request to a vhost often 301s to the HTTPS name, which confirms the pairing in one request.

The judgement being tested: do not start brute forcing vhosts until you have extracted every name the server already volunteered (CN, SAN, redirects, cookies, error pages). Names are cheap; requests are not.

3. The Tomcat manager returns 401. What are the legitimate moves, and when do you stop?

Read the worked answer

Enumerate before attacking.

  • Fetch /manager/html and read the WWW-Authenticate realm; check whether /host-manager/html and /examples exist. Examples deployed on old Tomcat is a much easier path than the manager.
  • Rescan for 8009/tcp. CVE-2020-1938 (Ghostcat) is an AJP file-read/include bug and is invisible to a scan that never touched 8009; your 9.0.31 build is right in the affected range.
  • Check whether the manager is in PUT-enabled mode (CVE-2017-12617 needs readonly=false); a PUT to /x.jsp/ returning 201 settles it in one request.
  • Only then try credentials, and only credentials you already have evidence for: the certificate name, usernames from the 403 directory, common ops patterns. Blind guessing of a manager login is almost always rate-limited or logged, and on this box it also burns the clock.

Stop rule: if the small credential set fails and 8009 is closed, the manager is a dead end today. Write it down, move to the vhost lead, and revisit only if you recover a password hash elsewhere that you can test cheaply.