Der „Perfect Storm“ der KI: Wie „Mythos“-ähnliche KI-Modelle SAP-Anwendungen hacken können

Künstliche Intelligenz verändert die Bedrohungslage bei SAP grundlegend. Angreifer nutzen mittlerweile universell einsetzbare LLMs und sicherheitsorientierte Modelle, um komplexe Cyberangriffe auf SAP-Systeme zu automatisieren, wodurch die bisherige Hürde – nämlich fundierte, proprietäre SAP-Kenntnisse – vollständig entfällt. Durch einfache Eingaben in normalem Englisch können Angreifer KI-Agenten anweisen, Fehlkonfigurationen aufzudecken, zwischen Datenbanken zu wechseln und kritische Exploits mit maschineller Geschwindigkeit auszuführen. 

Um genau zu veranschaulichen, wie diese Bedrohungen in der Praxis funktionieren, haben Onapsis Research Labs diesen Angriffsablauf Onapsis Research Labs live demonstriert. Diese Demonstration wird vorgestellt in „When AI Attacks SAP“, der dritten Folge unserer umfassenderen Dokumentarserie „Hacking & Defending SAP Applications“. 

Der „Perfekte Sturm“ der KI: Die Wissensbarriere überwinden

Es besteht eine enorme Kluft zwischen dem Wissen der Verteidiger und den Möglichkeiten der Angreifer. Früher musste ein Angreifer, um ein SAP-System zu kompromittieren, proprietäre SAP-Protokolle wie RFC, DIAG oder Gateway-ACL-Strukturen verstehen. Netzwerkverteidiger nutzten diese steile Lernkurve als informelle Sicherheitsebene.

Heutzutage verfügen moderne große Sprachmodelle (LLMs) von Haus aus über den Großteil dieses proprietären Wissens, was zu einem KI-getriebenen Anstieg von Sicherheitslücken in SAP-Umgebungen führt. Ein Angreifer muss nicht mehr wissen, wie ein SAP-Message-Server funktioniert oder wie man eine „secinfo“-Datei umgeht. Er gibt einem KI-Agenten einfach ein Ziel vor, und das Modell führt eigenständig einen vierstufigen Angriffszyklus durch:

• Abbildung: Die KI scannt alle erreichbaren Dienste und erstellt Fingerabdrücke davon, darunter SAP GUI, RFC-Gateway, Message Server, HANA und SAPControl.
• Begründung: Das Modell ordnet die erkannten Angriffspunkte nach ihrer Zuverlässigkeit und wählt den klarsten Pfad aus, beispielsweise eine bekannte CVE, Standard-Anmeldedaten oder eine fehlerhafte ACL-Konfiguration.
• Sicherheitslücke: Die KI ruft öffentlich zugängliche Proof-of-Concepts (PoCs) aus dem Internet ab und passt sie in Echtzeit an.
• Auswirkung: Das Modell erreicht das Ziel und liefert die Arbeitsschritte zur Reproduktion des Ergebnisses.

In „When AI Attacks SAP“ (Folge 3)stellte Pablo Artuso, Tech Lead bei Onapsis, drei Live-Szenarien vor, in denen KI-Modelle ein SAP-System vollständig kompromittierten, ohne dass dabei jeglicher menschlicher Eingriff erforderlich war.

In der Vergangenheit erforderte die Ausnutzung von SAP-Umgebungen fundierte Kenntnisse des ABAP-Codes, von Remote-Funktionsaufrufen und der Architektur auf Kernel-Ebene. Zwar wurden in diesen Demos bewusst vollautomatische Angriffe hervorgehoben, die nahezu keine menschliche Interaktion erfordern, doch stellt dies lediglich die baseline dar. 

Die Bedrohung nimmt exponentiell zu, wenn ein KI-Operator einen kontinuierlichen Dialog führt, dem Modell Echtzeit-Systemrückmeldungen zuführt und den Angriffspfad verfeinert. Verfügt der Angreifer bereits über grundlegende SAP-Kenntnisse, um das LLM zu steuern, erweitern sich die zerstörerischen Möglichkeiten erheblich. 

Szenario 1: Automatisierte Rechteerweiterung über Standard-Anmeldedaten

Das erste Szenario veranschaulicht, wie ein KI-Agent eine klassische Fehlkonfiguration des Systems ausnutzt, um ein Administrator-Backdoor-Konto zu erstellen. Der Angreifer gibt eine einzige Anweisung: „Ich habe keine Ahnung von SAP, daher verlasse ich mich voll und ganz auf dich. Assess System und finde einen Weg, einen Administrator-Benutzer anzulegen.“ 

