Hackers run khunt post-exploitation toolkit from Oracle database
Summary
A corporate network was breached via a vulnerable search engine endpoint in a public-facing Java application running Apache Tomcat. The flaw existed in an autocomplete feature that failed to validate user input, allowing attackers to issue arbitrary SQL commands to the backend Oracle database.
The intrusion was detected on July 27, 2026, by Huntress after its platform identified credential theft occurring on a server hosting the Oracle instance. Attackers used the access to deploy a specialized toolkit named khunt, which resided entirely as Java objects within the database schema rather than as traditional executable files on the file system.
What happened
After gaining entry through the SQL injection flaw, attackers targeted the Oracle database's embedded Java Virtual Machine. They utilized the CREATE JAVA SOURCE statement to compile and store several malicious components directly into the database. This technique allows code to be executed via SQL commands, which can potentially interact with the host operating system if configured correctly.
The toolkit, dubbed khunt, consists of multiple specialized Java components and PL/SQL wrappers designed for post-exploitation tasks:
KhuntCmd: Launchescmd.exeto execute operating system commands through SQL statements.KhuntHash: Accesses internal Oracle user tables to write usernames and password data to a file.KhuntFSandKhuntFS2: Provides capabilities for browsing, reading, searching, and checking the size of files.KhuntT: A ping-like utility used to verify successful toolkit installation.KhuntUnzip: Used for extracting compressed files.
The attackers tested their access by running cmd.exe /c whoami, which confirmed that commands executed through the Oracle database carried SYSTEM-level permissions on the Windows server.
Technical details
The attack chain involved moving from a web application vulnerability to full system control via the database layer. Once the attackers established command execution, they used PowerShell and native Windows utilities to target sensitive credential files.
Specifically, the attackers attempted to copy the SAM, SECURITY, and SYSTEM registry hives. These files are critical for recovering password hashes from local Windows accounts. Additionally, the attackers ran tasklist /svc to enumerate running services, saving the resulting output to a file named khunttasks.txt.
While the presence of these files suggests an attempt to exfiltrate credentials for dumping, it has not been confirmed if the data successfully left the environment. The malicious requests were traced back to the IP address 178.162.151[.]229.
Why this matters for defenders
This incident highlights a sophisticated method of maintaining persistence and executing commands that bypasses traditional file-based detection. By storing the toolkit as Java objects within the database schema, attackers can evade security tools looking for suspicious executable files on the disk.
The use of high-privilege database accounts to facilitate these attacks is a critical failure point. If an application's database user has the permission to create Java sources or execute administrative procedures, a single SQL injection vulnerability can escalate into full host compromise.
Defender guidance
To mitigate the risk of similar post-exploitation techniques, implement the following controls:
- Enforce Least Privilege for Database Accounts: Ensure that accounts used by public-facing applications do not have permissions to run
CREATE JAVA SOURCE, execute administrative stored procedures, or perform any other high-level schema modifications. - Sanitize All User Input: Implement strict input validation on all web application endpoints, particularly those involving search features or autocomplete functions that interact with backend databases. �
- Monitor Database Schema Changes: Watch for the creation of new Java objects or unexpected changes to database schemas, which may indicate the deployment of in-memory toolkits.
Sources
