A new, extremely dangerous attack method has been identified where hackers hide malware tools directly inside Oracle databases. We at TechNoid analyze how this technique works and what you should change in your architecture immediately.
- The attackers took advantage SQL injection to a public Apache Tomcat endpoint to infiltrate the system.
- Instead of traditional files on the server, they installed the Java toolkit khunt as an object inside the Oracle database.
- Oracle's embedded Java Virtual Machine was abused to execute system commands with SYSTEM privileges.
The mechanism of SQL injection
It all starts with a seemingly innocent search endpoint in a Java application running on Apache Tomcat, Huntress data revealed . The lack of strict input validation in autocomplete fields allows attackers to pass in a SQL payload. According to the logs, the requests were initially detected as coming from the IP address 178.162.151.229. If you haven’t shielded your public web forms, each such form becomes a Trojan Horse for your infrastructure.
Saving malware as a Java object
The hackers' real innovation in this attack is not the SQL injection itself, but the fact that they avoided the classic .exe files or scripts. Taking advantage of Oracle's built-in Java Virtual Machine and the CREATE JAVA SOURCE statement, they stored the khunt tool directly as an object in the database. As Oracle points out in its official documentation for Java management in the database, this feature was designed for ease of development, but not to host post-exploitation toolkits. The toolkit included building blocks such as KhuntCmd for operating system calls and KhuntHash for code extraction.
Risks with SYSTEM privileges
The critical point of failure in such scenarios is the excessive privilege assignment to the web application login accounts. When hackers used KhuntCmd to execute the command cmd.exe /c whoami, they found that the database was running with full SYSTEM privileges on WindowsThis allowed them to copy key Windows registry hives, such as SAM, SECURITY, and SYSTEM, to recover password hashes. Similar vulnerabilities in corporate networks are often analyzed in reports such as Picus whitepaper regarding breach simulation tests.
Our opinion at TechNoid
Storing malware inside the database proves that traditional EDR tools on endpoints are often blindsided by threats that live locked inside databases. We at TechNoid believe that the biggest mistake here is not the SQL injection vulnerability per se, but the lazy architecture that grants administrative privileges to web application accounts. You should immediately implement strict least-privilege policies and remove Java source creation privileges from any public-facing database account. Also read our guide to cloud infrastructure security to shield your endpoints.
Frequently Asked Questions about the khunt malware attack on Oracle
What is the khunt malware toolkit?
This is a set of Java components and PL/SQL wrappers that were installed inside the Oracle database to execute commands and steal credentials.
How did the hackers gain access to the database?
They used a flawed search endpoint in a public Java application via an SQL injection vulnerability.
Why did they store the malware inside Oracle?
To avoid detection by traditional antiviruses, by leveraging the database's built-in Java Virtual Machine.
What rights did the commands that were executed have?
The commands were executed with SYSTEM privileges on the Windows server, allowing access to critical registry files.
What tools did the toolkit include?
It included KhuntCmd, KhuntHash, KhuntFS, KhuntFS2, KhuntT, and KhuntUnzip for file and command management.
Who discovered this attack?
Huntress' security platform detected the credential theft on July 27, 2026.
How can I protect my Oracle database?
Restrict the permissions of application accounts so that they cannot create Java sources or run unnecessary processes.
