14. Juli 2026

Sprachmodelle verändern die Art, wie SAP-Systeme angegriffen werden können, grundlegend. Das Sicherheitsteam von Onapsis Research Labs hat in einer Live-Demonstration gezeigt, wie KI-Agenten selbstständig Fehlkonfigurationen aufspüren, zwischen Systemen wechseln und Schwachstellen ausnutzen – ganz ohne tiefgehendes SAP-Fachwissen auf Seiten des Angreifers. Vorgestellt wurde die Untersuchung von Pablo Artuso, Tech Lead bei Onapsis, im Rahmen von „When AI Attacks SAP“, der dritten Folge der Dokumentarreihe „Hacking & Defending SAP Applications“. Onapsis ist ein auf SAP- und ERP-Sicherheit spezialisiertes Forschungs- und Softwareunternehmen, dessen Labs regelmäßig Schwachstellen in Geschäftsanwendungen untersuchen und dokumentieren.

Die Demonstration richtet sich laut Onapsis nicht in erster Linie an technische Spezialisten, sondern soll auch Entscheidern ohne SAP-Hintergrund verdeutlichen, wie schnell sich die Angriffsfläche durch den Einsatz von KI verändert hat. Genau dieser Perspektivwechsel steht im Mittelpunkt der Folge: weg von der Frage, ob ein Angriff technisch möglich ist, hin zu der Frage, wie viel Aufwand er einen Angreifer heute tatsächlich noch kostet.

Wenn Fachwissen keine Hürde mehr ist

Bislang galt tiefes Verständnis proprietärer SAP-Protokolle wie RFC, DIAG oder Gateway-ACL-Strukturen als eine Art natürliche Hürde für Angreifer. Wer ein SAP-System kompromittieren wollte, musste genau wissen, wie ein Message-Server arbeitet oder wie sich eine „secinfo“-Datei umgehen lässt. Netzwerkverteidiger konnten sich, so beschreibt es Onapsis, lange Zeit auf diese steile Lernkurve als eine Art informelle Schutzschicht verlassen.

Moderne Sprachmodelle bringen dieses Spezialwissen inzwischen von Haus aus mit, da sie mit einer großen Menge öffentlich verfügbarer technischer Dokumentation trainiert wurden. Ein Angreifer muss dem Modell nach Einschätzung von Onapsis nur noch ein Ziel vorgeben – den Rest übernimmt die KI eigenständig in einem vierstufigen Ablauf:

Kartierung: Das Modell scannt erreichbare Dienste und identifiziert Systeme wie SAP GUI, RFC-Gateway, Message Server, HANA oder SAPControl.
Bewertung: Erkannte Angriffspunkte werden nach Erfolgsaussicht sortiert, etwa eine bekannte Sicherheitslücke, Standard-Zugangsdaten oder eine fehlerhafte Zugriffskontrolle.
Ausnutzung: Das Modell greift auf öffentlich verfügbare Machbarkeitsnachweise (Proof-of-Concepts) zurück und passt diese in Echtzeit an das Zielsystem an.
Umsetzung: Das Ziel wird erreicht, inklusive einer Schritt-für-Schritt-Anleitung zur Reproduktion.

Pablo Artuso stellte in der Folge drei Live-Szenarien vor, in denen KI-Modelle SAP-Systeme vollständig übernahmen – ohne jegliches menschliches Zutun während der eigentlichen Ausführung. Nach seiner Einschätzung waren früher fundierte Kenntnisse von ABAP-Code, Remote-Funktionsaufrufen und der Architektur auf Kernel-Ebene notwendig, um SAP-Umgebungen erfolgreich anzugreifen. Diese Voraussetzung entfällt nun weitgehend.

Wichtig zu wissen: Diese vollautomatischen Abläufe bilden laut Artuso lediglich den Ausgangspunkt, gewissermaßen den Basisfall. Führt ein Angreifer mit eigenem SAP-Grundwissen stattdessen einen fortlaufenden Dialog mit dem Modell und speist Systemrückmeldungen in Echtzeit ein, lässt sich der Angriffspfad gezielt verfeinern. Onapsis weist ausdrücklich darauf hin, dass sich das Schadenspotenzial in einem solchen Fall deutlich steigert, weil Mensch und KI-Modell im Wechsel agieren und Fehler des Modells laufend korrigiert werden können.

Szenario 1: Ein Administrator-Zugang aus dem Nichts

