How to check RFC usage in your ABAP system?

Security teams might request to you as basis administrator: which RFC calls are being made to and from your ABAP system? And you need to know which users and applications are calling on RFC.

Questions that will be answered in this blog are:

  • Which users and systems are calling my ABAP system using RFC?
  • Which programs and processes are using RFC?
  • How much data is transferred using RFC?

If you need to check HTTP usage in your ABAP system: read this blog.

RFC statistics in ST03

Go to transaction ST03N or ST03, and open the total for this month. Then open the analysis view for RFC statistics. First check the WEB Client Statistics:

This already gives a lot of information: function modules and amount of data. On the tabs for Transaction, User and Remote destinations, Remote servers and Local servers you can get even more details you need for RFC transaction source.

On all 6 tabs on all 4 reports you can double click to get more details:

Tab PageMeaning
Function ModuleTransactionUserWhat workload is caused by the function modules, transactions, or users (depending on the selected RFC profile, as the RFC client or the RFC server)?
Remote DestinationRemote ServerLocal ServerWhere is the RFC workload created?

Reference OSS notes

OSS notes:

Setting up trusted RFC connection

This blog will explain how to set up trusted RFC connection.

Questions that will be answered are:

  • How to setup a trusted RFC connection?
  • How to edit generated RFC in SM59 using the TOGL function?


Setting up trusted RFC

Start in transaction SM59 to create an RFC to the destination system:

Trusted RFC with user name

Fill out your own user ID first. Make sure your user ID is existing in the destination system and is having sufficient S_RFCACL rights in the destination system. See OSS note 128447 – Trusted/trusting systems for the details.

Test the connection including the remote logon.

If that is ok, start transaction SMT1 and start the roadmap for setting up the trusted connection:

SMT1 enter destination

Enter the destination and finish the roadmap:

SMT1 complete roadmap

Complete the roadmap. 

Now return to SM59 for the destination and remove the user ID, tick the box “Current User” and switch the Trust Relationship to Yes:

Trusted RFC with trust setting

Now test again. All should work.

Background SAP wiki can be found in this link.

Background notes:

Testing trusted RFC

A trusted RFC can be tested via the Remote Logon button:

If you now can jump from the current system to the connected system without password prompt: then all is fine.

If it is not working: check in the target system in ST22 for a remote logon failure dump. Must likely your user does not have sufficient rights in the target system.

RFC security settings

For checking RFC security settings, read this dedicated blog.

RFC Access Control List

In the newer S4HANA versions, you can switch from an authorization check towards a full Access Control List setup. Use transaction SMTACL and select the trust connection:

Switch here to Access Control List Check.

RFC hacking

Be aware that RFC’s and especially trusted RFC’s can be misused for hacking. Read this dedicated blog on how, and how to protect.

Checking which systems you trust

With transaction SMT2 you can check which systems have a trusted system setup towards the system you are currently logged in to.

Editing trusted connections

Trusted connections are generated. In case of emergency you might need to edit this, in the command bar enter keyword TOGL to go to SM59 edit mode:

See note 3212943 – How to edit the settings of unchangeable RFC destinations.

Trusted systems and installation number changes

If you have trusted systems and want to change an installation number of one of the systems, carefully read this OSS note: 2849941 – SMT1/SMT2 configuration after SID or installation number change.

Issues with trust certificates

In exceptional cases you might face issues with cache refresh of replaced certificates. See OSS note 2947038 – Error SOAP:1033 CheckPSE occurs in STRUST/STRUSTSSO2. Solution is to run program SRT_CFG_CLEAR_DESIGNTIME_CACHE.

Trusted RFC security note 3157268

Unfortunately SAP released security note 3157268 – How-To-Guide: Migration of Trusted/Trusting Relationships. Along with the FAQ note 3281854 – FAQ for Security Note 3089413. If you did not migrate your existing trusted RFC’s to the new setup, do it fast within reasonable time (which includes proper testing).

After migration is done, or when you have a new setup, make sure you have set parameter rfc/allowoldticket4tt to the value no.

Checking RFC security settings

RFC security is a cumbersome job. There are programs to help speed up the security checks for RFC connections.

