{"id":166670,"date":"2026-10-01T10:00:00","date_gmt":"2026-10-01T08:00:00","guid":{"rendered":"https:\/\/e3mag.com\/?p=166670"},"modified":"2026-09-28T10:45:19","modified_gmt":"2026-09-28T08:45:19","slug":"no-more-free-passes-into-the-operating-system-detecting-and-containing-attacks-on-sap-environments","status":"publish","type":"post","link":"https:\/\/e3mag.com\/en\/schluss-mit-dem-freifahrtschein-ins-betriebssystem-angriffe-auf-sap-umgebungen-erkennen-und-eindaemmen\/","title":{"rendered":"No More Free Passes into the Operating System: Detecting and Containing Attacks on SAP Environments"},"content":{"rendered":"

SAP applications do not exist in isolation; rather, they are closely integrated with the underlying operating system. Whether it involves writing log files, processing input data, executing background jobs, or performing health checks\u2014access to the operating system\u2019s resources is always required to call system functions or perform operations on the file system.<\/p>\n\n\n\n

All processes initiated by SAP at the operating system level are started there by a dedicated operating system user, who, on Linux systems, is named after the SAP System Identifier and is called, for example, \"adm.\" The operating system is unaware of the business processes at the SAP level or of the users, roles, transactions, and authorizations there. Conversely, SAP does not know which functions were executed in the operating system or what access occurred\u2014SAP applications simply submit a request and receive a result in return. Visibility between the two levels is thus relatively limited; the exchange is based on mutual trust.<\/p>\n\n\n\n

The SAP kernel acts as an intermediary between the ABAP code of SAP applications and the operating system, handling process creation, memory management, network communication, file system access, and the execution of operating system commands. It validates requests from the applications and uses SAP\u2019s operating system user to execute commands or perform file access operations. In most cases, the specific commands and access options are precisely defined. ABAP applications invoke them using standardized function modules\u2014the kernel resolves these, validates authorizations, organizes the parameters, and finally executes them.<\/p>\n\n\n\n

However, due to historical reasons, there is still the possibility that ABAP applications send specific operating system commands directly to the kernel using statements such as CALL \u2018SYSTEM\u2018 or CALL \u2018CFUNC\u2018. This is strongly discouraged, and in modern environments this option is increasingly restricted; however, it is still frequently found in legacy code. In addition, kernel components themselves can, of course, initiate command calls to, for example, control instances, perform system status checks, or monitor resources. However, this does not change the fundamental principle that the kernel executes the commands via the SAP operating system user.<\/p>\n\n\n\n

<\/div>\n\n\n\n

File Accesses with a High Risk Potential<\/h2>\n\n\n\n

If attackers succeed in exploiting vulnerabilities or misconfigurations at the SAP level or in misusing stolen credentials, they can interact with the operating system level through the operating system user. The specific consequences depend on the particular SAP landscape, the operating system configuration, and the surrounding infrastructure. However, access to the file system alone already provides them with ample scope for activity: Among other things, they can read configuration files, connection parameters, interface definitions, and certificates; modify scripts; or even replace them.<\/p>\n\n\n\n

This enables attackers to spy on the system, manipulate it, and secure permanent access\u2014even if passwords are changed or vulnerabilities are patched. To do this, it may be enough to modify or replace startup scripts, cron jobs, and other elements that run automatically at specific times or in response to specific events. Attackers also often set up backdoors, secure communication channels, and hacking tools for their future activities. To ensure these go unnoticed, they alter log files, delete forensic evidence, or disrupt monitoring.<\/p>\n\n\n\n

Regardless of this, the compromised SAP system can also serve as a springboard to other systems within the SAP environment, such as database and file servers, backup systems, or monitoring platforms.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Possible Attack Scenarios in Practice<\/h2>\n\n\n\n

Various attack scenarios, which experts from Fortinet, No Monkey, PwC, and Red Hat were able to demonstrate as part of a project called Ironroot, are based on the exploitation of various SAP transactions. AL11, for example, allows administrators to access predefined directories via the SAP interface. If new entries are added to the directory list, the files located there can be opened directly from within SAP\u2014without requiring shell access to the server. Depending on the SAP user\u2019s permissions on the host system, this provides access to sensitive information such as configurations, logs, credentials, and application data, which can help attackers plan and carry out further activities.<\/p>\n\n\n\n

In addition, ABAP\u2019s native file-handling functions and transaction SE38 can be used to edit and create files on the system. In a demonstration, a report was generated in this way that created a harmless file in the file system. In such a scenario, attackers could, for example, modify or create new configurations and scripts. If these are elements that the operating system launches on its own at specific times or under certain conditions, the attackers do not even need permissions to execute files or code to cause significant damage.<\/p>\n\n\n\n

However, attackers can certainly gain these privileges by deceptive means. One way is to exploit transaction SM69 to define custom commands that can then be called from the SAP interface using transaction SM49. SAP opens a shell that executes the command\u2014such as running a script\u2014at the operating system level. In the experts\u201e demonstration, this was merely a harmless \u201cHello from the OS\u201d message that was sent back directly to the SAP layer. In the event of an attack, however, it could involve dangerous binaries, scripts, or system tools.<\/p>\n\n\n\n

In addition to SM49 and SM69, SAP also includes functions that enable direct interaction with the operating system shell, including the ABAP report RSBDCOS0, which executes operating system commands and displays the resulting output within the SAP interface. In their demonstrations, the experts used the report and, initially, simple commands such as `whoami` to determine whether commands were being executed as an SAP operating system user. They then used Netcat to initiate a reverse shell and establish an outbound connection to an external system. Through such a connection, attackers could secure continuous access to the operating system, search for and create files, execute arbitrary commands, and establish a persistent presence. Essentially, they have the same capabilities as a locally logged-in user, which significantly changes the nature of the compromise compared to the previously described attack scenarios involving SAP transactions. The SAP application now serves only as an initial attack vector.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Multi-layered security becomes mandatory<\/h2>\n\n\n\n

To prevent attacks and system compromises, companies typically take a whole range of measures: they harden operating systems, install security solutions, patch vulnerabilities, segment networks, adopt secure practices in software development, and implement continuous monitoring. However, in complex and constantly evolving enterprise environments\u2014which are increasingly being targeted by attackers using AI\u2014such preventive measures are no longer sufficient. Vulnerabilities, misconfigurations, and other points of entry can be identified and exploited faster than ever with AI, which is why multi-layered security strategies are needed to reduce the attack surface and limit the scope of action for intruders.<\/p>\n\n\n\n

\"\"
Discretionary Access Control (DAC), SELinux, and fapolicyd complement one another and prevent compromised accounts or vulnerabilities at the SAP level from being exploited to carry out far-reaching actions at the operating system level. (Source: Red Hat)<\/em><\/figcaption><\/figure>\n\n\n\n

This approach, also known as \u201cdefense in depth,\u201d is based on the interlocking of multiple security mechanisms so that\u2014if one is bypassed\u2014others are in place to stop attackers or at least slow them down. This is particularly important in SAP environments due to the trust relationship between the SAP and operating system layers; if an attacker manages to execute operating system commands or perform operations on the file system via the SAP stack, the preventive protection mechanisms have already been bypassed. At that point, the attack is already underway and can no longer be prevented\u2014it can only be contained.<\/p>\n\n\n\n

As part of the Ironroot project, experts from Fortinet, No Monkey, PwC, and Red Hat have therefore developed measures to limit attackers\u2019 capabilities at the operating system level and make it more difficult for them to spy on and infiltrate other systems. The specific goals are:<\/p>\n\n\n\n