Mapping the Invisible: How nmap-sap Exposes SAP Services That Standard Scanners Miss

Hook

When you run a default nmap scan against an SAP landscape, up to 70% of active SAP services will show as 'unknown'. You're essentially flying blind through one of your organization's most critical attack surfaces.

Context

SAP systems are the backbone of enterprise operations at most Fortune 500 companies, managing everything from financial transactions to supply chain logistics. Yet these systems communicate using proprietary binary protocols that standard network scanning tools simply don't understand. When security teams run nmap—the de facto standard for network reconnaissance—against SAP infrastructure, they encounter a frustrating wall of 'unknown' service labels. The scanner detects something listening on the port, but can't identify what it is or extract any meaningful metadata.

This gap exists because nmap's service detection relies on a database of probe definitions that send specific payloads to network services and match their responses against known patterns. While nmap ships with thousands of probes for common protocols like HTTP, SSH, and DNS, SAP's ecosystem of specialized services—SAP Router, Message Server, Dispatcher, Internet Communication Manager—remained largely invisible. Security auditors conducting penetration tests would have to rely on expensive commercial tools or manually probe each port, a time-consuming process prone to errors. The gelim/nmap-sap project emerged to bridge this gap, providing open-source probe definitions that teach nmap to speak SAP's languages.

Technical Insight

At its core, nmap-sap works by extending nmap's service-version detection engine with custom probe definitions written in nmap's specialized probe format. These probes leverage deep knowledge of SAP's architectural conventions and binary protocols to both target the right ports and decode the responses.

SAP systems use an instance numbering scheme (00-99) that determines which ports services listen on. For example, instance 00 uses port 3200 for its SAP Gateway, while instance 01 uses 3201. Rather than scanning all 65,535 TCP ports, nmap-sap generates targeted port lists based on this convention. The nmap-services-sap file defines these mappings:

sapgw00 3300/tcp # SAP Gateway (instance 00)
sapgw01 3301/tcp # SAP Gateway (instance 01)
# ... continues for instances 02-99
sapmsDEV 3600/tcp # SAP Message Server
sapdp00 3200/tcp # SAP Dispatcher (instance 00)

The probe definitions themselves are where the real intelligence lives. Each probe specifies a binary payload to send and regex patterns to match against responses. For SAP Router, the probe sends a connection request packet and parses the response to extract version information:

Probe TCP SAProuter q|\x00\x00\x00\x2f\x00\x00\x00\x00\x00\x00\x00\x00|S
rarity 5
ports 3298-3299

match saprouter m|^\x00\x00\x00\x08\x00\x00\x00\x02|s p/SAP Router/ cpe:/a:sap:router/
match saprouter m|NI_VERSION:\s+([\d]+)|s p/SAP Router/ v/$1/ cpe:/a:sap:router:$1/

This probe sends a 12-byte binary payload (the \x00 notation represents hexadecimal bytes) that initiates a SAP Router connection. The match directives use regex patterns to identify the service and extract version numbers. The 'S' flag indicates this is a SSL-capable probe, and 'rarity 5' tells nmap to use this probe relatively early in its detection sequence.

For SAP Message Server, the probe is more sophisticated, sending a monitor request and parsing the structured binary response:

Probe TCP SAPms q|\x00\x00\x00\x28\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|S
ports 36NN,81NN

match sapms m|\x00\x00\x00.*\x00([^\x00]+)\x00.*Release\s+([\d]+)| p/SAP Message Server/ h/$1/ v/$2/
match sapms m|MS_SERVER_NAME=([^,]+)| p/SAP Message Server/ h/$1/

The regex capture groups (indicated by parentheses) extract the hostname and release version, which nmap then displays in its output. This is crucial metadata for security assessments—knowing you're dealing with an older SAP NetWeaver 7.0 system versus a current 7.5 release immediately informs your testing strategy.

The project also demonstrates intelligent use of nmap's port notation. The pattern '36NN' and '81NN' represents SAP's instance-based port calculations. Port 3600 is the base Message Server port for instance 00, with each subsequent instance adding to both the base and the instance number (3601 for instance 01, etc.). By encoding this pattern, the probes avoid hardcoding 100 separate port definitions while still achieving comprehensive coverage.

One particularly clever aspect is how the probes handle SAP's tendency to embed multiple pieces of information in single responses. The Dispatcher probe includes multiple match directives that extract different metadata from the same response packet—hostname, kernel version, operating system, and database type can all be parsed from a single reply. This efficient extraction means you get maximum intelligence from minimal network traffic, important for staying stealthy during security assessments.

Gotcha

The most significant limitation acknowledged in the project's own documentation is incompleteness. SAP landscapes are incredibly diverse—different versions, patch levels, and custom configurations mean that no probe set can catch everything. In testing, you'll encounter services that respond in unexpected ways or don't respond to standard probes at all. Custom SAP developments, third-party SAP add-ons, and heavily locked-down systems may evade detection entirely.

SSL/TLS wrapping presents another serious challenge. Many organizations now encrypt SAP communications using SSL, which means the binary probes can't reach the actual SAP protocol without first negotiating the SSL handshake. While nmap has some SSL negotiation capabilities (hence the 'S' flag on probes), the detection accuracy drops significantly for encrypted services. You'll often get generic 'ssl/http' identifications rather than specific SAP service types. The project's issues section includes multiple reports of this limitation, and there's no easy fix—it's a fundamental constraint of probing encrypted protocols. For production SAP systems with mandatory encryption, you may need to fall back on application-layer scanning that can properly handle SSL negotiation before sending SAP-specific probes.

Verdict

Use if: You're conducting security assessments or inventory of SAP landscapes and need to quickly identify what services are exposed across multiple systems. This is invaluable for penetration testing engagements where you need to map the attack surface before diving deeper, or for compliance audits where you must document all SAP services. It's also perfect for organizations running SAP that want a free, open-source way to verify their network segmentation and firewall rules are actually blocking unwanted SAP service exposure. The probes work well for unencrypted or lightly encrypted environments and provide significantly better results than vanilla nmap. Skip if: You need enterprise-grade, comprehensive SAP security scanning with vendor support—the authors themselves recommend ERPScan's commercial suite for that use case. Also skip if your SAP landscape is heavily SSL-wrapped, as detection accuracy will be poor. If you're scanning non-SAP environments or need real-time continuous monitoring rather than point-in-time scans, this isn't the right tool. Finally, if you're expecting 100% detection accuracy or planning to make critical security decisions based solely on these scans, understand that this is a best-effort reconnaissance tool, not a definitive inventory system.