Zero-Day-Lücke in SAP NetWeaver Von der Lücke zur Welle: Was CVE-2025-31324 über ERP-Exploits verrät

Anbieter zum Thema

Onapsis GmbH

FTAPI Software GmbH

Ein veröffentlichter Exploit, ein paar Zeilen Code – und plötzlich stehen zig ERP-Landschaften unter Beschuss. Die An­griffe rund um CVE-2025-31324 zeigen eindrücklich, wie schnell Schwachstellen zu massenhaften Kampagnen werden können und warum klassische Schutzmechanismen dafür nicht mehr ausreichen.

Sicherheitslücken in ERP-Systemen werden heute nicht mehr nur punktuell ausgenutzt, sondern in automatisierte An­griffsabläufe eingebettet, die in kurzer Zeit enorme Reichweite erzielen. Angreifer bauen initiale Kom­pro­mit­tie­rungen zu langfristigen Zugriffsmöglichkeiten aus und nutzen diese als Basis, unter anderem für Datendiebstahl, Manipulation oder weitere Ausbreitung. Für Unternehmen bedeutet das, dass Reaktionsfenster immer kürzer und die Anforderungen an Monitoring und Incident Response deutlich höher werden.

Was ist passiert? Eine Timeline von CVE-2025-31324

Im März 2025 nutzen Akteure erstmals eine neue Schwachstelle in „SAP NetWeaver“ aus – ein Zero-Day-An­griff. Bis zur Bereitstellung des Patches im April hatten bereits zahlreiche Kom­pro­mit­tie­rungen stattgefunden und Angreifer nutzten zuvor installierte „Webshells“ weiterhin aus, sodass die Bedrohung trotz Patch weiter bestehen blieb. Erst Wochen später, im August, folgte eine öffentliche Exploit-Phase, ausgelöst durch die Veröffentlichung eines lauffähigen Exploit-Skripts in einem Telegram-Channel, die eine zweite An­griffswelle nach sich zog.

Diese Abfolge – von der stillen Zero-Day-Phase bis zur öffentlichen Exploit-Verbreitung – macht CVE-2025-31324 einzigartig und gleichzeitig zu einem Lehrbeispiel für moderne ERP-An­griffe: Es zeigt, wie lange ein Risiko bestehen kann, selbst wenn ein Patch existiert, und wie schnell eine solche Dynamik zur globalen Bedrohung wird.

Sicherheitslücke ermöglicht Systemkontrolle

Notfallpatch für kritische Zero-Day-Schwachstelle in SAP NetWeaver

Überblick in Kürze: die Mechanik hinter dem Exploit

Wichtig aus Sicht von Erkennungs- und Abwehrteams war in diesem Fall die Kombination aus folgenden Ei­gen­schaften: das Vorhandensein eines öffentlich dokumentierten, lauffähigen Exploits; der Einsatz von Webshells ab dem Zero-Day-An­griff; und ein modularer An­griffsablauf, bei dem die erste Kom­pro­mit­tie­rung schnell in lateralere Aktivitäten und Datendiebstahl übergehen kann. Diese Merkmale erschweren klassische Defensivstrategien, die sich primär auf Signaturen, IP-Blocklisten oder punktuelle Patching-Zyklen stützen.

Der Exploit nutzte eine Java-Deserialisierungslücke, die über einen Upload-Pfad ausgenutzt wurde. Angreifer konstruierten serialisierte Objekte, die beim Deserialisieren schädlichen Code auslösten. Es bot zwei Betriebsmodi: einen Modus zur einmaligen Befehlsausführung (–command) für schnelle Prüfungen und einen Modus zum Ablegen einer Webshell (–dropshell) für persistente Kontrolle. Praktische Beobachtungen zeigten darüber hinaus mehrere Webshell-Varianten, darunter Implementierungen mit verschlüsselter Kommunikation und Mechanismen für dynamisches Class-Loading, was die Erkennung erschwerte. Ebenfalls dokumentiert wurden wiederkehrende Upload-Versuche an einen spezifischen Upload-Endpunkt. Diese technischen Details stammen aus der forensischen Analyse der Onapsis-Forschungsteams.

Technik und Ablauf sind typisch: Ein initialer, oft automatisierter Scan erkennt verwundbare Endpunkte. Das veröffentlichte Exploit-Tool ermöglicht danach einfachen Zugriff für eine große Zahl an Angreifern. Als nächster Schritt kommt meist die Ablage einer Webshell, um Persistenz zu schaffen und Folgeaktionen zu ermöglichen.

Angriffsziel SAP

Strukturelle Schwächen erhöhen das Risiko für SAP-Landschaften

Was uns der Vorfall lehrt

Drei Aspekte machen den Vorfall exemplarisch:

• Erstens die Verfügbarkeit eines funktionierenden Exploits für eine nicht triviale Schwachstelle;

• Zweitens die schnelle Automatisierung und Verbreitung dieses Exploits;

• Drittens die gezielte Verschleierung der An­griffe über anonymisierende Netzwerke.

Zusammengenommen erhöhen diese Faktoren die An­griffsintensität unmittelbar nach Exploit-Veröffentlichung und verkleinern die Zeitfenster für erfolgversprechende Abwehrmaßnahmen drastisch. CVE-2025-31324 ist deshalb nicht nur ein Einzelfall, sondern ein Indikator für eine sich verändernde Exploit-Ökonomie: An­griffe werden zunehmend modular, reproduzierbar und quasi „user friendly“, so dass selbst Angreifer mit begrenzter Spezialkenntnis effektiv operieren können.

Parallel dazu ändert sich die Infrastruktur: Cloud- und Managed-ERP-Modelle verschieben Verantwortlichkeiten, die nicht jedem Kunden klar sind. Das bietet Angreifern ideale An­griffs­punkte.