Questions that will be answered in this blog:

  • How to quickly check all the RFC’s in my system?
  • How to quickly check the trusted RFC’s in my system?

Hacking using RFC connections

RFC callback hacking: read this blog.

RFC jump hacking: read this blog.

Check RFC connections

Program RSRFCCHK (which also has the same transaction code RSRFCCHK) can quickly scan all your RFC’s. In the selection screen, please make sure to select the 2 extra boxes for “Also check RFC destinations without explicit password” and the “Select destinations without target system too”:

The connection test is optional. But if the RFC is not working, then you might consider it old and no longer needed. In this case you can perform the clean up by deleting the RFC.

The output of the report RSRFCCHK, you can use to look for:

  • RFC’s with personal user ID
  • Cross system layer RFC’s (from production to development, or from development to production)
  • Trusted connections where you don’t expect them
  • Old destinations no longer in use
As a best practice at least yearly check on every system the RFC's that are setup there. Read this blog on how easy it is to use wrongly configured RFC's to hack a system.

OSS notes: 3283474 – Adjustment of authorization for program RSRFCCHK.

Check trusted connections

To check trusted connections run program RS_SECURITY_TRUST_RELATIONS. Output example:

The red lights should be investigated and fixed.

More on setting up trusted RFC’s is written in this blog.

SAP standard on RFC security

OSS note 2008727 – Securing Remote Function Calls (RFC) contains a very extensive PDF explaining all ins and outs on RFC security.

qRFC tips & tricks

This blog will give tips and trick on the basis part of qRFC (queued RFC).

Questions that will be answered are:

  • How to assign a specific server group to qRFC?
  • How to correct host ID in SMQS?
  • What to do with the scheduler error RES_LACK?
  • What to do when inbound entries in SMQ2 stay in status RETRY?
  • How to check performance of qRFC?
  • How to check consistency of qRFC?
  • How can I activate the application log to detect manual actions performed on qRFC?
  • How to monitor qRFC?
  • In which table is qRFC header data stored?

Assigning specific server group for qRFC

In RZ12 you have defined a specific server group. In SMQR or SMQS you can assign that server group with menu option Edit / Change AS group:

