Attackers are increasingly turning database features into launchpads. In a recent case, the path started with Oracle SQLi to SYSTEM access: a SQL injection weakness in a public-facing application enabled the intruders to feed Java source code into Oracle. Oracle compiled that code into stored schema objects, and the attackers then triggered operating-system actions from within the database engine—ending with Windows-level SYSTEM code execution.
Security researchers at Huntress, who track the toolkit as khunt, connected the activity to suspicious credential events detected on July 27, 2026. From there, they traced the chain from SQL injection to privilege and ultimately to SYSTEM on the underlying Windows server.
The entry point: unvalidated search input over JDBC
The weakness resided in the application, not in Oracle itself. Specifically, an autocomplete search field passed user-controlled data to the database without proper validation. That input travelled over a Java Database Connectivity (JDBC) connection.
The database account used by the application had enough permissions to create Java objects. That matters because it turned a typical injection scenario into a code-injection-and-execution scenario inside the database.
Why this goes beyond “querying the database”
A key detail is how the attackers worked. They did not drop an executable to disk. Instead, they fed Java source code to Oracle and relied on Oracle’s ability to compile and store that code as schema objects.
From an endpoint or traditional detection point of view, this can look different from the usual pattern of spawning a process from a file. As Huntress frames it, the database stops being just a place attackers query and becomes a beachhead they can actively use to attack the host.
How Oracle’s embedded Java enables stored execution
Oracle ships an embedded Java Virtual Machine. With the right database permissions, an account can use statements that allow users to submit Java source code. Oracle then compiles and stores that code as objects within a schema.
In documentation discussed by Huntress, the permission level required in a user’s own schema is described as low enough that a single system privilege can allow creating Java source objects. Huntress notes that, at least in one documented path, the barrier is framed as CREATE PROCEDURE in a user’s schema context.
Once compiled Java exists in the database, the logic can call Java APIs that ultimately invoke operating-system commands via mechanisms like Runtime.exec. That execution still depends on additional file-execution permissions under the covers, and Huntress points out that only privileged administrators should normally be granted those.
However, the attack succeeded, implying that the compromised database account chain had sufficient privileges for both phases: creating the Java objects and enabling the host-level execution they needed.
The hunt: spotting khunt objects and Oracle schema artifacts
Huntress emphasizes that finding the toolkit requires hunting, not just scanning the Windows filesystem for binaries. A Java class compiled into a database schema object is not a process, a standalone executable, or a normal file artifact.
Huntress provides a practical starting point:
- Search the Oracle installation for object names beginning with Khunt.
- Search SQL logs for patterns like KHUNT%.
Important limitation: the indicators Huntress describes are tied to this specific toolkit. That means searching only for “khunt” style names may not reveal other intrusions that use the same general architecture but different object naming.
What the khunt toolkit did
The toolkit consisted of multiple Java objects and wrapper routines in PL/SQL. Huntress observed six Java objects and several khunt_* PL/SQL wrappers forming a set of capabilities.
- KhuntCmd: loads cmd.exe and runs operating-system commands passed in as SQL.
- KhuntHash: reads usernames and password hashes from Oracle’s internal user table and writes them out to a file.
- KhuntFS and KhuntFS2: provide file system actions such as listing, reading, searching, and sizing files.
- KhuntT: checks that the toolkit is reachable.
- KhuntUnzip: unpacks archives.
From cmd.exe to Windows SYSTEM
The crucial pivot point reported by Huntress was that commands executed through the toolkit returned SYSTEM when running cmd.exe /c whoami via KhuntCmd.
After establishing SYSTEM-level capability, the attackers moved into typical post-exploitation actions. Huntress observed the use of tools and commands such as:
- PowerShell and reg.exe to copy the SECURITY and SYSTEM registry hives to a directory under F:Oracle.
- tasklist /svc writing results to a file (noted as khunttasks.txt).
- Copying the SAM and SECURITY hives using esentutl.exe.
Huntress saw files being staged locally, but did not confirm whether they were exfiltrated in this observed sequence.
The missing patch story: application flaw plus privilege risk
A common question after incidents like this is whether “there’s a patch for Oracle.” In this case, Huntress indicates that no Oracle patch addresses both sides of the issue.
The application flaw must be fixed: the injection vector remains in the public-facing code path. But the second half is also critical: the database account behind the JDBC connection must not hold privileges that allow creating and using Java sources and stored execution paths it doesn’t require.
In other words, the remedy is not only technical hardening in Oracle—it also involves reducing what the application account can do.
Least privilege that actually blocks the chain
Huntress’ recommendations align with a core principle: least privilege. An account serving a public-facing application should not be able to create Java sources or run stored procedures that fall outside its normal responsibilities.
If that account cannot create the Java objects (or cannot support the host-level execution path), then even a SQL injection vulnerability has a smaller blast radius. The attackers in this case reportedly had enough privileges for both creation and execution steps.
How old the technique is
This approach is not new. Huntress notes that similar methodology has existed for at least two decades. An earlier example mentioned by Huntress is Marco Ivaldi’s raptor_oraexec.sql from 2006, which creates an Oracle source object that provides command-execution and file-read methods, then exposes it through PL/SQL wrappers.
Huntress observed that khunt follows a comparable underlying architecture. The main change is packaging and naming: “use in the wild” appears less frequently documented, which can delay detection by defenders who only look for more conventional SQL injection outcomes.
Practical prevention: parameterized queries and input validation
The most direct defense is straightforward but essential. The application should use parameterized queries and ensure input validation on user-controlled fields such as autocomplete search.
Even with strong Oracle configuration, injection should not be possible. And if something does slip through, least-privilege database permissions should prevent attackers from turning SQL injection into stored code compilation and command execution.
Conclusion: treat the Oracle engine as an attack surface
This incident illustrates a brutal reality for defenders: the database is not just a data store. With the right combination of SQL injection weaknesses, permissive JDBC account privileges, and Oracle’s embedded Java capabilities, attackers achieved Oracle SQLi to SYSTEM access without dropping a classic executable to disk.
To reduce risk, fix the injection point with parameterization and validation, and tighten database privileges so the application account cannot create stored Java objects or execute procedures it has no reason to use. For detection, don’t rely only on endpoint process telemetry—hunt for database object names and SQL log patterns tied to stored compilation behavior.
Source: https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html
