The Silent SAP Killer: Why S_RFC* = Could Be Your Biggest Cybersecurity Risk

From Data Extraction to Financial Fraud—How One Misstep in S_RFC Can Wreck Everything

The Silent SAP Killer: Why S_RFC* = Could Be Your Biggest Cybersecurity Risk

Have you ever received an email about an “unclaimed inheritance” or a “once-in-a-lifetime” overseas business deal?

A WhatsApp message from a friend using a new number, urgently asking for help?

Or maybe a stranger connected with you on Instagram or Facebook, posing as an “investment advisor”?

These aren’t random events—they’re the frontlines of an ever-expanding cyber battlefield. Cybercriminals are innovating faster than technology itself, exploiting trust, urgency, and curiosity in ways most people never expect. Individuals today are targeted in a hundred different ways, and while the result might be a painful financial loss for them, enterprises face far graver consequences:

reputational damage, loss of customer trust, regulatory penalties, and sometimes, a hit to their very survival.

When the threat landscape evolves at lightning speed, the question isn’t if you’ll be targeted—it’s how prepared you are when it happens.

For enterprises running SAP, the risk isn’t just internal - it’s the digital nervous system of the organization, connecting critical business processes across departments, geographies, and subsidiaries.

External applications, interfaces, and APIs often interact through S_RFC authorizations, and a single misconfigured one can let unauthorized programs execute high-risk functions inside SAP.

Poorly maintained S_RFC permissions can open backdoors for data theft, system manipulation, and compliance breaches. In an interconnected landscape, securing these gateways is not optional—it’s critical to protecting both business operations and reputation.

Shocking Realities from the Cybersecurity Frontline

• 83% of SAP systems exposed to the internet had at least one vulnerability exploitable remotely. (Onapsis Threat Report, 2023)

• A typical SAP environment has over 45,000 function modules, many of which can:

  • Execute OS-level commands

  • Bypass business logic

  • Read/write sensitive data directly

• Insider threats account for 22% of data breaches, and unrestricted RFC access makes privilege escalation almost trivial.

Real-World Penetration Test Findings:

• In one critical case, a user with S_RFC = accessed RFC_READ_TABLE to exfiltrate payroll and personal data in under 30 seconds. (Tools such as Jitterbit are available to quickly read data from SAP tables.. check this link)

