SM59 Destination SSRF

cl_http_client=>create_by_destination( destination = '<name>' ) is a documented ABAP kernel API that turns any SM59 destination into an attacker-controlled HTTP client, with the SAP kernel itself acting as the request engine. Delivered via RFC_ABAP_INSTALL_AND_RUN (a small generated ABAP report, sometimes referred to by the placeholder name ZHTTPDEST), it lets an attacker with an S_RFC + S_DEVELOP foothold choose the destination, HTTP method, path, and body - the kernel makes the request and returns status/headers/body. This is architecturally an SSRF primitive scoped to whatever destinations are configured in SM59/table RFCDES on the compromised system.

The differentiated case is a cert-authenticated Type-G/H destination (mutual TLS via an STRUST PSE): the kernel transparently performs the TLS handshake and attaches the destination’s client certificate without the attacker ever touching the private key. From the target endpoint’s perspective, the request carries the SAP system’s own X.509 identity. Where the destination points at a BTP service - in particular the BTP destination-configuration REST API - a single on-prem foothold becomes a direct on-prem -> cloud identity pivot, and the same primitive can be used to bulk-harvest other destinations’ credentials from that API.

No network reachability from the attacker’s own host to the destination’s target is required - the kernel makes the request on the SAP application server’s behalf, which is the entire pivot value.

An attacker with S_RFC + S_DEVELOP (or any other path to RFC_ABAP_INSTALL_AND_RUN) can issue arbitrary HTTP(S) requests through any configured SM59 destination, inheriting that destination’s authentication - including mTLS client-certificate identity - without needing outbound network access from their own host. Against a BTP destination-service-pointing destination, this yields enumeration of subaccount destinations and any cleartext credentials they carry, a direct lateral-movement path back into the on-prem landscape or onward into BTP.

• Precondition: S_RFC (RFC session) + S_DEVELOP (the gate RFC_ABAP_INSTALL_AND_RUN enforces on modern kernels) + an existing, valid SM59 destination pointing at the intended target service.
• Arbitrary request via a destination - generate an ABAP report calling cl_http_client=>create_by_destination, set method/URI/headers/body, send/receive, dump status+headers+body via WRITE:, deliver through RFC_ABAP_INSTALL_AND_RUN. Tool: SAPMAP modules/exploitation/sap_http_via_dest.py - call_via_destination(node, dest_name, method, path, creds, body, content_type).
• BTP credential harvest - GET /destination-configuration/v1/subaccountDestinations against a BTP destination-service-pointing destination; flag any Password/ClientSecret/TokenServiceUserPassword/OAuthClientSecret/SystemUserPassword field that is non-empty and not masked (!= "*"). Tool: enumerate_btp_subaccount_destinations() in the same module.
• Manual equivalent: SE38/SE80 with developer access, write and run a report calling cl_http_client=>create_by_destination directly.
• Manual limited equivalent: SM59 -> “Connection Test”/“Remote Login” - confirms reachability/auth only, not a general request/response primitive.

Note

Zero output lines on delivery is the tell-tale failure signature - it almost always means a short dump: missing S_DEVELOP, a kernel too old for cl_http_client, or an unhandled CX_ exception. Check ST22 on the target rather than assuming the call silently no-op’d.

• Restrict S_DEVELOP and any path to RFC_ABAP_INSTALL_AND_RUN to genuinely trusted developer/service accounts - see OS command execution for the same delivery-channel mitigation.
• Scope SM59 destinations tightly; avoid broad, long-lived cert-authenticated destinations to cloud identity/configuration services where possible.
• On BTP, avoid storing cleartext on-prem service credentials in subaccount destination configuration; prefer destination-service features that reference a secure credential store rather than inline Password/ClientSecret fields.
• Prefer short-lived tokens over stored client certificates for system-to-system links where the target service supports it.

• RFC_ABAP_INSTALL_AND_RUN compiling/running a short-lived, dynamically-installed report (e.g. named ZHTTPDEST) containing cl_http_client calls, from a non-standard/non-developer source - correlate with ST22 short dumps.
• Outbound HTTP(S) traffic from the SAP application server host to destinations not matching the SM59 destination’s normal scheduled integration pattern - particularly /destination-configuration/v1/subaccountDestinations on a BTP destination-service host.
• Security Audit Log (SM20): RFC session logon + RFC_ABAP_INSTALL_AND_RUN FM-call events correlated with an unusual authenticated user.
• Unusual read volume against a SM59 destination pointing at the BTP destination-configuration service is a strong indicator of the enumeration path specifically.

• OS command execution - shared delivery channel (RFC_ABAP_INSTALL_AND_RUN)
• Book: SAP-Systeme schützen (Rheinwerk/SAP PRESS) - SM59/RFC destination hardening, RFCDES protection via SM59 authorization restriction
• Book: SAP® System Security (SAP PRESS, 2026) - destination credential exposure discussion