Evasion, Obfuscation, and Advanced Scanning Techniques

IP Fragmentation and Stateful Reassembly Realities

IP fragmentation remains one of Nmap's most misunderstood evasion features. The -f flag fragments probe packets into 8-byte payloads (post-IP-header), while --mtu allows explicit specification of fragment sizes, constrained to multiples of 8 due to the 13-bit fragment offset field's 8-byte granularity in the IPv4 header.

Mechanical operation: When you execute nmap -f -p 80 192.168.1.1, Nmap splits a standard TCP SYN packet into multiple fragments. A typical 20-byte TCP header plus 20-byte IP header becomes unwieldy: with -f, the first fragment carries 8 bytes of TCP header, subsequent fragments carry the remainder. For --mtu 24, you specify the total fragment size including IP header—meaning 4 bytes of payload per fragment, still constrained to 8-byte multiples for the offset calculation.

The evasion theory assumes IDS/IPS sensors lack reassembly capabilities, examining fragments in isolation. Modern defenses operate differently. Stateful firewalls, Suricata, and Snort 3.0 maintain fragment reassembly buffers keyed by (source IP, destination IP, protocol, IP ID). These systems typically implement:

  • Time-based eviction: Fragments held for 60–120 seconds before discard
  • Overlap handling: Favoring first-seen, last-seen, or Linux/BSD-specific policies per RFC 5722
  • Resource limits: Per-host or global fragment assembly limits to prevent memory exhaustion attacks

Why -f frequently fails: Enterprise environments rarely encounter legitimate fragmentation. Path MTU discovery and TCP MSS negotiation have largely eliminated fragmentation on modern networks. Security teams routinely flag fragmented traffic as suspicious per se. Nmap's fragment implementation also exhibits fingerprints: consistent IP ID sequences, predictable timing between fragments, and default source ports that don't match typical application behavior.

When fragmentation retains utility: Targeting legacy embedded systems with minimal TCP/IP stacks, certain ICS/SCADA environments, or specific appliance implementations with known reassembly bugs. For directed evasion, combine with --send-eth to control link-layer transmission timing, though this requires root privileges.

# Fragment with explicit MTU, slow timing, and randomized IP IDs
sudo nmap -f --mtu 16 -T2 --ip-options "R" -p 443 10.0.0.5

Decoy Scanning: The Half-Open Problem and Log Correlation

Decoy scanning (-D decoy1,decoy2,...,ME) attempts to obscure the scanner's true source address by interleaving identical probes from multiple spoofed or legitimate sources. The positional keyword ME determines where the real scanner IP appears in the sequence; omitting it appends the real address last.

Decoy selection mechanics matter enormously. Responsive decoys—live hosts that reply to the target—generate backscatter traffic the target logs, complicating attack attribution. Unresponsive decoys (unused addresses in the target subnet) produce no SYN-ACK responses, creating asymmetric patterns detectable through simple log analysis:

# Scan with six decoys, real address in third position
sudo nmap -D 192.168.1.50,10.2.3.4,ME,172.16.5.5,decoy.example.com,RND:5 -p 22,80,443 203.0.113.10

The RND:5 generates five random addresses. This is practically worthless: random IPs across the internet won't route back to the target's responses, creating obvious non-responder patterns. Better decoy strategies:

  • Responsive decoys: Compromised hosts, VPN exit nodes, or legitimate machines in the target's address space that receive and respond to SYN packets
  • Geographic distribution: Decoys spanning multiple ASNs and countries, complicating cross-jurisdictional log correlation
  • Behavioral matching: Decoys with similar TTL values, window sizes, and timing to the scanner's actual TCP stack

The half-open problem: Decoy scanning only functions against TCP SYN scans (-sS) where no completion handshake occurs. Connect scans (-sT), UDP scans, or version detection (-sV) require bidirectional communication impossible through spoofed addresses. The scanner must receive responses to determine port state, collapsing the decoy illusion for anything beyond initial port status.

Critical local segment limitation: On Ethernet segments, ARP resolution exposes the scanner's true MAC address regardless of IP-level decoys. The target's ARP cache records scanner_ip -> scanner_mac when decoys use non-local addresses requiring gateway resolution, but for local decoy addresses, gratuitous ARP or static entries would be needed. Port security implementations binding MAC to switch ports render decoy scanning locally transparent to network administrators.

Log correlation challenges: Modern SIEMs normalize (timestamp, source IP, destination IP, destination port) tuples. Decoy scans create obvious clusters—identical port sequences from multiple sources within microseconds. Sophisticated correlation identifies the scanner as the IP exhibiting unique characteristics: the only source receiving RSTs from closed ports rather than silently dropping them, or the only address with subsequent full-session behavior on discovered open ports.

Source Address Spoofing and Asymmetric Routing

The -S flag enables explicit source IP specification, functioning correctly only when the scanner can receive responses through asymmetric routing or when combined with capture interfaces (-e). This serves two distinct scenarios:

Multi-homed scanners: Systems with interfaces across security boundaries (e.g., red team jump boxes with DMZ and internal interfaces). Specifying -S 10.0.10.5 -e eth1 ensures probes originate from the correct address for the target subnet, avoiding route-table ambiguity.

Asymmetric routing exploitation: When the scanner controls routing infrastructure or operates through specific network positions where target responses traverse monitored capture interfaces despite spoofed sources. This requires either:

  • BGP hijacking or route injection capabilities
  • Control of intermediate hops in the target's return path
  • Placement on shared network segments where promiscuous mode captures responses
