Hackers Deploy 'khunt' Post-Exploitation Toolkit Inside Oracle Databases

Attackers have been observed leveraging a SQL injection vulnerability in a public-facing Java web application to deploy a custom post-exploitation framework directly inside an underlying Oracle database. Discovered by Huntress, the intrusion demonstrates how threat actors abuse legitimate, built-in database features—specifically Oracle’s embedded Java Virtual Machine (JVM)—to achieve arbitrary command execution on the host operating system without dropping traditional executable binaries onto disk.

The entry point for the compromise was a public-facing Java application running on Apache Tomcat. Apache access logs revealed that the application failed to sanitize user-supplied input within an autocomplete search endpoint. This flaw allowed attackers operating from IP address 178.162.151[.]229 to inject arbitrary SQL statements through the web application straight into the backend Oracle database server.

Executing Code via Oracle’s Embedded JVM

Rather than attempting to drop web shells or standalone malware executables directly onto the underlying web server file system, the attackers directed their post-exploitation activity into the database engine itself. Oracle databases include an embedded Java Virtual Machine (JVM) designed to allow developers to run Java code directly inside the database process. Using SQL injection, the attackers executed SQL statements containing CREATE JAVA SOURCE commands.

This functionality allows raw Java source code to be compiled and stored as native database schema objects. Once compiled inside the database schema, these Java objects can be exposed as PL/SQL procedures and invoked through standard SQL commands. If the database user account executing the statements possesses adequate privileges within Oracle’s Java permissions framework, the underlying Java code can break out of the database context and invoke operating system shell commands on the hosting server.

Because the Java code resides inside the Oracle database schema rather than as a file on the host file system, traditional Endpoint Detection and Response (EDR) solutions monitoring local disk activity often miss the initial staging phase.

Breakdown of the ‘khunt’ Post-Exploitation Framework

The post-exploitation toolkit, named khunt by researchers, consists of multiple Java components paired with PL/SQL wrapper functions. Each component in the modular toolkit targets a specific post-exploitation function:

• KhuntCmd: Acts as an OS command bridge. By invoking this component via SQL queries, the attackers forced the host operating system to launch cmd.exe and execute commands directly on the server host.
• KhuntHash: Targets Oracle internal user management. This module queries Oracle’s internal user tables to pull account credentials and writes user password data out to a file for offline cracking or credential theft.
• KhuntFS and KhuntFS2: Function as a lightweight file system manager. These modules provide the attackers with directory browsing, file reading, file searching, and file size checking capabilities across the server host.
• KhuntT: Serves as an installation validation test. The attackers used this ping-like check to confirm that the Java objects had compiled successfully and were ready to process commands inside the database.

Escalation to Host Registry Copying and SYSTEM Access

After compiling the khunt toolkit, the attackers used KhuntCmd to run cmd.exe /c whoami. The output confirmed that the Oracle database service was running under the Windows SYSTEM account, granting the SQL injection payload full administrative permissions over the host operating system.

With elevated execution rights confirmed, the attackers leveraged PowerShell and native Windows administration tools to copy sensitive registry hives from the system:

• SAM (Security Account Manager)
• SECURITY
• SYSTEM

Copying these hives allows threat actors to extract local Windows account password hashes for offline brute-forcing or lateral movement across the enterprise network. Additionally, the attackers ran tasklist /svc to enumerate all running processes and service dependencies on the host, saving the output directly to a file named khunttasks.txt.

While credential exfiltration was not explicitly confirmed in the initial triage, extracting the SAM and SYSTEM registry hives strongly indicates an intent to establish persistent access or move laterally into the broader Windows environment.

Mitigating Database JVM Execution Risks

This attack highlights the severe blast radius when application service accounts are granted excessive administrative rights inside backend databases.

Organizations running public-facing Java applications connected to Oracle databases should implement the following targeted controls:

• Input Sanitization: Parameterize all database queries across web endpoints, specifically within autocomplete, search, and filter features running on Apache Tomcat or similar Java web containers.
• Database Least Privilege: Restrict application service accounts used by web applications so they cannot execute CREATE JAVA SOURCE, CREATE PROCEDURE, or access administrative packages such as DBMS_JAVA. Application database accounts should never possess DBA-level roles or system-level privileges.
• Operating System Isolation: Ensure that the Oracle database service runs under a dedicated, low-privileged local service account rather than NT AUTHORITY\SYSTEM or LocalSystem. Restricting service permissions prevents an attacker from automatically inheriting host-level administrative control if a database execution flaw is exploited.
• Database JVM Hardening: Disable Oracle’s embedded JVM component entirely if business applications do not explicitly require Java stored procedures.