Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP ABAP Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Transport System Abuse
Edit page

Transport System Abuse

Description

The Change and Transport System (CTS) moves over 1,000 different object types from development into production. One object type deserves special attention from an offensive perspective: R3TR/XPRA (“eXecution of PRogram After import”). A transport request containing this object type causes SAP to execute a named ABAP report immediately after the transport is imported into the target system - a legitimate mechanism for post-transport cleanup work, and an equally effective way to run attacker-chosen ABAP code the moment a poisoned transport lands.

Two properties make XPRA execution distinctive as an attack primitive:

  • Execution always targets client 000, and it always runs under the identity of the transport-import user - by default DDIC, which commonly still holds SAP_ALL.
  • STMS_TCRI (table TMSTCRI), the standard mechanism for blocking the transport of critical objects, cannot block it. STMS_TCRI blocks transport content (e.g. R3TR/TABU rows for a sensitive table); XPRA is not content, it is an instruction to execute a program - the export-time check has nothing to inspect.

The transport system also depends on a technical RFC user, TMSADM, configured on every RFC connection between systems in the transport domain, and on the transport directory (/usr/sap/trans - data, cofiles, bin, buffer) shared at the OS level across the whole landscape, extending the attack surface beyond the ABAP layer entirely.

Risk

An attacker who can get a transport request released and imported - via a compromised developer account, a compromised transport directory, or an inserted foreign transport that mimics a legitimate one - can execute arbitrary ABAP as DDIC (frequently SAP_ALL) in client 000 of every downstream system, without that transport ever being blockable by STMS_TCRI. Because DDIC typically carries full authorization, the resulting code execution is equivalent to full system compromise, and because it lands via the normal release/import pipeline, it can ride alongside a batch of legitimate changes with low operator suspicion. A default or weak TMSADM password additionally exposes the RFC connections that hold the whole transport domain together; OS-level write access to the shared transport directory allows payload poisoning or foreign-transport insertion independent of any ABAP-layer control at all.

Options

  • R3TR/XPRA payload - attach the object type “Program, Executed After Transport” (R3TR/XPRA) to a transport request (visible/creatable via SE10) referencing an attacker-controlled report; on import it executes with no parameter-passing (no variant support) as DDIC in client 000. This works whether the request also contains legitimate content or is XPRA-only.
  • Confirm the blocking gap - if STMS_TCRI/TMSTCRI with CHK_CRIOBJ_AT_EXPORT is configured to block a target object (e.g. table NRIV), verify the export-time error only fires for genuine content objects; an XPRA-only request exports and imports cleanly regardless.
  • Transport-directory-level attacks (OS access to /usr/sap/trans required) - payload poisoning: modify an in-flight request’s data/cofiles files to implant a backdoor or logic bomb before import. Foreign transport insertion: craft a complete transport (data + cofile) that mimics a legitimate one and drop it into the buffer/queue so it imports alongside a scheduled release. DoS: flood the transport directory to disrupt legitimate import processing.
  • TMSADM targeting - check for the known default password (SAP Note 1414256; see Default SAP users and passwords) via RSUSR003, which reports standard-user default-password status across all clients. A compromised TMSADM yields the RFC connections (TMSADM@<SID>.<domain>, read-only; TMSUP@<SID>.<domain>, change access) that hold the entire transport domain together.
  • DDIC as the standing target - because import execution defaults to DDIC, any technique that recovers or resets the DDIC password (weak/default credential, or via underlying database access to USR02) yields the same privilege the XPRA payload runs with, without needing a transport at all.
  • Tooling: SE10/SE01 (transport organizer, to inspect/craft requests if developer access is held), STMS/STMS_IMPORT/STMS_QUEUE (queue and route visibility), tp/R3trans (kernel-level transport tools, for direct transport-directory manipulation once OS access is held). Cross-link the existing transport playbook pages for the standard import/creation workflow this technique piggybacks on: import_transport, transport_creation.

Mitigation

  • Set CHK_CRIOBJ_AT_EXPORT = E in STMS_TCRI/TMSTCRI for genuinely critical content objects, but do not rely on it as a complete control - it does not, and cannot, block R3TR/XPRA.
  • Replace DDIC as the transport-import user: create a copy of DDIC with a distinct name in client 000 (SU01, copying SAP_ALL if genuinely required), log on as that user and run report RDDNEWPP to reschedule the internal transport-execution job under the new identity, then set the new user’s type to System and disable its password (preventing SAP GUI logon), and finally disable and lock DDIC itself. This does not close the underlying XPRA mechanism, but it removes the well-known, high-privilege identity the payload would otherwise inherit.
  • Change the TMSADM password per SAP Note 1568362 (report TMS_UPDATE_PWD_OF_TMSADM) and remove TMSADM from every client except 000; strip all authorizations beyond profile S_A.TMSADM.
  • Run RSUSR003 regularly to catch any standard user, including TMSADM/DDIC, still on a default or known password.
  • Restrict OS-level access and permissions on /usr/sap/trans (and its data/cofiles/bin/buffer subdirectories) to the minimal required Basis/transport-administrator population; treat it as an extension of the ABAP-layer trust boundary.
  • Enforce release approval workflow (S_TRANSPRT restricted to transport administrators for release activity; developers restricted to releasing only their own requests) and require review of transport contents - including object type - before import into production.

Detection and Monitoring

  • Transport logs and SE01/SE03 history for any request containing object type R3TR/XPRA prior to import into a production system - this object type should be rare and always attributable to a known, reviewed maintenance activity.
  • RSUSR003 output for TMSADM/DDIC default-password status across all clients.
  • OS-level audit (e.g. Linux auditd) on /usr/sap/trans, particularly data/cofiles; ausearch -k DIR_TRANS -f <transport-id> surfaces manipulation of a specific transport’s files.
  • Any successful logon as DDIC (or its designated replacement) outside a known, scheduled transport-import event.
  • Security Audit Log (SM20) for RFC logons using TMSADM/TMSUP from unexpected source systems.

References