Beyond the Perimeter: How Attackers Pivot Across SAP Cloud Migrations (and How to Stop Them)

The Expanded Attack Surface of Hybrid SAP Landscapes

SAP cloud migrations expand an organization’s attack surface by moving from isolated on-premises systems to more complex, interconnected hybrid environments. While migrating to RISE with SAP, SAP Business Technology Platform (BTP), and SaaS solutions drives business agility, it could also introduce potential lateral movement vectors that can bypass traditional perimeter defenses. Threat actors do not need to break through corporate firewalls when they can exploit misconfigured trust relationships, exposed trace logs, and shared cloud credentials to move freely between on-premises and cloud instances.

To demonstrate these cross-perimeter attacks, CTO JP Perez-Etchegoyen, Lead Offensive Security Researcher Pablo Artuso, and Senior Sales Engineer Hector Espinosa recently presented Beyond the Perimeter: Managing the Expanded Attack Surface of SAP Cloud Migrations, the fourth episode of our Hacking & Defending SAP Applications docuseries.

Key Takeaways

• Firewalls No Longer Protect SAP Data: While relying solely on firewalls left critical blind spots in the past, the risk has escalated significantly today. Hybrid architecture creates connective bridges (such as SAP Cloud Connector and RFC destinations) that threat actors traverse once an initial foothold is established. 
• Insecure configurations can expose sensitive data: Enabling verbose diagnostic tracing (such as Cloud Connector Tunnel Traffic Trace) can write Base64-encoded administrative credentials directly to readable log files.
• Trust Relationships Can Be Weaponized: Compromising an on-premises S/4HANA or ERP system allows attackers to abuse established SM59 destinations and communication arrangements to provision backdoor accounts in SAP BTP.
• Subaccounts Are Not Hard Security Boundaries: Web application flaws (e.g., Command Injection in BTP apps) expose environment variables (VCAP_SERVICES), enabling attackers to harvest plaintext service credentials and pivot across subaccounts to internal databases.

The Hybrid SAP Reality: Why Traditional Perimeter Controls Fail

Traditional perimeter security fails in modern SAP environments because hybrid cloud connectivity turns external endpoints into internal gateways.

In legacy architectures, enterprise resource planning (ERP) systems resided behind corporate firewalls. Security teams relied on network segmentation to keep core business logic safe. Today, an enterprise SAP ecosystem spans multiple operational layers:

When organizations execute S/4HANA transformations or transition to RISE with SAP, they create tight integration flows between these layers. Threat actors target the integration protocols, authentication tokens, and diagnostic configurations connecting these environments rather than attacking hardened application cores directly.

Research from Onapsis Research Labs shows threat actors weaponize newly disclosed vulnerabilities in as little as 72 hours. To defend these hybrid environments, security teams must understand how attackers execute lateral movement across cloud and on-premises topologies. 

Attack Vector 1: Cloud Connector to On-Premises  

Attackers pivot from cloud connectors to on-premises core systems by extracting Base64-encoded credentials from diagnostic logs and invoking dangerous ICF services.

The SAP Cloud Connector acts as a reverse-invocation proxy connecting SAP BTP cloud applications to on-premises systems. Because it establishes outbound secure tunnels, it avoids opening inbound firewall ports. However, administrative misconfigurations within the Cloud Connector create severe risk.

The Exploit Chain

1. Trace Configuration Exposure: An administrator enables verbose diagnostic tracing (specifically the Tunnel Traffic Trace) in SAP Cloud Connector during troubleshooting.
2. Credential Extraction: A user with a low-privileged monitor or support role accesses log files. The trace logs record HTTP/REST payloads passing to internal systems, including Base64-encoded HTTP Basic Authentication headers.
3. Internal Gateway Targeting: The attacker decodes the Base64 string to reveal cleartext administrative credentials used by the BTP destination.
4. Service Abuse: The attacker connects directly to the internal application server and locates activated Internet Communication Framework (ICF) services. By calling the SOAP RFC service, the attacker executes remote function calls to create a new dialog user with full SAP_ALL administrative authorizations.

