NSLAP

NSLAP is a new tool to find live hosts using non-standard listening application/ports that NMAP would often mark as down. It uses YAML configuration files to make your own probes.

These are the ways Nmap’s standard live-host discovery can fail grouped by probe type and general network behavior.

Important please read this

NSLAP requires root privilages to run its scans!

ICMP / ping

• Blocked by firewalls or perimeter filters.

• Rate-limited or deprioritized by network devices.

• Hosts intentionally configured to ignore ICMP.

ARP (local L2)

• Only works on the same Ethernet/broadcast domain; useless off-link.

TCP SYN scans

• Stateful firewalls/drop rules silently drop SYNs.

• Load-balancers, captive portals or proxies may reply SYN/ACK but never forward the real app handshake (false positive).

• Firewalls may accept the TCP handshake but block or terminate higher-layer traffic (socket exists but protocol doesn’t).

• SYN/ACK response alone does not prove the claimed protocol.

TCP ACK / window / odd TCP probes

• Middleboxes rewrite or forge RST/ACK behavior (unreliable signals).

• ACK probes don’t trigger application logic so they can’t confirm protocol presence.

UDP probes (e.g., UDP/53)

• UDP is often filtered, rate-limited, or proxied; many UDP probes are silently dropped.

• Intermediate DNS proxies or resolvers may answer in ways that don’t reflect the real host.

• UDP replies can be blocked by NATs until an outbound mapping exists.

ICMP timestamp / netmask / obscure pings

• Rarely enabled on modern hosts; low yield.

SCTP and niche protocol probes

• Niche, often filtered, and thus unreliable for broad discovery.

Ping sweeps / traceroute tricks

• Hosts may silently drop traceroute/ICMP probes while still answering application handshakes. Traceroute can miss alive hosts.

General network behaviors that foil Nmap

• Stateful middleboxes (firewalls, proxies) that only forward application-shaped traffic.

• NAT behavior that requires outbound traffic first to create mappings.

• Application gateways / TLS terminators that terminate TLS and never reveal backend behavior (can mislead about origin host).

• Deep IPS / blacklist systems that drop or alter nonstandard traffic.

• Hosts behind multi-stage proxies or encapsulation (GRE, VXLAN, cloud overlays) where the end host isn’t addressable by raw SYN/ICMP from your vantage.

• Services that require authentication or mutual TLS before revealing application semantics, you’ll only see a transport accept, not the service.

When to use NSLAP instead of (or after) Nmap

Use NSLAP when you need proof of protocol presence or to find hosts that standard Nmap discovery missed.

• **After Nmap marks hosts “down” or “filtered”**Use NSLAP to re-probe the “dead” list with protocol probes (STUN, QUIC VN, TLS ClientHello, LDAP Bind, MQTT CONNECT). NSLAP often revives hosts that drop pings or SYNs.

• When middleboxes/filtering likely block SYN/ICMP but forward app trafficIf the network has stateful firewalls, proxies, or content filters, send real application handshakes — those are more likely to be forwarded.

• **To prove a specific application/service (not just a listening socket)**Need to demonstrate “this host is actually speaking DoT/LDAP/MQTT/QUIC”? NSLAP sends RFC-correct frames and requires a protocol reply (ServerHello, BindResponse, CONNACK, XOR-MAPPED, VN packet).

• For UDP-only stacks or NATed devicesUse STUN, QUIC VN, mDNS, SSDP — they often get responses where TCP/ICMP fail.

• When you want actionable certainty for red/blue opsFewer false positives means fewer wasted exploits for red teams and better triage for blue teams.

• When stealth and low noise matterNSLAP favors fewer, richer probes (surgical) rather than noisy broad sweeps useful for quiet recon or reducing log volume.

• For local/link-local discovery that Nmap missedUse mDNS and SSDP carriers to find IoT devices and services that don’t respond to Internet-style probes.

• To validate services behind TLS terminators or ALPN-aware stacksNSLAP’s TLS ClientHello with SNI+ALPN reveals whether the stack negotiates specific application protocols (e.g., ALPN=dot, h2).

• When you need provable evidence for reports/bug bountiesNSLAP yields protocol-level replies you can cite (hex + RFC reference) better for reproducible findings.

• When scanning environments with NATs, consumer gateways, or multimedia stacksSTUN and QUIC VN often succeed where traceroute and pings do not.

Quick “when not to use NSLAP” (so you pick the right tool)

• Don’t use NSLAP for ultra-large, fast port sweeps where speed > accuracy because Nmap excels there.

• Don’t use NSLAP where you lack authorization; protocol probes can be invasive.

• If you only need a rough inventory of listening sockets and speed is critical, run Nmap first then run NSLAP against the interesting subset.

How to combine them (recommended workflow)

1. Fast sweep with Nmap to collect obvious up/down status.

2. Feed Nmap “down/filtered” hosts to NSLAP for protocol-accurate re-checks.

3. Classify results: confirmed protocol replies → actionable; only SYN/ACK or generic accepts → escalate with different carriers or manual inspection.

4. Log everything (requests, RFC refs, timeouts) for auditability.