Eine neue Sicherheitsforschung zeigt, wie ein Nutzer mit <sid>adm-Zugriff den laufenden SAP-Kernel manipuliert, um einen versteckten Super-User zu erzeugen und den SAP Security Audit Log gezielt blind zu machen. SAP PSIRT hat den Report abgelehnt. Die eigentliche Lehre steckt genau in dieser Ablehnung.

Kurzfassung

Die Forschung virtual-sap-death-star demonstriert, dass ein Angreifer mit <sid>adm-Zugriff einen temporären, voll berechtigten Virtual-SAP*-Account (SAP_ALL) erzeugen kann, dabei den Profilparameter login/create_virtual_user_sapstar = 0 umgeht und den zugehörigen Audit-Event unterdrückt. Ein zweites Tool fängt Audit-Records direkt im Kernel ab, bevor sie irgendein Ziel erreichen (Datei, Datenbank, ETD). Bestätigt auf SAP-Kernel 916, S/4HANA 2023 und 2025. Die praktische Konsequenz: Behandle <sid>adm wie ein root-äquivalentes Konto und verlasse dich nie auf den SAP Security Audit Log als einzige Beweisquelle.

Worum es geht

SAP NetWeaver bringt einen Notfall-Super-User mit, den Virtual SAP*. Das ist ein temporärer, voll privilegierter SAP*-Account mit SAP_ALL, der nur im Prozessspeicher lebt: kein Datenbankeintrag, nicht in der Benutzerverwaltung sichtbar, kein Änderungsbeleg.

SAP hat diese Funktion mit zwei Sicherheitskontrollen versehen:

Beide Kontrollen sollen zusammen sicherstellen: Entweder das virtuelle SAP* wird verhindert, oder seine Nutzung hinterlässt eine Spur. Genau diese Annahme stellt die Forschung auf die Probe.

Was die Forschung zeigt

Das Repository enthält zwei Werkzeuge, die konzeptionell folgendes demonstrieren (die technischen Details bleiben hier bewusst grob, es geht um die Bedeutung, nicht um eine Anleitung):

Erzeugung ohne SAP-Werkzeuge. Das erste Tool klinkt sich per Prozess-Injektion in den laufenden disp+work-Prozess ein und ruft die interne Kernel-Funktion direkt auf. Es braucht dafür nichts als eine normale <sid>adm-Shell, kein SAP-SDK, keine SAP-Binaries. Dabei kann es den Profilparameter umgehen (die 0-Sperre wird ignoriert), den Audit-Event unterdrücken (die Aufrufstellen der Audit-Funktion werden vor dem Aufruf ausgehebelt) und die Gültigkeit des Accounts weit über das normale Limit hinaus verlängern.

Audit-Log-Manipulation an der Quelle. Das zweite Tool hängt sich an die Audit-Schreibstellen im Kernel und fängt Audit-Records ab, bevor sie irgendein Ziel erreichen. Und zwar an allen Senken gleichzeitig: der klassischen Audit-Datei, der Datenbank und dem ETD-Konnektor. Es kann Events mitlesen oder gezielt einzelne Event-Klassen unterdrücken, sodass bestimmte Vorgänge nie irgendwo protokolliert werden.

Bestätigt wurde das auf aktuellem SAP-Kernel (916) sowie S/4HANA 2023 und 2025. Das ist keine Alt-System-Kuriosität, sondern betrifft moderne Landschaften.

Der Kernpunkt: die Kontrollen sind nicht manipulationssicher

Hier liegt der eigentliche Wert der Forschung. SAP liefert für diese Funktion sowohl einen Parameter, der sie verhindern soll, als auch einen Audit-Event, der sie erkennbar machen soll. Wenn <sid>adm beide aushebeln kann, dann sind diese Kontrollen keine unabhängigen, manipulationssicheren Sicherheitsbarrieren.

Genau das ist der Unterschied, der oft untergeht: Ein einzelner Schutzmechanismus, der umgangen werden kann, ist etwas anderes als zwei Mechanismen, die sich gegenseitig absichern sollen und gemeinsam fallen.

SAP PSIRT: abgelehnt, und warum das diskutabel ist

SAP PSIRT hat den Report im Juni 2026 als “false positive” zurückgewiesen. Die Begründung, sinngemäß: Das Szenario setzt Zugriff auf Betriebssystemebene voraus, der außerhalb der Sicherheitsgrenze der SAP-Anwendung liegt. Wer solche privilegierten OS-Rechte hat, kann ohnehin in laufende Prozesse eingreifen, also sei das kein Fehler der SAP-Software.

Diese Position ist nachvollziehbar, <sid>adm-Zugriff ist tatsächlich Voraussetzung. Sie ist aber auch angreifbar, und zwar an einer präzisen Stelle: Der Profilparameter und der Audit-Event sind keine Eigenschaften des Betriebssystems. Es sind Eigenschaften der SAP-Anwendung. SAP hat sie bewusst geschaffen, um genau diese Funktion zu kontrollieren und zu protokollieren. Wenn sie umgehbar sind, ist das eine Aussage über die Wirksamkeit dieser SAP-Kontrollen, nicht nur über OS-Rechte.

Man muss SAPs Grenzziehung nicht teilen, um beide Seiten fair zu sehen: Der Prozess-Eingriff braucht Host-Rechte, das stimmt. Aber die versprochene Erkennbarkeit über den Audit-Event hält diesem Eingriff nicht stand, und das ist ein Ergebnis, mit dem Verteidiger rechnen sollten.

Was das für die Verteidigung bedeutet

Aus der Forschung ergeben sich sehr konkrete, positive Handlungsansätze. Nichts davon erfordert, auf SAPs Einschätzung zu warten:

Der rote Faden: Verlagere einen Teil deines Vertrauens von der Anwendungsebene, die manipuliert werden kann, auf unabhängige Ebenen, die der Angreifer nicht mit demselben Zugriff kontrolliert.

Einordnung

Diese Forschung ist ein gutes Beispiel dafür, warum Defense in Depth mehr ist als ein Schlagwort. Eine einzelne SAP-Kontrolle, so gut gemeint sie ist, wird zum Risiko, sobald man sie für unantastbar hält. Der SAP Security Audit Log bleibt ein wertvolles Werkzeug, aber er ist eben ein Werkzeug innerhalb der SAP-Anwendung, und wer die Anwendung auf Kernel-Ebene kontrolliert, kontrolliert auch das Log.

Die gute Nachricht: Sobald man das akzeptiert, sind die Gegenmaßnahmen klar und machbar. <sid>adm schützen, unabhängig protokollieren, den Host überwachen. Das sind Dinge, die du heute angehen kannst, unabhängig davon, wie SAP die Sache einordnet.

Quellen