# Spoof source through specific interface, with no reverse DNS
sudo nmap -S 198.51.100.25 -e tun0 --disable-arp-ping -Pn -p 80 203.0.113.0/24

The --disable-arp-ping and -Pn are mandatory: ARP resolution would reveal the true MAC, and host discovery with spoofed sources fails without response capture capability. This scan mode is fundamentally blind—no positive confirmation of open ports without packet capture infrastructure.

Custom Payload Insertion for Signature Evasion

Nmap's --data, --data-string, and --data-length options append arbitrary payload to probe packets, primarily affecting UDP scans and protocol-specific probes. Their evasion utility centers on IDS signature manipulation rather than protocol-level disguise.

Mechanism distinctions:

  • --data-length 50: Appends 50 random bytes, altering packet size to evade length-based signatures
  • --data-string "GET / HTTP/1.0\r\n\r\n": Inserts specific byte sequences, potentially triggering application-layer processing or masquerading as legitimate protocol traffic
  • --data 0xdeadbeef: Hex-encoded arbitrary payload

For protocol tunneling, these options enable crude encapsulation. A UDP probe to port 53 with DNS-formatted payload may traverse firewalls permitting DNS while carrying non-DNS content. However, Nmap's implementation lacks true tunneling protocol state machines—no sequence numbers, acknowledgments, or reassembly logic.

Practical signature evasion: Suricata and Snort signatures frequently target default Nmap probe contents. The nmap -sV service probes contain distinctive strings (e.g., NULL, GenericLines, Help). Custom payload insertion substitutes these, though version detection accuracy degrades without expected responses to standard probes.

# UDP scan with DNS-mimicking payload to port 53
sudo nmap -sU -p 53 --data-string "$(printf '\x12\x34\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x07example\x03com\x00\x00\x01\x00\x01')" 10.0.0.1

Proxy Chains and Ncat Relay Techniques

The --proxies option supports HTTP CONNECT and SOCKS4/5 proxy chains for TCP connect scans only. This fundamental limitation—no raw socket support through proxies—restricts utility to -sT connect scans, application-level reconnaissance, and scenarios where proxy chains provide geographic or organizational obfuscation rather than technical stealth.

Chain configuration: Comma-separated proxy specifications with failover semantics. The scanner connects through each proxy sequentially; proxy failure aborts the probe rather than attempting alternatives.

# HTTP CONNECT chain through two proxies
nmap -sT -Pn -p 80,443 --proxies http://proxy1.example.com:8080,http://proxy2.internal:3128 target.com

The Ncat relay technique provides more flexible redirection:

# On relay host: forward local port 8080 to target:443
ncat -l 8080 --sh-exec "ncat target.example.com 443"

# Scanner connects through relay
nmap -sT -p 8080 relay-host.example.com

For multi-hop relays, chained Ncat instances create arbitrary topologies. Combining with SSL wrapping (--ssl) and access controls (--allow) produces rudimentary covert channels. However, each relay introduces latency and potential points of failure or logging.

Zenmap topology limitations: The graphical Zenmap's topology view displays discovered routes and host relationships based on traceroute data and scan timing. For obfuscated scanning, this visualization becomes actively misleading—relays appear as direct connections, proxy endpoints as scan origins, and decoy sources may generate phantom topology nodes if any responses are captured. The topology view has no native support for annotating scan obfuscation techniques, rendering it useful for post-scan analysis of network structure but not for understanding scan attribution exposure.

MAC Address Spoofing and Local Segment Realities

The --spoof-mac option operates exclusively on local Ethernet segments, accepting vendor prefixes, specific addresses, or 0 for random generation. Its functionality addresses two distinct scenarios:

Port security bypass: Switch implementations binding specific MAC addresses to physical ports (Cisco port-security, Juniper MAC limiting) drop frames from unauthorized source MACs. Spoofing an authorized MAC permits frame transmission, though collision with the legitimate host produces ARP instability and potential detection.

Local segment anonymity: Within broadcast domains, the source MAC address identifies the physical scanning host regardless of IP-layer obfuscation. Changing MAC addresses between probes or scans complicates switch CAM table correlation and host tracking.

# Random MAC with Apple vendor prefix for plausible mobile device
sudo nmap --spoof-mac Apple -e eth0 -sn 192.168.1.0/24

Critical constraints: MAC spoofing provides no protection beyond the local segment. Layer-3 devices rewrite source MAC addresses; upstream visibility depends entirely on IP-level controls. Combined with decoy scanning, MAC spoofing addresses the local exposure decoys cannot—yet simultaneous use creates contradictions: decoys with different IP addresses but identical MAC addresses appear as IP spoofing to any observant analyst.

Honest Assessment: Plausible Deniability Versus Undetectability

Contemporary network defense has catalogued Nmap's evasion techniques exhaustively. The tool's open-source nature ensures signature databases, behavioral models, and academic analyses cover every option described here. No single technique or combination provides undetectability against determined, resourced monitoring.

What remains achievable is plausible deniability and attribution complexity:

  • Decoy scans force investigators to prove which source conducted follow-on exploitation, not merely which sources probed
  • Proxy chains introduce jurisdictional and organizational friction to log acquisition
  • Fragmentation and payload manipulation consume analyst time and may trigger less-tuned detection pipelines differently than standard scans
  • MAC spoofing and source address manipulation require local access, shifting investigative focus from remote attribution to physical security

The honest practitioner treats these techniques as delay and complicate mechanisms, not avoid and evade solutions. Their value lies in operational security for authorized testing—preventing premature detection that would cause target administrators to alter configurations—rather than unauthorized intrusion against competent defenders.