„Khunt“-Angriff: Wie Hacker eine Oracle-Datenbank in eine Angriffsplattform verwandelten

Die Angriffskette: Von der Autovervollständigung zur Datenbank-Übernahme

Der erste Zugang erfolgte über eine SQL-Injection-Schwachstelle in einer öffentlich zugänglichen Java-Anwendung auf Apache Tomcat . Eine Autocomplete-Suchfunktion der Anwendung filterte Benutzereingaben nicht ausreichend, sodass die Angreifer über eine JDBC-Verbindung eigene SQL-Befehle in die Oracle-Datenbank einschleusen konnten . Wie die Forscher von Huntress betonen: SQL-Injection ist keine neue Angriffsform – sie passiert, wenn Eingaben, die an den SQL-Server gehen, nicht ordnungsgemäß bereinigt werden .

Das Khunt-Toolkit – Unsichtbar in der Datenbank

Die Angreifer setzten kein einziges Schadprogramm auf die Festplatte. Stattdessen nutzten sie Oracles JVM und speicherten das Toolkit als Java-Schema-Objekte in der Datenbank . Dadurch blieb es für Betriebssystem-Ebene unsichtbar, da EDR- und AV-Tools Java-Klassen und PL/SQL-Wrapper in Oracle nicht überprüfen .

Das Toolkit bestand aus folgenden Komponenten, die jeweils als Datenbankobjekt abgelegt waren:

Vom Datenbanksystem zur Windows-Vollkontrolle

Die Angreifer beschränkten sich nicht auf die Datenbank. Über das Toolkit gelangten sie in mehreren Schritten zur vollständigen Kontrolle über den Windows-Server :

1. Betriebssystembefehle ausführen: Mit KhuntCmd starteten sie cmd.exe /c whoami und stellten fest, dass sie mit SYSTEM-Rechten arbeiteten – der höchsten Berechtigungsstufe unter Windows .
2. Passwort-Hashes extrahieren: Per PowerShell riefen sie reg.exe auf und kopierten die Registry-Hives „SECURITY“ und „SYSTEM“ in die Dateien khuntSECURITY.hiv und khuntSYSTEM.hiv im Verzeichnis F:\Oracle\ .
3. Dienste auslesen: Sie ließen tasklist /svc laufen und speicherten die Ausgabe in khunttasks.txt .
4. Weitere Hives kopieren: Mit esentutl.exe kopierten sie die SAM- sowie eine zweite Kopie der SECURITY-Hives und speicherten sie als khuntSAM.hiv und khunt_SECURITY.hiv .

Die erbeuteten Registry-Hives können offline genutzt werden, um die Passwort-Hashes aller lokalen Konten zu extrahieren und zu entschlüsseln .

Gefährliche Blindstellen in der Unternehmenssicherheit

Huntress‘ Untersuchung offenbarte mehrere kritische Sicherheitslücken, die diesen Angriff ermöglichten :

• Datenbank als Angriffsplattform: Die Datenbank wurde von einem passiven Datenspeicher in eine aktive Angriffsplattform verwandelt, wobei die Schadsoftware in der Datenbank und nicht auf der Festplatte oder im Arbeitsspeicher lebte .
• EDR/AV-Umgehung: Herkömmliche EDR- und Antiviren-Tools überprüfen Java-Klassen und PL/SQL-Wrapper in Oracle nicht – das Toolkit blieb unsichtbar .
• Altbekannte Schwachstelle, neuartige Ausnutzung: Die SQL-Injection war keine Zero-Day-Lücke. Die Autocomplete-Funktion genügte, um über PL/SQL zum Betriebssystem zu gelangen. Basis-Fehler bei der Eingabevalidierung können zu tiefgreifenden Kompromittierungen führen, wenn die Datenbank-Engine über Betriebssystem-Funktionen verfügt .
• Überdimensionierte Datenbankkonten: Selbst wenn eine SQL-Injection gelingt, bleibt der Schaden begrenzt, wenn das Datenbankkonto nicht über die Berechtigungen zum Erstellen von Java-Quellen oder zum Ausführen von gespeicherten Prozeduren verfügt. Viele Organisationen gewähren ihren Datenbankkonten zu viele Rechte – die Angreifer nutzten dies aus, um Khunt zu installieren .

Schutzmaßnahmen: Empfehlungen von Huntress

Huntress empfiehlt aufgrund dieses Vorfalls :

• Gründliche Eingabevalidierung und Verwendung von parametrisierten Abfragen für alle Webeingaben
• Einschränkung der Datenbank-Benutzerrechte, sodass injizierte Abfragen keine Java-Quellen erstellen oder beliebige gespeicherte Prozeduren ausführen können
• Erweiterung der Überwachung auf Datenbankobjekte (Java-Klassen, PL/SQL-Wrapper) und nicht nur auf Betriebssystem-Ebene

Dieser Angriff ist eine eindringliche Erinnerung daran, dass Datenbank-Engines mit eingebauten Programmierumgebungen (wie Oracles JVM) zu heimtückischen Angriffsplattformen werden können – selbst durch eine einzige ungeprüfte Eingabe von außen. Sicherheitsteams müssen ihren Fokus über das Betriebssystem hinaus auf die Datenbank-Objektebene ausdehnen.