Sie haben Ihren neuen Benutzer. Dieser neue Benutzer ist „admin“ und verfügt über Administratorrechte – und so stellt man eine Verbindung zum System her. Wie Sie dort sehen können, ist das die URL. Der Angreifer stellt über diese URL eine Verbindung her und nutzt dabei die Anmeldedaten des SAP-Systems – Verzeihung, die von der KI bereitgestellten. Und sobald die Anmeldung erfolgt ist – ja, schon jetzt verfügt der Angreifer über einen Benutzer mit vollen Rechten innerhalb des SAP-Systems. Das ist unglaublich. Und nur um es Ihnen zu zeigen: Wenn Sie zu den Profilen gehen, sehen Sie, dass dieser Benutzer „SAP all“ hatte. Die Folgen sind also drastisch, denn das bedeutet, dass er die volle Kontrolle über dieses System hat.

Die Angriffskette:

• Die Erkundung: Der KI-Agent erfasst die Umgebung mit generischen Scannern und stellt fest, dass Client 001 weiterhin das SAP*-Kernel-Notfallpasswort akzeptiert.
• Die Sicherheitslücke: Über SOAP-RFC ruft das Modell die Funktion BAPI_USER_CREATE1 auf, um einen brandneuen Administrator anzulegen, und weist ihm das Profil SAP_ALL zu.
• Die Auswirkung: Die KI liefert dem Angreifer funktionierende Anmeldedaten sowie Schritt-für-Schritt-Anleitungen für die Anmeldung über die WebGUI und die SAP-GUI.

Szenario 2: Falsche Konfiguration des Gateways und Datenbank-Pivot

Im zweiten Szenario weist der Angreifer die KI an, die Anwendungsschicht vollständig zu umgehen, um Finanzbetrug zu begehen. Das Ziel besteht darin, den Anbieter mit den höchsten Rechnungsbeträgen zu identifizieren und dessen Bankverbindung heimlich zu ändern.

Im Grunde genommen werden über die Befehlsausführung des Betriebssystems SQL-Abfragen direkt an die Datenbank gesendet und diese Daten – also die Bankleitzahl und die Kontonummer – geändert. Am Ende sehen wir also nach etwa fünfzig Minuten eine Meldung. Wir sehen eine abschließende Meldung des cloud , die besagt, dass die Änderung bereits vorgenommen wurde, wie Sie dort sehen können. Die neuen Werte für die Bankleitzahl und die Kontonummer sind also bereits übernommen worden. Wenn wir dies also noch einmal aus der Perspektive eines Administrators betrachten, das System starten und die Informationen des Anbieters anzeigen, werden wir sehen, dass die neuen Werte dort eingetragen sind.

Die Angriffskette:

• Die Erkundung: Die KI erstellt mithilfe des „Start Service“-Zugriffs anonym eine Übersicht über die Bedrohungslage und bewertet laufende Komponenten wie das SAP-Gateway und den SAP-Message-Server.
• The Pivot: The AI identifies a permissive Gateway secinfo ACL, yielding unauthenticated OS command execution as the <sid>adm user.
• Die Auswirkung: Das KI-Modell greift auf die Datenbank (HANA) zu, liest die Lieferantentabellen (LFA1 und LFC1) aus und schreibt die Bankdaten des führenden Lieferanten direkt in die Tabelle LFBK um.

Szenario 3: Autonomer Betrieb und Systemabschaltung

Das letzte Szenario zeigt, wie KI die Ausnutzung bekannter, kritischer Sicherheitslücken beschleunigt. Der Angreifer weist die KI an, assess Zielsystem auf eine bestimmte, ein Jahr alte CVE zu assess , die ursprünglich als Zero-Day-Exploit in freier Wildbahn ausgenutzt wurde. Das Ziel besteht darin, nachzuweisen, dass die Ausführung von Remote-Code (RCE) möglich ist, und die Umgebung ordnungsgemäß herunterzufahren. 

Es liegt erneut eine Remote-Code-Ausführung im System vor, diesmal in einem hochsicheren System. Das Hauptziel dieser Demo war es also, das System herunterzufahren. Der Angreifer gibt in diesem Fall der KI lediglich den Befehl, das System herunterzufahren. Hätte der Angreifer dies auch mit einem Befehl in der Web-Shell tun können? Ja, natürlich. Aber die Idee war, die KI zu nutzen – also einfach zu fragen: „Bitte fahre es für mich herunter.“ Wenn wir anschließend zum Webbrowser zurückkehren und die Seite aktualisieren, werden wir sehen, dass das System bereits heruntergefahren ist.

Die Angriffskette:

• PoC-Auswertung: Der KI-Agent durchsucht öffentlich zugängliche PoCs für CVE-2025-31324 und ermittelt erfolgreich, welche Skripte echt sind und funktionieren.
• 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.
• Die Auswirkung: Die abgesetzte JSP-Webshell wird von der Festplatte gelöscht, um unauffällig zu bleiben, bleibt jedoch bis zu einem Neustart im JVM-Speicher bestehen. Schließlich durchläuft sapcontrol die Instanzen von GRÜN über GELB bis GRAU, und das System wird vollständig deaktiviert.

Abwehr von Angriffen in Maschinen-Geschwindigkeit mit Onapsis

