Hardcoded and Virtual Super-User SAP*

Updated on Sep 18, 2026

Description

SAP* is SAP’s built-in super-user. There are two distinct ways to obtain a working SAP* logon without knowing any password - they are frequently confused, so this page separates them:

A. Hardcoded / emergency SAP* (all kernels). A kernel fallback: if no SAP* record exists in table USR02 for a client and the profile parameter login/no_automatic_user_sapstar = 0, the kernel provides a hardcoded super-user SAP* with the well-known password PASS. Reaching it as an attacker means deleting the USR02 SAP* row (requires DB access), setting the parameter, and restarting the instance - noisy and high-prerequisite. (SAP Note 3303172, “second option”.)

B. Virtual SAP* via dpmon (kernel ≥ 790). SAP Note 3303172 (“first option”) added a time-limited, client-specific virtual super-user SAP* created in memory by the kernel tool dpmon. There is no USR02 row, no database write, and no SU01 visibility. Any process running as <sid>adm at OS level can create it and receive a one-time password, valid 10–30 minutes, that logs on as full super-user SAP* in the chosen client.

The security-relevant consequence: every OS-command-execution channel on an ABAP system (RFC Gateway SAPXPG, SXPG_STEP_XPG_START, WebGUI RSBDCOS0) already runs as <sid>adm. So any OS-command foothold converts directly into an interactive SAP* super-user session - no database access, no restart. It bridges “run one OS command as <sid>adm” to “authenticated SAP GUI super-user”.

Risk

An attacker who can execute a single OS command as <sid>adm (typically reached via OS command execution or an RFC Gateway ACL weakness) can activate a virtual super-user SAP* and log on with full authorization, entirely bypassing the SAP authorization concept and gaining complete control over the system and its data. The hardcoded variant achieves the same outcome where a SAP* record can be removed at database level. Both compromise confidentiality, integrity, and availability.

Options

Virtual SAP* (kernel ≥ 790) - from an <sid>adm OS-command channel, drive dpmon’s Virtual SAP* user sub-menu (Virtual SAP* [u] → create [c]), supplying the 3-digit client and validity in minutes; dpmon returns a 40-character one-time password. Automated by SAPMAP modules/exploitation/sap_dpmon_sapstar.py. Log on SAP* / one-time-password, then create a persistent privileged user.
Note
Any password-based logon attempt for SAP* (success or failure) invalidates the one-time password immediately - re-activate with dpmon to obtain a new one.
Hardcoded SAP* - delete the SAP* row from USR02 for the target client at DB level, set login/no_automatic_user_sapstar = 0, restart the instance, log on SAP* / PASS.

Mitigation

Apply SAP Note 3633474 and set login/create_virtual_user_sapstar = 0 on every instance where break-glass virtual SAP* is not required (restart to activate). This governs the virtual variant.
Keep login/no_automatic_user_sapstar = 1 and ensure a locked SAP* user record exists in every client (including newly created clients) - this defeats the hardcoded variant.
Eliminate the upstream OS-command primitive: harden RFC Gateway ACLs (secinfo/reginfo, gw/rem_start = DISABLED) and restrict SXPG/SM49/SM69, so <sid>adm OS command execution cannot be reached (see OS command execution).
Restrict OS access to <sid>adm.

Detection and Monitoring

Security Audit Log event EUP (virtual SAP* create/delete) - alert on any occurrence; legitimate use is rare and change-controlled.
Successful SAP* dialog logon, especially in production clients, outside a known emergency-access window.
OS-level: dpmon executed by an unexpected parent (spawned from sapxpg/disp+work rather than an admin shell); creation of unplanned privileged users after such an event.
Hardcoded-variant indicators: USR02 SAP* row deletion, login/no_automatic_user_sapstar flipped to 0, an unplanned instance restart.