SEC504 - Hacker Tools, Techniques, and Incident Handling
Lab 2.1 - Network Discovery and Service Enumeration with Nmap
Solo, Lab
Focus: Network Reconnaissance
Level: SEC504
Date: Jun 2026
Artifacts: Sanitized Nmap terminal output from the SEC504 Slingshot Linux lab against the 172.30.0.0/24 range
TL;DR
- •A privileged ARP ping sweep (sudo nmap -sn) found a live host the unprivileged sweep missed entirely
- •Mapped services with full-range -sT -p 1-65535 then -sV: caught Dropbear SSH hiding on port 2430, plus nginx and MariaDB
- •NSE scripts found an unauthenticated MongoDB 5.0.27 (enumerated its databases) and an SMB server not requiring message signing
Skills demonstrated
Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.
Why this matters
Nmap is the first tool on both sides of an engagement: attackers map your attack surface with it, and defenders use the exact same output to find the exposures before someone else does. Knowing the funnel (discovery, ports, versions, scripts) and reading the results critically is what turns a wall of port numbers into actionable findings like 'this MongoDB answers queries with no password.' The unprivileged-vs-privileged contrast also teaches a lesson that bites real assessments: the scan technique you choose determines what you are even able to find.
Context
This lab works the full Nmap reconnaissance funnel against a lab subnet (172.30.0.0/24): start with host discovery, narrow to open ports, fingerprint service versions, and finally run NSE scripts to extract detailed configuration from the interesting services. It also contrasts unprivileged and privileged scans to show how scan technique changes what you can see, and ends by finding three real misconfigurations: SSH hidden on a non-standard port, an unauthenticated MongoDB instance, and an SMB server that does not require message signing.
Tools used
Steps taken
1Host 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-nno reverse-DNS-snhost discovery only, no port scansudoenables ARP discovery + MAC resolution on the local segment2Default 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-sTfull TCP connect scan-p 1-65535every TCP port, not just the top 10003Version-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-sVprobe open ports to identify the service and versionVersion detection corrects Nmap's port-number guesses4Find 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.265NSE 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-sCrun the default safe NSE script category-oNwrite normal (human-readable) output to a file6Targeted 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 category7Scan .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/445runs the SMB/NetBIOS NSE scripts (nbstat, smb2-security-mode, smb2-time)Key findings
Outcome / Lessons learned
Worked the Nmap funnel end to end on 172.30.0.0/24 and surfaced three concrete misconfigurations. A privileged ARP sweep found a host (172.30.0.26) the unprivileged sweep missed; full-range scanning plus -sV caught Dropbear SSH hiding on port 2430 alongside nginx and MariaDB on .20; NSE confirmed an unauthenticated MongoDB 5.0.27 on .26 by listing its databases; and SMB scripts on .114 (FILESTOR) showed message signing was not required. The MongoDB evidence was saved with -oN for reporting.
Treat the unauthenticated MongoDB as a critical: enable authentication, bind it to localhost or a private interface, and firewall 27017 immediately, then audit access logs for prior unauthorized reads. Move Dropbear SSH back to a managed port behind key-based auth and monitoring, since a non-standard port is obscurity, not security. Enforce 'require message signing' on the FILESTOR SMB server to close the relay path. Schedule recurring authenticated Nmap (or a dedicated scanner) sweeps and diff results over time so newly exposed services and version drift get flagged automatically.
Security controls relevant
- 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
What I took away from this
The unprivileged-versus-privileged contrast is the most important lesson in this lab, and it is easy to skip past. The plain nmap -sn sweep reported four hosts; the sudo sweep reported five, and the extra host (172.30.0.26) was the one running the unauthenticated MongoDB. On a local segment, root lets Nmap use ARP, which finds hosts that ignore ICMP. If your assessment methodology only ever runs unprivileged discovery, the single worst exposure on the network can be invisible to you and fully visible to an attacker already on the segment.
Version detection earns its runtime every time. Nmap's bare port scan labeled 2430 as 'venus' from its static port-to-name table, which is meaningless. Only -sV revealed it was Dropbear SSH on a non-standard port, a deliberate attempt to hide a remote-access service from anyone scanning the usual port 22. Reading the port number alone would have missed it entirely; the version banner is what turns a number into a finding.
The MongoDB result is the kind of finding that still causes real breaches. A database listening on its default port that answers a stranger's NSE script with its full database inventory and no password is not a theoretical risk. Exposed MongoDB instances have leaked enormous datasets for exactly this reason. Nmap found it in seconds with -sC. The same scan a defender runs to catch this is the scan an attacker runs to exploit it, which is the whole argument for scanning your own surface first and on a schedule.