Nmap as a Decision Engine: Operating Under Pressure During a Red Team Engagement

1. Entry Point Thinking: The Clock is Ticking

The Rules of Engagement (RoE) are signed. We have exactly four hours to map an undocumented /24 subnet, identify an exploitable external entry point, and prove impact without tearing down production. There is no prior asset inventory, and we know an active Intrusion Prevention System (IPS) is in line.

Before I even touch a terminal, my first question is never “What tool do I use?” It is “How noisy can I afford to be, and what constitutes a win?” The goal isn’t to build a beautiful network map; it’s to find one crack in the armor fast. The most dangerous assumption right now is trusting ICMP. If I assume hosts are dead because they don’t respond to a ping, I lose.

2. The First Scan Decision: Speed vs. Truth

If you run nmap -A across a /24, you’ve already failed. It is deafeningly loud, agonizingly slow, and immediately burns your IP address in the SOC. My first move is pure discovery. I need to know who is home without triggering the alarm bells.

nmap -sn -PE -PP -PS21,22,23,25,80,113,443 -PA80,113,443,10025 --source-port 53 203.0.113.0/24 -oA initial_sweep

Why this command? Standard -sn ping sweeps are blocked by default Windows firewalls and perimeter gateways. I’m forcing Nmap to throw a surgical mix of ICMP Echo, Timestamp requests, and highly specific TCP SYN/ACK packets disguised as returning DNS traffic (--source-port 53).

What I expected: 30-40 live hosts. What I got: 4.

3. When Things Go Wrong: The Silent Drop

Only four hosts returning traffic on a /24 corporate subnet is highly suspicious. I’m hitting a wall. The packets aren’t being rejected (TCP RST); they are being silently dropped. This screams stateful firewall inspection. If I just up the speed (-T4), the firewall will throttle me harder or blacklist me.

I have to adjust. I need to bypass the state table.

nmap -sA -T2 203.0.113.0/24

I switch to a TCP ACK scan (-sA). I’m not looking for open ports; I want to map the firewall rules. If a port responds with a RST, the port is unfiltered. If it drops, it’s blocked. I slow the timing to T2 to slip beneath the IPS rate-limit velocity. Suddenly, I see a pattern: the firewall is strictly filtering inbound TCP, but it’s wildly inconsistent above port 10000.

4. Attack Surface Expansion: The Hidden Depths

I have three target IPs verified alive and bypassing stateful filters on high ports. It’s time for extraction. I can’t guess where the administrators hid their management interfaces. A segmented port scan strategy fails here. I need all 65,535.

nmap -sS -p- --min-rate 300 --max-retries 1 203.0.113.5 -oA full_tcp

Reasoning: The SYN scan (-sS) tears down the connection before the handshake completes, keeping me out of the application logs. I enforce a --min-rate 300 because I am running out of time, but limit retries to 1 so I don’t flood the wire.

The result changes the entire engagement strategy. The typical 80 and 443 are present, but buried on port 10443 is an open TCP service.

5. Service Enumeration With Intent

I don’t blindly throw -sV at every port I see. Service enumeration involves Nmap sending dozens of probes per port, analyzing the response regex. It is heavily scrutinized by IPS. I isolate my targets.

nmap -sV --version-light -p 22,10443 203.0.113.5

I use --version-light to speed up the banner grabbing, restricting Nmap to only the most likely probes.

• Port 22: OpenSSH 8.2p1 (Ubuntu).
• Port 10443: Apache Tomcat 9.0.31.

6. The Decision Point: Tactical Prioritization

I have an updated SSH daemon and an undocumented Tomcat server residing on a non-standard port. Which one do I hit first?

The Choice: Tomcat on 10443. Why? SSH 8.2 is relatively modern. Unless I have valid credentials or an exposed private key, brute-forcing SSH is a profound waste of my remaining two hours and will guarantee detection.

Tomcat, however, is a Java application server. Administrators historically deploy these on custom high ports for “security through obscurity” and frequently forget to update them or leave default diagnostic consoles exposed. Human error lives on high ports.

7. NSE As A Weapon (Not a Feature)

The Nmap Scripting Engine (NSE) is not a vulnerability scanner; it is a surgical scalpel. If you run --script vuln, you are throwing everything from MS08-067 to Heartbleed checks at a Tomcat server. It’s loud and amateurish.

I need to confirm if this Tomcat instance exposes the Manager application HTTP paths.

