khunt Weaponizes Oracle's Embedded JVM to Run Post-Exploitation Toolkit from Inside the Database

July 27, 2026, somewhere in a SOC. Huntress’s platform flags a credential theft alert on a server hosting an Oracle Database. The investigation team expects routine credential dumping. They find something far worse: a full post-exploitation toolkit — named khunt — compiled and running inside the Oracle database itself, via the embedded JVM.

August 5, 2026, the public report drops. Lawrence Abrams at BleepingComputer details the attack chain. For DBAs, it is a rude awakening: your database is a complete application runtime. Attackers figured that out before you did.

The Attack Chain: From SQL Injection to a SYSTEM Shell

The attack, dissected by Huntress, follows a surgical progression:

1. Entry point. A public-facing Java application, hosted on Apache Tomcat, exposes a search endpoint with autocomplete functionality. Input validation is absent.
2. SQL injection. Attackers inject SQL commands through the search field, gaining access to the underlying Oracle database.
3. Payload deployment. Using the CREATE JAVA SOURCE statement — a legitimate Oracle feature that stores and compiles Java code as a schema object — the attackers deploy khunt directly inside the database.
4. OS execution. Oracle runs the Java code through its embedded Aurora JVM. khunt’s PL/SQL wrappers invoke cmd.exe with SYSTEM privileges on the underlying Windows server.
5. Credential theft. KhuntHash dumps Oracle’s internal user table. cmd.exe /c whoami confirms SYSTEM privileges. The SAM, SECURITY, and SYSTEM registry hives are copied for offline NTLM hash extraction.

“The use of the technique in the wild has rarely been documented,” Huntress noted.

The malicious IP address, 178.162.151[.]229, was traced through Apache logs. But the alert came late: the toolkit was already entrenched.

khunt: The Swiss Army Knife of Oracle Post-Exploitation

The khunt toolkit comprises six Java components, each with a dedicated function:

The attackers used KhuntCmd to run a whoami, confirming SYSTEM privileges, then followed up with PowerShell to copy registry hives and tasklist /svc to enumerate running services.

None of this required dropping an executable file onto the server’s disk. All malicious code lived inside the database itself.

Oracle’s Embedded JVM: Feature or Backdoor?

The centerpiece of this attack is Oracle’s embedded Java Virtual Machine (Oracle JVM, formerly Aurora JVM). This feature, enabled by default in many configurations, allows:

• Storing Java source code as a database object (CREATE JAVA SOURCE)
• Compiling and executing it inside the Oracle process
• Interacting with the operating system through Java stored procedures

The embedded JVM is a powerful tool for developers — it allows extending Oracle with business logic in Java without an external application server. But in an attacker’s hands, it is a native exfiltration runtime that leaves no disk footprint.

Huntress explicitly recommends that database accounts used by public-facing applications should not have sufficient privileges to create Java sources, execute unnecessary stored procedures, or perform administrative actions.

Concrete Actions for DBAs and DevOps Teams

This attack does not exploit an Oracle zero-day. It exploits misconfiguration and missing input validation at two successive layers. Here is what teams need to do:

1. Disable or Restrict the Embedded JVM

-- Check if the JVM is installed
SELECT comp_name, version, status FROM dba_registry WHERE comp_name LIKE '%JAVA%';

-- Revoke Java creation privileges from application accounts
REVOKE CREATE PROCEDURE, CREATE ANY PROCEDURE FROM app_user;
REVOKE EXECUTE ON DBMS_JAVA FROM app_user;

If your application does not use Java stored procedures, disable the embedded JVM entirely.

2. Harden Input Validation at the Application Layer

The initial SQL injection came from an autocomplete field — the kind of endpoint teams often consider “low risk.” Every user input reaching a database must be parameterized:

// ❌ Concatenation — vulnerable
String query = "SELECT * FROM products WHERE name LIKE '%" + userInput + "%'";

// ✅ PreparedStatement — protected
PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM products WHERE name LIKE ?"
);
ps.setString(1, "%" + userInput + "%");

3. Enforce Least Privilege on Database Accounts

The Oracle account used by the application must never have CREATE JAVA, CREATE ANY PROCEDURE privileges, or the DBA/JAVA_ADMIN roles. Use a dedicated account with only the SELECT, INSERT, UPDATE, DELETE privileges on required tables.

4. Monitor Suspicious Java Object Creation

-- Monitor recent Java object creation
SELECT object_name, object_type, created, status
FROM dba_objects
WHERE object_type = 'JAVA SOURCE'
AND created > SYSDATE - 30;

Verdict

khunt is not the first database-embedded post-exploitation toolkit, but it is one of the few publicly documented. It underscores a truth too many DevOps teams ignore: an Oracle database is a full application runtime, not a simple data store.

If you manage an Oracle database accessible from a web application, verify today that:

1. Input validation is parameterized on all endpoints, including “innocuous” features like autocomplete.
2. The application database account cannot create Java sources.
3. The embedded JVM is disabled if unused, or restricted to admin accounts only.

If you run Apache Tomcat as a frontend, audit publicly exposed endpoints — that is the entry point that enabled this compromise.

References

• BleepingComputer, Hackers run khunt post-exploitation toolkit from Oracle database, August 5, 2026 — https://www.bleepingcomputer.com/news/security/hackers-run-khunt-post-exploitation-toolkit-from-oracle-database/
• Huntress investigation report, August 5, 2026
• Oracle Documentation, Oracle Database Java Developer’s Guide — Embedded JVM and CREATE JAVA SOURCE chapter