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 Business Technology Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. On-Premise <-> SAP BTP Credential Based Pivot
Edit page

On-Premise <-> SAP BTP Credential Based Pivot

Description

Hybrid landscapes create a bidirectional trust boundary between on-prem ABAP systems and BTP subaccounts, and both directions are practically exploitable once one side is compromised:

  • On-prem -> BTP: on-prem systems routinely hold live, usable cloud credentials - SM59 HTTP destinations, OA2C_CONFIG OAuth2 client profiles, ABAP RSECTAB/Java SecStoreFS entries - trusted to reach *.hana.ondemand.com. Once decrypted or abused, these are exchanged directly at the tenant’s XSUAA /oauth/token endpoint for a live BTP access token, converting an on-prem foothold into cloud-subaccount access without a BTP administrator ever handing out credentials.
  • BTP -> on-prem: a BTP-side foothold (a CF app, a stolen client-credentials/x509 pair) can drive the SCC Principal Propagation trust chain to impersonate an on-prem ABAP user - see Principal Propagation Abuse for the full mechanism; this page covers only the BTP-side reachability precondition.

No CVE underlies either direction - both are legitimate SAP OAuth2/XSUAA, RFC-8705, and Principal Propagation mechanisms used exactly as designed. The finding is credential and trust hygiene across the hybrid boundary, not a software bug.

Risk

A compromised on-prem system is routinely also a working BTP credential store - the blast radius of an on-prem compromise extends into the customer’s cloud subaccount by default unless destinations/OAuth clients/SecStore entries pointing at BTP are treated as Tier-0 material. Conversely, CF-level BTP access (Space Developer or above) can reach into on-prem systems via SCC without ever knowing an on-prem password, provided Principal Propagation is misconfigured as described in the companion page.

Options

On-prem -> BTP: harvest credentials, mint an XSUAA token

Harvest (offline, from already-captured on-prem state - no live traffic):

  • SM59 HTTP destinations with a decrypted SecStore password, whose target host ends in .hana.ondemand.com - requires the destination’s rfc_user (as client_id) and password.
  • OA2C OAuth2 Client profiles (OA2C_CLIENT/OA2C_CLIENT_EXT, joined by CLIENT_UUID) - the canonical/highest-fidelity source: client_id, token endpoint, and grant type all come from ABAP configuration rather than URL-pattern heuristics. The matching client_secret lives in the ABAP Secure Store as /OA2C/CS_<CLIENT_UUID_no_hyphens>_<NN> - decrypt per Secure Store Decryption.
  • ABAP RSECTAB (with a regex fallback for embedded URLs) and Java SecStoreFS entries - opportunistic fallback sources.
  • Manual equivalent: SE16/SE16N on RSECTAB, SM59 destination inspection, SU01/SOA_MANAGER review of OA2C_CLIENT.

Mint - three mechanisms, increasing stealth/sophistication:

  1. Plain client_credentials basic-auth - POST <uaa_url> with Authorization: Basic base64(client_id:client_secret), grant_type=client_credentials. No on-prem system involvement at request time; the on-prem system was only the source of the credential. Publicly-reachable HTTPS call against the customer’s own XSUAA tenant - fully reproducible, no special network position beyond outbound HTTPS.
    curl -u client_id:client_secret <uaa_url> -d grant_type=client_credentials
  2. Kernel-proxied cert-auth (RFC 8705, no secret) - an mTLS client_credentials grant issued through the on-prem ABAP system itself over an existing SM59 Type-G/H destination: the SAP kernel performs the mutual-TLS handshake using the destination’s STRUST PSE, so the private key never leaves the on-prem kernel and, from XSUAA’s perspective, the calling identity is the on-prem system’s own registered x509 client. Requires a live RFC session and an SM59 destination pointing at <sub>.authentication.cert.<region>.hana.ondemand.com.
  3. Local-process cert-auth - the identical RFC 8705 flow issued directly from the operator’s own host with a PEM cert/key pair, bypassing the on-prem kernel entirely. Built to route around a documented kernel 7.53 HTTP/2->1.1 chunked-response body-loss bug against XSUAA. The realistic precondition for this specific path - a valid cert/key pair - is usually satisfied via cf create-service-key against an X509_GENERATED XSUAA binding, itself a cloud-side, Space-Developer-class self-service action (see Service Key Abuse) rather than an on-prem-extracted artefact - despite living conceptually in the “on-prem->BTP” direction, this path’s realistic use case is often “already have BTP access, mint a cert-bound token to avoid the basic-auth secret path.”

