Advanced Nmap: NSE Scripts for Internal Recon in a Simulated Corporate Lab

Nmap is not dead, and anyone who thinks otherwise has never opened /usr/share/nmap/scripts. The Nmap Scripting Engine (NSE) ships more than 600 Lua scripts covering everything from legacy service fingerprinting to Active Directory enumeration via unauthenticated LDAP. Inside a simulated corporate lab built with GOAD or Ludus, NSE replaces dozens of one-off tools and returns structured XML, which makes the whole tooling chain reproducible. This post lays out a reliable three-stage recon flow: broad port sweep, service-specific enumeration, and targeted validation. Before any exotic flag, though, the non-negotiable point is written scope: with no formal authorization, scanning is as wrong as opening someone else's mailbox and, in many jurisdictions, a crime. We assume an owned, isolated, documented lab throughout.

Why NSE instead of ten separate tools

The real value of NSE is consolidation. Instead of running enum4linux, smbmap, ldapsearch, and a dozen Python snippets one after another, a single engine orchestrates the probes and normalizes the output. Scripts carry categories like safe, discovery, intrusive, vuln, and brute, so you steer risk granularly. --script safe runs only non-invasive checks, --script vuln pulls in known-vulnerability checks. That distinction is not cosmetic: in a production-like environment the category decides whether your scan crashes a service. Before using anything, read nmap --script-help <name>, because the docs spell out each script's category, arguments, and side effects.

The lab: GOAD, Ludus, and network isolation

A serious recon lab needs a realistic topology. GOAD (Game of Active Directory) provides a vulnerable multi-domain AD environment, while Ludus automates deploying whole attack ranges on Proxmox. Both live in a segregated VLAN with no route into production. What matters is a separate management interface for your Kali or Parrot VM and a dedicated target subnet such as 10.10.0.0/24. If you do not have a lab yet, Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite is a tight, reproducible reference that works as a starting point and keeps your later recon drills from leaking onto the open network.

Stage one: a clean port sweep

Start with the basics done right. An initial sweep with nmap -sS -p- --min-rate 5000 -oA full_tcp 10.10.0.0/24 gives you a complete TCP inventory in minutes over a /24 with low latency. The SYN scan (-sS) is faster and quieter than a full connect, -p- covers all 65535 ports, and --min-rate sets a floor on packet rate. A focused second pass, nmap -sV -sC -p$(cat ports.txt) -oA versioned -iL hosts.txt, runs the default scripts (safe and discovery categories) against the actual open ports. This two-stage flow avoids the classic sin of launching -A across a full /16, which floods probes, lights up the SIEM, and still leaves you without reliable data. Do not forget UDP: nmap -sU --top-ports 50 finds SNMP, NetBIOS, and IKE that stay invisible in a TCP scan.

Stage two: SMB enumeration

Where NSE truly shines is service-specific enumeration. For SMB, scripts like smb-os-discovery, smb2-security-mode, smb-enum-shares, smb-enum-users, and smb-vuln-ms17-010 reconstruct Windows topology without valid credentials in many cases. A typical invocation is nmap -p445 --script 'smb-os-discovery,smb2-security-mode,smb-enum-shares' 10.10.0.0/24. smb2-security-mode reveals whether signing is enforced, a direct indicator of SMB relay feasibility. smb-enum-shares lists shares with access rights, often exposing anonymously readable directories full of scripts and backups. Watch for guest access and shares like SYSVOL, which in a domain can hold Group Policy Preferences with reversibly encrypted passwords.

Stage two: LDAP and Active Directory

For LDAP, ldap-search with the filter (objectClass=user) surfaces service accounts, descriptions with passwords pasted in them (more common than anyone admits), and weak password policies. The call nmap -p389 --script ldap-search --script-args 'ldap.base="dc=corp,dc=lab"' 10.10.0.10 pulls a surprising amount without a bind. Scripts like ldap-rootdse return naming contexts and functional levels. In a GOAD-style AD environment this recon feeds straight into the attack laid out in Active Directory Pentest: Step-by-Step Kerberoasting in a GOAD Lab, where Kerberoasting depends on SPNs identified during recon. Add krb5-enum-users to confirm valid account names via Kerberos pre-auth responses without generating a login failure.

Web enumeration and HTTP scripts

For web fleets, combine http-title, http-enum, http-headers, and http-methods to map entire application landscapes in seconds. http-enum probes known paths (admin panels, .git, backup files), while http-methods --script-args http-methods.test-all exposes dangerous verbs like PUT. A call such as nmap -p80,443,8080,8443 --script 'http-title,http-headers,http-enum' -iL web_hosts.txt is enough for a first pass. For exposed Java stacks, open Spring Boot Actuator endpoints and unsafe Jenkins configurations are the most rewarding finds, because they often lead straight to remote code execution.