• In another, S_RFC access combined with S_USER_AUT (An authorization object that is required to grant an administrator authorization allowed an attacker to create a new user with SAP_ALL authorizations via BAPIs and remove the traces of such creation using advanced tools.

Why S_RFC_ = is a ticking time bomb?

S_RFC authorization objects are one of the primary keys controlling how SAP systems communicate with other systems and applications through Remote Function Calls. While modern integrations also use OData services and CDS views to exchange data, RFC remains a powerful and sensitive channel—capable of executing function modules that can read, modify, or even administer core SAP data.

This makes S_RFC a high-value target for attackers and a critical point of control for security teams. Securing it with least-privilege access, strict whitelisting, and ongoing monitoring is essential to protect both business processes and sensitive information.

The main challenge?

In many SAP systems, I’ve observed that the S_RFC authorization object often doesn’t get the attention it deserves—frequently maintained with * (wildcard) values. This essentially grants access to numerous remote-enabled function modules, allowing an attacker to read, extract, or even manipulate critical business data. Such unrestricted access can open the door to serious security breaches, including financial fraud.

Mitigation Strategy: From Chaos to Control

To mitigate these risks, here’s an S_RFC Authorization Object Hardening Checklist:

1. Eliminate Wildcards

Avoid using * (wildcard) values when maintaining S_RFC* authorization objects such as S_RFC and S_RFCACL. Instead, identify the exact authorizations required and maintain only those.

I understand—it’s not easy to determine the precise values for these objects. One common approach is to enable User Trace and monitor usage, but this can be resource-intensive and quickly generate massive logs.

A far simpler option is to use ToggleNow’s custom-built S_RFC Authorization Analyzer, which traces only the S_RFC authorizations based on actual user executions—making the process faster, lighter, and more efficient.

If you’re facing the same challenge, feel free to connect with me with all the details and I am happy to help! (No free consulting please!)

2. Design Roles by Segregation

It's important to design roles with proper segregation of access for users who require RFC authorizations. Avoid creating a single, catch-all role (e.g., Z_RFC_AUTH) containing all interfaces. Instead, build roles with only the specific authorizations needed for the intended purpose.

Best Practices:

• Segregate integration users from other user types.

• Create dedicated non-dialog technical users for RFC calls.

• Assign only the S_RFC authorizations essential for their function.

• Remove access to high-risk function modules unless absolutely required.

3. Use UCON for RFC Control

One of the most effective ways to secure RFC communications in SAP is by enabling Unified Connectivity (UCON) in enforcement mode. This approach works on a positive list principle—only the explicitly approved Function Modules are allowed to be called, while all others are blocked by default.

Implementing UCON in enforcement mode significantly reduces the attack surface, prevents unauthorized RFC calls, and ensures tighter control over remote-enabled function modules. For a detailed guide on setting up and using UCON, refer to:

https://togglenow.com/learnings/unified-connectivity-ucon-the-built-in-sap-cybersecurity-solution/

4. Enforce SNC encryption for trusted RFCs

Without SNC, even “trusted” RFCs can be intercepted—putting sensitive business data at risk.

When configuring trusted RFC connections, it’s critical to enable Secure Network Communication (SNC) encryption to protect data in transit. SNC ensures that all communication between SAP systems is encrypted, authenticated, and tamper-proof, mitigating the risk of data interception or manipulation. Without SNC, even trusted RFCs can expose sensitive business data to potential network-level attacks. By enforcing SNC, you not only comply with security best practices but also strengthen the overall integrity and confidentiality of your SAP landscape.

Refer to SAP Note # 2653733 - Enabling SNC on RFCs between AS ABAP

5. Secure secinfo and reginfo files

In SAP landscapes, the secinfo and reginfo files control which external programs can start or register RFC servers in the gateway. If these files are left open or misconfigured, attackers can exploit the SAP Gateway to execute unauthorized programs, inject malicious processes, or gain entry into the SAP system.

To secure them, configure explicit allow rules rather than relying on broad or wildcard entries. Ensure that only trusted programs and hosts are permitted, and regularly review these files for outdated or unnecessary entries. Additionally, activate Gateway Security Logging to monitor access attempts and quickly identify suspicious activity. Properly maintaining secinfo and reginfo files is a critical step in hardening your RFC and Gateway security posture.

Secinfo:

# --- secinfo: explicit allow-list; everything else is denied by default ---

# Allow only the local application server to start rfcexec (if you truly need it)

P HOST=localhost, TP=rfcexec, USER=<sid>adm

# Allow specific batch/integration hosts to start a named helper program

P HOST=app01.corp.local, TP=/usr/sap/<SID>/exe/myhelper, USER=<sid>adm

P HOST=app02.corp.local, TP=/usr/sap/<SID>/exe/myhelper, USER=<sid>adm

# Block overly-broad patterns: DO NOT do this (example for training only)

# P HOST=*, TP=*, USER=*

Important:

• Keep the list minimal and host-specific.

• Prefer full paths for TP= where applicable.

• If you don’t use rfcexec, do not allow it.

Reginfo:

# --- reginfo: allow only known server programs from approved hosts ---

# Allow a specific RFC server to register from two app servers

P TP=Z_RFC_SERVER_PAYMENTS, HOST=app01.corp.local, SNC=1

P TP=Z_RFC_SERVER_PAYMENTS, HOST=app02.corp.local, SNC=1

# Allow PI/PO program to register from its dedicated host

P TP=SAPSLDAPI, HOST=pi01.corp.local, SNC=1

# Example: permit a trusted external scheduler to register a named TP

P TP=EXT_SCHEDULER, HOST=schedule01.tools.local, SNC=1

# Avoid wildcards; do not open this up:

# P TP=*, HOST=*

Important:

• Define one line per (program, host) pair where possible.

• Use SNC=1 to enforce encrypted/authenticated registration (omit only if unsupported in your release).

• Never allow TP=* or HOST=*.

Hardening checklist for secinfo & reginfo:

• Set gw/acl_mode = 1 and point gw/sec_info & gw/reg_info to your managed files.

• Store these files in a secured directory with restricted OS permissions.

• Review and prune entries regularly; remove obsolete hosts/programs.

• Enable and monitor Gateway Security Logging; alert on denied attempts.

• Combine with UCON (enforcement mode) and SNC for RFC to reduce the attack surface end-to-end.

6. Log all RFC calls in Security Audit Log (SAL)

Enabling RFC call logging in the Security Audit Log (SAL) is a crucial step in detecting unauthorized access and suspicious activity in SAP systems. By capturing RFC executions, you gain visibility into which function modules are being called, by whom, and from where—helping identify potential abuse, privilege escalation, or data exfiltration attempts.

To configure this:

1. Go to SM19 (Security Audit Log Configuration).

2. Activate logging for relevant user groups or specific technical users involved in RFC communications.

3. Include RFC function module execution events in the filter profile.

4. Regularly review logs in SM20 or route them to a SIEM for correlation and alerting.

Here is one of the example filter:

Event Class: RFC

Event Type: All

Users: RFC_*, SAP*, DDIC, BASISADM, <Integration_UserIDs>

Terminal: *

Audit Class: Critical Authorization Checks

Since RFC calls often happen in the background and may bypass standard UI logging, having them recorded in SAL ensures that no remote execution activity goes unnoticed. For high-risk systems, this logging should be enabled permanently and reviewed as part of your continuous monitoring strategy.

To maintain a strong RFC security posture, configure your monitoring tools or SIEM to send real-time alerts whenever sensitive function modules are executed or calls are made to unauthorized destinations.

Conduct regular reviews—at least quarterly—of all S_RFC assignments to ensure they align with current business requirements.

Remove any unused or obsolete RFC authorizations immediately to minimize the attack surface. Consistent monitoring, timely alerting, and disciplined cleanup are essential to preventing misuse and safeguarding your SAP landscape against RFC-based threats.

Final Word for CISOs

As enterprises move toward digitization and cross-system integration, RFC misuse becomes one of the most exploitable weaknesses in SAP landscapes.

Giving wildcard RFC access is like handing over a nuclear launch code and hoping no one presses the button.

The cost of fixing it now? A few days of effort.

The cost of ignoring it? Your data, compliance, and credibility.

Talk to the team at ToggleNow. We go #BeyondGRC—while others talk about their case studies, we’re busy delivering them.