Lab 2.1 - Network Discovery and Service Enumeration with Nmap

Network Reconnaissance | SEC504 | Jun 2026

Ran the Nmap recon funnel across 172.30.0.0/24: a privileged ARP ping sweep (sudo nmap -sn) found a host (172.30.0.26) that the unprivileged sweep missed, then full TCP connect scans (-sT -p 1-65535) and version detection (-sV) mapped the services. Findings included Dropbear SSH 2022.83 hiding on non-standard port 2430 plus nginx and MariaDB on 172.30.0.20, an exposed MongoDB 5.0.27 on 172.30.0.26 that the mongodb-databases NSE script enumerated without authentication (config, local, admin, builds), and an SMB/NetBIOS server (FILESTOR) on 172.30.0.114 whose smb2-security-mode reported message signing enabled but not required. Saved the MongoDB scan with -oN for reporting.

Tools: Nmap 7.60, NSE (mongodb-databases, smb2-security-mode, nbstat), Slingshot Linux, CLI

Commands

1. Host discovery, unprivileged then privileged

Ran a no-port ping sweep of the whole range: nmap -n -sn 172.30.0.1-254 found 4 hosts up (.1, .20, .114, .152). Re-running the same sweep with sudo found 5 hosts up, including 172.30.0.26, and returned MAC addresses. With root on the local segment Nmap uses ARP for discovery, which finds hosts that ignore ICMP and the unprivileged TCP probes. A host you never discover is a host you never assess.

nmap -n -sn 172.30.0.1-254
sudo nmap -n -sn 172.30.0.1-254

-n: no reverse-DNS -sn: host discovery only, no port scan sudo: enables ARP discovery + MAC resolution on the local segment

2. Default then full-range TCP scan of .20

Scanned 172.30.0.20 with a TCP connect scan. The default top-1000 ports showed 23/telnet filtered, 80/http open, 135/msrpc filtered, 443/https open, 445/microsoft-ds filtered, and 3306/mysql open. Re-running across all 65,535 ports (-p 1-65535) surfaced one more: 2430/tcp open, labeled 'venus' by Nmap's port-to-service guess. The lesson is that the default scan misses high ports, and attackers deliberately park services up there.

sudo nmap -n -sT 172.30.0.20
sudo nmap -n -sT -p 1-65535 172.30.0.20

-sT: full TCP connect scan -p 1-65535: every TCP port, not just the top 1000

3. Version-detect the .20 services

Ran -sV against the open ports (80, 443, 2430, 3306). The versions told the real story: 80 and 443 were nginx, 3306 was MySQL 5.5.5-10.11.6-MariaDB, and 2430, the port Nmap had guessed as 'venus', was actually Dropbear sshd 2022.83 (SSH protocol 2.0). SSH on a non-standard high port is a classic move to slip past port-based monitoring; only version detection, not the port number, reveals it.

sudo nmap -n -sT -sV -p 80,443,2430,3306 172.30.0.20

-sV: probe open ports to identify the service and version Version detection corrects Nmap's port-number guesses

4. Find and version-detect MongoDB on .26

Full-range scanned 172.30.0.26 (the host only the privileged sweep had found): 80 and 443 filtered, but 27017/tcp open, which is MongoDB's default port. A targeted -sV confirmed MongoDB 5.0.27. Port 27017 reachable from the network is itself a finding worth chasing, because MongoDB has a long history of being deployed with no authentication.

sudo nmap -n -sT -p 1-65535 172.30.0.26
sudo nmap -n -sT -p 27017 -sV 172.30.0.26

5. NSE enumeration of MongoDB and save output

Ran the default script set (-sC) against port 27017. The mongodb-databases and mongodb-info scripts answered with no authentication: a full database listing (config, local, admin, builds with sizes on disk), build info, version 5.0.27, and the OpenSSL/storage-engine details. An unauthenticated MongoDB exposed to the network is a critical finding: anyone who can reach the port can read the data. Re-ran with -oN nmap_mongodb_scan.txt to save the evidence for the report, then confirmed the saved file with head.

sudo nmap -n -sT -p 27017 -sC 172.30.0.26
sudo nmap -n -sT -p 27017 -sC -oN nmap_mongodb_scan.txt 172.30.0.26
head nmap_mongodb_scan.txt

-sC: run the default safe NSE script category -oN: write normal (human-readable) output to a file

6. Targeted mongodb-databases script

Ran a single NSE script directly with --script mongodb-databases to re-pull just the database inventory (builds, admin, local, config) in 0.50 seconds. Targeting one script instead of the whole default set is faster and produces a cleaner artifact when you already know exactly what you want to confirm.

sudo nmap -n -sT -p 27017 172.30.0.26 --script mongodb-databases

--script <name>: run a specific NSE script instead of a category

7. Scan .114 and enumerate SMB

Full-range scanned 172.30.0.114: 139/netbios-ssn and 445/microsoft-ds open. Running default scripts on those ports returned the SMB host scripts: nbstat resolved the NetBIOS name FILESTOR, and smb2-security-mode reported SMB 2.10 with 'Message signing enabled but not required.' Signing enabled-but-not-required leaves the server open to SMB relay attacks, because a man-in-the-middle can strip the optional signing. The name FILESTOR also hints at a file server worth prioritizing.

sudo nmap -n -sT -p 1-65535 172.30.0.114
sudo nmap -n -sT -sC -p 139,445 172.30.0.114

-sC on 139/445: runs the SMB/NetBIOS NSE scripts (nbstat, smb2-security-mode, smb2-time)

Key Findings

Privileged ARP sweep found 172.30.0.26, which the unprivileged ICMP/TCP sweep missed
172.30.0.20: nginx (80/443), MariaDB 10.11.6 (3306), and Dropbear SSH 2022.83 on non-standard port 2430
172.30.0.26: MongoDB 5.0.27 on 27017 enumerable without authentication (config, local, admin, builds)
172.30.0.114 (FILESTOR): SMB 2.10 with message signing enabled but not required (relay-exposed)
Saved MongoDB NSE output to nmap_mongodb_scan.txt with -oN for reporting

Security Controls

Authentication and network binding on database services (MongoDB)
Host-based and network firewalls restricting management ports
Mandatory SMB message signing to prevent relay attacks
Key-based SSH on managed ports with monitoring (not port obscurity)
Recurring authenticated vulnerability/port scanning with diffing
Network segmentation limiting east-west reachability to services