Cl0p vs. Oracle EBS: Forensik im Schatten eines zwei Monate alten Zero-Days
23.07.2026 oracle-ebscl0pzero-dayextortionmass-exploitation
Ein Zero-Day, zwei Monate Vorlauf
Ende September 2025 erhielten Führungskräfte dutzender Unternehmen plötzlich Erpressungsmails der Ransomware-Marke Cl0p. Der Vorwurf: Die Angreifer hätten ihre Oracle-E-Business-Suite-Umgebung (EBS) kompromittiert und sensible Daten gestohlen. Die Gruppe hatte eine Zero-Day-Schwachstelle in Oracles E-Business-Suite-Software ausgenutzt, und ab Ende September 2025 erhielten Führungskräfte dutzender Organisationen Erpressungsmails, die eine Kompromittierung ihrer EBS-Systeme behaupteten. Das eigentlich Brisante zeigte sich erst bei der forensischen Rekonstruktion: Die gemeinsame Untersuchung von Google und Mandiant ergab, dass die Ausnutzung bereits im Juli 2025 begann – möglicherweise verknüpft mit der später als CVE-2025-61882 katalogisierten Zero-Day-Lücke. CVE-2025-61882 wurde also mindestens zwei Monate lang als Zero-Day ausgenutzt, bevor Patches verfügbar waren – ein Fenster, das Angreifer aktiv beobachteten und nutzten.
Für Incident Responder bedeutet das: Wer erst nach der öffentlichen Erpressungswelle mit der Untersuchung beginnt, blickt womöglich auf zwei Monate alte Kompromittierungsspuren – falls überhaupt noch Logs vorhanden sind.
Die Angriffskette: RCE ohne Festplattenspuren
Technisch nutzte Cl0p eine besonders forensisch unangenehme Kette. Die Angriffe nutzen eine serverseitige Kette aus SSRF und CRLF-Injection, um EBS-Server dazu zu zwingen, bösartige XSL-Payloads abzurufen und auszuführen – Remote Code Execution ohne festplattenbasierte Artefakte. Das ist ein Albtraum für klassische Post-mortem-Forensik: Ohne persistente Dateien auf der Disk verlassen sich Ermittler fast ausschließlich auf Netzwerklogs, HTTP-Access-Logs und flüchtige Speicherartefakte – Datenquellen, die in vielen On-Premise-EBS-Umgebungen weder lange genug aufbewahrt noch ausreichend granular protokolliert werden.
Zusätzlich missbrauchten die Angreifer kompromittierte Mailboxen, um die lokalen Passwort-Reset-Workflows von EBS auszunutzen, SSO- und MFA-Schutzmaßnahmen zu umgehen und Zugangsdaten zu stehlen sowie Daten zu exfiltrieren. Das verschiebt den forensischen Fokus: Es reicht nicht, nur die Webanwendungslogs zu prüfen – auch E-Mail-Gateway-Logs, Passwort-Reset-Events und Authentifizierungsanomalien außerhalb des klassischen MFA-Pfads müssen in die Timeline einfließen. Nach der Kompromittierung staged Cl0p die Daten für Erpressung oder setzte Ransomware ein, um den Betrieb zu stören.
Die Zurechnung ist komplex: CrowdStrike geht mit moderater Zuversicht davon aus, dass eine als Graceful Spider bezeichnete, Russland-verknüpfte Gruppe die Schwachstelle massenhaft ausnutzt, die bekanntermaßen gemeinsam mit Cl0p operiert. Zudem wurde bereits seit mindestens dem 9. August 2025 in freier Wildbahn exploitiert, und ein Proof-of-Concept-Exploit wurde von der Gruppe Scattered LAPSUS$ Hunters veröffentlicht. Mehrere Threat-Actor-Cluster teilten sich offenbar denselben Exploit – ein Muster, das forensische Attribution zunehmend erschwert.
Was das für die Forensik-Praxis bedeutet
Rechtsberater und Incident-Response-Teams sind sich einig, dass reines Patchen nicht ausreicht. Organisationen, die die Juli-2025-Patches nicht rechtzeitig eingespielt hatten, müssen eine umfassende DFIR-Untersuchung durchführen, um eine mögliche Kompromittierung zu identifizieren – einschließlich Hinweisen auf Backdoors, Webshells, Credential-Manipulation und Exfiltrationswerkzeuge. Konkret sollten Organisationen verifizieren, dass die Patches für CVE-2025-61882 und CVE-2025-61884 angewendet wurden, forensische Untersuchungen durchführen, um eine Kompromittierung während des Zero-Day-Fensters festzustellen, und Incident-Response-Pläne vorbereiten, die eine öffentliche Offenlegung durch die Angreifer berücksichtigen.
Der Fall zeigt exemplarisch, warum ERP-Systeme wie EBS ein besonders lukratives Ziel sind: Oracle EBS ist eine weit verbreitete ERP-Plattform, die Geschäftsdaten wie Kundendatensätze, HR-Dateien und Finanzinformationen verwaltet. Wer solche Systeme betreibt, sollte nicht erst auf die Erpressungsmail warten, sondern jetzt prüfen: Sind Logs aus Juli/August noch verfügbar? Gibt es Hinweise auf ungewöhnliche Passwort-Reset-Aktivitäten? Und ist die forensische Bereitschaft so aufgestellt, dass ein zwei Monate zurückliegendes, dateiloses RCE überhaupt rekonstruierbar wäre?
← Zurück zur Übersicht