Attackers broke into an organization's Oracle database through a SQL injection flaw in a public-facing web application. Then they installed a post-exploitation toolkit without writing a single executable to disk.
They fed Java source code to the database, let Oracle compile it into stored schema objects, and ran commands from inside the database engine.
Huntress, which tracks the toolkit as khunt, investigated after credential-theft detections fired on July 27, 2026. The firm traced the chain to SYSTEM-level code execution on the underlying Windows server.
The Oracle khunt post-exploitation toolkit represents a sophisticated approach to post-compromise activity. Since the entire attack took place inside the Java Virtual Machine of Oracle, the attackers bypassed any sort of file-based detection methods. Here is how this attack worked and what defenders need to know.
The Initial Access Vector
The Oracle khunt post-exploitation toolkit attack began with a SQL injection flaw in the organization's public-facing web application. An autocomplete search field passed unvalidated input to the database over a Java Database Connectivity connection. The account behind that connection had enough privilege to create Java objects.
No Oracle patch closes either the application flaw or the account privilege behind it. The vulnerability was in the application code, not in Oracle itself. Fixing it requires parameterized queries and input validation in the application, plus least privilege enforcement for database accounts.
How the Oracle Khunt Post-Exploitation Toolkit Works
The Oracle khunt post-exploitation toolkit leverages a built-in Oracle feature. Oracle ships an embedded Java Virtual Machine. The CREATE JAVA SOURCE statement lets a user hand it Java code that the database compiles and stores as a schema object.
In a user's own schema, Oracle's documentation puts the bar at a single system privilege: CREATE PROCEDURE. Spawning an operating-system process from that code runs through Runtime.exec, which needs its own file-execution permission. Oracle says those are issued only by privileged administrators.
Huntress does not say which grants the compromised account held, or whether the attackers had to add any. The chain succeeded, so it had enough for both. The key insight is that no executable file ever touched the filesystem. The malware lived entirely as compiled Java objects inside the database.
The Khunt Toolkit Components
Six Java objects and several khunt_* PL/SQL wrappers made up the Oracle khunt post-exploitation toolkit:
- KhuntCmd: Loaded cmd.exe and ran arbitrary operating-system commands passed in as SQL
- KhuntHash: Read usernames and password hashes from Oracle's internal user table and wrote them to a file
- KhuntFS and KhuntFS2: Listed, read, searched, and sized files
- KhuntT: Confirmed the toolkit was reachable
- KhuntUnzip: Unpacked archives
Each component served a specific purpose in the post-exploitation chain. KhuntCmd provided command execution. KhuntHash extracted credentials. The filesystem components enabled reconnaissance. KhuntT served as a reachability check. KhuntUnzip allowed payload extraction.
The Post-Exploitation Activity
Running cmd.exe /c whoami through KhuntCmd returned SYSTEM. This confirmed the attackers had achieved the highest privilege level on the underlying Windows server.
The attackers then used PowerShell and reg.exe to copy the SECURITY and SYSTEM registry hives into F:\Oracle. They ran tasklist /svc into khunttasks.txt and copied the SAM and SECURITY hives with esentutl.exe. These actions are consistent with credential theft and system reconnaissance.
Huntress observed the files being staged locally but did not establish that they were exfiltrated. The firm named no threat actor and traced the malicious requests to 178.162.151[.]229.
The Technique Is Not New
The technique behind the Oracle khunt post-exploitation toolkit is at least two decades old. Marco Ivaldi's raptor_oraexec.sql, dated 2006, creates an Oracle source object with command-execution and file-read methods. It then publishes them to SQL through PL/SQL wrappers.
The khunt objects use the same basic architecture. "The use of the technique in the wild has rarely been documented," Huntress said. This suggests that while the technique is known, active exploitation has been uncommon, until now.
Why Traditional Detection Fails
The Oracle khunt post-exploitation toolkit is difficult to detect because it leaves no traditional traces. A Java class compiled into a database schema object is not a process, a binary, or a file on the filesystem. Endpoint detection and response products do not generally inspect Oracle's internals.
As Huntress frames it, the database stops being something attackers query and becomes a beachhead they attack from. The attackers used the database engine itself as their execution environment and command channel.
Finding the Oracle khunt post-exploitation toolkit requires specific hunting techniques. Search the Oracle installation for object names beginning with Khunt. Search SQL logs for KHUNT%. These indicators are specific to this toolkit, so no generic search will surface the technique behind it.
What This Means for Defenders
The Oracle khunt post-exploitation toolkit attack highlights several important lessons for defenders.
- First, application vulnerabilities matter. The SQL injection flaw was the entry point. Parameterized queries and input validation are essential controls for any public-facing web application.
- Second, least privilege is critical. The account serving a public-facing app should not be able to author Java sources or run stored procedures it has no reason to touch. Restrict database account privileges to the minimum needed for the application's function.
- Third, monitor Oracle internals. Traditional EDR tools will not detect activity inside the Oracle database. Consider specialized monitoring for unusual Java object creation, PL/SQL wrapper activity, and command execution from within the database.
- Fourth, hunt for known indicators. Look for object names beginning with Khunt and KHUNT% in SQL logs. These are the fingerprints of the Oracle khunt post-exploitation toolkit.
The Broader Context
The Oracle khunt post-exploitation toolkit attack is an example of the trend towards fileless malware. The attackers have avoided writing executable files to disk in order to avoid detection.
The Oracle Java Virtual Machine offers a very capable runtime environment, which is often not utilized by the security teams. The database is trusted, and its internal activity is not typically monitored with the same rigor as the operating system.
Organizations running Oracle databases should consider this attack as a reminder of the risks. The database is not just a data store. It is a potential execution environment for attackers.
Wrapping It Up
Oracle khunt post-exploitation toolkit attack highlights a sophisticated approach of post-compromise activity. The Attackers took advantage of the SQL injection vulnerability for initial access and used the JVM that comes along with Oracle to run the payload without placing any files to the disk.
Khunt had command execution, credentials harvesting, file system access, and other capabilities. The Attackers were able to get SYSTEM-level code execution on the underlying Windows server.
Detection requires hunting for specific indicators in Oracle logs and database objects. The fix requires application-level input validation and least privilege enforcement.
The Oracle khunt post-exploitation toolkit is a reminder that the database is not just a target. It is an attack platform. Defenders need to extend their monitoring and controls into the database itself.
FAQ Section
What is the Oracle khunt post-exploitation toolkit?
Khunt is a post-exploitation toolkit that runs entirely inside Oracle's database engine. Attackers feed Java source code to Oracle, which compiles it into stored schema objects. No executable file is ever written to disk.
How did attackers gain initial access?
Attackers exploited a SQL injection flaw in a public-facing web application. An autocomplete search field passed unvalidated input to the database over a JDBC connection. The account behind that connection had enough privilege to create Java objects.
What components make up the khunt toolkit?
The toolkit includes KhuntCmd (command execution), KhuntHash (credential theft), KhuntFS/KhuntFS2 (file system access), KhuntT (reachability check), and KhuntUnzip (archive extraction). All are compiled Java objects stored in the database.
How can defenders detect the khunt toolkit?
Search the Oracle installation for object names beginning with Khunt. Search SQL logs for KHUNT%. Traditional EDR products will not detect the toolkit because it leaves no files on disk.
How can organizations protect against this attack?
Use parameterized queries and validate inputs in web applications. Apply least privilege to database accounts. Monitor Oracle internals for unusual Java object creation and PL/SQL wrapper activity. No Oracle patch closes the underlying application flaw.
