Oracle-SQL-Injection-Angriff ermöglicht Remote-Code-Ausführung

Trotz jahrzehntelanger Kenntnis bleibt SQL-Injection (SQLi) eine effektive Technik für Cyberkriminelle. 

Eine aktuelle Untersuchung von Huntress zeigt, wie sich ein scheinbar routinemäßiger SQL-Injection-Angriff durch den Missbrauch von Oracle-Datenbankfunktionen zu einer vollständigen Kompromittierung des Betriebssystems (OS) entwickelte. 

Wichtigste Erkenntnisse zum SQL-Injection-Angriff

• Eine SQL-Injection-Schwachstelle in einer öffentlich zugänglichen Java/Tomcat-Anwendung ermöglichte es Angreifern, zunächst Zugriff auf eine Oracle-Datenbank zu erlangen und schließlich eine Remote-Code-Ausführung auf dem zugrunde liegenden Windows-Server zu erreichen.
• Angreifer missbrauchten die Oracle-Funktion CREATE JAVA SOURCE, um das Toolkit khunt einzuschleusen. Dies zeigt, wie sich legitime Datenbankfunktionen zur Etablierung von Persistenz und zur Umgehung herkömmlicher Endpoint-Sicherheitstools missbrauchen lassen.
• Mit dem Toolkit khunt führten die Angreifer Betriebssystembefehle aus, stahlen Zugangsdaten aus Oracle und Windows und sammelten Registry-Hives zur möglichen Exfiltration und Rechteausweitung.
• Organisationen können das Risiko ähnlicher Angriffe durch die Kombination sicherer Programmierpraktiken, eines Datenbankzugriffs nach dem Prinzip der geringsten Rechte, einer erweiterten Oracle-Überwachung, regelmäßiger Penetrationstests und getesteter Pläne zur Reaktion auf Sicherheitsvorfälle reduzieren.

So begann der Oracle-SQL-Injection-Angriff 

Laut Huntress begann der Vorfall am 27. Juli 2026, als Sicherheitsanalysten Aktivitäten zum Diebstahl von Zugangsdaten auf einem Windows-Endpunkt erkannten, der einen Oracle-Datenbankserver beherbergte. 

Die Untersuchung ergab, dass eine öffentlich zugängliche Java/Tomcat-Anwendung Benutzereingaben nicht ordnungsgemäß validierte, sodass Angreifer schädliche SQL-Befehle einschleusen konnten. 

Die anfällige Anwendung leitete diese Befehle über eine Java-Database-Connectivity-(JDBC-)Verbindung direkt an die Oracle-Datenbank weiter und verschaffte den Angreifern damit einen ersten Zugriffspunkt.

So setzten Angreifer das Toolkit mit Oracle Java ein 

Bemerkenswert an diesem Angriff war die Methode, die nach der anfänglichen Kompromittierung zum Einsatz kam. 

Statt Malware direkt im Betriebssystem einzusetzen, luden die Angreifer ein datenbankbasiertes Toolkit namens khunt mithilfe der Oracle-Funktion CREATE JAVA SOURCE hoch. 

Oracle-Datenbanken enthalten eine eingebettete Java Virtual Machine (JVM), die es Entwicklern ermöglicht, Java-Code als Datenbankobjekte zu speichern.

In diesem Fall missbrauchten die Angreifer diese legitime Funktion, um schädlichen Java-Code direkt in der Datenbank zu kompilieren und auszuführen. Dadurch entstand ein unauffälliger Persistenzmechanismus, den herkömmliche Endpoint-Sicherheitstools möglicherweise übersehen.

Das Toolkit bestand aus mehreren spezialisierten Modulen, die die Fähigkeiten der Angreifer erweiterten. 

KhuntCmd ermöglichte die Ausführung beliebiger Windows-Betriebssystembefehle über SQL-Anweisungen. 

KhuntHash extrahierte Oracle-Benutzernamen und -Passwortinformationen in eine Datei, während KhuntFS und KhuntFS2 Funktionen zum Durchsuchen, Lesen und Suchen von Dateien bereitstellten. 

Zu den weiteren Komponenten gehörten KhuntT, das die ordnungsgemäße Funktionsweise des Toolkits überprüfte, und KhuntUnzip zum Entpacken komprimierter Dateien. 

Diese Module verwandelten die Oracle-Datenbank effektiv in eine Plattform für die Post-Exploitation, die direkt mit dem zugrunde liegenden Betriebssystem interagieren konnte.

So ermöglichte das Khunt-Toolkit Remote-Code-Ausführung (RCE) und den Diebstahl von Zugangsdaten 

Das Toolkit khunt ermöglichte es den Angreifern, die Lücke zwischen der Oracle-Datenbank und dem zugrunde liegenden Windows-Betriebssystem zu überbrücken. 

