Eine Oracle SQL-Injection ist in vielen Umgebungen bereits seit Jahren ein Begriff. Aktuell zeigt ein beobachteter Angriff jedoch eindrucksvoll, wie weit sich eine Web-Schwachstelle in Richtung Systemrechte entwickeln kann: Aus einer unsauberen Eingabeverarbeitung wurde ein Kettenangriff, der letztlich Windows SYSTEM ausführbar machte – nicht über eine klassische Binärdatei auf dem Server, sondern über das Innenleben von Oracle selbst.
Im Mittelpunkt steht ein Post-Exploitation-Toolkit, das unter dem Namen khunt verfolgt wird. Ermittler fanden nach ersten Warnmeldungen zu abhandengekommenen Zugangsdaten eine Linie zurück bis zu gespeicherten Java-Objekten in Oracle und deren Fähigkeit, OS-Kommandos auszuführen.
Von der Webanwendung zur Oracle-Datenbank
Die Angreifer verschafften sich Zugang über eine SQL-Injection-Schwachstelle in einer öffentlich zugänglichen Webapplikation. Konkret spielte dabei eine Autocomplete-Suchfunktion eine Rolle, die unvalidierte Eingaben an die Datenbank weiterleitete. Für die Kommunikation wurde dabei eine JDBC-Verbindung genutzt.
Entscheidend war außerdem, dass das Datenbankkonto hinter der JDBC-Verbindung über genügend Rechte verfügte, um Java-Objekte in Oracle zu erstellen. Damit war die Voraussetzung geschaffen, schädlichen Java-Quellcode in der Datenbank abzulegen und von dort aus weiterzuarbeiten.
khunt: Post-Exploitation ohne klassische Dateien
Das Toolkit zielte darauf ab, nach der Kompromittierung nicht zwingend eine ausführbare Datei auf dem Dateisystem zu schreiben. Stattdessen wurde Java-Quellcode an die Datenbank übergeben, die ihn zu gespeicherten Schemaobjekten kompilierte. Anschließend konnten Befehle aus dem Datenbank-Engine-Kontext heraus angestoßen werden.
Damit verändert sich die Perspektive: Die Datenbank wird weniger zum Ziel, das “nur” abgefragt wird, sondern zum Angriffspunkt (beziehungsweise “Beachhead”), von dem aus sich weitere Aktionen anstoßen lassen. Genau an dieser Stelle wird das Risiko für Endpoint-Detection und Response-Teams besonders greifbar: Viele Produkte schauen primär auf Prozesse, Binärdateien oder Dateisystemzugriffe, während die eigentliche Ausführung hier innerhalb der Oracle-Interna vorbereitet und gestartet werden konnte.
Warum Oracle hier überhaupt mitspielt
Oracle liefert eine eingebettete Java Virtual Machine mit. Über einen Befehl wie CREATE JAVA SOURCE kann ein Nutzer Java-Code in Oracle als Schemaobjekt ablegen. Die Datenbank kompiliert diesen Code dann intern und macht ihn verfügbar.
In einem “eigenen” Schema gilt laut Oracle-Dokumentation als Schwelle zumindest eine Systemberechtigung, die in der Quelle als CREATE PROCEDURE beschrieben wird. Für das direkte Spawnen eines Betriebssystemprozesses wird zusätzlich ein Mechanismus benötigt, der unter anderem über Runtime.exec läuft. Solche Dateiausführungsrechte sollen laut Oracle nur durch privilegierte Administratoren erteilt werden.
Damit bleibt eine zentrale Frage: Welche konkreten Grants hatte das kompromittierte Konto? Die beobachtete Kette funktionierte, daher müssen für den Ablauf zumindest die erforderlichen Rechte vorhanden gewesen sein – entweder direkt beim Konto oder durch ergänzende Voraussetzungen.
Hunting-Ansatz: Welche Spuren man suchen sollte
Da keine klassische ausführbare Datei zwingend benötigt wird, reicht “nur” ein Dateisuche- oder Prozess-Check häufig nicht aus. Die Ermittlergruppe, die khunt als Toolkit verfolgt, beschreibt deshalb einen Suchplan mit zwei Hauptachsen:
- Oracle-Installation nach Objekt-/Namensmustern durchsuchen: Gesucht werden Objektbezeichnungen, die mit Khunt beginnen.
- SQL-Logs nach Pattern filtern: Erwartet werden Einträge, die mit KHUNT% zusammenhängen.
Wichtig: Die Quelle betont, dass die Indikatoren spezifisch zum beobachteten Toolkit sind. Wer ausschließlich nach “Khunt” oder “KHUNT%” sucht, findet zwar diese konkrete Kampagne, aber nicht unbedingt jede Variante der Technik.
Werkzeugkasten in Bausteinen: Was die khunt-Objekte konnten
Das beobachtete Toolkit bestand aus mehreren Java-Objekten sowie mehreren khunt_*-Prozedur-Wrappern in PL/SQL. Die Funktionen waren dabei klar auf typische Post-Exploitation-Aufgaben ausgerichtet:
- KhuntCmd: lädt cmd.exe und führt beliebige Betriebssystemkommandos aus, die über SQL übergeben werden.
- KhuntHash: liest Benutzernamen und Passwort-Hashes aus einer internen Oracle-Nutzertabelle und schreibt die Informationen in eine Datei.
- KhuntFS und KhuntFS2: Listen, Lesen, Suchen und Größenbestimmung von Dateien.
- KhuntT: prüft, ob das Toolkit erreichbar ist.
- KhuntUnzip: entpackt Archive.
Diese Aufteilung ist für Verteidiger hilfreich: Je nach Logging-Tiefe können einzelne Schritte in Oracle-Objektdefinitionen, kompilierten Java-Quellcodes und SQL-Ausführungsprotokollen sichtbar werden.
Vom Kommandoschritt zum SYSTEM-Zugriff auf Windows
Der entscheidende Beweis in der beobachteten Kette: Das Ausführen von cmd.exe /c whoami über KhuntCmd lieferte als Ergebnis SYSTEM. Damit war klar, dass die Ausführung nicht nur auf Anwendungsebene stattfand, sondern mit höchsten lokalen Rechten auf dem Windows-Server.
Im Anschluss nutzten die Angreifer weitere Windows-Tools, um Daten für Credential-Dumping und Eskalationszwecke zu sichern. Dazu gehörten unter anderem PowerShell und reg.exe, um Registrierungs-Hives zu kopieren. Ebenso kam tasklist /svc zum Einsatz, um Dienstinformationen zu protokollieren. Für Kopien der relevanten Hives wurde zudem esentutl.exe verwendet.
Die Quelle beschreibt, dass die Dateien lokal “gestaged” wurden. Ein eindeutiges Exfiltrationssignal wird in den beschriebenen Ergebnissen jedoch nicht belegt.
Was das für Defense & Patch-Strategien bedeutet
Ein zentraler Punkt: Für diesen Ablauf reicht ein klassisches Patchen allein vermutlich nicht aus. Laut den Ermittlern gibt es nämlich keinen Oracle-Patch, der sowohl die Schwachstelle in der Anwendung als auch die dahinterliegende Rechtevergabe im Datenbankkontext schließt.
Stattdessen braucht es Maßnahmen in zwei Richtungen:
- Application Hardening: Verwenden von parameterisierten Queries und konsequente Input Validation an der Stelle, an der die Webeingabe an die Datenbank übergeben wird.
- Least Privilege in der Datenbank: Das Konto, das eine öffentlich erreichbare Anwendung bedient, sollte keine Berechtigungen erhalten, die es “für den Normalbetrieb” nicht benötigt. Insbesondere sollte es nicht ohne Not Java-Quellen erstellen oder Prozeduren ausführen dürfen, die es nicht tangieren muss.
Dieser Mix reduziert die Wahrscheinlichkeit, dass aus einer SQL-Injection überhaupt eine Java-basierte Post-Exploitation-Schiene wird.
Ist das neu? Eher nein – aber die Dokumentation ist es
Die in der Quelle beschriebene Technik ist nicht erst seit kurzem im Umlauf. Sie gilt als mindestens zwei Jahrzehnte alt. Bereits 2006 existiert ein Beispiel, das unter dem Namen raptor_oraexec.sql dokumentiert ist. Dort werden Oracle-Quellobjekte mit Methoden zum Kommandofeuer und Datei-Read erstellt, die dann über PL/SQL-Wrapper in SQL verfügbar gemacht werden.
Was Ermittler hervorheben: Die “Nutzung in freier Wildbahn” wurde bislang selten so detailliert dokumentiert. In der aktuellen Beobachtung trifft genau das zusammen: eine reale Angriffskette aus einer Web-Schwachstelle, die bis in die SYSTEM-Ebene hineinreicht.
Fazit: Oracle SQL-Injection ernst nehmen – ganzheitlich
Die Kernaussage ist klar: Eine Oracle SQL-Injection ist nicht nur ein Problem für die Datenbank, sondern kann – wenn Rechte und Schnittstellen ungünstig sind – zum Sprungbrett für OS-Kommandos werden. Genau deshalb sollten Teams nicht nur nach bekannten Payload-Namen fahnden, sondern auch prüfen, ob Logging, Rechtevergabe und Eingabevalidierung wirklich die “richtigen” Barrieren bilden.
Wer jetzt handelt, reduziert das Risiko doppelt: in der Anwendung durch sichere Query-Strategien und in der Datenbank durch Least Privilege. So wird aus einer einmaligen Eingabe-Schwäche keine komplette Eskalationskette.
Quelle: https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html