nmap -sV -p 10443 --script http-tomcat-mgr-enum,http-title,http-enum 203.0.113.5

This is targeted. I am explicitly scraping the HTTP title, fingerprinting common directories, and testing for the Manager URI. Nmap confirms /manager/html is accessible.

8. Stealth vs. Speed Tradeoff

The clock is down to 90 minutes. I know where the target is, and I know what it is running. The IPS hasn’t severed my connection yet, meaning my slow SYN scans and decoy DNS source ports worked.

But I’m transitioning from enumeration to exploitation. Stealth goes out the window. I need to brute force the Tomcat Manager panel. I abandon Nmap’s stealth options, pivot to a dedicated brute-force tool (Hydra or Burp Intruder), and aggressively attack the URI. The login cracks in 4 minutes (tomcat:s3cr3t).

9. The Internal Network Shift

With valid Tomcat credentials, I deploy a malicious WAR file payload. I catch the reverse shell. I am now executing inside the perimeter firewall as tomcat user.

Nmap’s role completely shifts here. I upload a statically compiled Linux Nmap binary to /tmp/. Externally, I was fighting the IPS. Internally, the network is often a soft, chewy center. I no longer care about stealth; I care about lateral movement targets.

./nmap -sT -p 445,3389 10.10.0.0/24 > smb_targets.txt

I drop to a full TCP Connect (-sT) scan because I don’t have root privileges for raw socket SYN scans. I am explicitly hunting for SMB and RDP.

10. The Automation Mindset

Inside the network, I cannot afford to analyze results manually. Time is almost up. I pivot to automation for scale. I write a quick bash loop directly executing from the compromised Tomcat host to map lateral targets:

for ip in $(cat smb_targets.txt | grep open | awk '{print $2}'); do 
    ./nmap -p 445 --script smb-os-discovery $ip >> lateral_map.txt & 
done

Nmap isn’t just checking ports anymore; it is programmatically identifying operating systems and Active Directory domain membership for my entire pivot base in parallel.

11. Real Finding to Exploit Path

The internal map finishes. One host stands out: an internal file server displaying Windows Server 2008 R2 via the SMB scripts.

• Port: 445 Open.
• Service: SMBv1.
• Misconfiguration: Unpatched legacy OS running internally.
• Exploit Path: MS17-010 (EternalBlue).

Within 14 minutes, I pivot the EternalBlue exploit through my Tomcat proxy. I have NT AUTHORITY\SYSTEM on a core internal file server. The engagement objective is met.

12. The Defensive Perspective

If the Blue Team was actively hunting, how could they have stopped me?

• My Decoy Scan: They should have noticed a massive influx of DNS source-port traffic attempting to hit non-DNS ports (like 10443).
• My ACK Scan: The firewall explicitly blocking high-port traffic shouldn’t silently drop it; it should log the persistent probing and automatically dynamically ban my origin IP at the perimeter.
• Defending with Nmap: The SOC should run these exact same -p- UDP and TCP scans internally every day, comparing the XML output against a known baseline. When Port 10443 suddenly appears on a Friday night, the pager should go off before I ever find it.

13. Translating Technical Execution to Business Impact

When I brief the C-Suite, they do not want to see my Nmap SYN scan syntax. The conversation hinges on translated risk:

1. Data Exposure: “Due to an undocumented, misconfigured Tomcat deployment on a hidden port, we were able to drop an interactive shell into your DMZ.”
2. Financial Risk: “From the DMZ, we found unpatched internal servers storing unstructured corporate data. If a ransomware syndicate followed this exact path, your entire internal SMB network would have been encrypted in under 60 minutes.”
3. Lateral Movement: “Your perimeter firewall is functioning, but internal zero-trust is non-existent. Once inside, we freely mapped the network without any internal segregation preventing us.”

14. Why Nmap is Mandatory for Modern Operations

Many security engineers rely exclusively on point-and-click scanners like Nessus, Nexpose, or Qualys. Those tools are fantastic for compliance. But in a live operational environment—where IPS systems drop noisy traffic, where stealth matters, and where speed is critical—heavy automated tools fail violently.

Nmap is not a tool; it is a visibility engine. It requires the operator to understand the underlying TCP/IP stack to manipulate it. Every flag changes the behavior of the packet on the wire. If you want to understand how an attacker views your network, you must stop looking at compliance reports and start mastering how to orchestrate raw network sockets. Nmap forces you to actively think.