Über sein Modul KhuntCmd ermöglichte das Toolkit den Angreifern, beliebige OS-Befehle auszuführen, indem sie SQL-Anweisungen an die Datenbank sendeten. Dadurch wurde die Datenbank effektiv zu einer Plattform für Remote-Code-Ausführung.

Nach der Bereitstellung des Toolkits nutzten die Angreifer KhuntCmd, um den Befehl whoami auszuführen, und bestätigten, dass sie über Berechtigungen auf SYSTEM-Ebene verfügten. Dies belegte die erfolgreiche Remote-Code-Ausführung von der Oracle-Datenbank auf das Windows-Betriebssystem. 

Anschließend nutzten sie PowerShell und Windows-Dienstprogramme, um die Registry-Hives SAM, SYSTEM und SECURITY zu kopieren. Diese enthalten Passwort-Hashes, die zum Diebstahl von Zugangsdaten oder zur Rechteausweitung extrahiert werden können. 

Bevor sie die Daten für eine mögliche Exfiltration vorbereiteten, ermittelten die Angreifer außerdem mithilfe von tasklist /svc die laufenden Dienste.

So lässt sich das Risiko von SQL-Injection-Angriffen reduzieren

Die Untersuchung von Huntress zeigt, dass selbst jahrzehntealte Angriffstechniken verheerende Folgen haben können, wenn grundlegende Sicherheitskontrollen vernachlässigt werden.

In diesem Fall ermöglichte eine SQL-Injection-Schwachstelle den Angreifern, die Datenbank zu verlassen und durch den Missbrauch legitimer Oracle-Funktionen eine Remote-Code-Ausführung zu erreichen. 

Organisationen können das Risiko ähnlicher Angriffe durch mehrschichtige Sicherheitskontrollen reduzieren, die Prävention, Erkennung und Reaktion in ihren Oracle-Umgebungen stärken. 

• Implementieren Sie parametrisierte Abfragen und eine ordnungsgemäße Eingabevalidierung zum Schutz vor SQL-Injection-Schwachstellen, bevor diese ausgenutzt werden können.
• Setzen Sie das Prinzip der geringsten Rechte durch, indem Sie die Möglichkeiten von Datenbankkonten zum Erstellen von Java-Quellobjekten, Ausführen gespeicherter Prozeduren oder Durchführen administrativer Aktionen einschränken.
• Erweitern Sie die Überwachung über die Endpoint-Erkennung hinaus, indem Sie Oracle-Datenbankobjekte und SQL-Protokolle überprüfen und nach unerwarteter Erstellung von Java-Quellcode als Anzeichen für bösartige Aktivitäten suchen.
• Durchsuchen Sie Oracle-Umgebungen regelmäßig nach bekannten Kompromittierungsindikatoren, darunter verdächtige Java-Objekte, KHUNT%-Einträge in SQL-Protokollen und von Angreifern erstellte Registry-Hive-Artefakte.
• Härten Sie Oracle- und Anwendungsumgebungen, indem Sie unnötige Datenbankfunktionen einschränken, Datenbankzugangsdaten schützen und Datenbankserver von öffentlich zugänglichen Anwendungen segmentieren.
• Integrieren Sie Penetrationstest-Bewertungen in den Softwareentwicklungslebenszyklus, um Schwachstellen vor der Bereitstellung zu identifizieren.
• Testen Sie Pläne zur Reaktion auf Sicherheitsvorfälle und verwenden Sie Tools zur Angriffssimulation mit Szenarien rund um SQL-Injection-Angriffe und RCE.

In ihrer Gesamtheit können diese Maßnahmen Organisationen dabei helfen, ihre gesamte Angriffsfläche zu reduzieren, die Auswirkungen erfolgreicher Kompromittierungen zu begrenzen und langfristige Resilienz aufzubauen. 

Fazit

Das strategische Risiko liegt nicht allein in der SQL-Injection – entscheidend ist, was danach geschieht. 

Sobald die Angreifer einen Zugriffspunkt etabliert hatten, verwandelten sie die Oracle-Datenbank in eine Ausführungsplattform, die RCE ermöglichte und dabei weitgehend außerhalb des Bereichs der herkömmlichen Endpoint-Überwachung blieb. 

Da Angreifer weiterhin legitime Plattformfunktionen mit etablierten Angriffstechniken kombinieren, sollten Sicherheitsverantwortliche neu bewerten, ob ihre Erkennungsstrategie ausreichende Transparenz hinsichtlich datenbankbasierter Bedrohungen bietet – und nicht nur hinsichtlich der Aktivitäten im Betriebssystem. 

Vorfälle wie dieser unterstreichen auch den Wert einer Zero-Trust-Architektur, die darauf ausgelegt ist, implizites Vertrauen zu begrenzen und die Auswirkungen einer erfolgreichen Kompromittierung einzudämmen.