RFC is the most powerful and least monitored execution pathway in most SAP landscapes. A user who has authenticated via an RFC connection and holds S_RFC authorization can call function modules that read any database table, create and modify user accounts, change system configuration, and execute transactions, none of which appear in the business process monitoring that most SAP teams run day to day.
The authorization checks inside individual function modules vary enormously. Some are rigorous. Some are minimal. And some well-known function modules perform no meaningful authorization check at all when called via RFC, which is why RFC-based attacks are a documented and actively exploited attack vector in SAP penetration testing and real-world breaches.
This article covers what unauthorized RFC activity looks like in practice, where the monitoring signals live, and what real-time detection requires.
Why RFC is a wider attack surface than most teams recognize
What a remote function call can actually do
RFC_READ_TABLE is the most commonly referenced example because it demonstrates the problem clearly. The function module is RFC-enabled, widely known, and designed for legitimate use in data exchange scenarios. It accepts a table name and selection criteria, and returns the table contents. The authorization check it performs is S_TABU_DIS, which controls table access by authorization group. In practice, a significant fraction of SAP implementations have overly broad S_TABU_DIS assignments because the maintenance of fine-grained table authorization groups is complex and was rarely enforced during implementation.
An attacker who authenticates via RFC with a technical user holding S_RFC access and sufficient S_TABU_DIS coverage can extract USR02 (password hashes), UST04 (user-to-profile assignments), AGR_USERS (role assignments), and RSECTAB (security configuration) in a series of RFC_READ_TABLE calls. This extraction requires no SAP GUI access, leaves minimal footprint in standard logging if the security audit log is not configured correctly, and can be automated to run in minutes.
Beyond data extraction, RFC enables execution. BAPI_USER_CREATE1 creates SAP users when called by a user with the right authorizations. SUSR_USER_CHANGE_PASSWORD_RFC changes passwords. SXPG_COMMAND_EXECUTE runs OS-level commands if the calling user has S_RZL_ADM. These are legitimate function modules used in integration scenarios. They are also the function modules that make RFC a complete remote execution platform when combined with a compromised or overprivileged account.
The authorization gap that RFC creates
SAP’s authorization model was designed primarily for dialog users navigating menus and transaction codes. When a call arrives via RFC, the authorization checks that run depend entirely on what the function module developer implemented. There is no RFC-level authorization layer that enforces transaction-equivalent checks automatically.
The S_RFC authorization object controls which RFC function groups and function modules a user or role can call remotely. But S_RFC is typically granted at the function group level, not the individual function module level. Granting access to function group SDTX to allow one specific function module call also grants access to every other RFC-enabled module in that group. The practical consequence in most landscapes is that RFC authorization profiles are broader than intended because scoping them precisely requires knowing exactly which function modules are in which groups, which is maintenance-intensive work.
| Watch out: The SAP authorization profile RFC_NO_AUTHORITY grants unrestricted RFC access to all function modules and function groups. It is sometimes applied to service accounts or RFC technical users during implementation to bypass connection testing issues. It should be treated as a critical finding in any authorization review. An account with RFC_NO_AUTHORITY can call any RFC-enabled function module in the system, bypassing the S_RFC authorization layer entirely. |
What unauthorized RFC activity looks like
Reconnaissance patterns: table reads and authorization queries
An attacker exploring an SAP system via RFC typically follows a recognizable sequence. Initial calls probe what is accessible: RFC_READ_TABLE with common table names to test authorization coverage, function modules from the SYST and SYSTEM groups to retrieve system information, and calls to user management function modules to determine what user administration capabilities are available. These reconnaissance calls generate RFC authorization failure messages in the system log when they are rejected, and generate nothing when they succeed.
The pattern that distinguishes reconnaissance from legitimate use is the combination of breadth and timing. A legitimate RFC integration calls the same set of function modules repeatedly on a schedule. A reconnaissance sequence calls a variety of function modules in a short time window, often from a source system or IP address not associated with any configured integration. The breadth of function module calls and the absence of a matching configured RFC destination in SM59 are the two signals that most clearly distinguish attack behavior from normal integration traffic.
Privilege escalation and persistence via RFC
Once an attacker has mapped the accessible function modules, the escalation path is direct. If BAPI_USER_CREATE1 is callable, create a new user with a known password. If SUSR_USER_CHANGE_PASSWORD_RFC is callable on an existing high-privilege account, reset its password. If the system trust relationships allow a trusted RFC logon from the compromised system, use the trusted logon to access connected systems without reauthentication.
Trusted RFC connections deserve specific attention. When a system is defined as a trusted system in SM59 and the corresponding trust relationship is configured, users from the trusted system can log in to the target system without providing a password, using only their user ID. If a trusted source system is compromised, the attacker can log in to the target system as any existing user, including those with administrative privileges, without knowing any credentials on the target system. The authentication event looks legitimate because the logon mechanism is legitimate. The anomaly is the user ID and the calling system.
Where the monitoring data lives
Security audit log events and what to watch
The SAP Security Audit Log (transaction SM20, or RSAU_READ_AUD_LOG for newer systems) records security-relevant events including RFC-specific activity. The event classes that matter for RFC security monitoring are AU5 (RFC function module calls for activated audit log entries) and the authorization failure events in class AUB. Specifically, message type AUB with subtype AUB0003 records failed RFC authorization checks, which represent rejected calls where an attacker was probing for accessible function modules.
The security audit log is not active by default on all systems. It requires explicit configuration in SM19, including which client to audit, which event classes to capture, and whether to capture all users or only specific ones. Many SAP production systems have the security audit log configured incompletely: it captures dialog logon events but not RFC events, or it captures RFC events for specific users only. Verifying that RFC-relevant event classes are active for all users in the production client is a prerequisite for the monitoring to have any data to work with.
SM21 and RFC authorization failures as early indicators
The system log (SM21) records authorization failure messages in message class UC. An RFC call that fails because the calling user lacks S_RFC authorization generates a UC message with the function module name and calling user. These UC messages are the probe log: they show which function modules an attacker or misconfigured system tried to call and was denied.
A burst of UC authorization failure messages from the same user or RFC destination, calling a variety of function modules in a short window, is the clearest real-time indicator of active RFC reconnaissance. In a production system under normal operations, RFC authorization failures are rare. A system generating dozens of S_RFC authorization failures per minute from a single source has an active probe in progress.
The monitoring gap is that SM21 is a historical review tool, not an alerting mechanism. The data is there. Seeing it requires either a monitoring platform that reads and alerts on SM21 events in near real time, or a human who opens SM21 regularly enough to catch a probe while it is still in progress.
| Note: When the SAP Security Audit Log is configured to write to a database table rather than a file, query performance on the audit log table can degrade as the table grows over months. This sometimes leads administrators to reduce the audit scope to manage the table size, inadvertently removing RFC event capture. Check SM19 to confirm the current audit configuration reflects what is actually intended. |
What real-time RFC security monitoring requires
The security audit log and SM21 both contain the right data. The fundamental limitation is that they are read-after-the-fact. A monitoring platform that polls these sources every few minutes can reduce detection time from hours to minutes. But RFC-based attacks move faster than that. Extracting USR02 via RFC_READ_TABLE with automated tooling takes under a minute. A detection cycle measured in minutes catches it after the extraction is complete.
Real-time detection for RFC security events requires continuous collection from the security audit log at sub-minute intervals, with alert logic that fires on the patterns that indicate unauthorized activity rather than on individual events. The patterns that warrant immediate response are: more than three S_RFC authorization failures in 60 seconds from a single user or source IP, any successful call to a user management function module (BAPI_USER_CREATE1, SUSR_USER_CHANGE_PASSWORD_RFC) from a source not in the list of configured integration systems, any RFC session from an IP address not associated with a configured SM59 destination, and trusted RFC logons from source systems during hours when no legitimate integration activity is expected.
The distinction between a pattern-based alert and a threshold-based alert matters here. A threshold-based alert fires when RFC error count exceeds 50 per hour. It will not fire on a targeted attack that generates 12 precise calls to specific function modules, all succeeding, from a compromised account. A pattern-based alert that looks for calls to user management function modules from unexpected sources fires on the second call regardless of whether the first one succeeded or failed.
The SM59 destination list is the baseline. Every RFC source that appears in the security audit log should correspond to a configured and documented RFC destination. Calls from sources outside that baseline are anomalies by definition and warrant immediate review, regardless of whether any authorization failure was generated.
RFC security is not a configuration problem that gets solved once. The attack surface is defined by the intersection of which function modules are RFC-enabled, which users hold S_RFC authorizations with what scope, and which external systems have network access to the SAP gateway. All three of those factors change as landscapes evolve. New integrations add RFC sources. Authorization profiles drift. Systems get added to trust relationships without full documentation of the implications.
Monitoring that captures RFC events, surfaces the anomalous patterns in near real time, and alerts on deviations from the baseline of known integration traffic turns the RFC layer from an opaque execution pathway into a monitored and auditable one. The data is already there. The question is whether anyone is reading it at the speed the risk requires.
Redpeaks monitors SAP security audit log events and system log authorization failures in real time, with RFC-specific alerting patterns for reconnaissance detection and user management function module calls from unexpected sources. See the security monitoring coverage.
