Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP ABAP Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Anonymously Exposed ICF Services (SICF)
Edit page

Anonymously Exposed ICF Services (SICF)

Description

The Internet Communication Framework (ICF) is the HTTP(S)/SMTP engine of every AS ABAP instance, served by the Internet Communication Manager (ICM) on the instance-derived HTTP 8NNN / HTTPS 44NNN ports (NNN = three-digit instance number). All ICF web applications are shipped disabled by default and activated per business need via transaction SICF, which presents a tree of hundreds of URL-mapped services. In practice, landscapes frequently over-activate: installation guides that say “activate everything under /default_host/sap”, Basis admins enabling entire subtrees rather than individual leaves, and services enabled for a one-time scenario that are never deactivated afterwards.

Two distinct risk classes fall under “anonymously exposed ICF services”:

  • Intentional pre-auth info-leak endpoints - services SAP ships specifically to answer before authentication (so SAP GUI/SAP Logon clients can identify a system before a user logs on). GET /sap/public/info returns a SOAP-wrapped RFCSI_EXPORT structure - SID, hostname, kernel release, OS, DB type, SAP release - pre-auth on most kernels (a Java stack 404s here, making a 200 also a positive ABAP-vs-Java signal). GET /sap/public/ping is a trivial connectivity/liveness check. Both are demonstrated as commonly reachable anonymously in published SAP-hacking walkthroughs. The Message Server HTTP endpoint GET /msgserver/text/logon (81NN) leaks the same <host>_<SID>_<NN> routing string in plain text. SAPControl SOAP (5NN13) exposes unauthenticated methods (GetSystemInstanceList, etc.).
  • Over-activated internal-use services - ICF nodes SAP explicitly documents as “SAP-internal use only” or development-only, which if left active on a production/internet-facing ICM allow far more than information disclosure: /sap/bc/soap/rfc (arbitrary RFC-enabled function-module calls over SOAP, gated only by the calling user’s RFC authorizations - not by any additional check at the service level), /sap/bc/report (URL-driven report/transaction execution), /sap/bc/gui/sap/its/webgui (full SAP GUI in a browser), /sap/bc/webrfc, /sap/bc/FormToRfc, /sap/bc/xrfc//sap/bc/xrfc_test, /sap/bc/echo//sap/bc/error (reflected-XSS-capable diagnostic services), /sap/bc/bsp/sap/certreq/certmap and /sap/bc/bsp/sap/bsp_veri/icf (reflected XSS / session-token theft), /sap/bc/IDoc_XML//sap/bc/srt/IDoc (inbound IDoc processing).
Note
The ICM’s built-in web administration interface (/sap/admin, activated via icm/HTTP/admin_XX) is a separate, higher-value exposure: it grants powerful system-level control (restart ICM, view connections, adjust parameters) and must never be reachable outside a trusted admin network.

Risk

Anonymously reachable ICF services compromise confidentiality directly - SID/hostname/kernel/OS/DB-type disclosure feeds target selection for every other unauthenticated technique in this section (CVE applicability, default-credential client enumeration, gateway/message-server attacks) - and, where an internal-use service was left active without the intended compensating restriction, can additionally compromise integrity and availability: /sap/bc/soap/rfc and /sap/bc/report extend whatever RFC/transaction authorizations the assigned service user holds to any anonymous caller who can reach the ICM, and the reflected-XSS-capable diagnostic services enable session/credential theft against legitimate users who click a crafted link.

Options

  • SAPMAP modules/discovery/sapmap_scanner.py - six-channel unauthenticated fingerprint, including GET /sap/public/info (SOAP RFCSI_EXPORT leak; 200=ABAP-likely, 404=Java signal), Message Server GET /msgserver/text/logon (81NN), SAPControl SOAP GetSystemInstanceList/AccessCheck (5NN13), and SAPHostControl (1128/1129) system enumeration.
  • Manual equivalent: nmap with gelim/nmap-sap service probes; curl/openssl s_client directly against /sap/public/info, /sap/public/ping, SAPControl SOAP, /msgserver/text/logon.
  • SICF tree review (transaction SICF) or blind URL enumeration against the ICM 8NNN/44NNN ports for over-activated internal-use services (/sap/bc/soap/rfc, /sap/bc/gui/sap/its/webgui, /sap/bc/report, /sap/bc/webrfc, /sap/bc/echo, /sap/bc/IDoc_XML, and the BSP/ITS certificate services) - none of these gate on prior authentication at the ICF-entry level, only (for some) on the assigned service user’s own authorizations once reached.
  • Probe /sap/admin (ICM web administration interface) if icm/HTTP/admin_XX is active - indicates a high-value, frequently under-protected admin surface.

Mitigation

  • Enable ICF services on a demonstrated-need basis only; never blanket-activate a whole subtree (e.g. /default_host/sap) - activate individual leaf services and their documented dependencies.
  • Deactivate every internal-use/development-only service not in active use, and apply the corresponding SAP Notes: 1394100 (/sap/bc/soap/rfc), 626073 (/sap/bc/report, /sap/bc/xrfc, /sap/bc/xrfc_test, /sap/bc/FormToRfc, /sap/bc/echo, /sap/bc/error), 1417568 (/sap/bc/bsp/sap/certreq/certmap), 1422273 (/sap/bc/bsp/sap/bsp_veri/icf), 1487606 (/sap/bc/IDoc_XML, /sap/bc/srt/IDoc).
  • Restrict or disable /sap/public/info and /sap/public/ping where not operationally required (ICF service deactivation via SICF); this only raises fingerprinting cost, since DIAG/gateway-level leaks documented elsewhere remain - combine with hardening those channels too.
  • Suppress the ICM Server: response header (icm/HTTP/server_header_suppression).
  • Restrict the ICM web administration interface (/sap/admin) to trusted admin networks via firewall/ICM ACL, force HTTPS-only, require strong or client-certificate authentication, and log all access - or disable it entirely if not needed.
  • Implement an ICM-level ACL (icm/server_port_XXX = ... ACLFILE=...) to restrict which source networks may reach each HTTP(S) port at all.
  • Periodically audit the live SICF tree against a documented required-services allow-list - do this as a recurring control, not a one-time hardening pass.

Detection and Monitoring

  • ICM/Web Dispatcher access logs: repeated requests to /sap/public/info, /sap/public/ping, /sap/wdisp/admin, /msgserver/text/logon, or a spread of /sap/bc/* service paths from one source in a short window - an automated ICF-enumeration signature (see also SAPMAP-class network discovery).
  • ICF logging (transaction SICF recording) and, on newer S/4HANA systems, secure-by-default RFC/ICF logging (transaction SDBLOG) for calls to sensitive or internal-use services.
  • SAPHostControl access logs (1128/1129) for unauthenticated system-enumeration calls.
  • Any successful call to /sap/bc/soap/rfc, /sap/bc/report, or /sap/bc/gui/sap/its/webgui from an unexpected source IP or outside a documented use case.

References