So for this, we have a a demo. On the first part of the demo, you’re gonna see a black screen. This is the screen of the administrator. It’s actually not relevant for the attack, but it’s part of the demonstrating you how to enable this trace. So here we can see how there is, this part of the configuration where you can see the checkbox up there. But once it’s checked, there are gonna appear new files over there. Now let’s jump to the to the display of the attacker, the monitor user. User. So we see those files over there, and they are able to be read. The monitor is able to read the traffic that is going through the application to the HR system. Right? So here there, you can see not only the password, a user encoding base64 but also the URL. So it’s pretty easy for an attacker to decode this v sixty four and get the real credentials that are used in the BTP destination. After this, the attacker can do or is gonna do two different commands just to check the the, let’s say, the connectivity against the HR system that is running on prem. The first one is gonna result in a four zero one because no credentials was provided. And the last one, luckily for the attacker, it’s gonna result in a two hundred because the credentials were valid. So now the attacker can do several things to test these credentials. For instance, it could go to SAP GUI and try to log into the system. Unfortunately, for the attacker, this is not a dialog user. However, it can use other ICF services. For instance, the very well known SOAP RFC, which is pretty dangerous. Here, we can see that the attacker realizes that it’s activated. So by using crafted script, the attacker will try to create a new user in the system with potentially very high privileges. In this case, we’ll try to use SAP_ALL. This could work or not depending on the authorizations of all the credentials But as you can see here, it worked. So now the attacker can log in with the new created user using SAP GUI. And just for the sake of this demonstration, it would show that the credentials sorry. The authorizations obtained were actually SAP_ALL.

Remediation & Hardening Guide: Securing SAP Cloud Connector

To mitigate Cloud Connector credential exposure, implement the following security controls:

Prerequisites

• Administrative access to SAP Cloud Connector Management Console.
• Authorization to modify ICF service nodes in transaction SICF on target ABAP systems.

Step-by-Step Actions

1. Disable Diagnostic Tracing: Open the Cloud Connector console, navigate to Tools > Trace, and ensure Tunnel Traffic Trace is unchecked. Enforce a strict “four-eyes principle” (dual-authorization) for trace enablement.
2. Apply Least-Privilege Scoping: Review BTP destinations in the SAP BTP Cockpit. Ensure service account users specified in destinations hold minimal authorizations scoped strictly to required remote function modules (RFCs).
3. Deactivate Insecure ICF Services: Log into the on-premises system, run transaction SICF, locate node /sap/bc/soap/rfc, and deactivate the service if not explicitly required by business operations.
4. Configure Explicit Access Control Lists (ACLs): In Cloud Connector under Access Control, restrict allowed resources to specific function modules rather than granting open access to all RFC endpoints (/ or ALL).

Validation Step

Run transaction SM20 (Security Audit Log) or execute an automated scan via Onapsis Assess to verify that SOAP RFC calls from external IP ranges are blocked and logged.

Attack Vector 2: On-Premises-to-Cloud Pivoting via Trust Relationship Abuse

Attackers pivot from on-premises systems into cloud environments by abusing stored RFC destinations and over-privileged communication arrangements.

Organizations frequently assume that an attacker compromising an on-premises system cannot reach cloud environments like SAP BTP. However, applications routinely maintain pre-established trust relationships via SM59 RFC destinations and OAuth client configurations.

The Exploit Chain

1. Initial On-Premises Compromise: An attacker gains execution privileges on an internal S/4HANA or ERP system (e.g., via custom code vulnerabilities or stolen credentials).
2. Destination Inspection: The attacker executes transaction SM59 to identify active HTTP/RFC connections pointing to ABAP on SAP BTP or other cloud tenants.
3. Configuration Drift Abuse: The connected cloud communication user possesses over-assigned communication arrangements due to testing artifacts left in production.
4. Cloud Backdoor Provisioning: The attacker deploys a custom ABAP report that executes REST calls against BTP administrative APIs using the stored destination token. The script creates a new BTP communication user and a business user with elevated privileges, establishing an unmonitored backdoor in the cloud.

