SAP dispatcher exposure needs an instance-aware query
SAP NetWeaver uses instance numbers to derive several default ports. The dispatcher port is commonly 32<NN>, where <NN> is the two-digit instance number, with 3200 as the default for instance 00. A query for port="3200" is therefore a query for one common case, not for every SAP dispatcher.
In a count-only ZoomEye probe on 2026-11-13 around 22:45 UTC, service="sap" returned 135 matches and port="3200" returned 0. Both used sub_type="all", page 1, and page size 1.
The zero is a useful example of a precise negative that should not become a broad conclusion. It says the conventional instance-00 dispatcher port was not present in the index for this query at that moment. It does not say that SAP systems are absent or that no dispatcher is reachable on another instance number.
Why one port is too narrow
SAP administrators can run multiple instances on one host or distribute application servers across a landscape. Instance numbers change the dispatcher port. Other SAP services and gateway ports use related formulas. A review that checks only 3200 can miss a production system using 3201, 3202, or another instance value.
The service classifier may recognize some SAP protocol behavior without tying it to a single port. That makes service="sap" a useful discovery query, but it is not a complete asset inventory. It can also match components that are not the ABAP dispatcher.
The correct unit of review is the SAP system and its instance list. The external query can identify candidates; the internal system landscape directory, host inventory, and SAP management tooling should supply the authoritative instance map.
Build the query from the instance range
If the organization owns a range of instance numbers, construct separate port queries for the relevant values or use a bounded set of dorks. Keep the result at the same scope and time. Do not combine unrelated SAP services into one count and call it a dispatcher population.
For each candidate, confirm the dispatcher process, system ID, instance number, client network, and owner. Review the network ACLs and the SAP gateway or message-server paths that support the application. A dispatch listener that is reachable from an untrusted network is a management-plane exposure even if authentication is enabled.
The service query is a second view. Compare where the classifier sees SAP behavior with the ports the instance map predicts. A mismatch is a prompt to inspect the asset, not evidence of compromise.
Explain the zero in the report
Write "0 matches for port="3200" at this scope and time" rather than "0 SAP systems." Include the fact that dispatcher ports vary by instance number and that the query did not cover the whole 3200-3299 range. The 135 service matches provide context for the classifier, not proof that those assets are dispatchers.
This kind of precision is valuable during remediation. A team can show the exact query it ran, the ports it covered, and the internal assets it mapped. It can then expand the query or close the finding without arguing about what a headline number meant.
Use ZoomEye to narrow the review, then use the SAP landscape inventory to decide. The default port is a starting point, not the security boundary.
Top comments (0)