The AI Perfect Storm: How Mythos-Like AI Models Can Hack SAP Applications

Artificial intelligence is fundamentally changing the SAP threat landscape. Threat actors are now leveraging general-purpose LLMs and security-focused models to automate complex SAP cyberattacks, completely removing the traditional barrier of requiring deep, proprietary SAP knowledge. By simply issuing plain English prompts, attackers can instruct AI agents to discover misconfigurations, pivot across databases, and execute critical exploits at machine speed. 

To illustrate exactly how these threats operate in the wild, Onapsis Research Labs recently demonstrated this attack loop live. This demonstration is featured in When AI Attacks SAP, the third episode of our broader Hacking & Defending SAP Applications docuseries. 

The AI Perfect Storm: Removing the Knowledge Barrier

A massive gap exists between what defenders know and what attackers can do. Previously, compromising an SAP system required an attacker to understand proprietary SAP protocols like RFC, DIAG, or Gateway ACL structures. Network defenders relied on this steep learning curve as an informal layer of security.

Today, advanced LLMs hold most of this proprietary knowledge natively, fueling an AI-driven vulnerability surge in SAP environments. An attacker no longer needs to know how an SAP Message Server operates or how to bypass a secinfo file. They simply give an AI agent an objective, and the model autonomously executes a four-step attack loop:

• Map: The AI scans and fingerprints every reachable service, including SAP GUI, RFC Gateway, Message Server, HANA, and SAPControl.
• Reason: The model ranks the discovered entryways by reliability and selects the cleanest path, such as a known CVE, default credential, or ACL misconfiguration.
• Exploit: The AI pulls public proofs-of-concept (PoCs) from the internet and adapts them live.
• Impact: The model achieves the objective and hands back the working steps to reproduce it.

In When AI Attacks SAP (Episode 3), Onapsis Tech Lead Pablo Artuso showcased three live scenarios where AI models fully compromised an SAP system using zero proprietary human input.

Historically, exploiting SAP environments required deep proprietary knowledge of ABAP code, remote function calls, and kernel-level architecture. While these demos deliberately highlighted fully automated attacks requiring almost no human interaction, this represents only the baseline. 

The threat becomes exponentially more severe when an AI operator engages in continuous dialogue, feeding the model real-time system feedback and refining the attack path. If the attacker already possesses foundational SAP knowledge to guide the LLM, the destructive capabilities are vastly extended. 

Scenario 1: Automated Privilege Escalation via Default Credentials

The first scenario demonstrates how an AI agent exploits a classic system misconfiguration to create a backdoor administrator account. The attacker provides a single prompt: “I don’t know anything about SAP, so I would completely rely on you. Assess this system and find a way to create an admin user” 

You have your new user. This new user is admin has admin privileges, and this is the way to connect to the system. So if you see there, there is the URL. The attacker is connecting to that URL using the credentials of the SAP system sorry, the AI provided. And once it’s logged in, which is, yeah, already the attacker has a user with full privileges inside the SAP system. This is incredible. And just to show you, when you go to profiles, this user had SAP all. So the consequences are drastically because it means that it has full power on that system.

The Attack Chain:

• The Reconnaissance: The AI agent fingerprints the landscape with generic scanners and finds that Client 001 still accepts the SAP* kernel emergency password.
• The Exploit: Over SOAP-RFC, the model calls BAPI_USER_CREATE1 to mint a brand-new administrator and assigns the SAP_ALL profile.
• The Impact: The AI returns working credentials and step-by-step WebGUI and SAP GUI login instructions to the attacker.

Scenario 2: The Gateway Misconfiguration and Database Pivot

In the second scenario, the attacker instructs the AI to bypass the application layer entirely to commit financial fraud. The objective is to identify the highest-billing vendor and covertly alter their bank account routing details.

What it’s been doing basically is through the OS command execution is launching SQL queries directly to the database and modifying those data, those, the routing number and the account number. So at the end, we’re gonna see a message after fifty minutes more or less of work. We’re gonna see a final message of the cloud code saying that the change was already done, as you can see there. So the new values of the routing number and the account number are already in place. So again, if we show this from an admin perspective and we launch the system and we show the information from the vendor, we’re going see that the new values are written over there.

The Attack Chain:

• The Reconnaissance: The AI anonymously maps the threat landscape leveraging the Start Service access and assesses running components such as the SAP Gateway and SAP Message Server.
• The Pivot: The AI identifies a permissive Gateway secinfo ACL, yielding unauthenticated OS command execution as the <sid>adm user.
• The Impact: The AI model pivots into the database (HANA), reads the vendor tables (LFA1 and LFC1), and rewrites the top vendor’s bank details directly in the LFBK table.

Scenario 3: Autonomous Exploitation and System Shutdown