Im ersten von Onapsis gezeigten Beispiel genügte ein einziger, bewusst laienhaft formulierter Prompt: Der Nutzer gab an, keinerlei SAP-Kenntnisse zu besitzen, und bat die KI lediglich darum, das System zu bewerten und einen Administrator-Account einzurichten. Weitere Anweisungen waren nicht nötig.

Erkundung: Der Agent erfasste die Umgebung mit gängigen, frei verfügbaren Scan-Werkzeugen und stellte dabei fest, dass Mandant 001 noch immer das werkseitige SAP*-Notfallkennwort akzeptierte – eine seit Jahren bekannte, aber in der Praxis häufig übersehene Fehlkonfiguration.
Ausnutzung: Über die Schnittstelle SOAP-RFC rief das Modell eigenständig die Standardfunktion BAPI_USER_CREATE1 auf und legte damit einen neuen Nutzer an, dem es direkt das weitreichende Berechtigungsprofil SAP_ALL zuwies.
Ergebnis: Am Ende erhielt der Angreifer funktionierende Zugangsdaten sowie eine vom Modell selbst formulierte Anleitung zur Anmeldung über WebGUI und SAP-GUI – inklusive Hinweisen, wie sich der neue Account im System möglichst unauffällig verhält.

Pablo Artuso betonte in der Demonstration, dass für diesen gesamten Ablauf zu keinem Zeitpunkt SAP-spezifisches Fachwissen auf Seiten des menschlichen Angreifers notwendig war.

Szenario 2: Umgehung der Anwendungsschicht für Finanzbetrug

Im zweiten, von Onapsis vorgestellten Fall ging es nicht um einen klassischen Systemzugang, sondern um einen gezielten Betrugsversuch: Die KI sollte die eigentliche Anwendungsebene komplett umgehen und stattdessen direkt in der Lieferantenverwaltung eine Bankverbindung manipulieren. Zielvorgabe des Angreifers war, den Lieferanten mit dem höchsten Rechnungsvolumen zu ermitteln und dessen hinterlegte Kontodaten unbemerkt zu ändern.

Erkundung: Anonym über den öffentlich erreichbaren „Start Service“-Zugriff verschaffte sich das Modell einen Überblick über laufende Komponenten wie das SAP-Gateway und den Message Server, ohne dass hierfür Zugangsdaten notwendig waren.
Übergang ins Betriebssystem: Eine zu freizügig konfigurierte Gateway-Zugriffskontrolle („secinfo“) ermöglichte anschließend eine nicht authentifizierte Ausführung von Betriebssystembefehlen unter dem privilegierten Nutzerkonto adm – dem technischen Systemkonto der jeweiligen SAP-Instanz.
Auswirkung: Mit diesem Zugriff verband sich die KI eigenständig direkt mit der HANA-Datenbank, las die Lieferantentabellen LFA1 und LFC1 aus, identifizierte den umsatzstärksten Lieferanten und überschrieb dessen Bankverbindung unmittelbar in der Tabelle LFBK.

Onapsis weist an dieser Stelle ausdrücklich darauf hin, dass ein solcher Eingriff auf Datenbankebene die reguläre SAP-Anwendungslogik komplett umgeht – wodurch klassische Kontrollen auf Anwendungsebene den Vorfall gar nicht erst erfassen.

Szenario 3: Bekannte Sicherheitslücke, automatisierte Ausnutzung

Das dritte von Onapsis vorgestellte Szenario zeigt, wie zügig KI eine bereits bekannte, rund ein Jahr alte Schwachstelle ausnutzen kann, die ursprünglich als Zero-Day in freier Wildbahn beobachtet wurde. Der Angreifer gab dem Modell lediglich vor, das Zielsystem auf diese konkrete Sicherheitslücke zu prüfen. Ziel war der Nachweis, dass sich darüber Remotecode ausführen lässt, sowie im Anschluss eine geordnete Abschaltung der Umgebung.

Auswertung öffentlicher Quellen: Der Agent durchsuchte selbstständig öffentlich zugängliche Machbarkeitsnachweise zur Schwachstelle CVE-2025-31324 im Internet und filterte automatisch heraus, welche der kursierenden Skripte tatsächlich funktionsfähig waren.
Einschleusen der Schadkomponente: Eine passive Prüfung des sogenannten Metadatauploader-Endpunkts (Ports 50000 und 50001) bestätigte eine ungepatchte AS-Java-Instanz. Über einen öffentlich bekannten Deserialisierungs-Exploit erlangte das Modell daraufhin Codeausführung unter dem privilegierten Dienstkonto adm und platzierte eine JSP-Webshell im System, um sich dauerhaften Zugriff zu sichern.
Verschleierung und Abschluss: Zur Tarnung wurde die Webshell anschließend von der Festplatte gelöscht, blieb jedoch bis zu einem Neustart im Arbeitsspeicher der Java-Laufzeitumgebung (JVM) weiterhin aktiv. Zum Abschluss der Demonstration durchlief der über sapcontrol angezeigte Systemstatus die Stufen Grün, Gelb und Grau, bis das System schließlich vollständig heruntergefahren war.

