An SAP Remote Function Call (RFC) destination becomes a hop that needs no second password in three ways, and the landscape map in the RedRays Security Platform is drawn from exactly those three plus their equivalents on HTTP and external destinations.
Each of the three is a supported, documented SAP configuration. None of them is a bug and none is exploited by breaking anything. That is precisely why they survive audits organised around patches and findings: there is nothing broken to report.
| Mechanism | What SAP is configured to do | Who can use it |
|---|---|---|
| Stored logon | The destination logs on to the far system as a named user whose password is saved with the destination | Anybody on the source system who can execute the destination becomes that user on the target |
| Trusted relationship | The target system accepts the source system's assertion of who the caller is, so no password is stored because none is required | Anybody on the source system whose identity the target will accept, subject to the target's own trust authorisation |
| Current-user propagation | The caller's own logon is forwarded to the target rather than a service account being used | Anybody on the source system who also exists on the target with rights there |
The same idea applies beyond classic ABAP connections. HTTP and HTTPS destinations to an ABAP system or to an external server, and logical destinations that carry credentials of their own, all qualify when they are configured to reach the far end without a person supplying anything. A destination to a cloud tenant with a saved technical user is the same class of finding as a destination into the next SAP system in the landscape.
Because it is a logon with none of the properties an interactive logon has. It does not expire when the person who created it leaves. It is not subject to the password policy the rest of the landscape follows. Its use produces no logon record that names a human. It is not covered by any user access review, because it belongs to a configuration entry rather than to a user account. And it is held on the system most likely to be the weaker of the two, because development and test systems have looser change control, more people with access, and less scrutiny than the production system they are configured to reach.
Because the trust is a property of the pair, granted once and then permanent. The target has agreed to accept the source's word about who is calling. That is safe exactly as long as the source system is trustworthy, and the model exists to ask what happens when it is not. A trusted relationship from a development system into production converts control of development into control of production, subject only to whatever authorisation the accepted identity holds on the target.
There is no single remediation, which is why the map is a starting point rather than a work queue.
Before any of these, find out what runs over the destination. Deleting a destination is a change to a running interface on a production system, and the cost of getting that wrong is described in why a vulnerability list has no direction.
The analysis reads configuration, so it can say a destination is configured to need no second password. It cannot say the stored account is still unlocked, cannot say the trust is still accepted by the target, and cannot say the destination has ever been called. It also does not evaluate the far-end account's authorisations, which is what decides how much the hop is worth. What one attack path says sets out that boundary in full.
It is usually the better option, and it still creates a path worth knowing about. It removes the standing service account, but it means an identity compromised on the source system arrives on the target as itself. Whether that matters depends on whether the same people exist with rights on both systems, which on most landscapes they do.
It protects the traffic and changes nothing about the hop. Transport encryption stops somebody reading the interface data on the wire. It does not stop somebody who controls the source system from executing the destination.
They are the two halves of the same exposure question. What is listening is covered by SAP default ports and instance numbers; what happens after a logon succeeds is this page.
SAP threat modelling and attack paths is the capability overview, and what threat modelling reads from SAP describes the read that finds these destinations.