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. Dynamic Profile Parameter Tampering
Edit page

Dynamic Profile Parameter Tampering

Description

Security auditors and hardening baselines routinely read the SAP profile (RZ10 / DEFAULT.PFL / RSPARAM) and trust it to reflect the running security configuration. For dynamically-switchable profile parameters, that trust is misplaced: a parameter can be changed at runtime via RZ11, take effect immediately, and be reverted on the next restart - with the on-disk profile never changing. This page covers the gap between what the profile says and what the kernel is actually enforcing, why it is both an audit blind spot and a post-exploitation tampering primitive, and how to check the real running value.

This matters because many of the most security-relevant parameters - gateway ACL mode and simulation mode, RFC authority checks, SNC downgrade acceptance, audit-log enablement - are dynamic.

Risk

An attacker or rogue administrator can silently weaken a control at runtime, perform their action, and restore the value - leaving a profile that an auditor reads as compliant and no change record in the profile history. Conversely, a control the profile shows as “on” may have been dynamically turned off. Impact: security controls (gateway ACL enforcement, RFC authority checks, encryption requirements, audit logging) can be defeated for a window without leaving evidence in the place auditors look, undermining both prevention and detection landscape-wide.

Options

  • Dynamic runtime change that reverts clean: many security parameters can be changed via RZ11 (or programmatically), take effect immediately, and are lost on the next restart, reverting to the profile value with no profile change. An actor sets, for example, gw/sim_mode = 1 (gateway ACL logs but never denies), gw/acl_mode = 0 (no ACL check), auth/rfc_authority_check = 0, or snc/accept_insecure_rfc = 1 at runtime, acts, then restores the value - and the profile file an auditor reads never changed. See RFC Gateway / 10KBLAZE for what those gateway parameters gate.
  • Three “truth” layers can disagree: the kernel default, the DEFAULT.PFL / instance profile value, and the current dynamic value can all differ. RZ11 shows a “Resulting Source” field precisely because these diverge - reading only the profile misses a live override.
  • Read the actual running value, not the profile: confirm the enforced value with RZ11 (“Resulting Source”), RSPFPAR, or from the OS with sapcontrol -nr <NN> -function ParameterValue <parameter>. Compare that running value against the profile file for every security-relevant dynamic parameter (gw/*, snc/*, auth/rfc_authority_check, rsau/enable, login/*); any mismatch is drift worth investigating.
  • History is under-used but exists: profile versions are stored in TPFET / TPFHT (source RZ10), and parameter change dates are collected into PAHI by the SAP_COLLECTOR_FOR_PERFMONITOR job. A dynamic-only change that was never saved to a profile appears in neither the file nor TPFET - only a live RZ11 / sapcontrol read, or a PAHI snapshot that happened to capture it, catches it. Cross-check PAHI for off-hours parameter flips.

Mitigation

  • Baseline the running values, not just the profiles. Use continuous configuration monitoring (EarlyWatch Alert, Security Optimization Service, or a third-party SAP config-monitoring tool) that reads the enforced value, and alert on any deviation from the approved baseline.
  • Prefer setting critical security controls as static (restart-required) parameters where the option exists, so a runtime flip cannot silently take effect and persist.
  • Enable table logging on TPFET/TPFHT and audit changes to parameter configuration; restrict the authorizations that permit RZ11 dynamic changes to a documented few.
  • Alert on dynamic changes to security parameters that occur outside change windows.

Detection and Monitoring

  • Running-vs-profile diff: on a schedule, compare sapcontrol ... ParameterValue / RZ11 “Resulting Source” against the profile for the security-relevant dynamic parameters; a mismatch is the core detection.
  • Security Audit Log: enable the audit class covering parameter / audit-configuration changes; watch for RZ11 activity on gw/*, snc/*, auth/rfc_authority_check, rsau/enable.
  • PAHI change dates: review for parameter changes at unusual times, especially security parameters flipped and flipped back.
  • Because a dynamic change reverts on restart, treat any unexplained restart around a suspicious window as a reason to reconstruct the running config from monitoring history rather than the current profile.

References