Onapsis betont, dass dieses Szenario bewusst eine bereits öffentlich dokumentierte Schwachstelle nutzt, um zu zeigen, wie stark KI allein schon die Geschwindigkeit der Ausnutzung bekannter Lücken erhöht – unabhängig davon, ob völlig neue Angriffswege entdeckt werden.

Was Unternehmen jetzt tun können

Nach Einschätzung von Onapsis reichen klassische, reaktive Patch-Zyklen gegen Angreifer, die sich mit Unterstützung von KI in Maschinengeschwindigkeit durch ein Netzwerk bewegen, nicht mehr aus. Notwendig sei stattdessen eine Lösung, die die Anwendungsschicht durchgehend und automatisiert überwacht, statt nur in festen Zeitabständen zu prüfen.

Als erste Sofortmaßnahmen gegen die in der Demonstration gezeigten Angriffswege nennt Onapsis konkret:

Deaktivierung der automatischen SAP*-Anmeldung mit dem werkseitigen Notfallkennwort
Konsequente Absicherung der Gateway-Zugriffskontrolllisten, insbesondere der secinfo-Konfiguration
Zeitnahes Einspielen von Patches für nicht authentifizierte Remotecode-Lücken wie die im dritten Szenario gezeigte

Onapsis weist jedoch ausdrücklich darauf hin, dass diese drei Punkte keine priorisierte Checkliste im Sinne von „hier zuerst ansetzen“ darstellen. Sie seien lediglich ein Ausschnitt aus einer deutlich umfassenderen Sicherheitsgrundlage, die jedes Unternehmen mit SAP-Systemen etablieren sollte.

Häufig gestellte Fragen

Wie stark ist der Angriff automatisiert – braucht es überhaupt noch einen Menschen?

Laut Onapsis läuft der gesamte Ablauf eigenständig ab. Der Angreifer benötigt weder Kenntnisse proprietärer SAP-Protokolle noch eigene Skripte. Aus einer einfachen Anweisung in natürlicher Sprache erstellt das Modell selbstständig eine Systemübersicht, wählt eine Angriffsmethode, behebt auftretende Fehler und führt das gesetzte Ziel aus. Pablo Artuso beschreibt dies als eine Basisvariante, die sich durch menschliche Beteiligung während des Angriffs noch deutlich erweitern lässt.

Wie lassen sich Datenbankeinträge ändern, ohne sich je bei einem SAP-Nutzerkonto anzumelden?

Onapsis erklärt dies mit der technischen Funktionsweise von SAP-Systemen: Der Anwendungsserver verbindet sich bei jedem Start automatisch mit der Datenbank, ganz ohne manuelle Passworteingabe. Diese Verbindung basiert auf einer Vertrauensstellung, die fest an das Betriebssystemkonto adm gebunden ist. Wer Zugriff auf eine Shell unter diesem Konto erhält, übernimmt damit automatisch dieses Vertrauen und kann direkt mit der Datenbank kommunizieren – ohne SAP-Anmeldung, ohne SAP-Berechtigungsprüfung und meist ohne Eintrag im SAP-Audit-Protokoll. Genau diesen Weg nutzte das Modell im zweiten, von Onapsis gezeigten Szenario, um eigenständig Datensätze auszulesen und zu verändern.

Wie lassen sich KI-gesteuerte Angriffe frühzeitig erkennen?

Da KI-gestützte Angriffe nach Einschätzung von Onapsis schneller ablaufen, als menschliche Teams reagieren können, braucht es eine fortlaufende Überwachung auf Anwendungsebene. Das Unternehmen verweist hier auf die eigene Lösung Onapsis Defend, die SAP-Telemetriedaten erfasst und so ungewöhnliches Verhalten – etwa unautorisierte Funktionsaufrufe oder unerwartete Rechteausweitungen – erkennen und das Sicherheitsteam alarmieren soll, bevor ein Angriff tiefer in das System vordringt.

Redaktion AllAboutSecurity

Bild: KI-generiert