khunt Toolkit Turns Oracle SQL Injection Into Windows SYSTEM Access

Huntress researchers have detailed a stealthy intrusion in which attackers exploited a SQL injection flaw in a public-facing web application to install a post-exploitation toolkit called khunt directly inside an Oracle database, ultimately achieving SYSTEM-level code execution on the underlying Windows server. The breach was uncovered on July 27, 2026, after credential-theft detections fired, and the investigation traced the chain back to an autocomplete search field that passed unvalidated input over a Java Database Connectivity (JDBC) connection. The Oracle account behind that connection held enough privilege to create Java objects, and no Oracle patch addresses either the application flaw or the over-permissioned account.

The attackers leveraged Oracle's embedded Java Virtual Machine and the CREATE JAVA SOURCE statement, feeding Java source code into the database, letting Oracle compile it into stored schema objects, and executing operating system commands from inside the database engine. Six Java classes formed the toolkit: KhuntCmd loaded cmd.exe and ran arbitrary commands passed in as SQL, KhuntHash dumped usernames and password hashes from Oracle's internal user table, KhuntFS and KhuntFS2 handled file listing, reading, searching, and sizing, KhuntT confirmed reachability, and KhuntUnzip extracted archives. Running `cmd.exe /c whoami` through KhuntCmd returned SYSTEM, after which the attackers used PowerShell and reg.exe to copy the SECURITY, SYSTEM, and SAM registry hives into F:\Oracle, alongside tasklist output written to khunttasks.txt.

Because a Java class compiled into a database schema object is not a process, binary, or filesystem file, endpoint detection and response products do not generally inspect Oracle internals, making detection difficult. Huntress recommends hunting for object names beginning with "Khunt" inside the Oracle installation and scanning SQL logs for queries matching `KHUNT%`. The technique itself is not new, mirroring Marco Ivaldi's 2006 raptor_oraexec.sql, but Huntress noted that real-world use has rarely been documented until now. Defenders concerned about exposed database services should run a quick port scanner to verify what is reachable from the internet, while users whose credentials may have been harvested in similar intrusions can check exposure with the password checker and the email breach checker.

The case highlights how database servers can shift from passive data stores to active beachheads for lateral movement. With only the CREATE PROCEDURE system privilege required in the attacker's own schema, plus Oracle's file-execution permission for Runtime.exec, the threat model extends far beyond query injection. Security teams should audit Oracle account privileges, lock down the ability to create Java schema objects, and segment database servers from the rest of the network to prevent a single SQL injection flaw from escalating to full operating-system compromise.