SAP systems process 77% of global business transactions and hold an organisation’s most sensitive financial, HR and operational data. In 2024 and 2025, active exploitation of SAP vulnerabilities rose by 210%, and exploit prices on the black market now reach USD 250,000. Industry reports document a 400% increase in ransomware incidents affecting SAP systems since 2021. These figures make clear that regular penetration testing of ERP systems is no longer optional - it has become a fundamental security requirement.
In Poland, this topic is taking on particular significance in light of the NIS2 regulations, the DORA directive in force since January 2025, and the amendment to the National Cybersecurity System Act. For public sector institutions, which for various reasons must maintain on-premise environments, the challenges are even more complex.
What exactly is SAP penetration testing, and how does it differ from standard security testing?
SAP penetration testing consists of controlled, authorised attempts to breach an ERP environment, carried out by qualified specialists. Their aim is to identify vulnerabilities before real attackers do. It sounds simple, but the detail matters.
Standard IT infrastructure penetration testing focuses on operating systems, databases and web applications. SAP penetration testing requires an entirely different skill set. A pentester must understand ABAP architecture, SAP authorisation mechanisms, RFC communication protocols, the specifics of the Fiori interface, and dozens of other elements unique to the SAP ecosystem.
SAP systems differ fundamentally from typical business applications. They have their own communication protocols, their own authentication mechanisms, and their own authorisation logic based on authorisation objects and profiles. A standard web vulnerability scanner has no idea what transaction SE16 is, does not understand the significance of the S_DEVELOP object, and cannot assess the risk associated with an RFC destination of type H. It is like trying to diagnose a car with tools designed for a bicycle - theoretically both are vehicles, but the similarities end there.
“Many clients come to us after a standard security audit carried out by a firm specialising in network infrastructure,” says Jaroslaw Kamil Zdanowski, Partner at SNOK for Cybersecurity and SAP BASIS. “The auditors checked the firewalls, scanned the ports, tested the web applications. Everything looked fine. Meanwhile the SAP system remained practically untouched - nobody checked the RFC configuration, the authorisations of critical transactions, or the security of custom code. It’s like securing every window in the house while leaving the front door wide open.”
RFC hopping - a classic, yet still devastatingly effective attack vector
The RFC (Remote Function Call) interface is the standard communication mechanism between SAP systems and between SAP and external applications. Every organisation using SAP has dozens, hundreds, sometimes thousands of RFC connections. They link production systems to test systems, SAP to data warehouses, HR modules to external systems. At the same time, RFC is one of the most frequently exploited attack vectors. The RFC hopping technique involves using poorly configured RFC connections to move between systems.
How does this work in practice? An attacker first compromises a lower-security system - typically a development or test environment, where controls are looser. They then identify RFC destinations with stored credentials. They use these credentials to connect to further systems. Step by step, they escalate privileges until they reach the production system.
The problem is that many organisations treat non-production environments as less important from a security standpoint. Passwords are simpler, updates less frequent, monitoring symbolic. Yet these systems often have RFC connections configured to production - for integration testing, data migration or reporting purposes. A developer once needed to copy data from production for a test. An administrator configured an RFC connection with a stored password to simplify the process. Years pass, nobody remembers, and the connection still exists.
During a professional SAP penetration test, specialists scan all active systems, identify RFC destinations that bypass manual logon, check whether inherited authorisations on target systems are excessively broad, and detect connections using outdated or invalid credentials. It is also important to check Trusted RFC destinations, which allow passwordless logon based on trust between systems.
Key authorisation objects requiring verification include S_RFC, which controls access to RFC function groups, S_RFCACL, responsible for authorising trusted RFC connections, and S_ICF, which restricts access to RFC destinations by authorisation group. A typical configuration error is the use of wildcard authorisations, granting access to all function modules instead of only those required. A pentester also checks whether communication users have the minimum necessary set of permissions and whether passwords are sufficiently complex and regularly changed.
10KBlaze, ICMAD and the latest zero-days - threats that never sleep
The history of SAP security includes several watershed moments that changed how organisations perceive ERP risk. The 10KBlaze vulnerability, presented at the OPCDE conference in 2019, remains a current threat for organisations that have not implemented adequate safeguards. It exploits a misconfiguration of the SAP Gateway and Message Server - a default ACL file setting allowing connections from any host enables unauthorised remote code execution. An attacker can register as an SAP application server and execute operating system commands with administrator privileges.
What makes 10KBlaze so dangerous? Many SAP installations have a vulnerable default configuration. Many organisations never changed their ACL file settings because they were unaware of the risk. The attack requires no authentication - network access to the relevant ports is sufficient. In environments where SAP is accessible from the internet or from an internal network with broad access, the risk is significant.
In February 2022, the US CISA agency issued an alert regarding ICMAD (Internet Communication Manager Advanced Desync) - a set of critical vulnerabilities in SAP NetWeaver. The most severe received the maximum CVSS score of 10.0 and allows full, unauthenticated system takeover via a single HTTP request. This was the first SAP-related vulnerability to be added to CISA’s list of most frequently exploited vulnerabilities. The issue affects the ICM component responsible for handling HTTP communication - meaning every SAP system with a web interface, including Fiori, Web GUI, and portals.
The most recent threat is a zero-day vulnerability in SAP NetWeaver Visual Composer discovered in March 2025, also with a CVSS score of 10.0. Ransomware groups are actively exploiting this flaw. Attackers needed only 24 hours from disclosure to begin scanning for vulnerable systems, and functional exploits appeared within 72 hours. This illustrates how quickly criminals respond to new attack opportunities.
In September 2025, another critical vulnerability was discovered in S/4HANA with a CVSS score of 9.9, affecting both Private Cloud and on-premise installations. It allows a low-privilege user to inject arbitrary ABAP code, bypassing authorisation checks - leading to full system compromise. Particularly concerning is that the attack can be carried out by any user with basic access to the system.
“These vulnerabilities illustrate a fundamental truth about SAP security,” comments Michal Korzen, CTO of SNOK and Enterprise & AI Architect. “ERP systems evolve - new components, interfaces and integrations are introduced. Every change is a potential new attack surface. That’s why penetration testing cannot be a one-off event - it must be part of a continuous security management process. An organisation that ran pentests two years ago and has done nothing since has a false sense of security.”
Tools for SAP penetration testing - the ethical hacker’s arsenal
Professional SAP penetration testing requires specialist tools that go beyond the standard pentester’s toolkit. Both commercial and open-source tools are available on the market. The choice depends on the testing objectives, budget and available expertise.
Among commercial platforms, SecurityBridge offers a native SAP platform with real-time threat detection, vulnerability management, ABAP code scanning and SIEM integration. The solution runs directly within the SAP environment, providing deep visibility and minimal delay in threat detection. Onapsis Platform focuses on vulnerability assessment and compliance monitoring, and also offers threat intelligence features specific to the SAP ecosystem. RedRays specialises in SAP penetration testing services and ABAP code security scanning, helping to detect vulnerabilities in organisations’ custom programs.
For organisations seeking open-source alternatives, pysap is a Python library supporting SAP protocols - NI, Diag, Enqueue, Router, MS, RFC and HDB. It allows for building custom scripts and tools for testing. Metasploit includes SAP modules that enable, among other things, service discovery, logon brute-forcing, and operating system command execution. It is worth following the auxiliary/scanner/sap repository in Metasploit, which is regularly updated with new attack techniques. Nmap with a customised services file allows detection of SAP-specific services and version identification - system version often determines which vulnerabilities are relevant. The Sapyto framework offers plugins for the discovery and audit phase, though it requires somewhat more configuration than other tools.
Key SAP ports requiring attention during testing include: 32XX for SAP GUI and the Dispatcher, 33XX for the SAP Gateway, 36XX for the external Message Server, 39XX for the internal Message Server requiring strict control, 3299 for the SAP Router, 50XX for ICM HTTP, 81XX for the Web Dispatcher, and 1128 for the SAP Host Agent. Each of these ports can serve as an attack vector if incorrectly configured or exposed to the network.
“Tools are only half of the equation,” Jarosław Zdanowski stresses. “What matters is the expert knowledge needed to interpret results and plan attack paths. An automated scanner can detect open ports and default passwords. An experienced SAP pentester can chain together apparently harmless vulnerabilities into a full system compromise. They see the context, understand business processes, and know where to look for the most valuable data.”
S/4HANA, BTP and RISE - new architectures, new challenges
Migrating from SAP ECC to S/4HANA introduces significant architectural changes affecting security. Table consolidation - for example, the Universal Journal replacing separate finance and controlling tables - requires redesigning the authorisation concept. Data that was previously spread across multiple tables with different access levels is now held in a single location. This simplifies the architecture, but requires rethinking who should have access to what.
The unification of Business Partner master data and the introduction of the Fiori interface create new web application attack vectors. Fiori is a modern interface built on HTML5 and OData, but it is also a new attack surface for traditional web attacks - XSS, CSRF, injection. Organisations migrating to S/4HANA must factor these changes into their security strategy.
SAP Business Technology Platform (BTP) introduces a cloud security model built on four pillars - database management, application development and integration, analytics, and intelligent technologies. Key threats include unauthorised access via misconfigured BTP accounts, vulnerabilities in custom applications built with CAP or Fiori Elements, and weaknesses in third-party extensions acting as potential backdoors. BTP connects to on-premise systems via the Cloud Connector, creating additional points that must be secured and tested.
In the RISE with SAP model, security responsibility is shared, but often misunderstood. SAP manages the infrastructure, the operating system, the database, and basic hardening. The customer, on the other hand, is responsible for application-layer security, identity and access management, decisions regarding patch deployment (even when SAP provides the patches, the customer decides the timing of deployment), custom code security, data protection, and regulatory compliance.
“The shared responsibility model is often a source of misunderstanding,” explains Michał Korzeń. “I sometimes hear: SAP manages our infrastructure, so security is their problem. Nothing could be further from the truth. Under RISE you lose visibility at the operating system and database level, unless you purchase an additional subscription. But responsibility for who has access to which transactions, what permissions users have, and whether your custom code contains vulnerabilities - that always remains on your side. SAP will not manage your authorisation roles for you.”
The Polish context - NIS2, DORA, the KSC Act and the specifics of public institutions
The DORA (Digital Operational Resilience Act) directive has been in force since 17 January 2025 and applies to virtually all financial entities in the European Union - banks, insurers, investment firms, payment institutions, and even IT service providers to the financial sector. It requires annual penetration testing for all entities covered by the regulation, and advanced TLPT (Threat-Led Penetration Testing) at least every three years for systemically important financial institutions.
TLPT is not ordinary penetration testing. It must cover production systems, including SAP, if it is used for critical business processes. It mandatorily includes purple teaming - collaboration between attacking and defending teams, in which both sides learn from each other. Threat intelligence must be provided by an external provider specialising in threat analysis. Tests must simulate real-world attack scenarios used by criminal groups and state actors. Penalties for non-compliance can reach 1% of average daily global turnover - per day, not as a one-off.
NIS2 explicitly classifies SAP ERP systems as critical network and information systems for organisations in essential and important sectors. Implementation guidance recommends penetration testing at least once a year or following significant system changes. High-risk environments may require more frequent testing. The directive places emphasis on supply chain risk management, meaning organisations must also assess the security posture of their suppliers and partners.
Poland’s National Cybersecurity System Act is currently being amended to implement NIS2. The draft was submitted to the Sejm in November 2025 and introduces significant changes. The new classification divides entities into essential and important, with differing requirement and sanction levels. The self-identification mechanism in the S46 system requires organisations to independently assess whether they are subject to the regulation - they cannot wait to be notified. Personal management liability means fines of up to 600% of salary for failure to meet cybersecurity obligations. Financial penalties for essential entities reach EUR 10 million or 2% of annual revenue; for important entities, EUR 7 million or 1.4% of revenue.
It is worth noting that the regulations require not only that testing be carried out, but also that its results and any remedial actions be documented. In the event of an inspection or incident, an organisation must be able to demonstrate that it proactively managed risk. SAP penetration tests carried out by a competent external party provide strong evidence of due diligence.
“For many Polish organisations this will come as a shock,” admits Jacek Bugajski, CEO of SNOK. “Until now, SAP system security was treated as an internal matter, to be handled in-house or ignored in the hope that nothing would happen. The new regulations mandate documentation of all actions, regular testing by external parties, and incident reporting within strictly defined deadlines. Management will be personally accountable for negligence. This is a fundamental paradigm shift - from optional to mandatory, from internal to externally verifiable.”
Polish public institutions face additional challenges. Many of them cannot or will not use cloud solutions, maintaining on-premise environments due to data sovereignty requirements, security procedures, or simply lack of budget for migration. On one hand, this gives full control over the infrastructure. On the other, it requires maintaining security expertise in-house or through trusted partners, which, given limited budgets and difficulties recruiting specialists, represents a serious challenge.
“Public institutions in Poland operate in a specific environment,” adds Jarosław Zdanowski. “They have limited budgets, public procurement procedures that extend every decision by months, and often older versions of SAP systems due to the cost of upgrades. At the same time, they process particularly sensitive data - belonging to citizens, benefit recipients, taxpayers. SAP penetration testing for the public sector requires an understanding of this specificity and a flexible approach to scope and scheduling.”
Automated scanning vs. manual penetration testing - which to choose?
The question is not whether, but how to combine both approaches. Automated scanning provides rapid coverage of extensive SAP landscapes, consistent and repeatable checks, the ability to monitor continuously, and integration with security operations centre workflows. SAP security platforms offer more than 200 security rules and can be deployed within 48 hours. Automation is essential where there are large numbers of systems - an organisation with dozens of SAP instances cannot manually test everything frequently enough.
Typical automated checks include validating configuration against established SAP standards and best practices, verifying patch levels and missing security fixes, assessing the security of RFC destinations, and monitoring critical transactions and authorisations. This is the foundation without which it is difficult to speak of a mature SAP security programme. Automated scanners will detect default passwords, known vulnerabilities, and obvious configuration errors.
Manual testing remains essential for an initial security assessment when the state of the environment is unknown, during significant infrastructure changes such as migration to S/4HANA or the implementation of BTP, during compliance audits against PCI-DSS, SOX, NIST or DORA where independent verification is required, in post-incident analysis to understand how a compromise occurred, and when investigating zero-day vulnerabilities as new threats emerge. An experienced pentester can develop custom exploits, exploit RFC trust relationships, test privilege escalation paths, decrypt SAP passwords and SecStore keys, and escalate from the database to the operating system.
The recommended testing frequency is every 6-9 months, as a compromise between the traditional annual approach and the requirements of high-risk environments. Production systems should be assessed quarterly using automated scans. Additional manual testing is recommended during migrations or significant changes. Following the discovery of a critical vulnerability, testing should be immediate.
“Automation and human expertise don’t compete - they complement each other,” Michał Korzeń emphasises. “A scanner will detect known vulnerabilities and configuration errors. A human will find logical flaws in business processes, non-obvious escalation paths, and vulnerabilities in custom code. A scanner will tell you that you have a user with SAP_ALL authorisations. A human will tell you that this user is a service account used by the HR system for data synchronisation, and that compromising this account means a leak of every employee’s data. Organisations need both perspectives.”
Real-world incidents - cautionary tales from bankruptcies and data breaches
In August 2024, a ransomware attack on a large international food group led to the shutdown of its SAP ERP systems, encrypting the accounting and finance systems. The company was forced to run all processes manually - issuing invoices, managing inventory, settling accounts with suppliers. The estimated recovery time was 5-7 months. In November 2024, the company filed for bankruptcy, directly citing the SAP security breach as a leading factor in its insolvency.
The case of a US company conducting background checks for the federal government illustrates the long-term consequences of inadequate SAP protection. State-sponsored hackers exploited a vulnerability in an SAP application managed by a third-party IT service provider. 27,000 personnel files leaked, including data from security clearance records of government employees. The consequences were catastrophic - the company lost contracts worth USD 3 billion, laid off half its staff, and its parent company filed for bankruptcy. The incident also demonstrated the importance of supply chain security.
In September 2025, an attack on a global manufacturer exploiting the latest zero-day vulnerability resulted in USD 2.1 billion in quarterly losses and approximately USD 260 million in direct incident-related costs - data recovery, forensic work, regulatory fines, and customer compensation. Significantly, the vulnerability was known and a patch was available - the organisation simply had not deployed it in time.
It is also worth mentioning less dramatic, but equally painful cases. Many organisations experience SAP security breaches and never disclose them publicly - they pay the ransom, fix their systems, and hope no one finds out. But the internal costs - lost productivity, rebuilding employee trust, IT team overtime - are real and significant.
“These cases are not abstract stories from abroad,” says Jacek Bugajski. “We work with clients who have experienced SAP security incidents. We have seen operational paralysis, where the system stops working and nobody knows what’s in the warehouse, who owes money to whom, or which employees should be paid. We have seen management teams explaining themselves to supervisory boards and regulators, justifying why there had been no regular security testing. The cost of regular penetration testing is a fraction of the potential losses. And yet many organisations still treat SAP security as an optional expense that can be deferred.”
How should an organisation prepare for SAP penetration testing?
Before beginning penetration testing, an organisation should carry out an inventory of all SAP systems, hosts and instances, and identify mission-critical assets and their associated business risks. Many organisations do not have a full picture of their SAP landscape - systems were built up over years, some are forgotten, others managed by different departments. A good pentest starts with understanding what is actually being tested.
It is essential to define the scope of testing - whether it covers production systems (more realistic, but requiring caution), which components are in scope (ABAP, Java, HANA, Fiori, integrations with external systems), and whether testing is black-box, grey-box or white-box.
Black-box simulates an external attacker with no knowledge of the system - the pentester receives only an IP address and must discover everything else independently. Grey-box provides partial knowledge - for example, a user account with basic permissions, simulating an insider attack or one following credential theft. White-box grants full access to documentation, source code and configuration, allowing the deepest analysis, but is less realistic. Each approach has its uses - they are often combined within a single project.
For RISE with SAP and BTP environments, penetration testing must comply with the rules set out by SAP. Testing is limited to the application layer - for layers managed by SAP, organisations must rely on SOC reports and certifications available via the SAP Trust Center. You cannot test infrastructure that is not yours.
SAP penetration testing methodology comprises five phases. Discovery involves network detection, SAP port scanning, and reconnaissance - determining what is running, on which servers, and which versions. Enumeration includes identifying database type, SAP version, System ID and instance numbers - gathering the information needed for further attacks. Vulnerability assessment focuses on missing authorisation controls, default credentials, configuration errors and custom code vulnerabilities. Exploitation is the actual use of the vulnerabilities found - exploiting RFC trust relationships, injecting operating system commands, escalating privileges. Post-exploitation involves pivoting between connected systems and accessing critical business data - demonstrating what an attacker can really do once they have taken over the first system.
“It’s essential to involve the right stakeholders from the outset,” advises Jarosław Zdanowski. “SAP penetration testing is not solely an IT department matter. We need business system owners who can say what is critical. BASIS administrators, who will provide the necessary access. A security team to monitor the tests. Often lawyers too, given compliance and liability considerations. The better we prepare the ground, the more valuable the results will be.”
What should an SAP penetration test report contain?
A professional SAP penetration testing report must be useful to different audiences. The board needs an executive summary with a business risk assessment and prioritisation of remedial actions - free of technical jargon, with a clear translation into business language. The technical team requires detailed descriptions of the vulnerabilities found, reproduction steps enabling verification, and remediation recommendations. Auditors expect documentation of the methodology, testing scope, and its limitations.
The report should clearly classify the vulnerabilities found by severity. Critical vulnerabilities are those enabling unauthenticated system takeover, access to sensitive data, or significant business impact - requiring an immediate response. High-severity vulnerabilities pose a serious risk but require additional conditions for exploitation - they should be fixed within weeks. Medium and low-severity vulnerabilities are issues requiring attention within the normal maintenance cycle.
For each vulnerability found, the report should include a technical description explaining the nature of the problem, a proof of concept or screenshots documenting the possibility of exploitation, an assessment of business impact going beyond the technical CVSS score, recommended remedial actions with priorities and estimated effort, and references to the relevant SAP Security Notes if the vendor has already issued a fix.
A good report does not end with a list of problems. It should also include positive observations - what the organisation is doing well, which controls are working effectively. It should also identify areas requiring further analysis and recommendations for improving the overall security posture, beyond the specific vulnerabilities found.
“A penetration testing report is not the end, but the beginning of a process,” Michał Korzeń stresses. “A document left in a drawer does not improve security. What matters is a remediation plan with assigned owners and deadlines, verification of implemented fixes through retesting, and updated procedures and policies. That’s why at SNOK we offer support not only in carrying out the tests, but also in interpreting the results and planning remedial action. We accompany clients along the entire path - from identifying the problem to resolving it.”
Summary - act before it’s too late
The statistics are unambiguous. 92% of organisations consider data in their SAP systems mission-critical. At the same time, 23% experienced a cyberattack affecting their SAP environment in the past year. The average cost of an SAP security breach is USD 5 million. Downtime caused by a security incident costs an average of more than USD 50,000 per hour. These figures relate to the global market, but Polish organisations are not immune to the same threats.
Organisations operating in the financial sector must immediately ensure compliance with DORA, in force since January 2025. All entities should prepare for the implementation of the amended KSC Act. Establishing a regular penetration testing programme with a minimum annual frequency is essential - high-risk environments require quarterly testing.
It is essential to document all security actions as audit evidence. Risk assessment of external SAP suppliers, particularly in the context of RISE, should be part of the strategy. Organisations using SAP ECC should factor in the end of maintenance support in 2027 as an additional risk factor - systems without vendor support are particularly exposed to new vulnerabilities.
Regular, professional penetration testing is the most effective form of proactive protection against threats. It allows vulnerabilities to be detected before criminals find them. It provides evidence of due diligence for regulators and auditors. It builds security awareness within the organisation. It identifies gaps that are not only technical, but also procedural and organisational.
Do not wait for an incident to force you into action. Do not wait for a regulatory fine. Do not wait for a headline about a data breach at your organisation. The cost of a professional SAP penetration test is a fraction of the potential financial and reputational losses. Act now - your SAP system needs it.
Do you need support with SAP security?
SNOK offers comprehensive SAP penetration testing services - from initial security assessment, through regular testing compliant with DORA and NIS2 requirements, to support in remediating the vulnerabilities found. We work with leading SAP security solution providers - SecurityBridge and bowbridge - combining their technology with our expertise. Contact us to discuss your organisation’s needs.
Would you like to see this in practice or discuss implementation for your organisation? Get in touch – we will reply within 48 hours.