khunt: SQL Injection to Resident Threat Inside Oracle Database Stealing Credentials with SYSTEM Privileges

On August 5, 2026, the cybersecurity firm Huntress warned of a high-severity threat involving SQL injection attacks on Oracle databases. The breach began when hackers exploited a vulnerability in the autocomplete search feature of a public Java/Tomcat application. By injecting malicious SQL code, the attackers gained access to the database and used it to deploy a persistent toolkit.

The attack chain began with the exploitation of the web application's SQL injection vulnerability. The attackers sent crafted input to the Java/Tomcat autocomplete endpoint, exploiting poorly validated parameters and improper use of parameterized queries. This allowed the SQL injection to reach the Oracle database through a JDBC connection.

Once inside the database, the attackers used Oracle's CREATE JAVA SOURCE command to save and compile the malicious code, named "khunt," as a database schema object. This allowed the attackers to keep the toolkit resident within the database, rather than as a standalone executable file. The toolkit included various utilities such as KhuntCmd, KhuntHash, KhuntFS, and others, all designed to facilitate further exploitation.

The attackers then pivoted from the Oracle database to the Windows operating system. They used the KhuntT utility to check the toolkit's installation and connectivity. Next, KhuntCmd executed the command 'whoami' to verify that the oracle.exe process had SYSTEM privileges. Subsequently, KhuntFS and KhuntFS2 were used to enumerate and search the filesystem, while KhuntHash extracted usernames and passwords from the internal Oracle user table.

The attackers also staged Windows credentials by copying the SECURITY and SYSTEM hives using reg.exe, and extracting the SAM and SECURITY hives using esentutl.exe. These files were saved in the Oracle install/data drive paths. While it is not confirmed that the data was exfiltrated, the staging of these files indicates a strong intent to retrieve sensitive information.

Upon successful execution of the attack, the Oracle database transformed into a beachhead for OS attacks. The attackers gained SYSTEM privileges, allowing them to execute commands, perform service discovery, explore the filesystem, obtain Oracle credentials, and even dump Windows local account hashes. The malicious toolkit persisted even after the initial SQL injection vulnerability was patched, posing a significant ongoing threat.

The attack was observed primarily through abnormal HTTP requests to the public Java/Tomcat application, repeated requests from a specific external IP (178.162.151[.]229), and unusual endpoint activity involving oracle.exe spawning cmd.exe, PowerShell, reg.exe, and esentutl.exe. However, due to the nature of the toolkit being a database object rather than an executable, traditional endpoint detection and response (EDR) and antivirus (AV) tools may not have detected the initial deployment.