How to Perform an SAP Penetration Test Safely

Understanding the SAP Attack Surface

Before any test begins, the team must understand what they are testing. The SAP attack surface is broad and layered, spanning multiple protocols, interfaces, and application layers. A safe penetration test must account for each of these vectors without assuming they can all be tested with the same tools or permissions.

SAP Application Layer (ABAP and Java Stack)

The ABAP application server is the primary target for most SAP security assessments. Common entry points include RFC-enabled function modules, BAPIs, and screen exits. Unsecured RFC destinations, hardcoded credentials in custom ABAP code, and missing authorization checks in custom transactions represent the most frequent high-risk findings. The Java stack, while less common in newer S/4HANA deployments, still appears in hybrid landscapes and introduces its own set of vulnerabilities, including deserialization flaws and unpatched Apache Tomcat components.

SAP Network Interfaces and RFC Protocol

RFC (Remote Function Call) is the backbone of SAP integration, but it is also one of the most frequently exploited protocols. A safe pentest must include RFC gateway ACL analysis, S_RFC authorization checks, and validation of trusted RFC configurations. Testing RFC connections requires extreme care because a malformed call can crash a gateway process. Always use SAP-certified testing tools or custom ABAP reports specifically written for read-only analysis.

SAP HANA Database Layer

With S/4HANA, the database is no longer a separate concern — it is part of the security perimeter. HANA provides its own audit trail, role-based access control, and SQL-based attack surface. Safe penetration testing on HANA must never run destructive SQL commands. Use read-only system views such as M_ and SYS catalog views, and restrict any test connections to a dedicated HANA tenant or sandbox instance. The HANA _SYS_REPO user and other system accounts should be protected from any password-guessing or brute-force attempts, as account lockout policies apply at the database level as well.

Pre-engagement Planning and Authorization

The single most important determinant of a safe SAP penetration test is the quality of pre-engagement planning. A pentest that starts without clear authorization boundaries, a defined test window, and a rollback plan is inherently unsafe, regardless of the tester's skill level.

Define Scope Boundaries with Precision

Scope definition for an SAP test must go beyond IP ranges and domain names. Document every SAP system ID (SID), instance number, RFC destination, and client number that is in scope. Explicitly list systems that are out of bounds, especially production clients where financial postings or material movements occur. For S/4HANA environments, also specify which HANA database tenants or schemas are part of the test perimeter. A safe test uses a dedicated test client (e.g., client 300 or 400) that is a copy of production data but isolated from live business processes.

Obtain Explicit SAP Custom Authorizations

Standard network penetration testing tools like Nessus or OpenVAS may have generic SAP plugins, but these are not sufficient for a deep test. The tester must have an SAP user ID with specific authorizations for the transactions and RFCs being tested. The best practice is to create a dedicated test user in the SAP environment with a custom role that grants read access to security tables (USR02, AGR_USERS, AGR_1251), audit log displays (SM19, SM20), and RFC function groups (RFC1, SRFC). This user should never have SAP_ALL or SAP_NEW authorizations. The authorization profile should be approved by the SAP Basis team and logged in the change management system.

Establish Rollback and Communication Protocols

Define a clear escalation path before the test starts. If an unexpected lock, dump, or performance degradation occurs, the tester must have an immediate contact on the Basis team who can kill the test session or restore user accounts from backup. Document the exact steps for rolling back any configuration changes, restoring locked accounts, and refreshing test data. For regulated environments, also include a notification procedure for the compliance officer or internal audit team in case of test-induced incidents.

Safe SAP Penetration Testing Methodology

The methodology for a safe SAP pentest follows a phased approach, starting with reconnaissance and moving progressively into deeper analysis, but always with safety gates at each phase.

Tools and Technologies for Safe SAP Testing

Choosing the right tooling is critical to maintaining safety during an SAP penetration test. Not all tools are equal in their handling of SAP protocols, and some popular general-purpose pentest tools can cause damage if used without SAP-specific customization.