Vuln scripts and credentialed scans

Once you have valid credentials from a foothold, NSE gets much stronger. --script-args smbusername=svc_backup,smbpassword=... unlocks smb-enum-shares and smb-enum-sessions for the authenticated view that stays hidden anonymously. The vuln category bundles checks like smb-vuln-ms17-010, http-vuln-cve2017-5638 (Struts), and ssl-heartbleed; combined with --script-args vulns.showall you also see checks that did not fire. Important: vuln scripts confirm presence, not exploitability. A positive ms17-010 hit in the lab is the starting point for controlled exploitation, never for blind firing at unknown hosts. Document every hit with script name, arguments, and timestamp so the report stays reproducible later.

Parseable output and pipeline

Useful output is parseable output. Always use -oA basename, which produces .nmap, .gnmap, and .xml at once. The XML feeds nmap-parse-output, dnmap, or a custom Python script using python-libnmap. In larger teams, ingesting XML into Elasticsearch and correlating with Sigma rules turns offensive recon into blue team input, closing the loop described in Purple Team in Practice: Building a Red vs Blue Feedback Loop. Avoid dumping raw output into an LLM prompt for a summary: beyond the leakage risk, you lose fields like reason_ttl that are gold for spotting an inline IPS.

Writing custom NSE in Lua

Custom scripts are the real power move. Writing NSE in Lua is simpler than people fear: a single file under ~/.nmap/scripts/ with the three required parts, description, categories, and portrule, plus an action function, already runs. A minimal script defines portrule = shortport.port_or_service(8080, "http-proxy") and calls the http library inside action to build an internal CVE check. After dropping the file in place, refresh the database with nmap --script-updatedb. In an authorized red team engagement it pays to build checks for internal, non-public CVEs. For the pivot phase, Pivoting with Chisel and Ligolo-ng: Segmented Networks in a Pentest Lab picks up assuming recon is already done.

Timing, firewalls, and detection

Mind timing and stateful firewalls. -T4 breaks plenty of old IDS sensors, but today it raises easy alerts in modern XDR. For a realistic lab, tune --max-retries 2, --host-timeout 30m, and --scan-delay 100ms against Suricata NIDS. Use --source-port 53 or --data-length 24 to test sloppy rules that trust the source port, a pattern unfortunately still alive. From the blue team side, a SYN scan across all ports produces a distinctive signature of many half-open connections; Zeek and Suricata catch it reliably. If you work defensively, build detection rules on exactly that and measure your own detection rate against the scans shown here.

Common mistakes and checklist

The most common mistakes: throwing -A at ranges that are too large, ignoring UDP entirely, not saving XML, and treating version guesses as facts. Checklist before every run: (1) written authorization and scope are in hand; (2) the target subnet is isolated; (3) stage one is only -sS -p- with -oA; (4) stage two is -sV --script "safe,discovery" against open ports only; (5) stage three is service-specific NSE, documented per script; (6) UDP top ports checked; (7) all output archived, including failed scans, because they often hint at interesting ACLs worth manual review later.

FAQ

Is -sV safe against production? Usually, but old SCADA and printer stacks are fragile under version probes. Reduce aggressiveness with --version-intensity 2 and exclude fragile hosts. Can NSE crash a target? Yes, especially scripts in the intrusive and dos categories. Stay on safe and discovery unless an explicit engagement covers more, and test every new script in the lab first.

Why do my results differ between two runs? Packet loss, rate limiting, and stateful firewalls make results non-deterministic. Raise --max-retries on lossy paths, lower --min-rate, and always diff the .gnmap of both runs with ndiff. Do I need root for everything? SYN scan (-sS), OS detection (-O), and raw-packet options require CAP_NET_RAW, effectively root. A -sT connect scan runs unprivileged but is louder and slower because it completes the full TCP handshake. Credentialed NSE needs no local privileges, only valid service credentials in the target protocol.

In the end, NSE does not replace thinking. Nmap finds ports and guesses versions; correlating findings, prioritizing exploit paths, and respecting scope limits is still human work. Practical takeaway: build a three-layer pipeline, broad sweep with -sS -p-, enumeration with -sV --script "safe,discovery", and validation with service-specific NSE, always exporting XML for downstream parsing. In two hours you will map a corporate /24 better than many paid automated scanners do. And remember, without written authorization, none of this is a pentest, it is a crime.