Check also note: 3159931 – SM58 tRFC failed with “Error when opening an RFC connection (CPIC-CALL:”.

How to correct host ID in SMQS?

After a system copy the host ID in SMQS might be still pointing to the old system. To solve this, goto SM51 and select menu option Goto / Host Name Buffer / Reset / Entire System. Then go back to SMQS and re-activate the scheduler via menu option Edit / Activate Scheduler. See also OSS note 2377064 – How to correct the host ID in SMQS.

Empty host ID in SMQS

Initially the host ID in SMQS is empty. After the first message is sent, the host ID will be filled. See OSS note 2915187 – SMQS Host ID is blank or empty.

Outbound scheduler in status RES_LACK

If the outbound scheduler SQMS has the status RES_LACK, then the amount of DIA versus BTC processes is not balanced. Follow the instructions from OSS note 1970757 – Outbound qRFC scheduler with status RES_LACK to balance the processes.

Deletion of queued messages

Deletion of queued messages is possible, but should be done with care. After deletion, support can be lost on certain functions. See for example OSS note 2375304 – Deleted queues from SMQ2. You can apply OSS note 2837536 – Customer Connection – Improvement Request 217719 – Authorization check for message deletion in Smq2 / Smq3 to restrict the access to message deletion via special authorization object.

Inbound queues SMQ2 stay in status RETRY

When inbound entries in SMQ2 queue remain in status RETRY, this is normally caused by lack of authorization for launching batch job. This can happen to background user and user reprocessing the jobs. Check the authorization trace to see what needs to be fixed. More background in OSS note 1862256 – Inbound queues (SMQ2) stay in status RETRY.

Queue in the inbound queue scheduler SMQ2 with “Name or password is incorrect (repeat logon)”

When you get this issue a password change of the RFC might be required. Read more in OSS note 2474161 – Queue in the inbound queue scheduler SMQ2 with “Name or password is incorrect (repeat logon)”.

Queue resets via batch jobs

Report RSQOWKEX can be used to reset the outbound queue. RSQIWKEX can be used to reset the inbound queue. The goal is to reprocess messages in error state like SYSFAIL, CPIERR. More details are in OSS note 2552322 – RSQOWKEX and RSQIWKEX. Note 2195856 – Double message execution explains to be careful with using these programs with status RETRY.

These programs can be scheduled in batch mode to automate reprocessing.

Consistency checks of qRFC

Consistency checks of qRFC:

  • You can identify and delete inconsistencies in the outbound queue using report RSTRFCEG.
  • You can identify and delete inconsistencies in the inbound queue using report RSTRFCEH.

Background is described in OSS note 779664 – Consistency check of qRFC queues with deletion.

Deletion of unprocessed LUW’s in qRFC

Deletion of unprocessed LUW’s in qRFC: background is described in OSS note 760113 – Delete unprocessed LUWs in the qRFC.

Application log for qRFC manual processing

In SMQ1 and SMQ2 manual actions can be done, which are normally not logged. Apply OSS note 3031450 – Application log for inbound qRFC monitor such as SMQ2 to get the actions logged in the application log.

Alerting of failed qRFC in EWM systems

qRFC is very important in EWM systems. In EWM systems there is a built in program for alerting on qRFC failures: /SCWM/R_QRFC_QUEUE_ALERT. More on this feature you can read in OSS note 2226372 – EWM – Alerting for Failed Queues.

Issues with destination NONE

When using qRFC with SQMS for destination NONE, you can have unwanted interference with tRFC. See OSS note 1813159 – Hanging LUW┬┤s in SM58 with the function module IDOCS_OUTPUT_TO_R3. Set the registration of NONE with flag ‘w/o tRFC’ on. And make sure the max connections is not set to 1, but much higher.

Issues with performance of qRFC

OSS note 2183108 – t/qRFC processing: general performance verifications contains program Z_RFC_QUEUE_PERF. This program can be run to check for potential performance issues. Output example:

Deleting saved queues in SMQ3

To delete saved queues in SMQ3, follow the instructions in OSS note 2558561 – Delete saved queues in SMQ3.

Monitoring of qRFC

SAP Focused Run can be used to monitor qRFC’s. Read more in this blog.

Storage of qRFC header data

Header data of qRFC is stored in tables TRFCQIN and TRFCQOUT.

Reference OSS notes

Reference OSS notes:

Bug fix OSS notes

Bug fix OSS notes:

RFC callback hacking

This blog explains about RFC callback hacking.

When you start transaction SM59 for setting up RFC connections, you might see the red icon telling you RFC callback check not secure.

RFC callback not secure

This blog will explain you following:

  • How can a hacker exploit this RFC callback weakness?
  • How to make the RFC callback secure?
  • What is the difference between RFC callback simulation and intervention?
  • What to do in case of a valid use of RFC callback?

RFC callback hacking in action

What the RFC callback does is basically firing back function modules to the sender. These modules are then executed on the originating system with the privileges of the original caller.

If an attacker has gained access to one system and modifies code that is called from another system it can fire commands to the other system with the privileges of the caller.

In the example below the attacker has altered the standard RFC_PING function module (code snippet is below). He then convinces a high privilege admin of the target system to remotely call and ping the compromised system for example by asking the admin to do a connection test in SM59 (which calls the RFC_PING module). The callback code is fired against the target system and is run with the user ID of the admin (not of the attacker) of the target system.

RFC callback hack explanation

Code snippet of modified RFC_PING:

  • Call module to create user on destination ‘BACK’ and set the password.
  • Assign the privilege SAP_ALL (highest available privilege)
   ZLV_BAPIPWD = 'Welcome_in1!'.
       USERNAME                      = ZLV_BAPIBNAME
       LOGONDATA                     = ZLS_BAPILOGOND
       PASSWORD                      = ZLV_BAPIPWD
       ADDRESS                       = ZLS_BAPIADDR3.
     RETURN         = ZLT_BAPIRET2.

If the admin executes the ping towards the compromised system he will see this screen:

RFC ping

The only suspicious part the admin might see is the slightly longer logon time (in which the callback is executed).

End result on target system: ATTACKER user created by ADMIN user.

Attacker user created

With the privileges:

Attacker admin privileges assigned

This is one example. There are many different creative ways in which a callback RFC can be misused.

Detection of the RFC callbacks

RFC callback actions are registered in the SAP audit log if they are configured. The default classification is warning for RFC callback.

Audit log trace for the above action looks as follows:

Audit log for user ADMIN

How to make the RFC callback secure?

The SAP system parameter rfc/callback_security_method (set it in RZ11) is determining the RFC callback behavior.

rfc/callback_security_method set to 1 means basically “do nothing”. This is the insecure default setting and it will result into the red traffic light on SM59 RFC connection setup screen.

rfc/callback_security_method set to 2 means “simulation active”. With this setting entries are written to the audit log (for setup of the audit log see this blog).  This setting is still insecure!

It can be used on a productive system to see which callbacks are coming in and do analysis before switching to 3 (fully secure, but immediate interception).

Make sure in the audit log, that the simulation is captured:

Simulate for a while, and the generate the white list (or positive list):

rfc/callback_security_method set to 3 means that the system will do interfception of RFC callback methods. This is the secure setting. The SM59 RFC connection traffic light will now show green:

RFC callback secure

Callback positive lists

In some cases an RFC callback is used with a good intention and reason. These exceptions can be put into the callback positive list. Per RFC on the Logon & security tab you can activate the combination of called and called back function modules.

If you have enabled the audit log, you can use it to generate RFC callback positive lists. In SM59 select the option: RFC / Generate RFC Callback Positive List.

Check to apply OSS note 2863851 – RFC Callback Positive Lists not created.

If you have spaces in the RFC, or by accident add a space as well, it can also give issues. Apply OSS note 2941068 – sm59/Callback whitelist input validation missing to fix this issue.

A callback can be seen as ST22 dump CALL_FUNCTION_BACK_REJECTED: see OSS note 2981184 – What to do in case of CALL_FUNCTION_BACK_REJECTED short dump.

Bug fix notes

Bug fix notes:

Known positive callback: SAP CUA

SAP CUA (central user administration) uses a callback to fetch profiles. In your CUA system per RFC to remote child CUA system you have to set the following positive callback:

CUA postive callback settings


Known positive callback: SAP screen painter RFC EU_SCRP_WN32

In the screen painter RFC EU_SCRP_WN32 add the following list of modules (see OSS note 2251931 – Runtime error CALLBACK_REJECTED_BY_WHITELIST in graphical Screen Painter):












The screen painter is hardly used nowadays at all. Normally developer use this tool only on development system.

Known positive callback: remote ATC scenario

See OSS note 3084103 – Analyze reference check variants for RFC callbacks.

Known random callback issue: transport related callback calls

Some cases around transports are know. For example with system copies and refreshes. An RFC callback dump on module TRINT_PROGRESS_INDICATOR might occur on RFC destination BACK. In the dump you will find the real RFC (type TCP/IP) destination with variable LV_TP_DESTINATION. Regeneration is needed. Follow the instructions of OSS note 3356141 – CALLBACK_REJECTED_BY_WHITELIST when showing transport orders buffer.

SAP system hacking using RFC jump

This blog will explain the SAP system hacking using RFC jump method. It will show the simplicity of the hack, and tell you what to do in preventing this method to be used on your SAP system.

Question that will be answered:

  • How does the RFC jump SAP system hack work?
  • How do I check all my RFC’s for this weakness?
  • What can I do to prevent this hack from happening on my system?

RFC jump hack background

SAP uses RFC connections between SAP systems to send and received business data. For example the BI system will pull data from the ECC system via an RFC connection. The SAP solution manager system is fed from the ECC system via an RFC connection. Or a SAP netweaver gateway system serving SAP FIORI tiles.

In the RFC setup the system admin will have to set the connection details and its logon method. The logon methods can be:

  • Current user via logon screen
  • Current user via trust logon screen
  • Fixed user ID: dialog user ID or background user ID

The first method with logon screen will prompt for user ID and password and is not useful for hacking.

The trusted connection will check the rights in the other SAP system using your own user ID and privileges.

The RFC’s with fixed user ID’s will use the user ID and privileges of the user ID in the RFC connection and also using password entered by the admin. So you don’t even need to know the password…..

3 methods of misusing the RCF jump

3 methods of misusing the RFC jump will be explained. All of the scenario’s start from a already compromised system.

RFC jump explained

You have gained access to an SAP system, which in first instance is less important. For example by using standard SAP passwords (see blog on this topic).

1. Using the weakness to jump from one system to another: named dialog users in RFC

Now you start to scan the RFC’s of this server in SM59.

RFC with admin password

You notice that there is an RFC to another system which has the user ID and password of the system admin. You now simply click the remote logon button and you jump to the other system.

Remote logon button

You are logged on now into this system with the user ID and privileges of this other user ID. From this system you can even jump further.

This way you could go from a development to productive server. Or from a BI to an ECC server. Or from Solution manager to ECC productive server.

2. Using the weakness to jump from one system to another: named background users in RFC

The jump will not work if the user ID in the RFC is a background user ID. One example here is the ALEREMOTE user in ECC, which is used by the BI system to extract data from ECC. Since this user has to pull a lot of data and is needing a lot of privileges this user ID is sometimes given SAP_ALL privileges.

If this is the case the hacker can still misuse this RFC. In the hacked system he goes to transaction SE37 and creates a test function module sequence consisting of 2 calls: BAPI_USER_CHANGE and BAPI_TRANSACTION_COMMIT.

function modules

The first call will have the input to change user ID ALEREMOTE user type from B (background) to type A (dialog). The commit is needed to actually confirm and push the change to the database. Once the sequence is setup the hacker will use the test function to fire the sequence. In the testing the hacker will put in the RFC with the ALEREMOTE user. Now this sequence will be fired with the privileges of the ALEREMOTE user (it has SAP_ALL). So it will then itself change its own user type remotely…. After this is done the dialog jump will work from the remote system and the hacker comes into the system with user ALEREMOTE and the attached SAP_ALL rights.

3. Using the weakness to jump from one system to another: trusted RFC’s

If you have taken over one system and you see a trusted RFC towards another system this can be misused for hacking.

Trusted connection

But you need extra information. If you know the user ID of the admin in the system target, set up the user ID in the system already taken over, or if already there reset password. Then logon in the taken over system with the admin user ID. Goto SM59 to the trusted connection. Click remote logon and you jump to the other system without having to logon, but with the user ID and privileges of the admin.

For setup of trusted RFC’s read this blog.

How to detect the jumps which are misused?

The complexity in detection is not to detect the jumps itself, because there is also good use of the jumps (via the trusted RFC’s), but to detect the misused jumps. This is hardly possible.

Detection can be done for the user changes executed by background users. Detection could be done with tracking the terminal ID suddenly switching user ID.

The SAP audit log can help you find traces to what has happened as detective after the fact method. But it will not help you detect or prevent misuse.

How to scan your RFC’s for potential misuse?

SAP provides a program to check RFC’s for weak settings: RSRFCCHK.

Running this program will leave system log messages: 2724967 - Program CL_SAIS_ Reports Security Breach notification when running program RSRFCCHK

If you start the program select all the destinations and optionally the connection test to see if the connections work at all.

RSRFCCHK program

The result will give you a list of potentially dangerous RFC connections and the user ID’s used.

RSRFCCHK program result including connection test

This you can use as a work list for checking.

Read more on RFC security checking in this blog.

Apply note 3283474 – Adjustment of authorization for program RSRFCCHK to upgrade security of program RSRFCCHK itself.

Protection measures

Protection is possible by a series of actions (a single action will not be sufficient):

  • Access restriction. Restriction of access to SU01 user management and SM59 RFC setup. Not only on main systems, but also on connected trusted systems.
  • Remove SAP_ALL and user rights from background and RFC users.
  • At least yearly scan systems for wrongly setup RFC’s and delete them.
  • Instruct basis team never to put in their own account into an RFC connection.

The most though misunderstanding is with some security and control teams themselves. They heavily underestimate the danger of the trusted connections. They come with statements like “we focus on production only”, or “that system is not part of our compliance XYZ framework check”.

Basic golden principle:
The trusted system must have same protection level and control measures as the system it is connected to.

More RFC hacking: RFC callback hack

Next to the RFC attack methods above there is also the RFC callback hack, which uses the back direction to execute malicious actions. Read more in this blog.