Der Fall lehrt daher: Es reicht nicht mehr, Schwachstellenlisten zu beobachten. Unternehmen müssen verstehen, wie Exploits genutzt, wie sich Angreifer dauerhaft Zugang verschaffen und später lateral vorgehen. Nur so lassen sich die richtigen Erkennungs- und Reaktionsketten definieren.

Was Security- und ERP-Teams beachten sollten:

Aus den Beobachtungen lassen sich klare Empfehlungen für operative Teams ableiten:

• 1. Vollständige und aktuelle Inventarisierung: Jedes Modul, auch jede Test- und Ent­wick­lungs­in­s­tanz sowie jede mitgelieferte Komponente muss bekannt und bewertet sein. Verwaiste Add-ons und selten genutzte Module sind bevorzugte Ziele. Sie sollten offengelegt und, falls nicht benötigt, entfernt oder zumindest isoliert werden.

• 2. Konsequentes Monitoring: SAP-spezifische Logs und Ereignisse müssen lückenlos aus­ge­wertet und verstanden werden. Nur wenn Datenübermittlungen, ABAP-Änderungen, ungewöhnliche Tabellenzugriffe und Upload-Events in die Beurteilung eingehen, lassen sich frühe Kom­pro­mit­tie­rungszeichen erkennen.

• 3. Schnelle Priorisierung: Nach Veröffentlichung eines Exploits beginnt ein Wettlauf. Eine risikobasierte Priorisierung und beschleunigte Patch-Workflows sind deshalb unerlässlich. Teams benötigen Mechanismen und Lösungen, die kritische Lücken automatisiert erkennen, priorisieren und konkrete Handlungsempfehlungen liefern.

• 4. Proaktive Scans: Gezieltes Suchen nach „JSP/Servlet“-Ablagen, ungewöhnlichen POST-Requests oder neu angelegten Admin-Konten identifiziert Kom­pro­mit­tie­rungen, die sonst leicht übersehen werden.

• 5. Automatisierung als Skalierungshebel: Angesichts des globalen Fachkräftemangels sind automatisierte Priorisierung und Scans sowie vordefinierte Reaktions-Playbooks un­ver­zicht­bar. Au­to­ma­tisierung reduziert Time-to-Detect und Time-to-Respond und befreit das Sicherheitsteam von repetitiven Aufgaben, damit menschliche Expertise dort eingesetzt werden kann, wo Kontext und strategische Entscheidungen nötig sind. Gleichzeitig darf Automatisierung nicht blind erfolgen: Die Tools müssen ERP-Kontext kennen. Lösungen, die Schwachstellen mit diesem Kontext verknüpfen, schaffen die Basis.

• 6. Shared-Responsibility operationalisieren: In Cloud-Szenarien wie „RISE“ bleiben viele applikationsnahe Aspekte in Kundenverantwortung. Unternehmen müssen die Zu­stän­dig­kei­ten genau definieren, damit Patch-, Monitoring- und Incident-Response-Aufgaben nicht durch Annahmen verloren gehen.

SAP Patchday Mai 2025

Update für kritische NetWeaver-Schwachstelle

Wie sich solche An­griffe praktisch verhindern oder eindämmen lassen

Prävention kombiniert technische Härtung mit organisatorischer Disziplin. Technische Maßnahmen umfassen rechtzeitiges Patching, Härtung von Upload-Pfaden, konsequente Netzwerksegmentierung, verschlüsselte Kommunikation und die Isolierung nicht benötigter Komponenten. Auf Betriebsebene sind getestete Incident-Response-Prozesse, klare Es­ka­la­ti­ons­pfa­de und regelmäßige Simulationen zentral. Im konkreten Fall wirkten schnelle IOC-Checks, gezieltes Hunting nach neu deployten Artefakten und das Blockieren identifizierter TOR-Exit-Node-IPs unmittelbar begrenzend.

Der Beitrag von Threat Research und spezialisierten Tools

Frühwarnung entsteht durch Beobachtung: Forschungsgruppen mit branchenspezifischer Erfahrung tragen entscheidend dazu bei, Exploit-Wellen früh zu erkennen und technisch zu charakterisieren. Spezialisierte ERP-Security-Plattformen, die Threat Research, kontinuierliche Scans und automatisierte Priorisierung verbinden, ermöglichen es, die Lücke zwischen SAP-Fachwissen und allgemeinen Security-Kompetenzen zu schließen, indem sie direkt nutzbare Einblicke und Empfehlungen mit Prioritäten liefern. Denn generalistische Security-Tools sind wichtig, reichen aber oft nicht aus, um ERP-spezifische An­griffsmuster zu erkennen.

Fazit: Resilienz statt Reaktivität

Die Exploit-Welle um CVE-2025-31324 ist weniger ein einmaliger Zwischenfall als ein Lehrstück: moderne Exploits sind modular, automatisierbar und werden schnell von diversen Akteuren ge­nutzt. Gegen diese Dynamik helfen nur drei grundsätzliche Hebel: bessere Sichtbarkeit, mehr Proaktivität und höhere Reaktionsgeschwindigkeit sowie durchdachte Automatisierung. Wer diesen Dreiklang beherrscht, wappnet seine ERP-Landschaft optimal für die nächste Exploit-Welle.

Hinweis:

Die Beobachtungen zu Exploit-Mechanik basieren auf der Analyse der Onapsis Research-Teams und wurden öffentlich zugänglich dokumentiert. Weitere technische Details erfahren Sie hier.

Über den Autor: Juan Pablo Perez-Etchegoyen ist Chief Technology Officer bei Onapsis.

Datenschutzverletzungen „made in Germany“

Die größten deutschen Datenpannen in 2025

(ID:50683547)