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 ABAP Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Critical Authorizations & Privilege Hunting
Edit page

Critical Authorizations & Privilege Hunting

Description

Once a foothold exists - any dialog or RFC logon, however low-privileged - the next step is finding out what that user, or any user reachable through role/profile misconfiguration, is actually allowed to do. SAP’s authorization concept distinguishes two categories worth hunting for separately:

  • Critical single rights - one authorization object/value combination that is, by itself, sufficient to cause harm. The canonical example is debug-replace: S_DEVELOP with ACTVT=02 (“change”) and OBJTYPE=DEBUG. A user holding this can attach the ABAP Debugger to a running session (including another user’s, via ACTVT=90/DEBUG “debug remote requests”) and overwrite variable contents mid-execution - including the return code of an AUTHORITY-CHECK statement. Every application-layer authorization check in ABAP (anything implemented as an AUTHORITY-CHECK, not a kernel-level check) can be forced to return “authorized” regardless of the user’s actual authorizations. As of SAP NetWeaver 7.57 a second, finer-grained object, S_DBG, layers on top of S_DEVELOP for change-in-debugger scoping (by software component/package); if both objects are assigned, the more permissive of the two wins (SAP Note 65968).
  • Critical combinations - two or more authorization objects that are individually unremarkable but, held together by one user (directly, or via multiple assigned roles), enable fraud. The book’s example: S_TCODE/authority for FB01/FB02 (create/change a vendor master, including bank details) combined with authority for FB60 (post an invoice against that vendor) lets a single user redirect a payment run to an account they control - a textbook SoD conflict that no single authorization object flags on its own.

Beyond individual objects, SAP_ALL/SAP_NEW - the “all authorizations” composite profiles SAP ships for setup and emergency use - are worth hunting for directly: any account still carrying one of these in a productive client is an immediate, no-further-work objective.

Risk

A S_DEVELOP+DEBUG+ACTVT=02 grant converts any successfully-authenticated dialog logon into a full application-layer authorization bypass - every AUTHORITY-CHECK in every transaction and custom report becomes advisory, not enforced. SoD-critical combinations enable fraud (self-approved payments, self-created vendors paid to a controlled account) without needing any single “obviously dangerous” right. SAP_ALL/SAP_NEW grants are equivalent to full system compromise. Because critical combinations frequently arise only from the union of two or more separately-assigned roles, they are routinely missed by role-by-role review and only surface when checked at the user level - making them a reliable target for privilege-escalation testing even on otherwise well-hardened systems.

Options

  • Enumerate SAP_ALL/SAP_NEW holders - with any SUIM-equivalent access: SUIM -> Users -> By Complex Selection Criteria, or directly query USR04/UST04 (profile-to-user assignment) for profile SAP_ALL. Without SUIM access, RFC_READ_TABLE against AGR_PROF (generated profile per role) or UST04 gives the same answer from an RFC foothold.
  • Hunt the debug-replace single right - SUIM -> Roles/Users -> By Authorization Values, object S_DEVELOP, field OBJTYPE = DEBUG, ACTVT = 02. From an RFC-only foothold, the same query is a filtered read of AGR_1251 (authorization values per role) for OBJECT = S_DEVELOP AND OBJTYPE = DEBUG AND ACTVT = 02, cross-referenced against AGR_USERS for the assigned users.
  • RSUSR002 - classic report for cross-object user selection (e.g. “users with S_DEVELOP ACTVT=02 and dialog logon type”); still present on most systems even where newer SUIM variants are preferred.
  • RSUSR003 - as covered in Default SAP Users and Passwords, also reports which standard users are unlocked/on default passwords - a fast companion check.
  • RSUSR008_009_NEW (“list of users with critical authorizations/transactions”) - SAP-delivered report for exactly this hunting task, but it ships with no rule set: critical single rights/combinations must be defined first (via the same report) before it returns anything useful. Deprecated/unmaintained per the book, but still present and functional on most systems; worth running against whatever criteria are already configured (frequently left over from a prior audit).
  • SoD combination testing - pick a business-relevant pair (create/change vendor + post invoice; create PO + approve PO; create user + assign profile) and check both S_TCODE reachability and the object-level authorization for each half, per user, via SUIM by authorization values run twice and intersected, or the equivalent double AGR_1251/AGR_TCODES reads over RFC.
  • S_TABU_DIS/S_TABU_NAM reachability of sensitive tables - confirm which users can browse USR02, RSECTAB, AGR_*, RFCDES/RFCTRUST/RFCSYSACL via SE16/SE16N/RFC_READ_TABLE; S_TABU_NAM (SAP Note 1481950) is a second, independently-sufficient check layered on top of S_TABU_DIS since release 7.0x - a role cleaned of S_TABU_DIS access to a table authorization group can still expose the same table if S_TABU_NAM (checked by table name directly) was never cleaned in parallel. See secure store decryption for what RSECTAB access alone yields.
  • S_RFC, S_ADMI_FCD, S_USER_GRP/S_USER_AUT/S_USER_PRO - check for wildcarded (*) RFC_NAME on S_RFC (unrestricted RFC function-group access - see Critical RFC-Enabled Function Modules), broad S_ADMI_FCD (system administration functions), and any combination of S_USER_GRP+S_USER_AUT+S_USER_PRO sufficient to self-provision a new SAP_ALL account (the BAPI_USER_CREATE1 chain).
  • Underlying tables worth direct reads if SUIM itself is inaccessible: AGR_1251/AGR_1252 (authorization values/org-level values per role), AGR_USERS (role-to-user), AGR_PROF (generated profile name per role), AGR_TCODES (tcodes in role menus), USR04/UST04 (profile-to-user), UST12 (authorization values in profiles).
