¶ What One SAP Attack Path Says
One connection on the landscape map produced by the RedRays Security Platform asserts a single thing: an RFC destination configured on the source SAP system would let somebody already on that system reach the target system without producing another password.
That is the whole claim, and the map is a picture of exactly that claim repeated. Everything else a reader may want to conclude from a line is either a separate question or is not knowable from this evidence, and both cases are listed below.
¶ What does one connection assert?
That a destination exists on the source system whose configuration removes the second authentication. The analysis reads every outbound destination the system has, tests each one against that definition, and keeps only the ones that pass. Destinations that demand an interactive logon are read, tested and discarded: they are not stored, not counted and not drawn. The map is therefore a shortlist rather than an inventory, and a system with two hundred destinations may contribute one line or none.
¶ What does a connection record?
| Part of the connection | What it is | What it is not |
|---|---|---|
| Source | The SAP system the destination is configured on, identified by the address the scan reached it at | Not the attacker's origin. It is the system that would already be lost |
| Target | The far end as SAP recorded it in the destination: an address, a hostname, or a router route string naming an intermediate | Not necessarily a system the platform has scanned separately |
| Direction | Source to target, always. The evidence is held on the source only | Not reversible. A path back is a different destination on a different system |
| Transport | The kind of destination, such as an ABAP RFC connection or an HTTP destination to an ABAP or external server | Not a statement about encryption in transit |
| Destination names | The names the entries carry in SM59, which are the handles used to repair or delete them | Not a description of what the destination is for |
| Risk band | A grading combining the environment boundary the path crosses with the security posture recorded for the source system | Not a measurement of the credential's validity |
Opening one arrow turns the picture back into the parts a line is made of, including the destination name a Basis administrator needs in order to repair or delete the entry.
¶ Why is the direction the important part?
Because it decides who owns the fix and what the fix breaks. A destination is configured, stored and executed on the source system, so the remediation is always work on the source: remove the entry, remove the stored credential, or replace it with an authentication that cannot be replayed by whoever holds the machine. The target system's administrator cannot see the destination at all and cannot remove it.
Direction is also what makes an environment boundary meaningful. Development reaching production and production reaching development are two different findings with different consequences, and a picture that drew them as one undirected line would lose the distinction that matters most.
¶ What does a connection not say?
- That the destination is used. The configuration records intent, not traffic. Nothing in it distinguishes a destination created for a migration years ago from one an interface runs hourly.
- That the credential still works. The analysis sees that a logon is configured to need no second password. It does not attempt the logon, so a destination whose stored user was locked last year looks the same as one that would work this second.
- What the account can do at the far end. No user, role or authorisation object is read. A stored credential for a heavily restricted account and one for a wide-open account draw the same line. Pair this with SAP segregation of duties analysis to learn what the far-end account is worth.
- That the far end is one machine you would recognise. The target is whatever string the destination recorded. One machine reached by hostname in one destination and by address in another can appear as two nodes, and a route through an intermediate appears as its own node.
- That this is the only path. The model covers RFC and HTTP destinations. Database accounts, operating system trust, shared file systems and reused administrator passwords are outside it by construction.
- That an empty result is a clean landscape. No line drawn between two systems means no qualifying destination was found in what was read. Read that against the list of systems actually read, which is the subject of what the landscape map does not claim.
¶ How should one connection be triaged?
Read it in this order, because the order is what turns a picture into work.
- The boundary. Does the path cross into production, or out of production downwards into a less controlled environment? That is usually the whole decision. See system types and environment boundaries.
- The mechanism. A saved password, a trusted relationship and a forwarded logon are removed in different ways and have different blast radii. See RFC trust and stored credentials.
- The account. What can the far-end user do once the jump lands. This is where the model hands off to authorisation analysis.
- The interface behind it. Before deleting anything, find out what runs over it. This is the step whose absence causes the outage described in why a vulnerability list has no direction.
¶ Frequently asked questions
¶ If two systems have five qualifying destinations between them, is that five lines?
The picture collapses connections to one line per pair of systems, and the per-connection view names each destination on that pair. Counts elsewhere in the console may count destinations rather than pairs, so read a number next to the words that describe it.
¶ Does the platform try the stored credential to prove the path works?
No. Nothing in this analysis attempts a logon over a destination it has found. Proving a path by using it is a penetration testing activity and belongs under a separate authorisation from the one a scan runs under.
¶ Is a trusted RFC relationship a finding even with no password stored?
Yes, and it is the same finding for the same reason. The point of the model is a hop that needs no second credential. A trusted relationship stores no password because it does not need one.
¶ Where does this sit in the capability?
SAP threat modelling and attack paths is the overview, and reading the SAP landscape map covers the picture the connections are drawn in.
¶ What removes a path from the map?
Removing the qualifying configuration on the source system and reading that system again. The map reflects the most recent successful read, so a path stays drawn until a later read of that source system no longer finds it.