limkedin Skip to main content

An ancient SAP backdoor

By 22 November 2021January 7th, 2022No Comments

.. that could be a serious security risk in your SAP landscape!


SAP Administrators are creatures of habit and, as such, like to re-use passwords. I know that because I have been an SAP Administrator for longer than I care to remember. 

When easy and fast access would outweigh security, an SAP administrator would have the same SAP UID and password in every SAP system that he/she has access to, so the password never has to be looked up and login is quick. 

But because more and more SAP customers have an increased awareness about password weaknesses, they are starting to enforce password policies. 

Such a policy might contain requirements like:

  • the validity period of passwords in days. (login/password_expiration_time)
  • the number of passwords (chosen by the user, not the administrator) that the system stores and that the user is not permitted to use again. (login/password_history_size)
  • the number of days that a user must wait before changing the password again. (login/password_change_waittime)

SAP parameters like these are meant to prevent the re-use of passwords. But unfortunately, for example in SAP Managed Service Provider environments, the sharing of SAP super users like DDIC and the re-use of passwords is still common.

Give the existence of password policies, how is it still possible to circumvent these?

The backdoor

An answer is given by the ancient OSS Note 1942 – How does R3trans work?. With the transport tool R3trans it is possible to export and import table data. For example, an entry from table USR02 (User Master records). 

The user master record also contains the current password for a given SAP user, so when it is imported in an SAP system, the user master record contains the same password as it had when it was exported.

When SAP passwords expire, it is easy to re-establish them again because it just takes one R3trans import command.

Creation of a transport using TP containing the relevant R3TR TABU entries will not work here because master data table entries of class A (tables USR02) will not get exported.

But R3trans works.


The possible locations of the files used (import and export control files and *.dat files)  are : /usr/sap/<SID>,/sapmnt/<SID> or /usr/sap/trans and any of their subdirectories. 

A particularly good location for these is the /usr/sap/trans/tmp directory, because only an SAP Administrator would occasionally look there.

The other advantage for these *.dat files is that they are valid for most SAP systems. A user-master record exported from system A can be imported in system B and would reset the password also.

For the actual R3trans import an external command or report RSBDCOS0 could be used provided there are enough rights to execute.

New super users

It is also possible to create new super users by using a R3trans *.dat file that has both USR02 (usr master record) and UST04 table entries (roles of a user) contained in it.

A hacker could prepare these files on his/her’s on their own SAP system and provided he/she has OS access, gain quick access to the SAP application layer by creating a new SAP super user using R3trans.



To keep SAP systems safe, SAP Customers need a Vulnerability Management process. Protect4S offers an automated SAP Vulnerability Management Solution that can execute thousands of security checks in complex and large SAP environments, present the findings in a clear manner and offer mitigation and remediation advice based on SAP’s own Best Practices.

Protect4S offers a free trial so you can experience how much easier SAP Platform Security becomes with Protect4S and how easy it is to start up and work with it.

Give us a try!