Note
There is no universal list of “critical rights” - the book is explicit that a fully comprehensive list would be too large and would flag too many false positives. What counts as critical is business-context-dependent (a critical single right in Financials may be routine in a sandbox client). Treat the objects above as a starting checklist, not an exhaustive one, and validate findings with the client’s own risk owners before reporting.

Mitigation

  • Restrict S_DEVELOP OBJTYPE=DEBUG ACTVT=02 to a documented, time-boxed emergency-access (firefighter) process; never grant it standing in a productive client. On 7.57+, use S_DBG to scope any unavoidable change-in-debugger access to specific software components/packages rather than system-wide.
  • Define critical single rights and critical combinations for the specific business processes in scope, together with the process owners, and check every new/changed role against that catalog before transport to production (RSUSR008_009_NEW, or a dedicated GRC/SoD tool such as SAP Access Control) - the book notes real-world use of third-party critical-rights tooling (e.g. real-time AG’s apm atlantis/apm observer) specifically because native tooling doesn’t scale past a handful of rules.
  • Run RSUSR002/SUIM-based sweeps for SAP_ALL/SAP_NEW holders and standing debug-replace grants on a recurring schedule, not only at go-live.
  • Clean up both S_TABU_DIS and S_TABU_NAM together - cleaning one without the other leaves the table reachable (SAP Note 1481950).
  • Apply least privilege to S_RFC (no RFC_NAME=*), S_USER_GRP/S_USER_AUT/S_USER_PRO, and S_ADMI_FCD; never bundle any of these into a custom “all authorizations” collector role.

Detection and Monitoring

  • User/authorization change logging is automatic and unlimited in the USHxx tables (USH02, USH04, …), viewable via report RSUSR100N - any grant or revocation of SAP_ALL/SAP_NEW, or of S_DEVELOP DEBUG ACTVT=02, to any user is recorded here independent of Security Audit Log configuration. See Logging and Detection Surface.
  • Security Audit Log (SM19/RSAU_CONFIG): the critical object changes / transaction start / dialog logon audit classes will show a debug session start against a production transaction - the book calls this a textbook red flag for auditors regardless of whether the debug session actually modified anything.
  • SU53/STAUTHTRACE immediately after a suspected debug-replace event will not show a failed authorization check for actions that succeeded only because the check’s result was overwritten in the debugger - the absence of an expected failure is itself a signal worth correlating against the debug-session audit log entry.
  • Baseline and re-run RSUSR008_009_NEW/SUIM critical-combination sweeps after every role transport, not only periodically - critical combinations frequently appear only after a second, seemingly unrelated role is assigned to a user who already held the first half.

References