Hacker verstecken das Khunt-Toolkit nach einer SQL-Injection-Attacke in einer Oracle-Datenbank

Forscher haben einen Angriff auf eine Oracle-Datenbank aufgedeckt, bei dem Hacker eine SQL-Injection-Schwachstelle nutzten, um ein Post-Exploitation-Toolkit direkt in der Datenbank zu installieren.

Der Vorfall zeigt, wie Angreifer eine anfällige öffentlich erreichbare Anwendung als Einstiegspunkt für einen tieferen Netzwerkzugriff nutzen können. Anstatt herkömmliche Malware-Dateien auf dem Server abzulegen, speicherte die Gruppe Java-Code in Oracle und verwendete ihn, um Befehle mit weitreichenden Windows-Berechtigungen auszuführen.

Huntress entdeckte die Aktivität am 27. Juli 2026, nachdem die Plattform Versuche zum Diebstahl von Anmeldedaten auf einem Server mit Oracle Database erkannt hatte.

SQL-Injection öffnete die Tür

Die Angreifer verschafften sich Berichten zufolge über einen anfälligen Suchendpunkt in einer internetzugänglichen Java-Anwendung, die auf Apache Tomcat gehostet wurde, Zugang.

Die Anwendung verfügte über eine Autovervollständigungsfunktion für Suchanfragen. Allerdings wurden eingegebene Daten nicht korrekt validiert. Dadurch konnten die Angreifer SQL-Befehle einschleusen und mit der zugrunde liegenden Oracle-Datenbank interagieren.

Huntress führte die bösartigen Anfragen auf die IP-Adresse 178.162.151[.]229 zurück.

SQL-Injection-Schwachstellen sind besonders gefährlich, wenn Anwendungen auf Datenbanken mit übermäßigen Berechtigungen zugreifen. In diesem Fall scheint das Datenbankkonto über ausreichende Rechte verfügt zu haben, um Java-Objekte innerhalb von Oracle zu erstellen und auszuführen.

Khunt-Toolkit wurde als Oracle-Java-Objekte gespeichert

Oracle Database enthält eine integrierte Java Virtual Machine. Außerdem unterstützt die Datenbank die Anweisung CREATE JAVA SOURCE, mit der Java-Quellcode als Datenbankschemaobjekt gespeichert und kompiliert werden kann.

Die Angreifer missbrauchten diese Funktion, um ein Toolkit namens Khunt direkt in der Oracle-Umgebung zu installieren. Dadurch mussten sie keine herkömmlichen ausführbaren Dateien auf dem Windows-Server ablegen, was den Angriff möglicherweise schwerer erkennbar machte.

Laut Huntress wurde diese Technik bislang nur selten bei realen Angriffen dokumentiert.

Das Toolkit bestand aus mehreren Java-Komponenten und PL/SQL-Wrappern, die für Post-Exploitation-Aktivitäten entwickelt wurden. Sie ermöglichten den Angreifern, Betriebssystembefehle auszuführen, Dateien zu durchsuchen, Anmeldedaten zu sammeln und komprimierte Archive zu entpacken.

Toolkit ermöglichte Befehlsausführung und Diebstahl von Anmeldedaten

Eine Komponente namens KhuntCmd startete cmd.exe und ermöglichte es den Angreifern, Windows-Befehle über SQL-Anweisungen auszuführen.

Die Angreifer nutzten sie, um den Befehl cmd.exe /c whoami auszuführen. Der Befehl bestätigte, dass über die Oracle-Datenbank gestartete Aktivitäten mit SYSTEM-Berechtigungen auf dem Windows-Server ausgeführt wurden.

Zu den weiteren Khunt-Komponenten gehörten:

• KhuntHash, das auf die interne Benutzertabelle von Oracle zugriff und Benutzernamen sowie Passwortdaten in eine Datei schrieb.
• KhuntFS und KhuntFS2, die das Durchsuchen, Lesen und Suchen von Dateien sowie die Überprüfung ihrer Größe ermöglichten.
• KhuntT, das als einfacher Test diente, um die Funktionsfähigkeit des Toolkits zu bestätigen.
• KhuntUnzip, das komprimierte Dateien entpackte.

Nachdem die Angreifer die Befehlsausführung erlangt hatten, nutzten sie PowerShell und integrierte Windows-Werkzeuge, um die Registry-Hives SAM, SECURITY und SYSTEM zu kopieren. Diese Dateien können Angreifern dabei helfen, Passwort-Hashes lokaler Windows-Konten wiederherzustellen.

Außerdem verwendeten sie tasklist /svc, um laufende Dienste zu identifizieren, und speicherten die Ergebnisse in einer Datei mit dem Namen khunttasks.txt.

Huntress erklärte, dass die Registry-Hives wahrscheinlich zum Auslesen von Anmeldedaten gesammelt wurden. Der Bericht bestätigte jedoch nicht, ob die Angreifer sie tatsächlich erfolgreich exfiltrieren konnten.

Angriff auf Oracle-Datenbank verdeutlicht Risiken übermäßiger Berechtigungen

Der Vorfall unterstreicht, warum öffentlich erreichbare Anwendungen nur Datenbankkonten mit den tatsächlich erforderlichen Berechtigungen verwenden sollten.

Unternehmen sollten sämtliche Benutzereingaben validieren und bereinigen, um das Risiko von SQL-Injection-Angriffen zu verringern. Außerdem sollten sie verhindern, dass Datenbankkonten von Anwendungen Java-Quellcode erstellen, unnötige gespeicherte Prozeduren ausführen oder administrative Aufgaben durchführen können.

Eine Einschränkung der Datenbankberechtigungen kann den Schaden begrenzen, selbst wenn ein Angreifer eine Möglichkeit findet, eine anfällige Anwendung auszunutzen.