Ein klassischer Angriffsweg mit unerwartetem Ausgang: Sicherheitsforscher von Huntress haben einen Vorfall dokumentiert, bei dem eine simple SQL-Injection-Schwachstelle am Ende zur vollständigen Kontrolle über einen Windows-Server führte. Ausgangspunkt war eine öffentlich erreichbare Webanwendung mit Oracle-Datenbank im Hintergrund, die Eingaben nicht ausreichend prüfte.

Am 27. Juli 2026 registrierte Huntress verdächtige Aktivitäten auf einem Server, der eine Oracle-Datenbank hostete. Die Angreifer hatten Kopien mehrerer Registry-Hives angefertigt – ein deutliches Zeichen für versuchten Datendiebstahl.

Wie die Angreifer erste Zugriffe erlangten

Die Analyse der Apache-Zugriffsprotokolle zeigte, wie die Täter vorgingen. Über ein Formularfeld einer Java/Tomcat-Anwendung, das SQL-Befehle ungeprüft durchreichte, verschafften sie sich Zugang zur dahinterliegenden Oracle-Datenbank. Die Menge an Anfragen an die verwundbare Schnittstelle erlaubte es den Forschern zudem, eine IP-Adresse als Ursprung der Angriffe zu identifizieren.

Bemerkenswert war jedoch der nächste Schritt. Statt die Datenbank lediglich auszulesen, luden die Angreifer ein komplettes Post-Exploitation-Toolkit namens "khunt" direkt in die Datenbank hoch. Möglich wurde das durch eine wenig beachtete Funktion: Oracle-Datenbanken verfügen über eine eingebettete Java Virtual Machine, mit deren Hilfe sich über den Befehl CREATE JAVA SOURCE Java-Code als Datenbankobjekt speichern und ausführen lässt.

khunt und seine Bestandteile

Das eingeschleuste Toolkit bestand aus mehreren spezialisierten Modulen. KhuntCmd etwa ermöglichte es, beliebige Betriebssystembefehle über cmd.exe auszuführen, während KhuntHash gezielt Benutzernamen und Passwörter aus internen Oracle-Tabellen extrahierte. Ergänzt wurde das Arsenal durch die Dateimanager KhuntFS und KhuntFS2, ein Verbindungstest-Tool namens KhuntT sowie ein Entpack-Werkzeug.

Mit KhuntCmd öffneten die Angreifer schließlich eine Windows-Kommandozeile und prüften per whoami ihre Rechte. Das Ergebnis: SYSTEM-Berechtigungen – der Sprung von der Datenbankebene auf das Betriebssystem war damit vollzogen. Anschließend kopierten sie über PowerShell und das Tool esentutl.exe mehrere Registry-Hives, aus denen sich Passwort-Hashes lokaler Konten auslesen lassen.

Klassische Schutzmechanismen versagen

Aus Sicht der IT-Sicherheit wirft der Fall ein grundsätzliches Problem auf. Wird eine Datenbank selbst zum Ausgangspunkt für Angriffe, greifen viele etablierte Schutzmechanismen ins Leere. Herkömmliche EDR- und Antivirenlösungen konzentrieren sich auf Prozesse und Dateien auf Betriebssystemebene, prüfen jedoch in der Regel keine Java-Klassen oder PL/SQL-Objekte innerhalb von Oracle-Systemen.

Huntress empfiehlt Unternehmen daher mehrere Gegenmaßnahmen. Dazu zählen eine saubere Eingabevalidierung sowie parametrisierte Datenbankabfragen, um SQL-Injection von vornherein zu verhindern. Ebenso wichtig sei eine restriktive Rechtevergabe: Datenbankkonten sollten selbst im Falle einer erfolgreichen Injection nicht in der Lage sein, eigene Java-Quellen zu erstellen oder gespeicherte Prozeduren auszuführen.

Der Fall zeigt damit vor allem eines: Auch Jahrzehnte nach ihrer Entdeckung bleibt SQL-Injection eine reale Bedrohung, wenn grundlegende Schutzmaßnahmen fehlen. Gleichzeitig macht der ungewöhnliche Einsatz der Java-Source-Funktion deutlich, dass Angreifer zunehmend Wege finden, sich innerhalb legitimer Systemfunktionen zu verstecken.