Skip to content

Back to the catalog

bencteux.frwriteup

Nmap - detecting the network mapper

A blue-team writeup arguing that broad scan detection at the Internet perimeter is low-value noise, and that scan detection is most valuable inside the network perimeter after initial compromise. It then catalogs specific network signatures Nmap leaves in DNS, FTP, HTTP, RDP, SIP, SMB, SSH, and SMTP probes (e.g. the NSE User-Agent, mstshash=nmap RDP cookie, SSH-x.x-NmapNSE client string, IEUser@ FTP password) that can be used to build reliable detection rules.

TL;DR Practical signatures and rationale for detecting Nmap scans on the internal network via application-layer protocol fingerprints.
Document

What it is

A blue-team catalog of the exact application-layer strings Nmap emits when fingerprinting services, intended for building high-confidence detection rules. The patterns were pulled from Nmap's GitHub source and confirmed against pcaps of real scans. It targets commands like nmap -sSVC 1.2.3.4 and nmap -sS -script <name> 1.2.3.4.

How it works

The author argues perimeter scan detection is noise-generating sub-optimization; the value is detecting scans inside the perimeter, where a scan means an attacker is already present and lateralizing. Rather than detect all scans (unreliable, high false-positive), it keys on Nmap's recognizable protocol probe strings — specific enough to make alerts trustworthy while accepting it will miss scans not using these NSE probes.

What to do

Detect these verbatim signatures per protocol:

  • DNS — transaction ID 0xdead with request for www.wikipedia.org; also a request with transaction id 0x06 for domain version.bind.
  • FTP — client sends other-protocol probes on port 21 before the server banner (mstshash=nmap, 0xffSMB, <sip:nm@nm>, <sip:nm2@nm2>), and authenticates with password IEUser@.
  • HTTP — User-Agent Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html); request URIs: `` /nmaplowercheck<epoch_time> /NmapUpperCheck<epoch_time> /Nmap/folder/check<epoch_time> /evox/about /HNAP1 ``
  • RDP — cookie value mstshash=nmap.
  • SIP — headers From: <sip:nm@nm>, Contact: <sip:nm@nm>, To: <sip:nm2@nm2>.
  • SMB — Nmap's name appears in the hostname field of SESSION_SETUP_ANDX_REQUEST.
  • SSH — client protocol version strings SSH-<X.X>-NmapNSE_<X.X> and SSH-<X.X>-Nmap-SSH<X>-Hostkey.
  • SMTP(S) — EHLO nma.

Deploy these on internal (LAN) traffic for real value; treat perimeter matches only as a low-severity weak signal to correlate after other activity is confirmed (e.g. cross-reference a scanning IP once a webshell drop is seen).

flowchart TD
    A[Scan detected] --> B{Where?}
    B -->|Internet perimeter| C[Tag low / correlate only]
    B -->|Inside LAN| D[High value: attacker already present]
    C -.after other activity confirmed.-> D

Caveats

The page states these patterns detect only Nmap's application-level NSE fingerprinting, not all scans made with the tool (e.g. bare -sS port sweeps without service probes). The RDP/SIP/SMB signatures overlap with the FTP pre-banner probes, so those are the same strings surfacing across contexts. Some source references point to a pinned commit hash while SMB/others point to master, so line numbers may drift.

Technologies named here

  • Nmap
  • Nmap Scripting Engine
  • rdp.lua
  • smbauth.lua
  • http.lua
  • nmap-service-probes
  • SIEM/SOC tooling

Techniques named here

  • Network/port scanning detection
  • Internal lateral movement scan detection
  • Application-layer protocol fingerprinting detection
  • DNS probe detection
  • FTP probe detection
  • HTTP User-Agent and URI fingerprint detection
  • RDP cookie detection
  • SIP header detection
  • SMB hostname field detection
  • SSH client version string detection
  • SMTP EHLO domain detection
  • Bruteforce script credential detection
  • Alert aggregation/correlation