"The use of the technique in the wild has rarely been documented," Huntress said.
How khunt lived inside Oracle's embedded JVM
Attackers exploited a SQL injection vulnerability in a public-facing web application to feed Java source code directly into an Oracle database and compile it into stored schema objects. Oracle ships an embedded Java Virtual Machine and supports the CREATE JAVA SOURCE statement, which allows supplied Java code to be compiled and retained as database schema objects. Huntress tracked a toolkit it calls khunt that comprised six Java objects and several khunt_* PL/SQL wrappers; together they turned database-stored Java into a post-exploitation toolkit.
The Java objects in this campaign had explicit, named roles: KhuntCmd executed cmd.exe and ran arbitrary operating-system commands provided via SQL; KhuntHash read Oracle internal user tables and wrote usernames and password hashes to a file; KhuntFS and KhuntFS2 provided file-listing and reading capabilities; KhuntT served as a reachability check; and KhuntUnzip unpacked archives. The architecture follows a pattern documented at least as far back as 2006 and mirrors a prior tool, raptor_oraexec.sql, but Huntress says real-world use has seldom been publicly observed.
From SQL injection to SYSTEM: the attack chain
Huntress began its investigation after credential-theft detections fired on July 27, 2026, and linked the activity to SYSTEM-level code execution on the Windows server hosting Oracle. The vulnerable application used an autocomplete search field that passed unvalidated input to the database via a JDBC connection. The database account behind that connection had sufficient privilege to create Java objects and to execute the compiled code; Huntress does not say which specific grants the account held or whether the attackers added privileges, only that the chain succeeded.
KhuntCmd was used to run cmd.exe /c whoami and returned SYSTEM. From that privilege level the attackers ran PowerShell and reg.exe to copy the SECURITY and SYSTEM registry hives into F:\Oracle, ran tasklist /svc and saved output to khunttasks.txt, and used esentutl.exe to copy the SAM and SECURITY hives. Huntress observed the files staged locally but did not establish they were exfiltrated. The malicious requests traced to 178.162.151[.]229; Huntress named no threat actor.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleHuntress's indicators and detection gaps
Huntress recommends searching the Oracle installation for object names beginning with Khunt and scanning SQL logs for entries matching KHUNT% as immediate indicators of compromise. The firm emphasizes a key detection gap: a Java class compiled into an Oracle schema object is neither a process nor a binary on disk, and endpoint detection and response products typically do not inspect Oracle's internal object store. In Huntress's framing, the database ceases to be merely a queried repository and becomes a beachhead attackers operate from inside the DB engine.
Oracle documentation sets the privilege requirement for creating Java source in a user's own schema at a single system privilege, CREATE PROCEDURE, and states that spawning an operating-system process from that code goes through Runtime.exec and requires a separate file-execution permission normally granted only by privileged administrators. Huntress did not report any Oracle patch that closes the application vulnerability or the account privilege it exploited.
What this means for technologists and security teams
- Search for Khunt object names and KHUNT% log entries right away, and inspect Oracle schema objects for unexpected Java sources.
- Recognize that typical EDR workflows may miss in-DB Java code; monitoring strategies must include database object audits and SQL-log analysis rather than relying solely on filesystem/ process telemetry.
What this means for application owners and procurement leaders
- Fix the application: parameterized queries and input validation in the autocomplete/search field are the direct remediation Huntress prescribes to stop this attack vector.
- Apply least-privilege principles: accounts used by public-facing applications should not hold privileges to author Java sources or run stored procedures they do not require.
The incident is a blunt reminder that attack surface can move upward, from web front end into the database engine itself. With no vendor patch cited that eliminates both the application flaw and the privileged account misuse, the immediate defense rests on code hygiene, account privilege reviews, and database-object visibility. Huntress's finding—activity tied to 178.162.151[.]229 and credential-theft alerts beginning July 27, 2026—leaves a concrete trail for defenders to follow and a clear, if uncomfortable, lesson: when databases compile code internally, they can become active platforms for adversaries.