BTP -> on-prem: reach the SCC Principal Propagation tunnel

  • Reproducibility gate - the critical precondition to flag before attempting this direction: the live BTP-side leg only works from inside BTP’s own runtime for the target region - the connectivity proxy hostname is not internet-reachable by design. This is satisfiable from either application runtime in the customer’s own subaccount (not a SAP-managed-infrastructure dependency), provided the tester holds - or has pivoted to - a workload foothold there:
    • Cloud Foundry - tunnel through a controlled app, or run probe tooling as a workload in the CF org/space:
      cf ssh -L 20003:<proxy-host>:<proxy-port> <app-name>
    • Kyma - a workload that can reach the in-cluster Connectivity Proxy service inherits the same on-prem reach; the Application Connector’s on-prem credentials also sit as Secrets in kyma-system. See Kyma Application Connector Pivot.
  • Chaining note: this precondition is frequently already satisfied by the on-prem->BTP harvest above - a stolen client_credentials/x509 pair reaches BTP APIs, and cf create-service-key-derived access (or a Kyma ServiceBinding Secret) reaches the runtime directly - or simply by engagement scope explicitly granting the tester a CF space or Kyma namespace.
  • The full destination-resolve -> connectivity-proxy forward-request -> /sap/bc/ping verdict -> whoami-detection mechanism is documented in Principal Propagation Abuse - not duplicated here.

Mitigation

  • Treat every SM59 HTTP destination, OA2C client profile, and SecStore entry pointing at *.hana.ondemand.com as Tier-0 material - rotate on any suspected on-prem compromise, same as any other privileged credential.
  • Prefer x509/PSE-bound destinations over static-secret OA2C bindings where feasible - a stolen PSE still requires the on-prem kernel (or a stolen private key file) to exercise, raising attacker cost versus a portable client_secret string.
  • Restrict which roles/personas can mint X509_GENERATED service keys - Space Developer access should not translate into arbitrary self-issued, cert-bound BTP credentials.
  • Monitor XSUAA client_credentials grant volume and unusual client_id/geography combinations; alert on any x509-bound token mint whose calling TLS fingerprint diverges from the expected on-prem system’s registered certificate.
  • Apply least-privilege scoping to every OAuth2 client registered against a subaccount - a harvested credential should grant the minimum destination/service access necessary.
  • Restrict destination_configuration.write scope and which CF apps/spaces can reach the BTP connectivity proxy segment - see Principal Propagation Abuse for the full mitigation set on the BTP->on-prem direction.

Detection and Monitoring

  • On-prem ABAP: RFC_ABAP_INSTALL_AND_RUN execution and dynamic report compilation is a strong indicator on systems where ad-hoc report generation via RFC is not an expected admin workflow - audit via Security Audit Log (SM20/RSAU_READ_LOG).
  • On-prem ABAP: outbound CL_HTTP_CLIENT calls to *.hana.ondemand.com hosts originating from an SM59 destination not normally exercised at that frequency/time - ICM trace / STRUST usage logging on the source PSE.
  • BTP/XSUAA: monitor client_credentials token-mint volume per client_id for anomalous spikes, especially against x509-bound clients whose certificate thumbprint doesn’t match the expected calling system’s known fingerprint.
  • BTP/XSUAA: repeated basic-auth client_credentials failures (wrong/rotated secret) followed by success is a signature of an attacker iterating through multiple harvested candidate secrets.
  • Reverse-direction (BTP->on-prem) detection is covered in Principal Propagation Abuse - not duplicated here.

References