Lateral Movement Through SAP Landscapes

In many SAP landscapes, access to one SAP system can become a starting point for lateral movement into other systems. This is especially relevant when sandbox, development, or quality assurance systems have RFC connections to productive systems.

This attack path is commonly known as RFC hopping. It can occur when RFC Type 3 destinations in SM59 contain stored credentials, trusted relationships, or technical users with excessive authorizations in the target system.

SAP recommends not storing logon information for dialog users in RFC destinations. SAP also recommends that system users with stored logon data should have only a minimal level of rights in the target system.

RFC hopping can lead to unauthorized access to productive SAP systems and the data they contain.

Depending on the authorizations of the configured RFC user, an attacker may be able to:

• log on directly to the remote system,
• execute remote-enabled function modules,
• read sensitive business or security-relevant tables,
• extract password hashes or sensitive configuration data,
• create or modify users,
• assign roles or profiles,
• escalate privileges in the target system,
• use the compromised target system as a new pivot point for further lateral movement.

An RFC Type 3 destination in SM59 may contain a stored dialog user with excessive privileges in the target system.

If an attacker gains access to the source system and can access the destination, the Remote Logon function may allow direct interactive access to the configured target system.

This is especially critical when the source system has a lower security classification than the target system, for example:

• sandbox to production,
• development to production,
• quality assurance to production.

An RFC Type 3 destination may also use a non-dialog or technical user. Even without interactive logon, this user can still be abused if it has excessive RFC authorizations.

For example, remote-enabled function modules may allow access to sensitive data or administrative actions in the target system. SAP documents that access to RFC function modules is controlled by authorization object S_RFC, including the fields RFC_TYPE, RFC_NAME, and activity 16 for execute.

A particularly sensitive example is RFC_READ_TABLE. SAP notes in the context of technical RFC users that RFC_READ_TABLE is not assigned to certain roles because it would allow the user to read almost all tables.

If the RFC user has sufficient authorizations, remote-enabled user administration functions may be abused to create or modify users in the target system.

For example, an attacker may abuse BAPI_USER_CREATE to create a new SAP user in the remote system. In a second step, user administration BAPIs or function modules may be used to assign powerful roles or profiles, such as SAP_ALL.

This can result in an attacker-controlled user with extensive authorizations in the remote productive system.

• Do not create RFC connections from systems with a lower security classification to systems with a higher security classification unless there is a documented business requirement.
• Treat RFC connections from development, sandbox, or quality assurance systems to production as security boundary violations unless explicitly justified and controlled.
• Avoid RFC paths such as development to production or quality assurance to production.
• Where such connections are unavoidable, document the purpose, owner, source system, target system, user, required authorizations, and compensating controls.
• Regularly review RFC destinations in SM59, especially destinations with stored credentials.

• Do not store credentials for dialog users in RFC destinations.
• Avoid generic or shared users in RFC destinations.
• Use dedicated technical users where stored credentials are required.
• Restrict technical users to the minimum authorizations required for the specific business purpose.
• Do not use SAP_ALL, SAP_NEW, broad S_RFC, or other excessive authorizations in RFC users.
• Rotate passwords for stored technical users according to the organization’s credential policy.

• Restrict S_RFC to the required function groups or function modules only.
• Avoid wildcard authorizations such as broad access to all RFC function groups.
• Review access to sensitive remote-enabled function modules, especially modules that can read tables, modify users, assign roles or profiles, execute commands, trigger jobs, or access security-relevant configuration.
• Pay special attention to functions such as RFC_READ_TABLE, BAPI_USER_CREATE, and user administration-related BAPIs or function modules.
• Explicitly review whether RFC users can create users, change users, assign roles, assign profiles, or indirectly grant authorizations such as SAP_ALL.

• Review trusted RFC relationships separately.
• Restrict and monitor authorizations related to trusted RFC, especially S_RFCACL.
• Avoid trust relationships from lower-classified systems to higher-classified systems unless strictly required and risk-accepted.

Monitor for indicators such as:

• remote logons from development, sandbox, or quality assurance systems to production,
• execution of sensitive remote-enabled function modules,
• unusual use of RFC_READ_TABLE,
• execution of BAPI_USER_CREATE or similar user creation functions via RFC,
• execution of BAPIs or function modules that assign roles or profiles to users,
• creation of users through RFC connections,
• assignment of critical roles or profiles such as SAP_ALL, SAP_NEW, or highly privileged custom roles,
• user creation followed shortly by role or profile assignment,
• user creation or privilege assignment performed by technical RFC users,
• changes to RFC destinations in SM59,
• changes to stored credentials,
• trusted RFC logons,
• failed or unusual RFC authorization checks.

Recommended SAP data sources include:

• Security Audit Log,
• system log,
• change documents for user and role administration,
• RFC destination change monitoring,
• role and authorization reviews,
• SIEM correlation for cross-system access patterns.

• SAP Help Portal: RFC/ICF Security Guide, User Administration
  SAP recommends not storing information for dialog users in RFC destinations and ensuring that system users with stored logon data have only minimal rights in the target system.

• SAP Help Portal: RFC/ICF Security Guide
  SAP provides general security guidance for the secure use of RFC and ICF communication between SAP systems and external systems.

• SAP Help Portal: Authorization Object S_RFC
  SAP documents that S_RFC controls RFC access to function modules and function groups using fields such as RFC_TYPE, RFC_NAME, and ACTVT.

• SAP Help Portal: Technical Users for RFC Connections READ and TMW
  SAP notes that RFC_READ_TABLE is not assigned to certain technical RFC roles because it would allow the user to read almost all tables.

• SAP Help Portal: Authorization Object S_RFCACL
  SAP documents the authorization object used to control trusted RFC access.

• SAP Help Portal: Security Audit Log
  SAP documents the Security Audit Log as a tool for recording security-relevant activities in the SAP system, including changes to user master records.

• SAP Help Portal: Security Audit Log Configuration
  SAP documents configuration-related information for the Security Audit Log.