SAPMAP — SAP Landscape Attack Path Mapper

What to do (defensive)

The summary tells you SAPMAP exists and lists its exploits; it does not carry the page's hardening and detection specifics, which is what an engineer defending an SAP landscape can act on. The page's own guidance: patch first, detect second.

Configuration changes that kill SAPMAP's primary paths:

• Populate gw/sec_info and gw/reg_info deny-by-default on the Gateway — an empty ACL or P TP=* USER=* HOST=* USER-HOST=* is fatal (the 10KBLAZE path dies without it).
• Set gw/sim_mode = 0, not 1 — simulation mode logs but still allows the exploited path.
• Populate and enforce ms/acl_info; the MS betrusted path needs an open internal port (39NN).
• Restrict RFC_ABAP_INSTALL_AND_RUN via S_DEVELOP auth check for non-developer service users — SAPMAP uses it for OA2C reading, RSECTAB decryption, DBTABLOG purge, and several LPE paths.
• Stop storing SAP_ALL on RFC destinations — the single most common pivot during lateral movement; use least-privilege technical users per destination.
• Rotate every default credential before the system touches a non-isolated network (SAPMAP tries 16 via DIAG at sub-second latency).
• Disable VisualComposer if unused — CVE-2025-31324's /developmentserver/metadatauploader is the primary JSP-deploy channel.

**Detection signals SAPMAP does not suppress:**

• OS-level (survives SAP-side audit evasion): new JSPs under .../irj/servlet_jsp/irj/root/ named db<6>.jsp, lc<6>.jsp, pse<6>.jsp owned by <sid>adm (inotify-watch this); /tmp/sapmap_* staged SQL; unexpected <sid>adm children of gwrd/disp+work/ms.sap*; FIM on /usr/sap/<SID>/SYS/global/security/; auditd ptrace_attach rule for kernel-binary tampering.
• SAP-level: fresh USR02 INSERT followed by a successful login within minutes (e.g. SAPMAP00); USR04 with PROFILE='SAP_ALL'/'SAP_NEW' on non-admins; new SAPMAP_BACK_* SM59 destinations; RFC_ABAP_INSTALL_AND_RUN programs matching ZSAPMAP_*/ZSAP_OA2C.
• Network: single-source high-volume short connections to 32NN/33NN/36NN/39NN/50NNN; user-agent SAPMAP/1.0 in ICM logs.

Beating the Tier-3 evasion (each technique still leaks):

• SAL slot disable leaves no SM19 header update → poll RSAU_API_GET_CONFIG every 5 min, alert on STATUS/UNAME differing from RSAUPROF; push SAL to SIEM so on-disk gaps don't matter.
• Kernel-param flips are recorded by RSPFL_HISTORY_DISPLAY — alert on changes to gw/logging, rdisp/TRACE, rec/client, rsau/*.
• DBTABLOG purge only deletes rows in its hold window; catch it via HANA SQL audit AUDIT ACTION ON DBTABLOG (DELETE) or sequential-LOGID gap analysis.

Version boundary

The described CVE-2026-58240 (MS ASCS_GW rogue registration, SAP Note 3759472) is fixed at kernel 9.16 PL100 / 9.18 PL032 / 9.19 PL017 / 9.20 PL007; system/secure_communication = ON blocks the plaintext path as a compensating control.

Caveats

Read-only mode (--read-only) is described by the page as a UX/API guardrail, not a security control — an operator can restart without the flag. Only the first ~60,000 of 117,897 characters were retrieved; detection detail beyond the truncation point is not shown here.