Now the demo, I said that it’s an S/4 system. Right? So it’s a system that is running either on a private cloud or on premises. This going through s m fifty nine, we can see the existing integration with ABAP on BTP. We tested. It’s working. It’s pointing to a specific tenant of ABAP on BTP And this has a there is a specific, report that can be executed that shows us the connectivity, some exchange of information with the with the remote system. But then this attacker that compromised this on premise system, because that’s that’s the overall objective, right, showing that a compromise in one system could impact the the other the rest of the systems. In this case, this this attacker is creating a specific report, custom code that can be used to do different things. We’ll see what what it’s being done. But this is just because of the privilege of the attacker. He realized he or she realized that there is a established trust relationship through this destination. So this ABAP code is basically using this destination. So this attacker is listing the communication users first through this communication arrangement that was configured. Then he’s using the same communication arrangement to create another communication user. And also through this same code, right, it’s a code that could be doing anything. But in this case, it’s using the right APIs to connect with ABAP on BTP. It’s creating also a business user and widening the privileges of that business user. So through this integration, the attacker was able to actually get a hold a foothold into the ABAP on BTP system and creating both a communication user as well as a business user. And then now we we go and list the users. Now we see this backdoor user that was created. Right? This is just for the purpose of the demo. Other things could be executed depending on the privileges, depending on on the the code that is deployed, the the privileges on both the target and the source system. And we can see the the created communication user there, basically highlighting the compromise on the target system.

Remediation & Hardening Guide: Securing Integration Destinations

Secure inter-system connections against credential misuse by applying these controls:

Step-by-Step Actions

1. Eliminate Static Stored Passwords: Replace hardcoded user passwords in SM59 destinations with Principal Propagation using X.509 mutual TLS certificates or OAuth 2.0 SAML Bearer assertions.
2. Implement Transport & Code Security: Deploy Onapsis Control within your transport management workflow (SAP TMS, ChaRM, Rev-Trac) to scan all custom ABAP code before migration, blocking unauthorized API calls to external cloud tenants.
3. Audit Cloud Communication Arrangements: Log into SAP BTP Cockpit, navigate to Communication Management > Communication Arrangements, and revoke unused communication scenarios (such as user management APIs).

Validation Step

In SAP BTP Cockpit, review the Change Documents log under User Management to confirm that no unauthorized communication users or role collections were created during the past 30 days.

Attack Vector 3: Cloud to On-Premise Exploitation & Cloud Foundry RCE to Internal HR Data Exfiltration

Attackers exploit web application flaws in BTP apps to extract shared cloud service credentials and exfiltrate on-premises HR data across subaccount boundaries.

A common architectural misconception is treating SAP BTP subaccounts or Cloud Foundry spaces as isolated security boundaries. When multiple cloud applications share underlying connectivity and destination services, a vulnerability in a low-criticality app can compromise high-value enterprise databases.

The Exploit Chain

1. Application Vulnerability Exploitation: An external attacker identifies a Remote Code Execution (RCE) flaw (such as a command injection vulnerability in a UI5 or Node.js application) running in Cloud Foundry BTP.
2. Environment Variable Extraction: By executing OS commands within the container, the attacker inspects the VCAP_SERVICES environment variable. In Cloud Foundry, VCAP_SERVICES contains JSON objects storing API keys, tokens, and plaintext passwords for bound destination and connectivity services.
3. Cross-Service Credential Harvesting: The shared destination service contains credentials for both the low-risk application (supplier_prod) and high-value production systems (HR_prod).
4. Data Exfiltration: Using the harvested HR_prod service token, the attacker routes queries through the internal proxy established by Cloud Connector, dumping employee compensation data, bank details, and personal records directly from the internal database.