The final scenario shows how AI accelerates the weaponization of known, critical vulnerabilities. The attacker prompts the AI to assess a target system for a specific, year-old CVE that was originally exploited as a zero-day in the wild. The goal is to prove remote code execution (RCE) is possible and gracefully shut down the environment. 

You have remote code execution in the system again once more in this time in a hard system. So now the the main goal of this demo was to shut down the system. So, the attacker in this case is just prompting this to the AI asking to shut down the system. Could the the attacker did this with a command in the web shell? Yes, of course. But the idea was to use AI, so just ask it, please shut it down for me. So afterwards, if we go back to the web browser and we refresh, we’re gonna see that system is already down.

The Attack Chain:

• PoC Evaluation: The AI agent researches public PoCs for CVE-2025-31324 and successfully evaluates which scripts are real and working.
• Web Shell Deployment: A passive check of the metadatauploader endpoint (ports 50000 and 50001) confirms an unpatched, vulnerable AS Java instance. A public deserialization PoC lands code execution as the privileged <sid>adm service account and a JSP webshell is dropped inside the system to keep persistence.
• The Impact: The dropped JSP webshell is deleted from the disk to maintain a stealthy footprint, but lives on in JVM memory until a restart. Finally, sapcontrol walks the instances from GREEN to YELLOW to GRAY, and the system goes completely dark.

Defending Against Machine-Speed Attacks with Onapsis

Traditional, reactive patching cycles are obsolete against attackers who use AI to move laterally at machine speed. Protecting your business requires an autonomous defense platform that continuously monitors the application layer. To protect against the specific attacks demonstrated in this episode, immediate hardening steps include disabling the SAP* auto-logon, locking down Gateway ACLs, and patching unauthenticated RCEs. However, it is critical to understand that these examples do not represent a prioritized “start here” checklist. Instead, they are merely a fraction of the comprehensive baseline protections every enterprise must implement. 

Onapsis solutions seeing like, hey, there is some type of activity in the system. So number one, and if you think about the LLM, what it’s doing is basically pinging different clients to see which ones is receiving a feedback, which one is enabled. So with that being said, they see that client one, which didn’t have a SAP star user enabled. Now it’s basically receiving or sending a response to the LLM. Also from Onapsis sixty five product or from the continuous monitoring capability, it’s also telling us that someone locks in with the substar using into the system, which makes it again, part of the exploitation process that Pablo just demonstrate. Now Onapsis is capturing all that information into the different product. And last one but not least one is look, the scenario is once you’re logged in with a SAP star user, the attackers basically what they want to do is, look, they create another user, they assign a high profile. So when they’re doing the security team is trying to do the investigation and seeing what’s happening in their system, it’s more difficult for them to detect that the attack it’s possible or it was executed. In this case, what we are demonstrating with the Onapsis platform, we’re telling the customer, hey, someone with a SAP star user logs into the system and basically connect it and create another user inside that high profile, which is something that, you know, from the security perspective shouldn’t have.

The Onapsis Platform neutralizes AI-driven attacks through continuous application-layer monitoring. Solutions like Onapsis Assess identify permissive secinfo configurations that leave gateways exposed, while Onapsis Defend flags the SAP* logon and the SAP_ALL grant the exact moment they happen. The Onapsis Threat Intel Center keeps defenders ahead of the curve by publishing pre-patch protection rules for emerging zero-day vulnerabilities before threat actors can train their LLMs to exploit them.

To see exactly how these AI-driven attacks unfold in real time, watch the full replay of Hacking & Defending SAP Applications Live: When AI Attacks SAP.

Frequently Asked Questions

How much of the attack chain is fully automated by the AI versus requiring human prompt engineering?

These attacks are entirely automated. In this case, the attacker does not need to understand proprietary SAP protocols or write custom scripts. By providing a basic, plain English prompt, the AI model autonomously maps the system, selects the exploit, debugs errors, and executes the final objective.

How can an attacker modify database records without ever logging into a valid SAP user account?

The SAP application server connects to the database automatically at every startup, completely removing the need for a human to type a password. That connection relies on a stored trust tied directly to the <sid>adm OS user. Consequently, anyone who obtains an OS shell as <sid>adm inherits that trust and can communicate with the database directly. This results in no SAP logon, no SAP authorization checks, and typically no SAP-level audit trail. This is the exact path the AI leveraged to autonomously run queries and modify records. 

How does an autonomous defense system catch AI-paced zero-day attacks?

AI-driven attacks move faster than human defenders can react. Autonomous defense requires continuous application-layer monitoring. Solutions like Onapsis Defend natively ingest SAP telemetry, allowing them to instantly detect anomalous behavior like unauthorized remote function calls or unexpected privilege escalations, alerting the SOC before the AI agent can pivot into the core.