There is a quiet moment in this line of work when a system that was sold as locked down starts to give way. We had one of those moments during an authorized engagement. It is a useful example of why the word restricted rarely means what people assume it means.
SAP sits at the center of operations for many large organizations. It can hold finance, supplier, customer and payroll processes. Because it has logins, roles and a controlled access portal, it is easy to assume those controls add up to safety.
The customer asked us to test that assumption from a deliberately difficult starting point: two ordinary test accounts, a locked remote portal and no tester machine permitted on the internal network. On paper, neither account should have amounted to much.
It amounted to a great deal.
Turning a login into control of the server
Working from a restricted standard account, we reached a point where the SAP server would run commands we supplied on the machine hosting the business application. We kept the proof deliberately plain: identify the executing account, identify the host and return a controlled system file.
The results demonstrated high-privilege command execution. From that position, the potential server-side impact included access to data, configuration and administrative capability. What matters is the route, because it is precisely the kind of route a broad automated scan is unlikely to establish.
A locked door with an open one beside it
The standard screens for running server commands were correctly closed to the test account. That is where a narrow assessment might record access denied and stop. We treated those screens as only the front entrance.
The machinery beneath them was still reachable by another route. The account was not limited to a fixed list of approved commands: it could define new ones and have the server execute them. The front was locked; the side was open.
Stepping out of SAP and into the network
The remote portal was intended to present one thing: the SAP login. In practice, it also exposed a file browser and a Windows desktop. Using the file browser, we opened a command window on the machine behind the portal and created a benign folder to confirm the access path.
In effect, the test account could move out of the SAP-only room and into the wider corporate environment, even though it was never intended to leave that room.
An everyday account that could read every customer
The authorized proof also demonstrated that a standard business user, with no intended elevated rights, could retrieve the organization’s customer receivables ledger. The accessible records included names, account numbers and balances at significant scale.
No technical control had to be forced. The account had simply been granted far more reach than its business role required.
Enforced here, forgotten there
One pattern kept repeating. A control was enabled in one area, making it look effective, while the same action remained open elsewhere. A control applied in only some places offers the appearance of protection rather than the fact of it.
That inconsistency is easy to miss because a quick look at one correctly restricted interface suggests the rest of the path must be equally constrained.
We were just as clear about what held
Many attempted paths were stopped, and we documented which controls held and why. The objective was not to inflate a report with theoretical concerns. Every reported finding was demonstrated and reproducible; where a control did its job, we said so.
What sets our work apart
SAP is not one application. It is a layered platform of clients, roles, function modules, background jobs and operating-system hooks. Material risk often lives in the way those layers join together.
Real attackers do not follow a single script. They collect small, unremarkable details and connect them until the route changes what they can reach. Portal-only access, low-trust accounts and a segmented network are not excuses to stop; they are realistic starting conditions.
Our reporting is designed to be relied on. Claims are reproduced and evidenced, ratings must be defensible, and findings are written so the people responsible for remediation can weigh the consequences for customers, revenue and operations.
Restricted is not the same as safe.
Serious breaches rarely begin with one glaring flaw. They begin with someone connecting the details everyone else dismissed. The engagement produced a clear sequence of controls to address before someone with worse intentions found the same route.
If your organization depends on SAP—or on any platform assumed to be locked down—that assumption deserves to be tested properly.