Attackers Compile 'khunt' Java Toolkit Inside Oracle DB to Gain Windows SYSTEM Access

An intrusion investigated by Huntress highlights how threat actors can leverage a web application SQL injection vulnerability to achieve full Windows SYSTEM compromise without dropping binary executables onto the target filesystem. By feeding Java source code directly through an unvalidated input field in a public-facing application, attackers instructed an Oracle Database engine to compile a post-exploitation toolkit directly into stored schema objects, turning the database itself into an execution environment.

Huntress began investigating the incident after credential-theft detections fired on July 27, 2026. Security analysts traced the activity back to an autocomplete search feature in a web application that communicated with an underlying Oracle Database instance over Java Database Connectivity (JDBC). The database account bound to this JDBC connection held excessive privileges, enabling the attackers to escalate from SQL injection to command execution on the host server.

How Oracle’s Embedded JVM Enables Fileless Execution

The core mechanism relies on Oracle Database’s embedded Java Virtual Machine (JVM), an architecture designed to execute Java code directly within database sessions. When a web application contains a SQL injection flaw, an attacker can pass arbitrary SQL statements to the database engine. By issuing CREATE JAVA SOURCE statements, the attacker hands raw Java source code to the database, which Oracle compiles internally and stores as schema objects.

Because these compiled Java classes reside inside Oracle’s internal schema dictionary tables rather than as standalone files on the disk, traditional endpoint detection and response (EDR) solutions typically fail to inspect or flag them. To the host operating system and EDR agents, no suspicious binary has been downloaded, compiled by an external utility, or written to the filesystem. The database engine executes stored code in-memory within its own process space (oracle.exe).

While this execution technique is not novel—security researcher Marco Ivaldi publicly documented the approach in 2006 with raptor_oraexec.sql—documented instances of in-the-wild exploitation remain rare. Standard Oracle security models require the CREATE PROCEDURE system privilege to create Java schema objects in a user’s own schema, alongside specific Java permissions (such as file-execution rights) administered through Oracle’s DBMS_JAVA package to invoke Runtime.getRuntime().exec(). In this intrusion, the compromised database service account possessed sufficient privileges to complete the entire attack chain.

Breakdown of the ‘khunt’ Post-Exploitation Toolkit

Huntress tracks the post-exploitation toolkit as khunt. The attacker compiled six distinct Java classes into the Oracle schema and exposed their capabilities through matching khunt_* PL/SQL wrapper functions, allowing arbitrary execution via simple SQL queries.

The toolkit comprises the following specialized components:

• KhuntCmd: Acts as an execution channel, launching cmd.exe to run operating system commands passed directly through SQL statements and returning output to the database session.
• KhuntHash: Queries internal database tables (such as SYS.USER$) to extract user accounts and password hashes, writing the credential data to host storage.
• KhuntFS & KhuntFS2: Provide filesystem management functions, allowing attackers to list directory contents, inspect file metadata, search file trees, and calculate file sizes across accessible storage volumes.
• KhuntT: Serves as a reachability test to confirm that the compiled Java objects and PL/SQL wrappers are functional.
• KhuntUnzip: Utility class designed to extract archived files staged on the target system.

Because Oracle Database services on Windows typically run under elevated service privileges, executing cmd.exe /c whoami via KhuntCmd returned NT AUTHORITY\SYSTEM. This instantly converted a web-level SQL injection vulnerability into full host administrative access.

Post-Exploitation and Registry Staging

Once SYSTEM-level execution was established through the database engine, the attackers engaged in credential harvesting and system discovery. Operational commands observed during the incident include:

• Service Enumeration: Executing tasklist /svc and redirecting output to khunttasks.txt to map active processes and running services.
• Registry Hive Harvesting: Executing commands via PowerShell and reg.exe to dump the SYSTEM and SECURITY registry hives, saving the outputs directly to F:\Oracle.
• System File Extraction: Utilizing the native Windows Volume Shadow Copy utility esentutl.exe to duplicate locked system hives, including SAM and SECURITY, into local staging directories.

Huntress confirmed that the extracted credentials and system hives were staged locally in F:\Oracle, though exfiltration could not be definitively established. Network indicators traced the malicious SQL injection requests to IP address 178.162.151[.]229. No specific threat actor group was named in connection with the intrusion.

Remediation and Detection Strategy

Because this attack relies on legitimate Oracle Database capabilities and privilege misconfigurations, no vendor software patch closes the technique itself. Mitigating the risk requires fixing the application-layer vulnerability and enforcing least privilege on the database backend.

Application Defenses

• Parameterized Queries: Refactor all application endpoints communicating via JDBC to use parameterized SQL queries (PreparedStatement objects in Java) rather than dynamic string concatenation.
• Input Sanitization: Implement strict allow-list input validation on all user-supplied data, particularly search fields and autocomplete queries.

Database Hardening

• Enforce Least Privilege: Web application service accounts must never possess administrative or DDL privileges. Revoke CREATE PROCEDURE, CREATE ANY PROCEDURE, CREATE JAVA SOURCE, and administrative grants from database accounts tied to public web interfaces.
• Restrict Java Execution: Audit permissions granted through DBMS_JAVA and strip OS execution rights (java.io.FilePermission and process creation permissions) from non-administrative roles.

Threat Hunting and Detection

• Oracle Schema Inspection: Query the Oracle installation for suspicious objects by searching schema metadata: SELECT OBJECT_NAME, OBJECT_TYPE, CREATED FROM ALL_OBJECTS WHERE OBJECT_NAME LIKE 'KHUNT%' OR OBJECT_NAME LIKE 'Khunt%';
• SQL Audit Logs: Monitor SQL execution logs and statement caches for queries containing KHUNT% or executing CREATE JAVA SOURCE.
• Process Creation Monitoring: Configure EDR solutions to alert whenever the primary Oracle process (oracle.exe) spawns OS command shells or administrative binaries such as cmd.exe, powershell.exe, reg.exe, or esentutl.exe.