KHunt Toolkit Turns Oracle SQL Injection Into SYSTEM-Level RCE and Credential Theft

KHunt shows how a “routine” SQL injection against an Oracle‑backed web app can be weaponized into SYSTEM‑level remote code execution and credential theft by compiling a full post‑exploitation toolkit directly inside the database engine.

This incident materially shifts the Oracle threat model: the database itself becomes attacker infrastructure, not just a data store.

Subsequent triage tied the activity to a SQL injection flaw in a public‑facing Java/Tomcat application using Oracle via JDBC.

The vulnerable autocomplete search feature blindly passed user input into SQL queries, allowing adversaries to issue arbitrary SQL statements via the web front end.

No Oracle CVE was required; classic input mishandling was enough to turn an application bug into database‑host compromise.

Once the attackers had SQL‑level access, they pivoted from data access to code deployment. Leveraging Oracle’s embedded JVM and the CREATE JAVA SOURCE statement.

The threat actor fed Java source code through the Tomcat JDBC connection and had Oracle compile it as schema‑resident Java objects inside the database.

The resulting toolkit, tracked as “khunt,” lived entirely within Oracle as Java classes plus khunt_* PL/SQL wrappers, never touching the filesystem as traditional malware binaries. This database‑resident design sharply reduces visibility for endpoint‑centric EDR and AV that focus on processes, files, and in‑memory artifacts.

KHunt’s modules were purpose‑built for post‑exploitation control and credential operations. KhuntCmd loaded cmd.exe and executed arbitrary OS commands included in SQL statements, providing a direct bridge from SQL to the Windows command shell.

KhuntHash interrogated Oracle’s internal user tables, dumping usernames and password data to disk.

KhuntFS and KhuntFS2 functioned as file explorers, enabling recursive listing, reading, searching, and sizing of files across the host.

KhuntT acted as a “ping” check for toolkit reachability, while KhuntUnzip handled archive extraction. All of these were invoked through khunt_* PL/SQL wrappers, making the malicious functionality look like routine stored procedure calls when viewed purely at the SQL layer.

With the toolkit in place, the actors demonstrated full OS‑level control. Through KhuntCmd they executed cmd.exe /c whoami, confirming that commands launched from Oracle were running as SYSTEM on the Windows server, establishing definitive remote code execution from the database tier to the operating system.

On July 27, 2026, Huntress detected credential‑theft activity on a Windows endpoint hosting Oracle Database, after their telemetry flagged reg.exe hive‑copy operations originating from an oracle.exe parent process.

From there, they used PowerShell and native Windows utilities such as reg.exe and esentutl.exe to copy the SAM, SECURITY, and SYSTEM registry hives to paths under F:\Oracle\, and ran tasklist /svc to inventory running services, saving output as khunttasks.txt.

These hive copies are ideal for subsequent offline extraction and decoding of local account password hashes, representing a clear credential‑theft objective.

KHunt Exposes Credentials

Huntress assessed that the hives were likely staged for exfiltration, even though the investigation did not definitively confirm their removal.This attack also highlights dangerous privilege design in many Oracle environments.

Oracle documentation notes that creating Java schema objects via CREATE JAVA SOURCE in a user’s own schema requires system privileges such as CREATE PROCEDURE/CREATE JAVA, and that Java’s Runtime.exec runs under the Oracle service account unless DBAs deliberately constrain it.

In this case, the application’s database account appears over‑privileged: SQL injection reached an identity capable of authoring Java sources and exposing them via PL/SQL, and the underlying Oracle service was configured such that spawned processes executed with SYSTEM‑level rights on Windows.

For defenders, the KHunt incident carries several hard lessons. First, “legacy” SQL injection remains a viable entry point when public‑facing apps still concatenate unsanitized input into queries; robust input validation and parameterized queries are non‑negotiable.

Second, least privilege must extend to database accounts used by internet‑facing applications: they should not be able to create Java sources, execute arbitrary stored procedures, or touch administrative schemas.

Finally, Oracle itself must be treated as a potential staging ground for malware. Detection and response should include searching the data dictionary for unfamiliar Java source/class objects and khunt‑like naming patterns, auditing DDL and Java policy changes.

Huntress has published a detailed technical breakdown of this intrusion, including IOC paths, module behavior, and mitigation guidance, and acknowledges Lindsey O’Donnell‑Welch for her contributions to the investigation and public write‑up.

For organizations running Oracle behind Java/Tomcat front ends, this case is a timely reminder: if SQL injection can reach a privileged database account with Java capabilities, your “database tier” can quietly become the attacker’s RCE platform.

Indicators of Compromise (IOCs)

Item	Description
[drive:][path]\Oracle\khuntSECURITY.hiv[drive:][path]\Oracle\khuntSYSTEM.hiv[drive:][path]\Oracle\khuntSAM.hiv[drive:][path]\Oracle\khunt_SECURITY.hiv	Registry files dumped by the attacker.
[drive:][path]\Oracle\khunttasks.txt	Text file containing a list of tasks.
178.162.151[.]229	Attacker IP address.
KhuntTKhuntFSKhuntFS2KhuntCmdKhuntHashKhuntUnzip	Search within the Oracle installation for object_name instances that match these names.
KHUNT%	Search SQL logs for this string.

Why use the 2026 Agentic SOC Buyer’s Guide? 8 Best Platforms Compared – Download the 2026 Buyer’s Guide