Common SAP Vulnerabilities and Safe Testing Approaches

Each vulnerability class requires a specific testing approach to remain safe. Below are the most common categories found in SAP environments and the method for validating them without causing harm.

Missing Authorization Checks in RFC and Transactions

This is the most frequent finding in SAP security assessments. An RFC function module or ABAP report that lacks an AUTHORITY-CHECK statement can allow any user with basic access to execute privileged operations. To test this safely, use transaction SUIM to generate a list of all RFC-enabled function modules, then cross-reference them with a list of those missing authorization objects. Use the RS_ABAP_SOURCE_SCAN report to search for function modules that lack the AUTHORITY-CHECK keyword. This is entirely read-only. Never attempt to call the function module directly with test parameters in production unless you have validated that it performs no write operations.

Hardcoded Credentials in ABAP Code

Custom ABAP programs often contain hardcoded database passwords, RFC passwords, or SAP system logon credentials. To discover these, run a source code scan using transaction SE38 or SE24 with a search string for common patterns like PASSWORD, CONNECT, or RFC_DESTINATION. Use the CODE_SCANNER tool or the custom report RS_ABAP_SOURCE_SCAN with a filter for objects in the custom namespace (e.g., Z* or Y*). This is a completely safe, read-only operation. If you find credentials, do not use them to authenticate; instead, document them as evidence for remediation.

Insecure RFC Destinations and Trusted Systems

RFC destinations that use unencrypted connections, hardcoded passwords, or overly permissive trust relationships represent a critical risk. To test, use transaction SM59 to display all RFC destinations. Review the activation type, logon procedure, and target system. For trusted RFC relationships (where trust relationship = "Yes"), verify that the target system has appropriate authorization controls. Do not test trust relationships by sending RFC calls from one system to another unless you have explicit permission from both system owners and have validated that the call will not trigger any ABAP processing. Use CyberSilo SAP Guardian to continuously monitor RFC destination changes and trust relationship modifications in near-real time, reducing the need for manual RFC testing.

Integrating Pentest Findings into Continuous Monitoring

A penetration test is a point-in-time assessment. The real value comes from using the findings to improve ongoing security monitoring. After the test concludes, each finding should be mapped to a detection rule or monitoring mechanism that can alert on the same condition in the future.

From Pentest Finding to Detection Rule

For every vulnerability that is discovered and cannot be immediately remediated, create a monitoring rule that triggers when the vulnerable condition is exploited. For example, if the test found an RFC function module missing an authorization check, configure monitoring to log all calls to that function module, especially from users outside the expected authorization group. Use the SAP Security Audit Log (SM19/SM20) or integrate with a SIEM platform to correlate these events. CyberSilo SAP Guardian supports automated alerting on authorization misuse and can be configured to raise events when unsecured RFC modules are invoked, closing the gap between periodic tests and continuous coverage.

Using Threat Intelligence to Prioritize Remediation

Not all findings require immediate remediation. Use threat intelligence feeds to understand which vulnerabilities are actively being exploited against SAP systems. For example, if a known ABAP deserialization CVE is being used in ransomware attacks against S/4HANA systems, that finding becomes a priority regardless of its CVSS score. A ThreatSearch TIP can provide real-time context on which SAP CVEs are being weaponized, helping your team focus remediation resources on the highest-risk findings. This intelligence-driven approach ensures that pentest results are not simply filed away but actively used to reduce risk.

Common Mistakes That Compromise Safety

Even experienced testers can make mistakes that endanger SAP systems. Below are the most common safety failures observed in enterprise SAP engagements.