So let’s jump to a video. Let’s see how this actually works. So at first, you’re gonna see the screen of the supplier portal application. This is not very relevant to see what happens actually. What is important is that you see and recognize that there is a vulnerability that is gonna be shown by the attacker now. That is a command injection. And, also, for the sake of this demo, because that screen is a little bit very short or pretty small, we can use directly the API as you see in a moment. And we are gonna shift to second tab of the Chrome to see in a bigger size the the app that are working. So in Cloud Foundry, there is this VCAP_SERVICES which holds all the credentials of the actual applications need to connect to the destination and the connectivity. As you can see here, right in JSON format, all this information is stored in the OS. So with this information, first, an attacker who has access to can craft tokens and use these services, the destination and the connectivity service. So in the following screen, you will see the attacker using making use of this information and dumping all the destinations with the information that is in the shared service, the destination shared service. Here, you’ll see the HR_prod and the supplier_prod with plain text passwords. Right? This is possible. This is not a bug. This is by by default, is. So now having this information, the HR_prod information, we can use the connectivity decision, right, with these new credentials and try to grab and reach the system that is behind the Cloud connector. The quality is the service is goes through internal proxy, as I told you. So the only way to reach it is through the internal this the using the remote code execution. Right? So the attacker, what it did there first was to try to see if it’s reachable, the system. And now what it’s gonna do is try to dump all the information that is exposed in HR system, like if it was using the other application, the HR portal application. Here is a nicer way to see this information leaked where you can see, for instance, the monthly income of each person of the company employee and the email

Remediation & Hardening Guide: Isolating BTP Services & Applications

Prevent cross-app credential leakage and subaccount pivoting with these defensive steps:

Step-by-Step Actions

1. Enforce Subaccount Security Boundaries: Separate high-value business applications (HR, Finance) into dedicated BTP subaccounts with independent Destination Service instances. Do not share single destination service bindings across unrelated applications.
2. Scan Custom BTP Code for Security Flaws: Integrate DevSecOps code testing into your CI/CD pipelines (Azure DevOps, GitHub Actions, SAP Cloud ALM) to detect command injection, SQL injection, and hardcoded secrets before deployment.
3. Restrict Cloud Connector Resource Paths: Configure granular Access Control Lists in Cloud Connector. Specify exact URL paths (e.g., /sap/bc/gui/sap/its/supplier_app/*) rather than granting blanket domain access (/).

Validation Step

Inspect Cloud Connector audit logs (ljs_trace.log) to confirm that requests targeting unauthorized backend URL paths receive HTTP 403 Forbidden responses.

How Onapsis Delivers Defense-in-Depth Across Hybrid SAP Topologies

The Onapsis Platform delivers unified, automated visibility, vulnerability management, threat detection, and code security across on-premises, RISE with SAP, and BTP landscapes.

Securing complex hybrid environments requires moving beyond point-in-time manual checks. The Onapsis Platform addresses security and compliance across the entire lifecycle:

• Onapsis Assess: Delivers continuous vulnerability management across 6,000+ checks spanning ABAP, Java, HANA, BTP, Cloud Connector, Web Dispatcher, and SuccessFactors. Automatically validates whether manual SAP Security Notes and workarounds were correctly applied.
• Onapsis Control: Performs static, dynamic, and interactive application security testing across custom ABAP, Fiori, SAPUI5, HANA XSJS, and BTP Node.js code. Features in-IDE “One-Click Fix” automated remediation to clean code before deployment.
• Onapsis Defend: Operates as a real-time application intrusion detection system (IDS) featuring 2,500+ specialized SAP threat detection rules and 574+ exploit signatures. Delivers zero-day pre-patch protection rules ~120 days before public SAP Security Notes.
• Onapsis Research Labs: The premier threat research team credited with discovering over 1,000 zero-day vulnerabilities in business-critical applications, serving as a direct threat intelligence feed to US CISA, German BSI, and SAP engineering. According to official SAP Security Researcher Acknowledgments, Onapsis researchers consistently lead the industry in responsible vulnerability disclosure.