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. Identity Persistence: Universal ID & Rogue Trust Configs
Edit page

Identity Persistence: Universal ID & Rogue Trust Configs

Description

Once an attacker is elevated to subaccount-admin by any other vector, two durable, comparatively unreviewed surfaces become the highest-value, longest-lived persistence primitives - sitting alongside Role Collections but far less likely to be caught in a routine review: the SAP Universal ID (S-user) identity plane that gates Cockpit and Support Portal admin access, and a subaccount’s Trust Configuration list of federated IdPs. Where getting in is covered by Identity & Trust Misconfiguration, this page covers staying in.

Both primitives are quiet by design, and the BTP Audit Log’s default 90-day retention means even the events they do generate age out of the free-tier evidence trail - see BTP Audit Log Blind Spots for the retention detail that governs how long any of this stays discoverable.

Risk

  • S-user / Universal ID MFA-bypass loophole: the underlying SAP login step can be completed with S-user + password alone even where the organization believes MFA is enforced on the account - MFA can be layered on but does not necessarily gate the first factor. As the admin identity plane for Cockpit/Support Portal, a captured S-user is durable admin access that survives changes to the corporate IdP side entirely.
  • Trust-configuration tampering: adding an attacker-controlled OIDC/SAML IdP as an additional trust source in a subaccount is a durable SSO backdoor that most incident-response reviews of role collections and user lists never touch - the attacker keeps a login path even after their original foothold account is disabled.

Options

  • Persist via the S-user plane: test password-only authentication against SAP Universal ID login for an admin account even where the organization believes MFA is enforced; confirm whether MFA actually gates the first factor or is only a short-circuitable secondary step. A working password-only S-user is standing admin access.
  • Enumerate existing Trust Configuration (Security -> Trust Configuration) for every subaccount in scope; baseline the legitimate IdP entries so a planted one is distinguishable.
  • Establish a rogue trust config as persistence (requires prior subaccount-admin elevation): add a custom OpenID Connect/SAML IdP as an additional - not replacing - trust source, then specifically test whether the addition is logged and for how long that log entry survives (the 90-day retention window governs this).
  • Both can be driven via the platform API/btp CLI as well as the Cockpit UI - see BTP Cockpit & Platform API Abuse.

Mitigation

  • Federate BTP Cockpit/Support Portal administration to a corporate IdP/IAS with enforced MFA rather than relying on SAP Universal ID as the admin identity plane; treat S-user credentials as Tier-0 assets.
  • Include Trust Configuration review in every cockpit-focused assessment - see BTP Cockpit & Platform API Abuse.
  • Ensure trust-config and admin-logon events actually reach a SIEM within the retention window - see BTP Audit Log Blind Spots.

Detection and Monitoring

  • Trust-configuration additions/modifications in the Audit Log - confirm they are actually captured and check the exact retention window in force.
  • Any successful Universal ID logon to an admin-scoped account with no second factor recorded.
  • Regularly diff the Trust Configuration list against a known-good baseline - a control that survives the 90-day audit gap because it does not depend on the log at all.

References