khunt: SQL Injection in Oracle leads to SYSTEM access

khunt , a post-exploitation toolkit installed inside an Oracle database , was used by attackers to gain SYSTEM-level access to a Windows server by exploiting a critical SQL injection vulnerability . Cybersecurity firm Huntress uncovered the attack after credential theft alerts were detected on July 27, 2026 , discovering an attack chain that turned the database from a target into a springboard. The unique feature of the attack was that the attackers did not write any executable files to disk, making detection extremely difficult.

See also: SourceCodester Class Timetabling: SQL Injection vulnerability CVE-2026-14770

The attack was triggered by an SQL injection in a publicly accessible autocomplete field of a Java running on Apache Tomcat. The application did not properly validate user input, allowing attackers to inject malicious SQL code that was passed to the database over a Java Database Connectivity (JDBC). The account using this connection had sufficient privileges to create Java objects within the database, which proved to be devastating.

Oracle has a built-in Java Virtual Machine (JVM), and the CREATE JAVA SOURCE allows a user to submit Java code that the database compiles and stores as a schema object. In a custom schema, Oracle's documentation specifies the CREATE PROCEDURE. Executing operating system processes from this code is done via Runtime.exec, which requires a separate file execution permission. Huntress did not disclose exactly what privileges the compromised account had, but the success of the attack chain suggests it had enough for all stages.

How khunt works within Oracle

khunt consists of six Java objects and several PL/SQL wrappers with the prefix khunt_*. Each component performs a specific function: KhuntCmd loaded cmd.exe and executed arbitrary operating system commands passed as SQL. KhuntHash read usernames and hashed passwords from Oracle's internal user table and wrote them to a file. KhuntFS and KhuntFS2 provided cataloging, reading, searching, and file size measurement functions. KhuntT verified that the toolkit was accessible, while KhuntUnzip decompressed files.

Running the cmd.exe /c whoami command through KhuntCmd returned SYSTEM, confirming that the attackers had gained the highest possible privileges on the Windows server. They then used PowerShell and reg.exe to copy the SECURITY and SYSTEM to the F:\Oracle directory, ran tasklist /svc saving the results to a khunttasks.txt file, and copied the SAM and SECURITY with the esentutl.exe. These registry hives contain encrypted local account credentials and other sensitive secrets that can be used for lateral movement.

This technique is not new — Marco Ivaldi published raptor_oraexec.sql back in 2006, which creates Oracle source objects with methods for executing commands and reading files. The khunt use the same basic architecture. What makes the case remarkable, as Huntress, is that the technique’s use in practice has rarely been documented.

See also: Oracle July Patch Update: 1,449 fixes and 10 critical security vulnerabilities

Why khunt is difficult to detect

A Java object compiled into a database schema is not a process, binary, or file in the file system. Endpoint Detection and Response (EDR) products generally do not inspect Oracle internals , leaving khunt invisible to traditional security tools. As Huntress puts it , the database ceases to be something that attackers simply query and becomes a bridgehead from which to attack. This shift in perception is critical for defenders.

Huntress noted that the files were staged locally, but was unable to confirm whether they were exported. The company did not name a specific threat actor, but said the malicious requests originated from the IP address 178.162.151[.]229 . There is no patch from Oracle to address either the application vulnerability or the account privilege escalation issue — the root of the problem lies in the application configuration and code, not a specific Oracle CVE

To detect khunt, Huntress recommends searching your Oracle installation for object names that start with Khunt, as well as SQL logs for KHUNT% patterns. However, these indicators are specific to this toolkit — a more general search will not reveal similar techniques that use different object names.

How to protect yourself from khunt attacks

The primary defense is to use parameterized queries and input validation throughout the application, especially in search and autocomplete fields. At the same time, the principle of least privilege should be strictly enforced: an account serving a public application should not have the ability to create Java objects or execute stored procedures that it does not need. Disabling or severely restricting Oracle and host command execution paths, unless explicitly necessary, significantly reduces the attack surface.

Additionally, organizations should monitor for suspicious Java object creation in Oracle and unusual compilation activity within the database, especially following SQL errors or credential alerts. Monitoring for operating system command pointers — such as cmd.exe usage , PowerShell , and access to the SAM , SECURITY , or SYSTEM hives by database-related processes — is also critical. Finally, correlating database audit logs with web logs can reveal attack chains that would otherwise remain invisible.

See also: Critical vulnerability discovered in Windows Common File System

The khuntis a reminder that fileless does not mean low-impact. The toolkit lived as database objects, but allowed command execution, access to credentials, and file operations on the Windows host. The attack highlights that database security cannot be treated in isolation from application security and permissions management — all three aspects must be treated as a single defense system.