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. SAP Integration Suite (Cloud Integration / CPI)
  8. /
  9. SAP Integration Suite Persistence - Script Collections, Malicious iFlows, and Productive Tampering
Edit page

SAP Integration Suite Persistence - Script Collections, Malicious iFlows, and Productive Tampering

Description

Once an attacker holds iFlow design/deploy rights in an SAP Integration Suite tenant (see Integration Suite Groovy Scripting for the initial-access primitives), the platform offers several built-in mechanisms for turning a one-time foothold into durable, tenant-wide persistence:

  • Script Collections - shared .groovy files packaged and deployed once, then referenced by any iFlow in the same tenant/package without copying code.
  • Direct tampering of productive iFlows - anyone holding WebTooling.IntegrationFlowConfigure can add or edit a Script step in any iFlow in scope, including production interfaces already carrying live business/partner traffic. No code-review gate is inherent to Integration Suite itself; whatever review process exists is entirely organizational.
  • Malicious iFlow deployment via /api/v1 - POST /api/v1/DeployIntegrationDesigntimeArtifact deploys programmatically, bypassing the Web UI (and any UI-adjacent review workflow) entirely. Authenticated the same way as the rest of the design/deploy surface: an OAuth2 client-credentials BTP service key.
  • Transport-layer injection - content packages move between tenants via SAP Cloud Transport Management, fronted by a dedicated SAP Process Integration Runtime service instance (role WorkspacePackagesTransport, OAuth2 client-credentials grant, endpoint .../api/1.0/transportmodule/Transport). A compromised CI/CD pipeline or transport-automation service key with this role lets an attacker inject a malicious iFlow or Script Collection directly into a downstream tenant - potentially production - bypassing manual WebUI review entirely.

Risk

A single edit to a widely-referenced Script Collection silently backdoors every iFlow that references it, the next time each is redeployed - with no forced re-review of the consuming iFlows, and no platform-native signal that the shared dependency changed underneath them. Combined with the design/deploy authorization split (edit rights alone are enough to plant the payload; a separate, more-trusted account or a CI/CD pipeline unwittingly deploys it), this gives an attacker with only partial or low-tier CPI access a path to full-tenant, multi-iFlow compromise that persists across redeployments and survives the original attacker’s own access being revoked. A compromised transport-automation or CI/CD service key extends the same pattern across tenant boundaries, directly into production.

Options

Script Collection backdoor:

  1. Identify a widely-referenced Script Collection (utility/logging/token-helper scripts are common high-fan-out targets - e.g. a shared LogUtil.groovy or TokenHelper.groovy).
  2. Add a payload to the shared script - a SecureStoreService credential dump (see Integration Suite Groovy Scripting), an MPL-attachment exfil sink, or a conditional beacon - while preserving the script’s original behavior so consuming iFlows keep functioning normally.
  3. Redeploy the Script Collection once. Every iFlow that references it inherits the payload on its own next redeployment - which may be driven by an unrelated, legitimate change made by someone else entirely, with no code diff visible against the Script Collection itself from within that iFlow’s change history.
  4. Persistence survives revocation of the attacker’s own account, since the payload now lives in colleagues’/CI’s redeploy actions rather than requiring the attacker to act again.

Direct productive-iFlow tampering:

  • WebTooling.IntegrationFlowConfigure is sufficient to add/edit a Script step in any in-scope iFlow, including live production interfaces. No design-time gate blocks this; whatever review exists is process, not platform-enforced.
  • Pair with NodeManager.deploycontent if held directly, or leave the change staged for someone else with deploy rights to push (see the design/deploy role split in Integration Suite Groovy Scripting).

Malicious/rogue iFlow deployment via API:

GET  https://{tenant-host}/api/v1/IntegrationDesigntimeArtifacts(Id=':Id',Version=':Version')
POST https://{tenant-host}/api/v1/DeployIntegrationDesigntimeArtifact

Both authenticated via an OAuth2 client-credentials BTP service key scoped to the same role collections as WebUI design/deploy - a leaked/compromised service key is a full programmatic deploy primitive with no WebUI trace of interactive use.

Transport/CI pipeline injection:

  • Target: a service key/instance holding WorkspacePackagesTransport, used against .../api/1.0/transportmodule/Transport on the SAP Process Integration Runtime service.
  • Compromising this key lets an attacker push a malicious package (iFlow and/or Script Collection) as part of an apparently-legitimate transport, directly into a downstream tenant - a supply-chain injection point that bypasses manual WebUI review by design (that’s the point of automated transport).

Externalized Parameter tampering abuse note: Content Modifier steps commonly source values (e.g. target URLs) from Externalized Parameters, which can be overridden per-environment at deployment time separately from the iFlow design itself. An attacker who can influence deployment-time parameter values (e.g. via a compromised transport/CI step) without touching the iFlow’s Groovy/mapping content gets a lower-visibility redirection technique - no diff shows up in the iFlow design proper.

Note
Report Script Collection fan-out (how many iFlows reference each shared script) as a standing finding even absent an actual compromise during the engagement - it quantifies blast radius for the client’s own remediation prioritization.

Mitigation

  • Treat Script Collections as shared production dependencies, not throwaway utility code: require code review and change-approval on every Script Collection edit, proportional to its fan-out (how many iFlows reference it), not just its own package.
  • Maintain and periodically review a reference map of which iFlows consume which Script Collections; alert on unreviewed changes to high-fan-out scripts.
  • Do not treat “can edit” and “can deploy” as equivalent risk tiers when scoping roles, but do treat the combination across two accounts (or an account plus a CI/CD pipeline) as equivalent to full design+deploy in a single attacker - an edit-only compromise is still a viable delivery mechanism.
  • Restrict and closely audit BTP OAuth2 client-credentials service keys scoped to /api/v1 deploy roles and to WorkspacePackagesTransport; rotate on any suspected exposure and scope them to the minimum tenant/package footprint needed.
  • Require a review/approval gate in the Cloud Transport Management pipeline itself (not just at the source tenant), so an injected package cannot reach production purely through automated transport.
  • Apply the same change-management/code-review discipline to iFlow Script steps as to any other production code path - the platform will not enforce this for you.

Detection and Monitoring

  • Script Collection deployment/redeployment events, correlated against a maintained reference map of consuming iFlows - flag any edit to a high-fan-out script that lacks a corresponding change ticket.
  • iFlow redeployment events where the iFlow’s own design content is unchanged but a referenced Script Collection version has changed - a signal the “affected iFlow” list is broader than the visible diff.
  • POST /api/v1/DeployIntegrationDesigntimeArtifact and transport-module (.../api/1.0/transportmodule/Transport) calls from unfamiliar OAuth2 client IDs, off-hours timing, or a client ID not matching the expected CI/CD pipeline identity.
  • Script step diffs on iFlows tagged as production, particularly additions of ITApiFactory, SecureStoreService, Runtime.getRuntime().exec, or new outbound java.net calls - reuse the detection guidance in Integration Suite Groovy Scripting.
  • Transport pipeline audit logs for packages introduced or modified outside the expected source-tenant -> target-tenant flow.

References