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. BTP Credential-Material Taxonomy
Edit page

BTP Credential-Material Taxonomy

Description

On SAP BTP the secrets an attacker recovers are cloud-native rather than file-based: OAuth2 client credentials and bearer tokens issued by XSUAA, service keys bound to service instances, and the Integration Suite (CPI) Secure Store holding per-tenant integration credentials. Unlike the on-prem stores, these are not obfuscated files on a <sid>adm filesystem - they are held in application environments (VCAP_SERVICES), Cloud Foundry / CLI config, and tenant-managed security material, and are recovered by reading those environments or minting fresh tokens from a captured client credential.

This page covers only BTP credential material. For the ABAP, AS Java, and Cloud Connector equivalents see the cross-references at the bottom.

Risk

A recovered XSUAA client credential or service key can be exchanged for a live bearer token carrying the bound scopes/role collections, authenticating as the service across every subaccount resource it is entitled to - with no further exploit. Integration Suite Secure Store entries yield the credentials CPI flows use to reach on-prem and third-party backends, pivoting out of the tenant. Because BTP audit-log retention is short (see BTP Audit Blind Spots), token theft and reuse can outlive the evidence window.

Options

BTP credential material, by type - recover from the app environment or CLI config, then use or exchange it (prefer the platform’s own token endpoints over re-implementing crypto):

Credential materialWhere it livesProtectionRecoveryPage
XSUAA client id/secret + JWTapp env (VCAP_SERVICES), CLI configbearer / client-credentials grantcf env, read env -> mint tokenXSUAA Token & Role-Collection Abuse
Service keysbound to a service instancecredentials in the key JSONcf create-service-key / cf service-keyService Key Abuse
Integration Suite Secure StoreCPI tenant Security Materialtenant-managedGroovy SecureStoreService.getUserCredentialIntegration Suite Groovy Scripting
JWT signing-key trust (jku/token-key)XSUAA /token_keys endpointissuer/jku validationtoken-key jku confusion where validation is weakXSUAA Token & Role-Collection Abuse
  • Read the app environment - from any foothold in a Cloud Foundry space (or a bound app’s runtime), cf env <app> and the VCAP_SERVICES block expose the XSUAA clientid/clientsecret and other bound-service credentials in clear text; exchange them at the XSUAA /oauth/token endpoint for a live token.
  • Mint a service key - with cf access to a service instance, cf create-service-key / cf service-key returns the instance’s credentials directly, a persistence-friendly path since a newly minted key survives a rotation of the originally-issued one. See Service Key Abuse.
  • Integration Suite - a Groovy step running inside a CPI iFlow can call SecureStoreService.getUserCredential(...) to read the tenant’s stored integration credentials from within the flow’s own trusted context. See Integration Suite Groovy Scripting.
  • On-prem -> BTP harvest - captured on-prem credential material pointing at *.hana.ondemand.com can be turned into BTP tokens from the on-prem side; see On-Prem -> BTP Pivot and the Lateral Movement Cloud Connector section.

Mitigation

  • Apply least-privilege scoping to every OAuth2 client / service instance registered against a subaccount so a harvested credential grants minimum blast radius.
  • Treat service keys as long-lived secrets: rotate on suspicion, review cf service-keys for keys nobody created intentionally, and alert on create-service-key outside change windows.
  • Restrict who can read app environments / bind apps in a space; do not embed static client secrets where a bound instance or x509 binding would do.
  • Scope Integration Suite Security Material and restrict who can deploy/modify iFlows containing Groovy steps.
  • Given short audit retention, export BTP audit logs to external long-term storage - see BTP Audit Blind Spots.

Detection and Monitoring

  • XSUAA token-issuance anomalies: unusual client_credentials mint volume per client_id; tokens issued to a client from an unexpected source.
  • cf create-service-key bursts or keys created outside change windows.
  • Integration Suite: unexpected Groovy-step deployments or Secure Store reads within iFlows.
  • Audit-log gaps (retention-limited) - corroborate token reuse against downstream resource-access logs where BTP’s own trail has rolled off.

References