• Using SAP_ALL test accounts: Granting an external tester SAP_ALL is the fastest way to cause unintended damage. A test account should have only the authorizations explicitly needed for the test scope.
• Running password sprays against production user accounts: Account lockout policies in SAP can lock hundreds of users in minutes, triggering a full-blown incident. Always use a dedicated test user with a known password.
• Executing custom SQL on HANA without validation: SQL commands that appear read-only can still trigger HANA triggers or automated processes. Use only system views and approved read-only procedures.
• Overlooking SAP Router ACLs: Attempting to bypass a SAP Router ACL without authorization is not only unsafe but may violate network security policies or applicable computer misuse laws.
• Failing to notify Basis team before each test phase: The Basis team needs to be ready to monitor system performance and respond to any anomalies. A surprise test phase can lead to unnecessary panic and escalation.

Regulatory and Compliance Considerations

SAP penetration testing is not just a technical exercise — it is a compliance requirement under multiple frameworks. Understanding how the test maps to compliance controls ensures that the test itself is defensible during an audit.

SOX and SAP Penetration Testing

Under SOX Section 404, organizations must test the operating effectiveness of IT general controls (ITGCs), including access controls, change management, and logical security. An SAP penetration test directly validates whether access controls can be bypassed. The test plan and results should be documented as evidence of control testing. Any finding related to segregation of duties (SoD) or excessive authorizations must be logged as a control deficiency. Tests that cause system instability can themselves become SOX deficiencies, which is why safety is a compliance issue, not just a technical one. Integrate pentest findings with your SOX compliance automation workflows to track remediation and closure of identified gaps.

GDPR and Data Protection During Testing

If the SAP system being tested contains personal data of EU residents, GDPR applies even during a penetration test. The test must be covered under the organization's legitimate interest assessment (LIA) or have explicit data processing agreements (DPA) in place with the testing party. Test data from production systems — even if read-only — constitutes processing of personal data. Ensure that all findings exported from the system are anonymized or pseudonymized where they contain personal identifiers. The test scope should explicitly state which data fields are in scope and which are out of bounds under GDPR.

Post-Test Remediation and Follow-Up

The value of a penetration test is realized only when findings are remediated. A structured follow-up process ensures that the test investment translates into reduced risk.

Building a Risk-Based Remediation Roadmap

Not all SAP vulnerabilities can be fixed immediately. Some require SAP kernel patches that must be scheduled during maintenance windows. Others require code changes in custom ABAP that need testing through the transport chain. Prioritize remediation based on the likelihood of exploitation and the business impact. For example, an unpatched SAP NetWeaver AS Java deserialization vulnerability (CVE-2020-6287, RECON) should be patched before month-end closing, while a missing authorization check on a rarely used Z-report can be scheduled for the next development cycle. Document the remediation plan with target dates and owners, and track it in your GRC tool or ticketing system.

Scheduling the Re-Test

After remediation is complete, schedule a focused re-test that covers only the remediated findings. Do not re-run the entire pentest scope unless the contract specifies it. A targeted re-test reduces operational risk and provides faster validation. Use the same testing methodology and the same test user account to ensure consistency. The re-test report should clearly state which findings have been resolved, which remain open, and any new issues introduced by the remediation (e.g., a security patch that breaks a custom integration causing a new authorization gap).

The Future of SAP Security Testing

The SAP security landscape is evolving rapidly. With the adoption of SAP Business Technology Platform (BTP), the attack surface is expanding into cloud-native services, APIs, and microservices. Penetration testing for BTP requires a different skill set, including knowledge of OAuth flows, SAP Cloud Identity, and the integration between S/4HANA and BTP via the Cloud Connector. Safe testing in BTP environments must account for shared responsibility models, where SAP manages the infrastructure but the customer is responsible for identity management and application-level security.

Automation is also changing the game. Tools like CyberSilo SAP Guardian can now continuously validate security controls, reducing the frequency of full penetration tests while improving detection coverage. The top 10 SIEM tools for enterprise environments are beginning to natively ingest SAP audit logs, making it possible to correlate SAP events with network and endpoint telemetry for a more comprehensive view. As these capabilities mature, the role of the annual penetration test may shift from a primary security validation mechanism to one component of a continuous validation program.