Herkömmliche, reaktive Patching-Zyklen sind angesichts von Angreifern, die sich mithilfe von KI mit Maschinen-Geschwindigkeit lateral ausbreiten, überholt. Zum Schutz Ihres Unternehmens benötigen Sie eine autonome platform die Anwendungsebene kontinuierlich überwacht. Um sich vor den in dieser Folge vorgestellten spezifischen Angriffen zu schützen, gehören zu den sofortigen Absicherungsmaßnahmen das Deaktivieren der automatischen SAP*-Anmeldung, das Sperren von Gateway-ACLs und das Patchen nicht authentifizierter RCEs. Es ist jedoch wichtig zu verstehen, dass diese Beispiele keine priorisierte „Hier-anfangen“-Checkliste darstellen. Vielmehr sind sie lediglich ein Bruchteil der umfassenden baseline , die jedes Unternehmen umsetzen muss. 

Die Onapsis-Lösungen erkennen sozusagen: „Hey, da ist irgendeine Aktivität im System.“ Also erstens: Wenn man sich das LLM vor Augen führt, dann sendet es im Grunde Pings an verschiedene Clients, um zu sehen, welche eine Rückmeldung erhalten und welche aktiviert sind. Vor diesem Hintergrund erkennen sie also, dass bei Client 1 kein SAP-Star-Benutzer aktiviert war. Nun empfängt oder sendet dieser Client im Grunde eine Antwort an das LLM. Auch das Onapsis-Produkt 65 bzw. die Funktion zur kontinuierlichen Überwachung zeigt uns, dass sich jemand mit dem „Substar“-Benutzer im System anmeldet, was wiederum Teil des Ausnutzungsprozesses ist, den Pablo gerade demonstriert hat. Onapsis erfasst nun all diese Informationen in den verschiedenen Produkten. Und zu guter Letzt noch ein Beispiel: Sobald man sich mit einem SAP-Star-Benutzer angemeldet hat, wollen die Angreifer im Grunde Folgendes tun: Sie erstellen einen weiteren Benutzer und weisen ihm ein hohes Profil zu. Wenn das Sicherheitsteam dann versucht, Nachforschungen anzustellen und zu erkennen, was in ihrem System vor sich geht, ist es für sie schwieriger zu erkennen, dass ein Angriff möglich ist oder bereits ausgeführt wurde. In diesem Fall demonstrieren wir dem Kunden mit der platform Folgendes: Jemand mit einem SAP-Star-Benutzerkonto meldet sich im System an, stellt eine Verbindung her und legt innerhalb dieses Benutzerprofils mit hohen Berechtigungen einen weiteren Benutzer an – was aus Sicherheitssicht eigentlich nicht vorkommen dürfte.

Die Platform neutralisiert KI-gesteuerte Angriffe durch kontinuierliche Überwachung auf Anwendungsebene. Lösungen wie Onapsis Assess identifizieren zu freizügige „secinfo“-Konfigurationen, die Gateways angreifbar machen, während Onapsis Defend die SAP*-Anmeldung und die SAP_ALL-Berechtigung genau in dem Moment kennzeichnet, in dem sie erfolgen. Das Onapsis Threat Intel Center verschafft Sicherheitsverantwortlichen einen Vorsprung, indem es Schutzregeln für neu auftretende Zero-Day-Schwachstellen noch vor der Veröffentlichung von Patches bereitstellt – bevor Angreifer ihre großen Sprachmodelle (LLMs) darauf trainieren können, diese auszunutzen.

Um genau zu sehen, wie sich diese KI-gesteuerten Angriffe in Echtzeit abspielen, sehen Sie sich die vollständige Aufzeichnung von „Hacking & Defending SAP Applications Live: Wenn KI SAP angreift“.

Häufig gestellte Fragen

Inwieweit ist die Angriffskette durch die KI vollständig automatisiert und inwieweit sind Eingriffe durch Menschen erforderlich?

Diese Angriffe laufen vollständig automatisiert ab. In diesem Fall muss der Angreifer weder die proprietären SAP-Protokolle verstehen noch eigene Skripte schreiben. Anhand einer einfachen Eingabeaufforderung in einfachem Englisch erstellt das KI-Modell eigenständig eine Übersicht über das System, wählt die Angriffsmethode aus, behebt Fehler und führt das endgültige Ziel aus.

Wie kann ein Angreifer Datenbankdatensätze ändern, ohne sich jemals bei einem gültigen SAP-Benutzerkonto anzumelden?

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. 

Wie erkennt ein autonomes Verteidigungssystem Zero-Day-Angriffe, die von KI gesteuert werden?

KI-gesteuerte Angriffe verlaufen schneller, als menschliche Verteidiger reagieren können. Eine autonome Verteidigung erfordert eine kontinuierliche Überwachung auf Anwendungsebene. Lösungen wie Onapsis Defend erfassen SAP-Telemetriedaten Defend und können so sofort anomales Verhalten wie unbefugte Remote-Funktionsaufrufe oder unerwartete Berechtigungserweiterungen erkennen und das SOC alarmieren, bevor der KI-Agent in den Kern vordringen kann.