How to Use SAP Pentest Playbook

Read before you continue

Before applying this Playbook, there are certain criteria that need to be considered:

• Always make sure to have the necessary permissions and access rights from the organization and from SAP (for cloud environments)!
• Keep in mind that the Playbook is designed for specific scenarios and may not be applicable to all situations.
• For SAP cloud environments it is necessary to request approval from SAP to conduct any penetration testing (see reference note below).
• In general, it is recommended to follow the approach of a whitebox (or greybox) penetration test.

Every technique in known_attack_vectors/ follows the same structure, so once you know the shape you can scan any page quickly:

Reconnaissance pages are lighter (Description → Options → References). Supporting _objects/_options pages are reference material the attack-vector pages link into.

The Playbook is organized so you can follow a normal engagement flow. A typical path through an SAP landscape:

1. Reconnaissance - identify reachable SAP components and fingerprint them (SID, instance number, stack type, version, exposed ports and services). Start in each platform’s reconnaissance/ section.
2. Initial access - unauthenticated or low-privilege footholds: default credentials, exposed services, missing ACLs, known unauthenticated CVEs.
3. Exploitation / privilege escalation - turn a foothold into command or data access on the target component.
4. Post-exploitation - harvest credential material (Secure Store, PSE keys, service keys), forge tickets, establish persistence.
5. Lateral movement - pivot across the trust domain: RFC/SSO trust between ABAP systems, on-prem ↔ BTP via Cloud Connector and destinations, DB access.
6. Impact & reporting - demonstrate business impact, then pair every finding with the mitigation and detection guidance the pages provide.

Which platform section you live in depends on the target: AS ABAP, AS Java, BTP, or one of the Other SAP Solutions. Cross-platform pivots (notably on-prem ↔ BTP) are documented where they occur.

Test safely

SAP production systems are business-critical. Before running anything active:

• Watch out for account lockouts. Credential testing trips login/fails_to_user_lock. Test credentials sequentially, stop on the first User is locked response for a given user, and agree lockout handling with the client in advance.
• Some checks are disruptive. Certain protocol, gateway, and deserialization tests can crash work processes or a whole instance. Prefer non-production first, and get explicit sign-off for anything that could affect availability.
• You will generate audit evidence - that’s expected in an authorized test. Coordinate with the client’s SOC so your activity isn’t mistaken for a real incident (or, if it’s a red-team exercise, so it deliberately isn’t).
• Mind the data. SAP systems hold sensitive business and personal data; handle anything you extract per the rules of engagement and applicable law.

Each SAP system has a three-character System Identifier (SID) - e.g. PRD, DEV. It is used, among other things, to generate OS-level usernames and to scope trust. In this documentation, <SID> is a placeholder for the SID of the target system.

A client is an isolated tenant inside a single ABAP system, identified by a three-digit number (e.g. 000, 001, 066, plus customer clients like 100). Users, roles, and most data are client-specific - the same username can exist independently in several clients. Standard clients (000/001/066) are frequent footholds.

A two-digit instance number (NN, e.g. 00) identifies an SAP instance on a host and drives its port numbers (see the port reference below).

On the operating system, an SAP system runs under:

• <sid>adm (Linux and Windows) - the SAP system administrator account; owns the Secure Store, PSE files, and profiles.
• SAPService<SID> (Windows only) - the service account the system runs under.

• Dispatcher - distributes SAP GUI (DIAG) requests to work processes.
• Gateway - handles RFC communication and can start/register external programs; a classic ACL target.
• Message Server - coordinates instances and load balancing; has its own ACL.
• ICM (Internet Communication Manager) - the HTTP(S) front door for Fiori/web/OData/SOAP.

Remote Function Call is SAP’s primary system-to-system protocol. Function Modules (FMs) exposed as remote-enabled are a major attack surface; trust between systems (Trusted RFC) enables lateral movement.

A PSE (Personal Security Environment) is SAP’s keystore file for certificates and private keys (SSO signing, SNC, TLS). PSE files live in the directory pointed to by the $SECUDIR environment variable, readable by <sid>adm.

SAP stores secrets (RFC/DB passwords, keys) in obfuscated stores - ABAP Secure Storage (RSECTAB), SSFS files, and AS Java SecStore. Default protection is often obfuscation, not encryption - a recurring post-exploitation theme.

Secure Network Communications wraps DIAG/RFC with authentication, integrity, and (only at the right quality-of-protection level) encryption.

• Subaccount - the BTP tenant/isolation boundary; each gets its own identity zone (XSUAA).
• XSUAA - the OAuth/JWT authorization service underpinning BTP apps.
• Destination - stored connectivity configuration (target + credentials) a BTP app uses to reach a backend.
• Cloud Connector (SCC) - the on-prem agent that bridges BTP to backend systems.
• Service key / binding - a standing credential document that lets a client or app authenticate to a BTP service.

Most SAP ports embed the instance number NN (e.g. instance 00 → 3200). Find a comprehensive list of common defaults below. For a detailed list, have a look at SAP Help Portal

Note

HANA Cloud exposes SQL over 443 on the public internet rather than the on-prem 3NN15 scheme.

Message-server internal vs external ports should be split (rdisp/msserv_internal); if they’re equal, that’s a finding. See the platform pages for how each service is tested and hardened.

• Customer Penetration Testing Request Process (SAP Note 3080379) - required approval for testing SAP-managed cloud environments.
• SAP Security Baseline Template (SAP Note 2253549) - SAP’s own baseline of secure-configuration parameters.
• TCP/IP Ports of All SAP Products